Re: switch from file system to raw device

Igor wrote:

> Thanks for your comments.
>
>> If your environment is that susceptible to the disk performance, you
>> might also get some benefit from the old (myth-age) style of separating
>> tablespaces to separate disk drives & controllers, etc. However, other
>> than for keeping someone busy, I would not recommend resurrecting those
>> techniques!
>
> We did so when there was something to separate on, when we had disks,
> which where seen/addressable individually. As we passed from single disk
> handling (IBM SSA 7133) to Raid5 (IBM FAStT SAN), there of course is not
> really much one can address individually. But in fact, we separated rbs
> from tmp, data from indexes and so on.

From a performance perspective, according to the SAME (stripe and mirror everywhere) supporters there is little, or even negative, benefit to separating indexes from tables, etc.

There is nothing wrong with separating for administrative reasons, though.  

> In all the contributes or documentation I read, people often say, that "it
> is not worth the effort" to go onto raw device instead of going to file
> system. Maybe I am blind or professionally deformed, but I find no
> particular effort in handling raw devices (maybe, because I started to do
> so about ten years ago; my first db was on file system and there was no
> performance issue to be investigated).

In many organizations I've seen or about which I've read, the DBA's role and the SysAdmin's (SA's) role are clearly separated and the DBA is really only taught file manipulation using traditional file system tools (cp, ls, tar, etc.) So a typical backup/recovery of raw files would require coordinated effort between 2 individuals. In addition, using raw devices has meant creating, maintaining and testing the backup and recovery 'software'.

That has changed a lot with RMAN and certainly seems not true in your case.

Another part of the effort is the monitoring and sizing of the tablespaces. With raw, such conveniences as autoextend are challenged.

In a world of ever-increasing point-and-click administration, a la Windows, reading about your experience is refreshing. And a reminder to me that not everyone wants the easy way out.

> When you back up an open database, depending on workload and size of the
> db and backup destination/application, individual tablespace handling and
> backing up datafiles of single tablespaces must be done, so whether I am
> backing up /dev/lvXYZ_file or /home00/oracle/oradata/XYZ/file.dbf does not
> make any real difference for the backup procedure. Recreating a copy of an
> existing db also is not really an issue if you let the backup procedure
> make a snapshot of the environment (like lv create scripts).
> But, of course, we are individuals, different experiences as for hw or
> backup sw or OS, so individual preferences may apply. And I guess that's
> just it, personal preference.

Avoiding raw devices can be a business requirement, not a personal preference. For example: if the majority of DBAs and SAs do not have experience with raw devices, and are not familiar with RMAN, replacing individuals (or letting the experienced ones go on vacation) is more difficult.

> By the way, we use raw devices on small Linux systems, too.
 

The majority of shops I've seen will not even consider running two file systems on a machine.

And then there is the question of getting enough raw devices when the entire system can be handled by one 146GB SCSI drive. And the 400GB SATA drive is causing some serious rethinking ... who would have thought that 3 disk drives for under USD$1500 (eg. www.dirtcheapdrives.com) could provide over a TB of storage.

My (our?) comments were largely aimed at the typical DBA/SA who ask the question purely because they are desperate for a quick gain in performance without having your experience.

/Hans Received on Thu Sep 16 2004 - 05:35:46 CDT