Message-Id: <10708.124309@fatcity.com> From: "Koivu, Lisa" Date: Tue, 12 Dec 2000 09:07:41 -0500 Subject: Your opinion please...RBS This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06444.E45A7AA4 Content-Type: text/plain; charset="iso-8859-1" Good morning - I'm reading through some doco about rollback segments and refreshing my memory. I remember a list discussion in the past about 'what is the point of optimal' with rbs's. The book I am reading (Oracle8i DBA Handbook, Oracle Press) states that shrinking to optimal, and extending a rollback segment, are both costly. Seems to me if you don't have the luxury of a very large tablespace then utilizing optimal is your only way to get rbs's to share disk nicely. However, if extending and shrinking is that costly, and you have a ton of disk at your disposal, I wonder about making my rbs's fairly large. Optimal right now is 40M (seems large to me). Our main app is more of a hybrid system, so I see wild numbers in v$rollstat - HWM's from 40M to 300M+. Has anyone just created really large rollback segments based on these types of weird sizes? I also see waits in v$rollstat, and undo waits in v$waitstat. I just bumped up the number of rbs's to 26 based upon a recent HWM of 101 concurrent sessions. My waits are still growing!! Is it totally wild of me to think about adding even more rbs's?? I have more disk than I could ever realistically use in my rbs ts (10G). I am thinking about just doubling the number of rbs's because 1. I don't want to see ANY rbs waits in v$rollstat, v$waitstat and 2. because I've got the disk. Am I out in left field? Any comments, suggestions, swift KITA's are appreciated. Gracias Lisa Rutland Koivu *O*penly *C*ynical & *P*essimistic Qode.com 4850 North State Road 7 Suite G104 Fort Lauderdale, FL 33319 V: 954.484.3191, x174 F: 954.484.2933 C: 954.658.5849 http://www.qode.com "The information contained herein does not express the opinion or position of Qode.com and cannot be attributed to or made binding upon Qode.com." ------_=_NextPart_001_01C06444.E45A7AA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your opinion please...RBS

Good morning -

I'm reading through some doco about = rollback segments and refreshing my memory. I remember a list = discussion in the past about 'what is the point of optimal' with = rbs's.  The book I am reading (Oracle8i DBA Handbook, Oracle = Press) states that shrinking to optimal, and extending a rollback = segment, are both costly. 

Seems to me if you don't have the = luxury of a very large tablespace then utilizing optimal is your only = way to get rbs's to share disk nicely.

However, if extending and shrinking is = that costly, and you have a ton of disk at your disposal, I wonder = about making my rbs's fairly large.  Optimal right now is 40M = (seems large to me).  Our main app is more of a hybrid system, so = I see wild numbers in v$rollstat - HWM's from 40M to 300M+.  Has = anyone just created really large rollback segments based on these types = of weird sizes?

I also see waits in v$rollstat, and = undo waits in v$waitstat.  I just bumped up the number of rbs's to = 26 based upon a recent HWM of 101 concurrent sessions.  My waits = are still growing!!  Is it totally wild of me to think about = adding even more rbs's??  I have more disk than I could ever = realistically use in my rbs ts (10G). I am thinking about just doubling = the number of rbs's because 1. I don't want to see ANY rbs waits in = v$rollstat, v$waitstat and 2. because I've got the disk.

Am I out in left field?  Any = comments, suggestions, swift KITA's are appreciated.  = Gracias

Lisa Rutland Koivu
*O*penly *C*ynical &  = *P*essimistic
Qode.com
4850 North State Road 7
Suite G104
Fort Lauderdale, FL  = 33319

V: 954.484.3191, x174
F: 954.484.2933
C: 954.658.5849
http://www.qode.com

"The = information contained herein does not express the opinion or position = of Qode.com and cannot be attributed to or made binding upon =