Hi,
Truncating this with the API will take a lot of time.
You could do this to truncate it completely:
1. Export Form-defs with directly related objects
2. Delete the form
3. Import Form-defs again
You can also use RRR|Chive to truncate the table, and it chunks things
automatically. If you have Linux/Solaris you can do it in one go, but the
windows 32 bit binary you have to do it in chunks:
This will export everything more than 7 years old. After that you can do
6, 5, ... up to the point you like.
source_server = myserver
source_user = Demo
source_password =
target_arx = auditdump.arx
multipleforms = Audit Form
qual = '3' < $DATE$ - 7*365*24*60*60
splitsearch = YES
transfertype = MOVE
logfile = AUTO
progressbar = YES
Not that this will NOT result in a table scan.
It will be slow, but there is nothing much you can do about that. And slow
also means that the impact on the server is low.
Best Regards - Misi, RR AB, http://rrr.se
> Thanks Ben!
>
>
> On Fri, Nov 16, 2012 at 12:14 PM, Ben Chernys <
> [email protected]> wrote:
>
>> Meta-Update will do it in any chunks you like. No need to build an API
>> program when there's a simple way to use the API to do what you want.
>> Trial licenses are unrestricted and are free. So you could clean the
>> table
>> free of charges :)
>>
>> Cheers
>>
>> Ben Chernys
>> Senior Software Architect
>>
>>
>> Canada / Deutschland
>> Mobile: +49 171 380 2329 GMT + 1 + [ DST ]
>> Email: Ben.Chernys_AT_softwaretoolhouse.com
>> Web: www.softwaretoolhouse.com
>>
>> We are a BMC Technology Alliance Partner
>>
>> Check out Software Tool House's free Diary Editor and out Freebies
>> Section for a ITSM 7.6.04 and 8.0.0 Fields spreadsheet.
>>
>> Meta-Update, our premium ARS Data tool, lets you automate
>> your imports, migrations, in no time at all, without programming,
>> without staging forms, without merge workflow.
>> http://www.softwaretoolhouse.com/
>>
>>
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[email protected]] On Behalf Of Longwing, LJ CTR MDA/IC
>> Sent: November-14-12 16:50
>> To: [email protected]
>> Subject: Re: HUMONGOUS table
>>
>> Warren,
>> I can verify that he 1=2 nomenclature, as late as 7.6.04 triggers a
>> table
>> scan in SQL Server 2008. My recommendation would actually be to setup a
>> new
>> thread for the escalation server, and put an escalation on that new
>> thread
>> configured to cut the size of the audit log down to a manageable size,
>> and
>> let it run. The nature of the escalation server will make it so that
>> the
>> server will be busy, yes, but not so busy as to take it down, the fact
>> that
>> it's running on its own thread will mean that none of your other
>> escalations
>> will be impacted...it'll likely take many days to cut the numbers down,
>> but
>> it'll do it properly.
>>
>> The only other suggestion involves building an api app that'll do it in
>> chunks 'periodically', but that may not be an option for you.
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[email protected]] On Behalf Of Warren R. Baltimore II
>> Sent: Wednesday, November 14, 2012 8:04 AM
>> To: [email protected]
>> Subject: HUMONGOUS table
>>
>> **
>> ARS 6.3 patch 16
>> ITSM 5.5
>> Oracle 10
>> Solaris
>>
>> I've got an audit trail table that has been quietly working for about 8
>> years now. We started seeing an issue about a month ago that is related
>> to
>> our AST:Asset table. Whenever a change is made and someone is
>> associated
>> with an asset, the system grinds to a halt. Usually, the change will
>> timeout, but it will update.
>>
>> The problem is that at least once a day (usually in the morning) we will
>> get
>> a malloc error. For some reason, the server is not recycling itself
>> when
>> this happens so I have to do it.
>>
>> I've run all sorts of logs, and have come to the conclusion that it's
>> the
>> push field to the audit file that is causing the problems.
>>
>> The Filter was built using the old 1=0 trigger. I believe that this is
>> triggering a table scan against the Audit Trail. The Audit Trail was
>> never
>> built to clean itself up and it has over 57 MILLION records!
>>
>> Anybody have any idea on a quick, easy, surgical method for knocking
>> this
>> thing down to a more manageable size without killing my server?
>>
>> Also, I know that in later versions, the need to use 1=0 went away. Any
>> ideas if it was still neccesary in 6.3? I've tried the alternate
>> method,
>> but have not had success.
>>
>> Thanks in advance!
>>
>> --
>> Warren R. Baltimore II
>> Remedy Developer
>> 410-533-5367
>>
>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>>
>>
>> ____________________________________________________________________________
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12
>> www.wwrug12.com ARSList: "Where the Answers Are"
>>
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>
>
>
> --
> Warren R. Baltimore II
> Remedy Developer
> 410-533-5367
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
