DBAsupport.com Forums - Powered by vBulletin
Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: Archivelog Overload...

  1. #1
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204

    Archivelog Overload...

    I need help figuring out a practical solution for handling big bursts of archive logs.

    DB: 10.1.0.4 / ASM / OMF
    OS: RedHat AS 3

    From time to time we have a process that writes 20gb of archive logs in about 1/2 hour. It floods our available space (17gb reserve) for these logs and hangs the database.

    Adding diskspace to the ASM diskgroup will obviously help but we'd I want to avoid the downtime of adding new raw disk devices.

    I've thought of writing a pl/sql job that checks the rate of archiving and if it hits a threshold, then trigger an rman process to flush the logs, provided it's not already running.

    Am I over-thinking this?

    Ken

  2. #2
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    Adding diskspace to the ASM diskgroup will obviously help but we'd I want to avoid the downtime of adding new raw disk devices.
    You don't need to add raw devices for archive log file system. You need to increase the arch file system only.

    Tamil

  3. #3
    Join Date
    Jul 2002
    Posts
    335
    Rather than writing pl/sql, can't you just set up a threshold/notifcation (in grid - I know you use it!!) for when the file system/archive area hits x% full? If you still want to automatically kick the rman job, then set a response action up.
    Either that or more space ;-)

    Bazza

  4. #4
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    Quote Originally Posted by tamilselvan
    You don't need to add raw devices for archive log file system. You need to increase the arch file system only.
    Unless I choose a locally mounted file system and switch my archivelog destination to it, I believe would need to add a raw device to the ASM disgroup where my archivelogs are going now.

    Ken
    "I do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

  5. #5
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    Quote Originally Posted by bazza
    Rather than writing pl/sql, can't you just set up a threshold/notifcation (in grid - I know you use it!!) for when the file system/archive area hits x% full? If you still want to automatically kick the rman job, then set a response action up.
    Either that or more space ;-)

    Bazza
    Yea, Great suggestion. I'd love to do this. I'm just not real comfortable with the alerting system 10g OEM. We've been running it side by side with other systems and they have been 100% right on, while OEM has missed some really big problems 50% of the time. That's probably me, but I think it needs help.

    I also have the addition of not wanting to fire this when an rman backup (datafile or archivelog) is already running.

    There's probably a sql query that could tell me if the db is currently being backed up through rman.

    I'm working along the lines of a cron job that counts the rows in v$archived_log where status = 'A' ('D' is deleted), and if rman isn't already running (grep rman or something) and I've got 20 archived logs or so, then kick off the rman process.

    Any thoughts/opinions are greatly appreciated.

    -Ken
    "I do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

  6. #6
    Join Date
    Jul 2002
    Posts
    335
    Instead of grepping for rman, you could check V$session instead and check for sys sessions running rman (program column is populated by rman).

    Know what you mean about grid, our whole setup stopped working for targets that were discovered > 250 days ago, due to a bug. You using Release 2 yet?

    Bazza

  7. #7
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    Quote Originally Posted by bazza
    ..check V$session .. for sys sessions running rman..
    Great idea. Thanks!

    That's a nasty bug we haven't run into. Was the root cause discovered? Was it platform specific?

    I'm working on installing OEM 10.2 on SuSE-9 64 bit without much success. I've had a compilation error TAR open for a few weeks. Some TAR's just don't get good traction.
    "I do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

  8. #8
    Join Date
    Oct 2000
    Location
    Saskatoon, SK, Canada
    Posts
    3,925
    My take would be to add more disk space to the archive destination and point your archives to collect in there.
    Thanx
    Sam



    Life is a journey, not a destination!


  9. #9
    Join Date
    Jul 2002
    Posts
    335
    Quote Originally Posted by KenEwald
    Great idea. Thanks!

    That's a nasty bug we haven't run into. Was the root cause discovered? Was it platform specific?

    I'm working on installing OEM 10.2 on SuSE-9 64 bit without much success. I've had a compilation error TAR open for a few weeks. Some TAR's just don't get good traction.
    It's a known issue with R1 apparently, have a look at bug 3674467 and note 303106.1. Its not platform specific, its a bug with grid itself.

    I'm going to have crack at Grid R2 on Red hat 3 next week. Just had to resolve a bug with the installer itself!!

    Happy times

    Bazza

  10. #10
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    Quote Originally Posted by sambavan
    My take would be to add more disk space to the archive destination and point your archives to collect in there.
    Yea, me too. Unfortunately I'm limited to the disks I have in that ASM diskgroup.

    This happens once every 2 weeks. I think we can "swallow the frog" if I can flush logs before it can fill up the space. I'm also thinking about adding online redo logs so we have a little more lead time before the "archivelog dest full" alert is triggered and when the db finally halts transactions.

    -Ken
    "I do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

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