-
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
-
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!
-
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!
-
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.
-
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|