Re: The old raw devices chestnut.

Mark Bole wrote: > I haven't worked with an Oracle raw device since version 7.3 seven > years ago, and would never go back. The administrative overhead is > just too much of a headache. [Posting from comp.databases.informix] I've never understood the "administrative overhead" argument against raw spaces. Can you elicidate on the administration you think needs to be applied? In my experience, the only admin overhead is making sure that a new, naive sysop doesn't try to turn a raw space into a filesystem - I saved an engine by SECONDS once, by looking over the shoulder of said sysop as I walked past.... Apart from that, I find that admin is slightly simpler simply because you don't need to run a mkfs style of command ;-) I have heard that Solaris (?) is in the habit of re-creating /dev at boot time, and I know that DG-UX used to do the same thing. Therefore some sort of tool is needed to make sure the raw devs exist after a boot. Is this what you mean?

Andrew Hamm wrote: > > Mark Bole wrote: > > I haven't worked with an Oracle raw device since version 7.3 seven > > years ago, and would never go back. The administrative overhead is > > just too much of a headache. > > [Posting from comp.databases.informix] > > I've never understood the "administrative overhead" argument against raw > spaces. Can you elicidate on the administration you think needs to be > applied? In my experience, the only admin overhead is making sure that a > new, naive sysop doesn't try to turn a raw space into a filesystem - I saved > an engine by SECONDS once, by looking over the shoulder of said sysop as I > walked past.... > > Apart from that, I find that admin is slightly simpler simply because you > don't need to run a mkfs style of command ;-) > > I have heard that Solaris (?) is in the habit of re-creating /dev at boot > time, and I know that DG-UX used to do the same thing. Therefore some sort > of tool is needed to make sure the raw devs exist after a boot. Is this what > you mean? This should only happen with a boot -r, Sun doesn't (used to) guarantee the mapping of mulitple external physical devices (A5200, A1000 etc) is consistent when boot -r'ing. The 'boot -r' asks what's out there and then assigns the devices in the order in which they respond. Mostly it catches lazy sysadmins, or sysadmins without larger server experience out. When the disks are used with filesystems AFAIK Sun can map the FS back to the disks, I'm guessing they use major/minor numbers. Solaris can't do this with the raw disk 'cos Solaris has no idea how they are being used. -- Paul Watson # Oninit Ltd # Growing old is mandatory Tel: +44 1436 672201 # Growing up is optional Fax: +44 1436 678693 # Mob: +44 7818 003457 # www.oninit.com #

Andrew Hamm wrote: > Mark Bole wrote: > >>I haven't worked with an Oracle raw device since version 7.3 seven >>years ago, and would never go back. The administrative overhead is >>just too much of a headache. > > > [Posting from comp.databases.informix] > > I've never understood the "administrative overhead" argument against raw > spaces. Can you elicidate on the administration you think needs to be > applied? In my experience, the only admin overhead is making sure that a > new, naive sysop doesn't try to turn a raw space into a filesystem - I saved > an engine by SECONDS once, by looking over the shoulder of said sysop as I > walked past.... > > Apart from that, I find that admin is slightly simpler simply because you > don't need to run a mkfs style of command ;-) > > I have heard that Solaris (?) is in the habit of re-creating /dev at boot > time, and I know that DG-UX used to do the same thing. Therefore some sort > of tool is needed to make sure the raw devs exist after a boot. Is this what > you mean? > > Gawd, this cross-posting is a little scary... I've touched DB2, administered Sybase for four years in the mid-nineties, otherwise Oracle is it... so take the following for whatever it's worth. To answer the question above: no, actually my experiences with Oracle raw devices were under DEC Ultrix, SGI Irix, and HP-UX. I've only managed "normal" filesystems under Solaris, Linux, and Windows. To this day the thought of messing with the /dev filesystem stresses me out... --) Yes, I've had to recover production (Oracle, Sybase) systems in real life disaster situations: Score: raw filesystems, W-1, L-1. cooked filesystems, W-2, L-0. So you can see where I'm heading... I use "adminstration" in a very tool-oriented sense. With cooked file systems (which I am defining as filesystems the OS is designed for... tautology or no...), there are lots of tools: tools for timestamps, tools for sizes, tools for checksums, tools for copying, tools for finding, tools for checking open handles, and so on. With raw filesystems, I have none of these tools. (OK, wrong if you consider "dd" under Unix to be a tool....) Your own example serves to make my point: the set of admins, naive or otherwise, who stand a chance of disaster recovery with raw filesystems in the 21st century is an order of magnitude less than those who stand a chance of disaster recovery with "normal" filesystems. And just to put the skin on the pudding, isn't the stated direction of MSFT to turn the entire filesystem into a database? Whither raw partitions then? --Mark Bole

