oncheck (quiet)

( for those of you who skim read, take your time as we have tried all sorts of options...) We have been looking into using oncheck with a series of scripts as we want to verify the integrity of the database before we do a level 0 ( very important data ). Unfortunately, we are running a Baan database with multiple companies and over 14000 tables. As you can imagine the "oncheck -p" option produces a substantial amount of data, the majority of which is absolute tosh - we only want to wory if there are errors. The problem we are getting is that the output generated by the oncheck is creating an enormouse file which has already filled file systems causing all sorts of problems (and being called out at 3:00am for a full file system is not my idea of support). We are performing an "oncheck -pDI" nightly (taking about 3 hours) and an "oncheck -cDI" weekly (Sunday nights), both oncheck commands are issued before the level 0 archive is performed. Q1) Should we need to perform oncheck's to this level of frequency ? Surely, it is an exception that the database would have corrupt data/index/blob pages and I would start to get worried (and consider a change in career) if these onchecks reported problems every week. Q2) Is there an option to produce output for errors only - "oncheck -cDI -q" does this okay but the -p option still produces 000's mb of output !! Q3) Does anyone have any pointers as to what is a good strategy to adopt in order to ensure that the integrity of your data is sound before performing a level 0 ? TIA Sean

In article <36c2fe45.0@145.227.194.253>, "Sean Kelsey" <chilliinc@hotmail.com> wrote: > ( for those of you who skim read, take your time as we have tried all sorts > of options...) > > We have been looking into using oncheck with a series of scripts as we want > to verify the integrity of the database before we do a level 0 ( very > important data ). Unfortunately, we are running a Baan database with > multiple companies and over 14000 tables. > > As you can imagine the "oncheck -p" option produces a substantial amount of > data, the majority of which is absolute tosh - we only want to wory if there > are errors. > > The problem we are getting is that the output generated by the oncheck is > creating an enormouse file which has already filled file systems causing all > sorts of problems (and being called out at 3:00am for a full file system is > not my idea of support). > > We are performing an "oncheck -pDI" nightly (taking about 3 hours) and an > "oncheck -cDI" weekly (Sunday nights), both oncheck commands are issued > before the level 0 archive is performed. > > Q1) Should we need to perform oncheck's to this level of frequency ? Surely, > it is an exception that the database would have corrupt data/index/blob > pages and I would start to get worried (and consider a change in career) if > these onchecks reported problems every week. > > Q2) Is there an option to produce output for errors only - "oncheck -cDI -q" > does this okay but the -p option still produces 000's mb of output !! > > Q3) Does anyone have any pointers as to what is a good strategy to adopt in > order to ensure that the integrity of your data is sound before performing a > level 0 ? > > TIA > > Sean > > Maybe no highligth inthat, but this is what we do: oncheck -cr -q oncheck -ce -q oncheck -cc -q | grep ERROR for i in `what_are_the_databases_here.sh` do oncheck -pt $i | <perl script to grep and present relevant data for everytable in a single row of text and as "|"-separated lines for load-ups> done oncheck -pe - daily before any type of backup. Plus selected onstat's [-d,-cDlmptuCR] (our onstat doesn't do dD together, but I don't know why, so it is 2 invocations of onstat) and a check if out onarchive BACKUP/CONT is still on the way And we also save the day's lines in online.log + $ONCONFIG-file + /tmp/af* files and /tmp/*itg* files, if such beasts are there, and of course /tmp/oncatlgr* files Every week we do a oncheck -cdi and oncheck -pT, the latter gives some info about index space filling (i.e. split pages) and the %-age of data in the data pages, things you don't get from oncheck -pt, but -pt runs so much faster ...., and oncheck -p{tT} places a lock on every table and keeps that lock until it is done with all the other tables (have no idea WHY) You find some important daily things to check in the Admin Guide on the web in INFORMIX's manual section in www.informix.com/answers in Chapter 27 'What is consistency checking' Richard Kofler debis Systemhaus EDVg Vienna / Austria -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

In article <36c2fe45.0@145.227.194.253>, Sean Kelsey <chilliinc@hotmail.com> writes >( for those of you who skim read, take your time as we have tried all sorts >of options...) > >We have been looking into using oncheck with a series of scripts as we want >to verify the integrity of the database before we do a level 0 ( very >important data ). Unfortunately, we are running a Baan database with >multiple companies and over 14000 tables. > >As you can imagine the "oncheck -p" option produces a substantial amount of >data, the majority of which is absolute tosh - we only want to wory if there >are errors. > >The problem we are getting is that the output generated by the oncheck is >creating an enormouse file which has already filled file systems causing all >sorts of problems (and being called out at 3:00am for a full file system is >not my idea of support). > >We are performing an "oncheck -pDI" nightly (taking about 3 hours) and an >"oncheck -cDI" weekly (Sunday nights), both oncheck commands are issued >before the level 0 archive is performed. > >Q1) Should we need to perform oncheck's to this level of frequency ? Surely, >it is an exception that the database would have corrupt data/index/blob >pages and I would start to get worried (and consider a change in career) if >these onchecks reported problems every week. > >Q2) Is there an option to produce output for errors only - "oncheck -cDI -q" >does this okay but the -p option still produces 000's mb of output !! > the -p option is suppose to give lots of output! the -c option is for checking for errors...use -c and -q >Q3) Does anyone have any pointers as to what is a good strategy to adopt in >order to ensure that the integrity of your data is sound before performing a >level 0 ? > >TIA > >Sean > > > > -- David Williams