Re: The old raw devices chestnut.

Andrew,

Fair enough considerations, and you hit the point on the head, the backup and restore.

We have always set up backup of logs and data to a real backup, but considering all the options I might 'need' in the event of system failure, or migration, or cloning, raw devices are an added risk. We use a third-party backup tool to backup our SQL-Server databases, as well as EMC Timefinder to flash-copy databases into production environments. We will apply the same methods with DB2 or MySQL for that matter. The raw-disk paradigm adds only extra trouble/work.

The real question is, how will you backup, much less restore raw device databases? Are you prepared to deal with the inflexibility it presents? Have you ever run Informix or other vendor database through a complete backup and restore, testing all the options with raw-device dbspaces? Most DBAs I've run into have never had to restore a database at any time in their career much less even test it. Is that amazing or what!

Consider too, clustering of systems and disks, and the administrative challenges associated with that. Add raw devices to multitudes of servers and it becomes more risky and more to manage. It puts more opportunities for failure in the administration path, and nobody in their right mind wants to increase risk. Is the extra 10% in speed worth it? Maybe that 'speed' can come from somewhere else?

One other thing you might find attractive to plain ole files instead of raw devices is the ability to clone databases. You can get quite creative with plain files in ways that you cannot with raw devices because of the lock-in of raw-devices. You create more work for yourself in the long run with raw disks, unless of course you're not as lazy as me and actually enjoy the extra work. '-)

"Andrew Hamm" <ahamm_at_mail.com> wrote in message news:c5i1me$1vnic$1_at_ID-79573.news.uni-berlin.de...
> Data Goob wrote:
> > I've found jfs to be "fast enough", considering we are moving
> > from SQL-Server, no raw-disks on that one ( chuckles and laughs
> > allowed :-) . The risks that raw-disks present makes me wonder
> > if they are worth it. Restoring raw-disk databases presents its
> > own set of problems, whereas regular files can be backed up and
> > restored more simply and with more flexibility.
>
> Ummmmm, if you try to archive regular files when the database is active, you
> *will* have an inconsistent snapshot of the database. Do you perform these
> backups only when the engine is offline? I can't see this being safe on any
> brand of engine if the database is "twinkling". The only way to get a
> consistent (ie logical instant in time) backup of a live, active database is
> to use a tool which maintains the illusion on your behalf.
>
>
Received on Tue Apr 13 2004 - 20:10:22 CDT