DBAsupport.com Forums - Powered by vBulletin
Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Data file on diffent disk

  1. #11
    Join Date
    Jun 2000
    Location
    Madrid, Spain
    Posts
    7,447
    i said raid 0 because of striping but obviously if it was production it must have redundancy such as raid 1 or 5

    mike since you are running raid 5 that does striping isnt it? so what is your problem?
    redologs should be kept in a seperate disk but if we wanna do that we will just have 2 disks for 2 groups of redologs which might sound a bit of waste to some shops

  2. #12
    Join Date
    Apr 2001
    Posts
    219
    It depends on your database load. If you have a lot of DML going on then seperation of RBS, logs and control files becomes more imperative. But if you have DB load of mostly queries and you do DML by batch you can keep the files on the same disk.

    High DML loads:
    -- I would use RAID 0 or solid-state drives for redo and use the redundacy capability of Oracle.
    -- Use RAID 0+1 and or solid-state drives for RBS and control files

    Low DML loads and cheap:
    -- Use RAID 5 for all.

    Mike RAID 5 is alright for dev and possibly production it all depends on your load and performance requirments. I frequently check my I/O performance, becuase my application is DML intensive, approx. 115 rows inserted a second and growing. So, I recommend you track your I/O performance. In Solaris 8 I did a iostat -xnc 3 into a file for about a day, then pulled this information into MS Excel. I played with the data and created many different graphs. These graphs helped me quickly discover my I/O bottlenecks.
    ______________________
    Applications come and go,
    but the data remains!

  3. #13
    Join Date
    Aug 2001
    Posts
    111
    I agree, placement should be based on redundancy first and then the type of database second.
    The number of disks to achieve complete separation is high. The thing to remember as well is that the number of disk controllers (or lack of) may well end up being a source of contention.

    The caveat here is to remember that although there can be performance improvement thru good placement,
    the most performance gain (normally 80-90%) will come from good design and good SQL!
    Have a look at the order in the Documentation in the Tuning chapter...
    Even if you reach a point where poor placement is causing a problem
    ask yourself first why are the so many disk reads?
    Are the disk reads the most efficient they can be?
    i.e is there index missing which is causing a FTS instead. Is the SQL holding rows right to the end, and then discarding most to return 1 or 2 rows out of 10 million.
    Is the database able to maximise I/O thru put or is it doing multiple small I/Os. eg doing a synthetic full table scan using a primary key index to return one row at a time for all rows.

    Have Fun
    Performance... Push the envelope!

  4. #14
    Join Date
    Jul 2001
    Posts
    45
    hi,

    For me, my priority is to stripe my data and indexes
    to all the 6 disks mixing it to achieve balanced I/O.
    Then whichever has the least I/O I put my control
    file and log files there.

  5. #15
    Join Date
    Sep 2001
    Location
    Makati, Philippines
    Posts
    857
    hi mike73,

    Using 3 disk to ensure that there will be no loose of control file and redo log files
    is a good intention, however, you will take away the controllers of this disks
    contribution towards performance.

    Remember that control file doesn't really make much of an I/O's specially in a production
    environment since there will be less DDLs transaction against server.
    And your rollback segment can't go along with redo logs in a transaction, since redo logs
    only writes after a COMMIT will be made in which rollback segment already finished its task.
    And your redo logs can be multiplexed anyway.

    But there's still a lot of issues that has to be address regarding DISK Distribution.
    What about ARChiving, where will be the archive files go? This files should not be with
    the redo logs in the same disk also. Is your SYSTEM file anyway protected? what if the disk
    of this file fail? Can you still issue a command that will complete your archive files
    before you can activate your standby database in case of a failure?

    The thing is, you have to consider a lot of issues first before u can make a decision.
    And it all depends on your systems requirements.

    I can help you if you want more clarification, I just don't have time now.

    regards

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