Leave the Push Fields criteria blank. The arserver process has logic in it so that if you are doing a push fields with no Push-If criteria and the push is set to If no Records match Create New Record / If any records match Take No Action then don't even check the database, just create a new record.
Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Campbell, Paul (Paul) Sent: Wednesday, November 14, 2012 11:46 AM To: arslist@ARSLIST.ORG Subject: Re: HUMONGOUS table ** How do you set the criteria, do you leave it blank? Paul Campbell | Development Team Lead | TS&D SSBL, A2R WFE, and ESP Remedy Team | Avaya Client Services | | 1145 Sanctuary Parkway Lake View II Suite 110 Alpharetta, GA 30009 | 678-421-5342 Everyone needs deadlines. Even the beavers. They loaf around all summer, but when they are faced with the winter deadline, they work like fury. If we didn't have deadlines, we'd stagnate. Walt Disney From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, November 14, 2012 11:11 AM To: arslist@ARSLIST.ORG Subject: Re: HUMONGOUS table ** 1=0 (or any other always FALSE result) was no longer needed as of ARS 5.1.x. That is when I started removing all the 1=0 triggers. A quick and easy method to knock down the table is to use Oracle directly. I use TOAD and right click to rebuild the table. When TOAD builds the SQL for you, edit it and add in a reasonable where clause (Yes you can even use a WHERE 1=0 clause). This way you will have a T12345 and a T12345x table (so you don't lose data). You could then move records from the old "x" table over as you need to. This method should take about 10 seconds. Something else you should also do (I think 6.3 had this) is to turn off the Status-History on the Audit Trail (as records in it are only created and never modified). That drops you from 2 commits down to 1 for each entry. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II Sent: Wednesday, November 14, 2012 9:04 AM To: arslist@ARSLIST.ORG 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