Mark Bole wrote: > > Gawd, this cross-posting is a little scary... Not wrong :) but we're being very well-behaved so far. I did see one slur against Sybase's market position, but they've been patient and I thank them for that. We still love you, folks... I was a big fan of Watcom 15 years ago, and i believe it's the spiritual ancestor of Sybase and MS? Sybase split from the Evil Empire, so that's a point in their favour, and in some simple play with MS SQL, it looks like fun... Has that buttered up enough people to keep things happy? > I've touched DB2, > administered Sybase for four years in the mid-nineties, otherwise > Oracle is it... so take the following for whatever it's worth. > > To answer the question above: no, actually my experiences with Oracle > raw devices were under DEC Ultrix, SGI Irix, and HP-UX. I've only > managed "normal" filesystems under Solaris, Linux, and Windows. To > this day the thought of messing with the /dev filesystem stresses me > out... --) True. If you MUST move a lump of data, which the engine thinks is called /dev/rdk0101, then there's no way that can be renamed on many O/S due to naming conventions. I got stuck with that several years ago. I actually cheated and broke the O/S naming convention just to get things working. That was an object lesson. However, common wisdom in the Informix world (probably discovered 1000 times by different people) is to use symbolic links. Personally I use something like /DBCHUNKS/enginename/lump01 -> /dev/blahblah and then the engine can always use the logical name; the physical space will be wherever it's pointed. > Yes, I've had to recover production (Oracle, Sybase) systems in real > life disaster situations: Score: raw filesystems, W-1, L-1. cooked > filesystems, W-2, L-0. So you can see where I'm heading... OK - that's a warning from experience on them engines. OP take note. We have a bunch of Oracle admins in this company, and I don't believe they use raw spaces either. I don't know how they do backups either; I really should lurn from them, but never quite get 'round to it. > I use "adminstration" in a very tool-oriented sense. With cooked file > systems (which I am defining as filesystems the OS is designed for... > tautology or no...), there are lots of tools: tools for timestamps, > tools for sizes, tools for checksums, tools for copying, tools for > finding, tools for checking open handles, and so on. With raw > filesystems, I have none of these tools. (OK, wrong if you consider > "dd" under Unix to be a tool....) ok - I've heard that Oracle has a "variety" of backup procedures, some of them home-cooked, some of them tools you have to pay for. In that case, you would need suitable tools to manage the objects. With Informix, it's shipped with one (now two) tools that perform complete, live, point-in-time archives along with continuous storage of logical logs. Any timestamps etc that need touching are self-contained within the engine spaces, so it's completely unnecessary and almost certainly destructive to do anything with informix spaces apart from via the utilities provided. By the way, you can still perform something like cksum < /dev/rawspace or dd if=/dev/rawspace bs=64k count=XXXk | cksum and so on. Raw devices on unix are still just files. They are just not appropriate to use without some smart access algorithms, such as might be found in database engines... Sure, dd is a wierd utility that doesn't match typical unix command line syntax, but it can still move "files" around. Not that I ever need to do that. Haven't heard any opinions from a DB/2 bod yet. > Your own example serves to make my point: the set of admins, naive or > otherwise, who stand a chance of disaster recovery with raw > filesystems in the 21st century is an order of magnitude less than > those who stand a chance of disaster recovery with "normal" > filesystems. By the same token, a dumb-**** naive sysadmin could easily destroy cooked files in their desperate and thoughtless search for more space. An inexperienced but over-confident admin is a dangerous creature no matter what product they are near. I don't think anyone could do a recovery using the cleaning tapes I mentioned in another reply. Murphy's law at work there. > And just to put the skin on the pudding, isn't the stated direction of > MSFT to turn the entire filesystem into a database? Whither raw > partitions then? MSFT? ?? Micro Soft Something Something? Not interested !:) UNIX and Linux suits me, our application and our customers well. Good luck to Microsoft with their FT, whatever that might be. I'm waiting for any Informix users to contradict me about always using raw with Informix. When the subject comes up over in c.d.i, we get 3 counter-responses. One is the "complicated" argument. One is about certain platforms which contain system calls and filesystems which are specifically tailored for write-through and no buffering. I've seen Solaris has a filesystem option to apply that on the entire file system. On such a machine, you'd only have to ensure contiguity, and to keep other peoples dirty hands out of your spaces. The third counter argument to raw is large high performance storage boxes - good luck to you if your customers or site can afford them. I think a few of our customers should be using them, but aren't. I think a history and principles of raw space on UNIX is worth posting, so the OP can make his/her own decisions... [looks - ok, him, Jim] That will have to wait a few hours, and be yet another oversized posting :-) There are many interesting points and developments along the way, not to mention big fast storage boxes.

Andrew Hamm wrote: [snip] > ok - I've heard that Oracle has a "variety" of backup procedures, some of > them home-cooked, some of them tools you have to pay for. In that case, you > would need suitable tools to manage the objects. With Informix, it's shipped > with one (now two) tools that perform complete, live, point-in-time archives > along with continuous storage of logical logs. Any timestamps etc that need > touching are self-contained within the engine spaces, so it's completely > unnecessary and almost certainly destructive to do anything with informix > spaces apart from via the utilities provided. [snip] For many aeons, it has been this on Oracle. Shell-scripted backups, with commands provided by the database to make the O/S-produced backup recoverable and usable. But since version 8.0 (and we've had 8.1.5, 8.1.6, 8.1.7, 9.0.1, 9.2, and 10g since then), Oracle has provided RMAN -for free- which does cleverer and safer backups than any shell script could manage. It's a command-line tool for the scripting addicts, but has a GUI front-end for those so inclined. Works very nicely. The emphasis is very much on using RMAN these days (when first released it was a bit rough round the edges!), and O/S-based backups are gradually becoming a thing of the past, or at least not too well looked upon, generally (though it's nice to have the choice). Point is, given the context of this discussion, RMAN works just as well with raw devices as it does with file systems, and will happily backup a raw-based database onto a file system, or vice versa. Raw isn't the utterly inflexible nightmare in Oracle it's sometimes made out to be. Regards HJR