DBAsupport.com Forums - Powered by vBulletin
Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Unexpected growth of a RBS

  1. #1
    Join Date
    Aug 2004
    Location
    Hermosillo, México
    Posts
    23

    Question Unexpected growth of a RBS

    I have a data base with 12 RBS's, one of them have 2177 extents, 2169 extends, 2205 wraps and it have grown more than 200 times the size of the other RBS's, is this normal?, a colleague made a big move to copy a great amount of rows from a MS Access data base to a table of that data base.

    Thank you

  2. #2
    Join Date
    Sep 2003
    Location
    over the hill and through the woods
    Posts
    995
    You've kind of answered your own question.
    "Your colleague made a big move". Chances are he didn't specify a commit after every 500 or so rows, therefore causing one big transaction which made your rollback segment grow. Just be glad you had enough extents specified and room in your tablespace otherwise you'd get a snapshot too old error. You can go into OEM and shrink it back down.
    Oracle it's not just a database it's a lifestyle!
    --------------
    BTW....You need to get a girlfriend who's last name isn't .jpg

  3. #3
    Join Date
    Jan 2001
    Posts
    3,134
    Yet another developer in need of a serious smack down.
    Commits R GuD, commits R yor freind!
    I remember when this place was cool.

  4. #4
    Join Date
    Nov 2000
    Location
    Pittsburgh, PA
    Posts
    4,166
    Originally posted by Mr.Hanky
    Yet another developer in need of a serious smack down.
    Commits R GuD, commits R yor freind!
    That's a gross over simplification of this situation.
    But then gross is your specialty.

    It is possible to get snapshot too old for committing too often. PL/SQL Collections are a great way to get around snapshot too old.

  5. #5
    Join Date
    Jan 2001
    Posts
    3,134
    SPARE ME THE EXCUSES AND USE A COMMIT DEVELOPER BOY!!
    I remember when this place was cool.

  6. #6
    Join Date
    Apr 2001
    Location
    United Kingdom
    Posts
    31

    Exclamation Commiting frequently !

    IS that the best solution ? Or should be it be creating a bigger rollback segment say large get the transaction sorted and get the new large rbs offline ... ?

  7. #7
    Join Date
    Jul 2003
    Posts
    323
    IMHO - it should be an optimization of both - RBS size and code i.e commits, collections - u should achive a balance based on your transaction actvity !

  8. #8
    Join Date
    Nov 2000
    Location
    Pittsburgh, PA
    Posts
    4,166
    Originally posted by Mr.Hanky
    SPARE ME THE EXCUSES AND USE A COMMIT DEVELOPER BOY!!
    Yet another gross over simplification.
    Way to go McPoo.

    When to commit depends on the situation.
    There is no one size fits all solution to this problem.

  9. #9
    Join Date
    Jan 2001
    Posts
    3,134
    See above!

    If it is growing X200, you need a commit, plain and simple.
    Or you need to break the job up into mangable segments, same difference.
    I remember when this place was cool.

  10. #10
    Join Date
    Nov 2000
    Location
    Pittsburgh, PA
    Posts
    4,166
    Originally posted by Mr.Hanky
    See above!

    If it is growing X200, you need a commit, plain and simple.
    Or you need to break the job up into mangable segments, same difference.
    Yes it does need incremental commits to work well. However, my comment was related to your comment not the issue at hand. I should have been more specific.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width