DBAsupport.com Forums - Powered by vBulletin
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: redo log size

  1. #11
    Join Date
    Feb 2000
    Location
    Singapore
    Posts
    1,758
    Originally posted by hrishy
    pando can you please explain what do you mean by the above statement..well all oracle9i boasts about this OMF feature..why do you think its bad ?

    can you elaborate

    regards
    Hrishy
    Hi Hrishy,

    The point is no one will want to put all its datafiles on one volume defined by DB_CREATE_FILE_DEST for a production database.
    Yes, you can dynamically change this parameter but it invloves same amount of work compared to manually mentioning the path.
    Also the filenames assigned by OMF is a bit complex.
    Sanjay G.
    Oracle Certified Professional 8i, 9i.

    "The degree of normality in a database is inversely proportional to that of its DBA"

  2. #12
    Join Date
    Apr 2001
    Location
    Louisville KY
    Posts
    295
    Be careful about 'noone'.

    I have four Oracle and about 15 SQL Server databases which are all allocated to a single mount point. One of the Unix Oracle's is 2TB. (Okay, it has two mount points, one of which is for read only tablespaces.) There is an NT Oracle that is 750GB on one mount point.


    We are using EMC. You can't load balance a single pipe with an 8 GB data buffer. And it can greatly simplify file management.
    Joseph R.P. Maloney, CSP,CDP,CCP
    'The answer is 42'

  3. #13
    Join Date
    Feb 2001
    Posts
    295
    The point is no one will want to put all its datafiles on one volume defined by DB_CREATE_FILE_DEST for a production database.
    The point is: simplify the work of the DBA. Let the mirroring and multiplexing with the system administrator on the OS level. "Why should a superior being like a DBA worry with those insignificant OS file issues?"

    Anyway, OMF seems useless for people who likes a little organization and perfect for those lazy DBA's who don't even remember where they put their own datafiles. Sounds like crap.

    As pando says, Oracle itself recommends OMF for test databases.
    An ounce of action is worth a ton of theory.
    —Friedrich Engels

  4. #14
    Join Date
    Apr 2001
    Location
    Brisbane, Queensland, Australia
    Posts
    1,203
    You can use OMF for Production database, especially if you are using SAME (Strip And Mirror Everything), under a single mount point, and as jrpm said, using an EMC array, you've already distributed your I/O.

    Nothing wrong with OMF under this configuration.

    Next I'll be hearing that if a Buffer_cache_ratio < 96% your database is performing badly.

    ALTHOUGH, redo logs are a different story, YOU MUST multiplex your redo logs, don't rely on OS Mirroring, cause if you have an error writing the the log... this error is MIRRORED and you're stuffed.
    OCP 8i, 9i DBA
    Brisbane Australia

  5. #15
    Join Date
    Feb 2001
    Posts
    295
    You can use OMF for Production database, especially if you are using SAME (Strip And Mirror Everything), under a single mount point, and as jrpm said, using an EMC array, you've already distributed your I/O.

    Nothing wrong with OMF under this configuration.
    Yeah, it works. But personally I feel losing control on datafiles when using OMF, it's like a black box. Naming convention doesn't help too. IMHO, OMF does not decrease DBA efforts so much to completely justify its adoption. That's the point.


    ALTHOUGH, redo logs are a different story, YOU MUST multiplex your redo logs, don't rely on OS Mirroring, cause if you have an error writing the the log... this error is MIRRORED and you're stuffed.
    That's not a problem. OMF can multiplex redo logs and control files with DB_CREATE_ONLINE_LOG_DEST_n.
    An ounce of action is worth a ton of theory.
    —Friedrich Engels

  6. #16
    Join Date
    Apr 2001
    Location
    Brisbane, Queensland, Australia
    Posts
    1,203
    Originally posted by adrianomp
    Yeah, it works. But personally I feel losing control on datafiles when using OMF, it's like a black box. Naming convention doesn't help too. IMHO, OMF does not decrease DBA efforts so much to completely justify its adoption. That's the point.

    That's not a problem. OMF can multiplex redo logs and control files with DB_CREATE_ONLINE_LOG_DEST_n.
    So you're saying, if your running OMF, you don't know where your Datafiles are? How are you losing control? What, just because you're not naming the datafiles yourself? Really, you stil lmonitor the tablespace via OEM...the name of the file shouldn't make any difference.

    I think it's a personal choice, I don't think OMF is a good or bad idea, it can be useful in situations, i.e. SIngle Mount Point, EMC arrays.

    I don't think it's related to whether or not its a PROD or TEST db. Why admister your TEST DB differently to your production environment?
    OCP 8i, 9i DBA
    Brisbane Australia

  7. #17
    Join Date
    Jun 2000
    Location
    Madrid, Spain
    Posts
    7,447
    well we must administer our development boxes differently from production boxes, we dont have same server, same disks, same file systems setups

    we have customers who use a massive box as production box and for development they use a PC heh

  8. #18
    Join Date
    Apr 2001
    Location
    Brisbane, Queensland, Australia
    Posts
    1,203
    Originally posted by pando

    we have customers who use a massive box as production box and for development they use a PC heh
    Volume testing must be... well, interesting to say the least.
    OCP 8i, 9i DBA
    Brisbane Australia

  9. #19
    Join Date
    Feb 2001
    Location
    UAE
    Posts
    304

    Red face

    This thread is going nowhere..............
    Agasimani
    OCP(10g/9i/8i/8)

  10. #20
    Join Date
    Jan 2001
    Posts
    2,828
    Hi Pando

    Thank you very much for an answer..thanks to larry too..please make databases complex..and diificult to manage..so that every oracle shops would always need a DBA ;-D

    regards
    Hrishy

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