How to use outside tracks of disks in VM
NetComrade
I create a subdisk in Volume Manager:
vxmake -g rockdg sd frontd101-01 disk=frontd101
offset=0 len=1050424
I print the private region of the disk:
How do I know which tracks are being used? Also, are tracks/cylinders
being counted from outside, or inside (in other words, where's
cylinder 0, closest to the spindle or farthest from the spindle)
[lroot/rock@: ]prtvtoc /dev/rdsk/c2t101d0s2
* /dev/rdsk/c2t101d0s2 partition map
*
* Dimensions:
* 512 bytes/sector
* 133 sectors/track
* 27 tracks/cylinder
* 3591 sectors/cylinder
* 4926 cylinders
* 4924 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
2 5 00 0 17682084 17682083
3 15 01 0 3591 3590
4 14 01 3591 17678493 17682083
Thnx.
.......
We use Oracle 8.1.6-8.1.7 on Solaris 2.6, 2.7 boxes
Andrey Dmitriev eFax: (978) 383-5892 Daytime: (917) 750-3630
AOL: NetComrade ICQ: 11340726 remove NSPAM to email
NetComrade
-wiseguy
news:3c5ee185....@news.globix.com:
> How do I know which tracks are being used? Also, are tracks/cylinders
> being counted from outside, or inside (in other words, where's
> cylinder 0, closest to the spindle or farthest from the spindle)
Why does it matter?
--
-wiseguy
slummin it in Colorado ski country, while watching the IT industry move
to India, and thinking about retraining as a Sanitation Engineer
NetComrade
b/c they are being read faster than inside tracks
http://technet.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf
-wiseguy
news:3c60c9e7....@news.acedsl.com:
> Apparently the outside tracks are better for using for 'hot' files,
> b/c they are being read faster than inside tracks
>
> http://technet.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf
Thanks for the link. There are some things about that statement that don't
set well with me so let me read the tech paper and get back to the thread on
this.
I'll followup shortly.
-wiseguy
news:Xns91AD61090C...@209.189.89.243:
> andre...@bookexchange.net (NetComrade) wrote in
> news:3c60c9e7....@news.acedsl.com:
>
>> Apparently the outside tracks are better for using for 'hot' files,
>> b/c they are being read faster than inside tracks
>>
>> http://technet.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf
>
> Thanks for the link. There are some things about that statement that
> don't set well with me so let me read the tech paper and get back to the
> thread on this.
>
> I'll followup shortly.
>
I cannot find too much technical flaw in the document, but it does scare me
for a couple of reasons. The author makes generalizations that seem to
release DBAs from their responsibility to design proper schemas and
transaction models. It's as if he's saying "don't worry about doing design
correctly because we're gonna give you a generalized solution to optimize the
thing in most cases." In real life experiences it doesn't work that way.
His points and my rebutal:
1) stripe data across all disks
* I certainly agree although I do challenge his generalization about optimum
slice size being 1MB in all cases.
2) put frequently accessed data on the outer disk cylinders.
* I find this advise without merit for a couple of reasons. First, trying to
reverse engineer or second guess the physical media characteristics is a
dangerous road and one I completely discourage. Disk manufacturers are not
under any particular order to layout disks in any particular fashion. All
that they must do is to provide a consistent industry standard hardware
interface that reads and writes data according to SCSI, IDE, or whatever
standards the disk follows. variable sectors/cylinder is not a hard
requirement. Some disks do and some do not. Sector relocation for bad
blocks also interferes with his assertion. Finally, very little was said
about solid state memory caching, which if used properly, can usually obviate
the issues surrounding rotational delays and seek time waits.
3) mirror media, then stripe
* As I've said many times before on this group, I challenge the necessity of
full mirroring for many applications. It costs nearly twice as much as
stripes+parity and in a well designed database the write overhead of raid5 is
negligible. The advantage of mirroring as implemented by companies like EMC
is that they do incremental mirroring change logs and that makes backup and
recovery easier if you spend the money up front to support it. Mirroring is
a higher cost item and is over-used IMHO.
4) subset data by partition, not disk
* generally agree with this point
Dissent:
He points out that under the SAME methodology the ability to expand available
dataspace is very difficult. This to me, is a large stumbling block. Many
small to medium sized firms do incremental development without any idea of
how much online storage they will really need. SAME technique expects that
you pre-allocate the required space (a requirement of striping). Under many
business models this simply isn't done effectively.