Re: running oncheck takes a long time
<FONT face=3D"Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif" size=
=3D2><DIV><BR><DIV><BR><DIV><FONT color=3D#990099>-----Dominic Seah Chin Te=
ck/Parkway/SG wrote: -----<BR><BR></FONT></DIV><blockquote style=3D"PADDING=
-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">To: nobody@ace.iiug.org<BR>From: Dominic Seah Chi=
n Teck/Parkway/SG<BR>Date: 04/19/2005 10:10AM<BR>cc: ids@iiug.org<BR>Subjec=
t: running oncheck takes a long time<BR><BR><FONT face=3D"Default Sans Seri=
f,Verdana,Arial,Helvetica,sans-serif" size=3D2><FONT face=3D"Default Sans S=
erif,Verdana,Arial,Helvetica,sans-serif" size=3D2><DIV>Hi <FONT face=3D"Cou=
rier New">Tilman,</FONT></DIV><P>Regarding oncheck -cD or oncheck -cI.</P><=
P><U>Our practice :</U></P><P>1) perform restore of production data into te=
st box once a month. Do oncheck(data & index) to ensure no corruption.<=
/P><P>Question : This practice a good way to check that production data has=
no data & index corruption ? Please advise.</P><P>2) Running onch=
eck -cD <sid> takes as much as 16 hours on 660gb database size. </P><=
P>Question : Can we do parallel running of oncheck on tables using scripts =
to reduce the timing ? We have tried this and found that the timing of para=
llel running is worse than serial running vai oncheck -cD <SID>. Look=
s like run into deadlock... or bottleneck. Please advise.</P><DIV><BR></DIV=
><DIV>Thank you</DIV></FONT></FONT><BR><BR>Disclaimer:-<BR>The information =
contained and transmitted by this e-mail is intended for use only by the in=
dividual or entity to which it is addressed and may contain information tha=
t is privileged, confidential or exempt from disclosure under applicable la=
w.<BR><BR>If you are not the intended recipient or it appears that this mai=
l has been forwarded to you without proper authority, you are hereby notifi=
ed <BR>that any use, distribution, printing, copying or dissemination of th=
is e-mail in any manner or taking action in reliance on the contents of thi=
s <BR>e-mail is strictly prohibited.<BR><BR>If you have received this e-mai=
l in error, please notify us immediately at paullee@parkway.sg and permanen=
tly delete the original and <BR>any copy of this e-mail and any printout th=
ereof.<BR></blockquote><br></DIV></DIV></FONT><br /><br />Disclaimer:-<br /=
>The information contained and transmitted by this e-mail is intended for u=
se only by the individual or entity to which it is addressed and may contai=
n information that is privileged, confidential or exempt from disclosur=
e under applicable law.<br /><br />If you are not the intended recipient or=
it appears that this mail has been forwarded to you without proper authori=
ty, you are hereby notified <br />that any use, distribution, p=
rinting, copying or dissemination of this e-mail in any manner or takin=
g action in reliance on the contents of this <br />e-mail is strictly prohi=
bited.<br /><br />If you have received this e-mail in error, please not=
ify us immediately at paullee@parkway.sg and permanently delete the origina=
l and <br />any copy of this e-mail and any printout thereof.<br />=
<FONT
face=3D"Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=
=3D2><DIV><BR><DIV>Hi friends & fellow forumers.</DIV><DIV><BR>Regardin=
g oncheck -cD or oncheck -cI.</DIV><DIV>Our practice :</DIV><DIV>1) perform=
restore of production data into test box once a month. Do oncheck(data &am=
p; index) to ensure no corruption.</DIV><DIV>Question : This practice a goo=
d way to check that production data has no data & index corruption ? Pl=
ease advise.</DIV><DIV>2) Running oncheck -cD <sid> takes as much as =
16 hours on 660gb database size. </DIV><DIV>Question : Can we do parallel r=
unning of oncheck on tables using scripts to reduce the timing ? We have tr=
ied this and found that the timing of parallel running is worse than serial=
running vai oncheck -cD <SID>. Looks like run into deadlock... or bo=
ttleneck. Please advise.</DIV><DIV> </DIV><DIV>Thank you<BR><BR><BR><B=
R>Regards<BR>Dominic Seah<BR>64616826<BR></DIV><DIV> </DIV></DIV></FON=
T><br /><br />Disclaimer:-<br />The information contained and transmitted b=
y this e-mail is intended for use only by the individual or entity to which=
it is addressed and may contain information that is privileged, confid=
ential or exempt from disclosure under applicable law.<br /><br />If you ar=
e not the intended recipient or it appears that this mail has been forwarde=
d to you without proper authority, you are hereby notified <br />that a=
ny use, distribution, printing, copying or dissemination of thi=
s e-mail in any manner or taking action in reliance on the contents of this=
<br />e-mail is strictly prohibited.<br /><br />If you have received this =
e-mail in error, please notify us immediately at paullee@parkway.sg and=
permanently delete the original and <br />any copy of this e-mail and any =
printout thereof.<br />=