Yes, leave it blank. On Wed, Nov 14, 2012 at 11:46 AM, Campbell, Paul (Paul) <p...@avaya.com>wrote:
> ** > > 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**** > > ** ** > > ** ** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > _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"
