Simpler Navigation for Servers and Operating Systems
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
Showing results for 
Search instead for 
Did you mean: 


Go to solution
Frequent Advisor


Hi Admins,
HSG80 v8.7f
please advise about,
I have stripset with full redandancy(6 Disks each tow disks is mirrorset)
I would like to know which performance is better
make stripset as one partition or devid it to partitions,
Hein van den Heuvel
Honored Contributor

Re: stripset


If you need to ask the question, then I would recommend leaving it as a single big space.

The real answer is of course 'it depends'.
- It depends to the applicaiton usage patterns of the disk space.
- it depends on the ease with which you can recover from a partition filling up: If that is hard, just avoid that problem by havign a single large space.

The HSG allocates its disk blocks up front, and the partitions on top of that make the final placement predictable. This is unlike the EVA, which just reserves up front, but allocates based on first usage time which can result in blocks from partitions intermingling

The problem of partitions on top of HSG storage is that they may a) force excessive seeks distances, and they may b) cause unexpected underuse of 'fast blocks' and overuse of 'slow blocks.

a1) if a you put for example an Oracle index tablespace on one partition, and the Data on an onthere, then every time when you go from an index lookup to the actual data page fetch, there will be a long seek over the full partition block range. Those file could have been adjacent. The result is the opposite of the (old) Oracle tuning recomendation to put the index and data on different spindles (to avoid those seeks).
They you would be better of to just present those mirror sets as units, but this will give you the challenge to balance the IO load accross the spindles.

a2) If you have multiple, independend applications, or large chunks of low use data (installation kits, certain backups, historical data) the partition are a great way to keep the high usage data blocks physically close together.

b) The first (50%?) blocks on the disks allow for higher transfer rates simply because there are more blocks / track. So with a constant rotation speed, more data will come by under the heads. The high blocks may have only 1/3 of the MB/sec rating of the low blocks.
This gets ammplified by the seek distance. I don't know the exact numbers, but I suspect that the first 1/2 of the blocks fits on the 1/3 outer part of the disk, and the other 1/2 required 2/3 of the radial distance on the disk. So the average seek time is potentially 2x worse on a partition using the high disk blocks.

If you can turn all of that into your advantage, then more power to you!... but I as I opened, I doubt you would have asked the question!.
For most applications the simple IO spread and file allocation time based data proximity from a single large 0+1 disk will work just fine. It means that data created together will more or less live together (until file deletes, re-usage and fragmentation start to play a major role), and it means that the 'hot' outer space is used first, and the 'slow' inner space only when (if?) the disk gets really full.

Hope this helps some.

For further advice, you'll have to tell us more about the kind of data, and that typical data access, the application is expected to show.


Frequent Advisor

Re: stripset

Many thanks Heuvel,
I would to put data file for OPS oracle v8,..
I alredy configure examp mirrorsetess m1...m30
I cannt create more mirror then I decide to using striped mirror(mirror to each two disks then stripe them) instead of just merrorset
I prefer partition stripset to destiguish datafiles,(oracle DBA,s)
I want the best performance,
where can I find DOCS about HSG80 describe how HSG80 work when configure mirrorsets or other
thanks again
please advise.
Hein van den Heuvel
Honored Contributor

Re: stripset

>> I would to put data file for OPS oracle v8,..

Ah, now we have somehting to work with.
Any chance to migrate to 9i RAC? Nicer!

>> I alredy configure examp mirrorsetess m1...m30

30 mirrors? That's too many devices to manage and balance.

Google for: +oracle +storage +same
"Stripe and Mirror Everything "

IF (and only if) you have significant REDO log IO (at least 3 mb/sec ?) , then I would argue for one or two mirrors more or less set aside for redolog as the sequential write behaviour will benefit you.

>> I prefer partition stripset to destiguish datafiles,(oracle DBA,s)

And then what? Using that you 'see' some datafile doing more IO with IOSTAT or MONITOR and you need to re-balance. But where to? How?
I would suggest simply using the ORACLE STATS to get the same (better!) visibility. Use statspack or utl[BE]stat to identify the per file / per tablespace IO rates and just stripe them all together at the physical layer.

>>. I want the best performance,

a) Solution: Stripe and Mirror Everything

b) Consider LSM as a very flexible way to carve some independend partitions from a large striped-mirror set.

c) Consider RAW on LSM for PARTS of the database (UNDO/RBS, TEMP, REDO,...)

>> where can I find DOCS about HSG80

Google for things like: +hsg80 +whitepaper
or: +hsg80 +technical

>> please advise.

Keep looking back to the basics:
- What defines the application performance?
- Is the SQL code sufficiently tuned?
- Do you even have an IO problem to worry about?
- What is the CPU load? (if it is 95%, then IO tuning will not help much, will it now?)
- get professional training and consultancy 'every now and then' to become a better admin over time.

Best regards,
Hein van den Heuvel
Honored Contributor

Re: stripset

>> where can I find DOCS about HSG80 describe how HSG80 work when configure mirrorsets or other

If you send me an Email, or post your 'encrypted' Email here then I may be able to send some documentation.

Hein: heinvandenheuvel at gmail dot com