Schedule execution of oncheck commands

Hello, friends. We´re on IDS 11.50.FC4 on a linux_64 environment. On our old instances (9.40), we had a script to run regularly, some oncheck commands on our instance. Does it applies also to the 11.50 version? Is it needed to execute on a regular basis, or not? Thanks and regards. -- Alexandre Marini Tecnologia da Informação - DBA SEFAZ-MS / SGI-UIMP / Sistemas IBM-Informix IIUG Member <http://www.iiug.org>;

Alexandre Marini wrote: > Hello, friends. > We´re on IDS 11.50.FC4 on a linux_64 environment. > On our old instances (9.40), we had a script to run regularly, some > oncheck commands on our instance. > > Does it applies also to the 11.50 version? Is it needed to execute on a > regular basis, or not? Possibly. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

The straight answer is that it was NEVER necessary, just prudent. Honestly, I'm not a big fan of running onchecks frequently. Partly the attitude is a throwback to the 7.xx days when all onchecks locked the object being checked, so we didn't have much of a window when it was safe to run onchecks. Partially, it's a matter of faith that IDS doesn't corrupt its data on disk very often and partially insistence that it should NEVER get corrupted - after all what are we paying all those support $$ for otherwise? Finally, the attitude is mostly because I rarely find anything wrong, which I assume matches with your own experiences. If the engine says there's a problem, or if I suspect one, that's the time I'll run the onchecks. Exception? I like to have an oncheck -pe output report and a dbschema/myschema output report (for each database) available on disk in case I have to recover data manually from an archive or from catastrophically damaged disks (either using archecker, my own recovery tools, or be calling tech support). I do want to have those reports periodically (the oncheck -pe weekly and the schema updates whenever the live schema is modified). Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Oct 6, 2009 at 10:29 AM, Alexandre Marini <amarini@fazenda.ms.gov.br > wrote: > Hello, friends. > We´re on IDS 11.50.FC4 on a linux_64 environment. > On our old instances (9.40), we had a script to run regularly, some > oncheck commands on our instance. > > Does it applies also to the 11.50 version? Is it needed to execute on a > regular basis, or not? > > Thanks and regards. > -- > > Alexandre Marini > > Tecnologia da Informação - DBA > > SEFAZ-MS / SGI-UIMP / Sistemas IBM-Informix > > IIUG Member > > <http://www.iiug.org>; > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --0023545bf548f9c4e3047545ac6d

Ok Mr. Art! That solved all my doubts, really. Thanks for your attention. Alexandre Marini Tecnologia da Informação - DBA SEFAZ-MS / SGI-UIMP / Sistemas IBM-Informix IIUG Member <http://www.iiug.org>; Art Kagel escreveu: > The straight answer is that it was NEVER necessary, just prudent. Honestly, > I'm not a big fan of running onchecks frequently. Partly the attitude is a > throwback to the 7.xx days when all onchecks locked the object being > checked, so we didn't have much of a window when it was safe to run > onchecks. Partially, it's a matter of faith that IDS doesn't corrupt its > data on disk very often and partially insistence that it should NEVER get > corrupted - after all what are we paying all those support $$ for > otherwise? Finally, the attitude is mostly because I rarely find anything > wrong, which I assume matches with your own experiences. > > If the engine says there's a problem, or if I suspect one, that's the time > I'll run the onchecks. > > Exception? I like to have an oncheck -pe output report and a > dbschema/myschema output report (for each database) available on disk in > case I have to recover data manually from an archive or from > catastrophically damaged disks (either using archecker, my own recovery > tools, or be calling tech support). I do want to have those reports > periodically (the oncheck -pe weekly and the schema updates whenever the > live schema is modified). > > Art > > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do > those opinions reflect those of other individuals affiliated with any entity > with which I am affiliated nor those of the entities themselves. > > On Tue, Oct 6, 2009 at 10:29 AM, Alexandre Marini <amarini@fazenda.ms.gov.br > >> wrote: >> > > >> Hello, friends. >> We´re on IDS 11.50.FC4 on a linux_64 environment. >> On our old instances (9.40), we had a script to run regularly, some >> oncheck commands on our instance. >> >> Does it applies also to the 11.50 version? Is it needed to execute on a >> regular basis, or not? >> >> Thanks and regards. >> -- >> >> Alexandre Marini >> >> Tecnologia da Informação - DBA >> >> SEFAZ-MS / SGI-UIMP / Sistemas IBM-Informix >> >> IIUG Member >> >> <http://www.iiug.org>; >> >> >> >> >> > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> > > --0023545bf548f9c4e3047545ac6d > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > >