Re: Why there is no controlfile in Informix like Oracle ?

Madison Pruet wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1093580806.482596@yasure... > > >>Failure to understand one's environment and back up required resources >>is the sign of a moron at the wheel. That is not a reflection on the >>product. More importantly ... anyone with even mediocre skills knows how >>to dynamically regenerate the control files. >> >>-- >>Daniel A. Morgan >>University of Washington >>damorgan@x.washington.edu >>(replace 'x' with 'u' to respond) >> > > > Daniel, > > Fundamental rule of encapsulation --- Everything that's needed for an object > is to be self-contained within that object. Meaning that if you don't have that object you are toast. That is not how any of the major systems works. > Fundamental rule for backups --- Everything that's needed to restore the > system is to be self-contained within the backup. True but irrelevant. > Fundamental rule of operations --- If it can go wrong - it will. So you don't think any backup of any system has ever been successful? > Fundamental rule of DBAs --- Most DBA's are not internalists. Nonsense. Most DBAs are competent. > Fundamental rule of most businessess... The DBA is expendable. Why not > hire an entry clerk to monitor the system. ;-) > > M.P. Then let them be toast. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1093612024.959247@yasure... > Madison Pruet wrote: > > > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > > news:1093580806.482596@yasure... > > > > > >>Failure to understand one's environment and back up required resources > >>is the sign of a moron at the wheel. That is not a reflection on the > >>product. More importantly ... anyone with even mediocre skills knows how > >>to dynamically regenerate the control files. > >> > >>-- > >>Daniel A. Morgan > >>University of Washington > >>damorgan@x.washington.edu > >>(replace 'x' with 'u' to respond) > >> > > > > > > Daniel, > > > > Fundamental rule of encapsulation --- Everything that's needed for an object > > is to be self-contained within that object. > > Meaning that if you don't have that object you are toast. That is not > how any of the major systems works. Err -- are you suggesting that my automobile is not self-contained? > > > Fundamental rule for backups --- Everything that's needed to restore the > > system is to be self-contained within the backup. > > True but irrelevant. How can that be irrelevant? That's the fundamental discussion of the thread. > > > Fundamental rule of operations --- If it can go wrong - it will. > > So you don't think any backup of any system has ever been successful? No - The backups are successful. It's the restores that aren't always successful. And more times that not because a lack of following encapsulation rules. > > > Fundamental rule of DBAs --- Most DBA's are not internalists. > > Nonsense. Most DBAs are competent. I said that most DBA's are not internalists, not that they were incompentent. Big difference, don't you think? Surely, you don't think that the DBA should have to have source-level knowledge of the system to perform their job. Surely you aren't suggesting that the DBA should have to have detailed knowledge of the algorthms within the system to perform their functionality. > > > Fundamental rule of most businessess... The DBA is expendable. Why not > > hire an entry clerk to monitor the system. ;-) > > > > M.P. > > Then let them be toast. > -- > Daniel A. Morgan > University of Washington > damorgan@x.washington.edu > (replace 'x' with 'u' to respond) >

Madison Pruet wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message >>>Fundamental rule of encapsulation --- Everything that's needed for an object >>>is to be self-contained within that object. >> >>Meaning that if you don't have that object you are toast. That is not >>how any of the major systems works. > > Err -- are you suggesting that my automobile is not self-contained? > > >>>Fundamental rule for backups --- Everything that's needed to restore the >>>system is to be self-contained within the backup. >> >>True but irrelevant. > > > How can that be irrelevant? That's the fundamental discussion of the > thread. True because a backup that didn't contain everything required to restore that backup would never work by definition. Irrelevant because that statement is true of every database on the planet more sophisticated than a set of 3x5 cards. If a control file is required to restore the backup than the control file must be included. If it isn't required then it isn't backed up. A statement that is true but of little value. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1093710314.191549@yasure... > Madison Pruet wrote: > > > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > > >>>Fundamental rule of encapsulation --- Everything that's needed for an object > >>>is to be self-contained within that object. > >> > >>Meaning that if you don't have that object you are toast. That is not > >>how any of the major systems works. > > > > Err -- are you suggesting that my automobile is not self-contained? > > > > > >>>Fundamental rule for backups --- Everything that's needed to restore the > >>>system is to be self-contained within the backup. > >> > >>True but irrelevant. > > > > > > How can that be irrelevant? That's the fundamental discussion of the > > thread. > > True because a backup that didn't contain everything required to restore > that backup would never work by definition. > > Irrelevant because that statement is true of every database on the > planet more sophisticated than a set of 3x5 cards. > > If a control file is required to restore the backup than the control > file must be included. If it isn't required then it isn't backed up. > A statement that is true but of little value. Daniel -- I'm afraid that you're showing circular logic. If the backup is encapsulated (rule #1) then the control information is self contained in the database backup. If control information is not able to be self contained within the backup, then we are not dealing with a sophisticated system, just an overly-complicated one. The whole topic of this thread was why Informix doesn't need a control file. Well -- the reason is because the control information is embeded within the database. So it is backed up and restored as part of the database itself. So while some systems may require careful backup of multiple things so that the backup is complete, that is not the case with IDS. > > -- > Daniel A. Morgan > University of Washington > damorgan@x.washington.edu > (replace 'x' with 'u' to respond) >

Madison Pruet wrote: > Daniel -- I'm afraid that you're showing circular logic. Not at all as I hope you will see. > If the backup is encapsulated (rule #1) then the control information is self > contained in the database backup. Exactly. I can't think of any other way to do it. Can you? If control information is not able to be > self contained within the backup, then we are not dealing with a > sophisticated system, just an overly-complicated one. It is if you follow the instructions on how to perform the backup. I don't think you can count as a backup something done that contravenes the instructions on how to perform a backup. Can you? > The whole topic of this thread was why Informix doesn't need a control file. > Well -- the reason is because the control information is embeded within the > database. So it is backed up and restored as part of the database itself. What to you constitutes a database in Informix and what do you believe is the equivalent physical object(s) in Oracle? > So while some systems may require careful backup of multiple things so that > the backup is complete, that is not the case with IDS. Does the Informix database exist anywhere, larger than Mom'sCookierecipeDB, that does not consist of multiple physical files? If so exactly what do you think will be the result of backing up only one of those physical files if another one is lost? -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1093731823.325925@yasure... > Madison Pruet wrote: > > > Daniel -- I'm afraid that you're showing circular logic. > > Not at all as I hope you will see. > > > If the backup is encapsulated (rule #1) then the control information is self > > contained in the database backup. > > Exactly. I can't think of any other way to do it. Can you? > > If control information is not able to be > > self contained within the backup, then we are not dealing with a > > sophisticated system, just an overly-complicated one. > > It is if you follow the instructions on how to perform the backup. I > don't think you can count as a backup something done that contravenes > the instructions on how to perform a backup. Can you? Why should the user have to follow a lot of instructions to back up the system? Is Oracle really that complicate to administer. Doesn't Oracle believe in self management? On IDS, all the user has to do to make a backup of the entire database is to issue.... ontape -s to retore everything ontape -r Are you telling me that the Oracle system is more complicated than that? - that it is not ensuring that control information is not embedded in the backup? - that the user has to be careful not to screw it up? > > > The whole topic of this thread was why Informix doesn't need a control file. > > Well -- the reason is because the control information is embeded within the > > database. So it is backed up and restored as part of the database itself. > > What to you constitutes a database in Informix and what do you believe > is the equivalent physical object(s) in Oracle? > > > So while some systems may require careful backup of multiple things so that > > the backup is complete, that is not the case with IDS. > > Does the Informix database exist anywhere, larger than > Mom'sCookierecipeDB, that does not consist of multiple physical files? > If so exactly what do you think will be the result of backing up only > one of those physical files if another one is lost? The IDS backup automatically encapsulates the pieces. Are you telling me that Oracle doesn't? > > -- > Daniel A. Morgan > University of Washington > damorgan@x.washington.edu > (replace 'x' with 'u' to respond) >

"Madison Pruet" <mpruet@comcast.net> wrote in message news:LV9Yc.200069$8_6.167839@attbi_s04... > > Why should the user have to follow a lot of instructions to back up the > system? Is Oracle really that complicate to administer. Doesn't Oracle > believe in self management? > > On IDS, all the user has to do to make a backup of the entire database is to > issue.... > > ontape -s> > to retore everything > > ontape -r ... or restore from tape two extraneous files, ixbar and onconfg, which he's also remembered to backup, and restore these before issuing the onbar restore command. Why should the user have to follow a lot of instructions to back up the system? Is Informix really that complicated to administer ...? :-) Point is, Madison, that in either Oracle or Informix, so long as you know what you're doing, backups are relatively straightforward to execute and - I know this is an objective matter - I don't believe that Oracle is significantly inferior in this respect.

Also sprach "Captain Pedantic" <theharlequin36@hotmail.com> : :"Madison Pruet" <mpruet@comcast.net> wrote in message :news:LV9Yc.200069$8_6.167839@attbi_s04... :> :> Why should the user have to follow a lot of instructions to back up the :> system? Is Oracle really that complicate to administer. Doesn't Oracle :> believe in self management? :> :> On IDS, all the user has to do to make a backup of the entire database is :to :> issue.... :> :> ontape -s :> :> to retore everything :> :> ontape -r : :... or restore from tape two extraneous files, ixbar and onconfg, which he's :also remembered to backup, and restore these before issuing the onbar :restore command. :Why should the user have to follow a lot of instructions to back up the :system? Is Informix really that complicated to administer ...? :-) : :Point is, Madison, that in either Oracle or Informix, so long as you know :what you're doing, backups are relatively straightforward to execute and - I :know this is an objective matter - I don't believe that Oracle is :significantly inferior in this respect. : Not significantly inferior, but.. Having done backups and restores with both, I have to say that Informix is at least somewhat easier in this regard. As you state, "so long as you know what you are doing" they are relatively straightforward for both, but IMHO you have to know a lot more with Oracle to really know what you are doing. Now to be fair, this really depends a lot on *how* you are doing your backups, as there are traditionally more options in this regard with Oracle than Informix, though the latest versions of each appear to have brought them more on par with each other. What I will call the "old" way of backing up Oracle (and in all cases here, I will assume "hot" backups) is to put each tablespace into backup mode, then use your favorite tool to backup the files and the control file(s), then take them out of backup mode. As each file is effectively an independent object, how the entire backup is accomplished is entirely up to the admin performing the backup. The timestamps on the control file are quite important. If you don't have a control file that corresponds correctly with your tablespace backups, recovery is at least somewhat more complicated. Thus the onus is placed on the admin to keep everything straight. In the case of informix, the backup tool is part of the product, and handles collecting all the necessary pieces (what would equate to tablespace files and control files in oracle) into one backup object. For recovery to a working system, one need only perform the restore operation - no need to worry about how the backup was done, whether all the needed pieces are there, etc. This is, of course, a simplified example, and does not take into account log recovery (which is NOT necessary with informix to get back to a *working* system - not necessarily an up-to-date one). I find this to be an easier process. YMMV. Now when we get to the most recent capabilities, Oracle's RMAN tool handles coordinating all the pieces needed for a restore, making the admin's job much easier in this regard. Informix provides comparable capability with onbar. Both use a database to store the backup info (which presents a further complication should you lose your backup catalog database). Informix goes it a step better, I think, by also writing the data needed for restore out to a text file, providing some protection against loss of the backup catalog database. Oracle lets you use the control file for backup info, but, as far as I know, only as a alternative to the database, i.e. it won't use both. They are both dependant on an SM layer (in both cases provided with the base product - and both use Legato Networker, so equal setup work required there) and both require some backup of files outside the database - control and config files for Oracle, config file and ixbar files for Informix. Just another 2 cents for the kitty.... Dave

"Captain Pedantic" <theharlequin36@hotmail.com> wrote in message news:2pdse9Fj4iabU1@uni-berlin.de... > "Madison Pruet" <mpruet@comcast.net> wrote in message > news:LV9Yc.200069$8_6.167839@attbi_s04... > > > > Why should the user have to follow a lot of instructions to back up the > > system? Is Oracle really that complicate to administer. Doesn't Oracle > > believe in self management? > > > > On IDS, all the user has to do to make a backup of the entire database is > to > > issue.... > > > > ontape -s> > > > to retore everything > > > > ontape -r> > ... or restore from tape two extraneous files, ixbar and onconfg, which he's > also remembered to backup, and restore these before issuing the onbar > restore command. > Why should the user have to follow a lot of instructions to back up the > system? Is Informix really that complicated to administer ...? :-) touche... sorta. ;-) I will admit that adding storage managers and partial backups do complicate things a bit. I'm not sure if the onconfig backup is totally necessary with ontape since we display the chunk and dbspace information with the restore. But I will admit that it makes it much easier. I just really don't like some of the things that Daniel has said. And I particularly don't like him twisting my words to make it sound like I said something that I didn't. That's intellectual dishonesty. Daniel is supposed to be an educator, and I would expect him to be honest in his responses. He has not. Here's the ones that have particularly irritated me. 1) Twisting my words about "most DBAs as not having internal knowledge" to be "most DBAs are incompetent". 2) Arguing that encapsulation is a bad thing. 3) Twisting my words about "If something can go wrong, it will" to be "no backup has ever been successful". I try very hard to be as honest, factual, and helpful in this newsgroup as I possibably can, and resent Daniel's apparent attempt to twist my statements into somthing that I did not say. The one stating that I implied that most DBAs were incompetent really chaps me. I don't think that I've ever said or thought that. In fact, I think that any customer that has ever worked with me directly, or through email knows that. (Copy of Daniel's reply to one of my postings...) >> Daniel, >> >> Fundamental rule of encapsulation --- Everything that's needed for an object >> is to be self-contained within that object. > >Meaning that if you don't have that object you are toast. That is not >how any of the major systems works. > >> Fundamental rule for backups --- Everything that's needed to restore the >> system is to be self-contained within the backup. > >True but irrelevant. > >> Fundamental rule of operations --- If it can go wrong - it will. > >So you don't think any backup of any system has ever been successful? > >> Fundamental rule of DBAs --- Most DBA's are not internalists. > >Nonsense. Most DBAs are competent. The honorable thing to do would be for Daniel to appoligize to me. For some reason, I doubt that will happen.

Madison Pruet wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1093731823.325925@yasure... > >>Madison Pruet wrote: >> >> >>>Daniel -- I'm afraid that you're showing circular logic. >> >>Not at all as I hope you will see. >> >> >>>If the backup is encapsulated (rule #1) then the control information is > > self > >>>contained in the database backup. >> >>Exactly. I can't think of any other way to do it. Can you? >> >> If control information is not able to be >> >>>self contained within the backup, then we are not dealing with a >>>sophisticated system, just an overly-complicated one. >> >>It is if you follow the instructions on how to perform the backup. I >>don't think you can count as a backup something done that contravenes >>the instructions on how to perform a backup. Can you? > > > > Why should the user have to follow a lot of instructions to back up the > system? Is Oracle really that complicate to administer. Doesn't Oracle > believe in self management? The user shouldn't be backing up the system ... a DBA should be. And to extend your thought why should a DBA have to do tuning or read instructions on how to install or patch either? Why can't those damnable software companies just write perfect code and why can't cars drive themselves and not get into accidents? Oh yeah ... drivers that don't do what they are supposed to do. Sarcasm aside I can back up an Oracle database by using the correct tools, OEM configuring RMAN, with just a few mouse clicks and it always does a perfect job. That some people insist on going to the command line, not following the instructions, doing it the hard way and making mistakes is not Oracle's fault any more than is it the fault of Informix that someone might choose to try to insert records into a table with vi. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1093800827.786475@yasure... > And to > extend your thought why should a DBA have to do tuning or read > instructions on how to install or patch either? Why can't those damnable > software companies just write perfect code and why can't cars drive > themselves and not get into accidents? Well actually, Daniel old chum, IBM actually has! They have invented something called 'autonomic computing', where the database actually heals itself, so you don't *need* all those expensive people who know what they're doing to have a system that runs perfectly, 365x24x7.

Captain Pedantic wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1093800827.786475@yasure... > > >>And to >>extend your thought why should a DBA have to do tuning or read >>instructions on how to install or patch either? Why can't those damnable >>software companies just write perfect code and why can't cars drive >>themselves and not get into accidents? > > > Well actually, Daniel old chum, IBM actually has! They have invented > something called 'autonomic computing', where the database actually heals > itself, so you don't *need* all those expensive people who know what they're > doing to have a system that runs perfectly, 365x24x7. Wow! What are all those unemployed DB2 DBAs doing for work these days? -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

On Sun, 29 Aug 2004 17:11:30 -0400, Captain Pedantic wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1093800827.786475@yasure... > >> And to >> extend your thought why should a DBA have to do tuning or read instructions >> on how to install or patch either? Why can't those damnable software >> companies just write perfect code and why can't cars drive themselves and >> not get into accidents? > > Well actually, Daniel old chum, IBM actually has! They have invented > something called 'autonomic computing', where the database actually heals > itself, so you don't *need* all those expensive people who know what they're > doing to have a system that runs perfectly, 365x24x7. Oh great, like I'm not redundant enough. Art S. Kagel

Art S. Kagel wrote: > On Sun, 29 Aug 2004 17:11:30 -0400, Captain Pedantic wrote: > > >>"Daniel Morgan" <damorgan@x.washington.edu> wrote in message >>news:1093800827.786475@yasure... >> >> >>>And to >>>extend your thought why should a DBA have to do tuning or read instructions >>>on how to install or patch either? Why can't those damnable software >>>companies just write perfect code and why can't cars drive themselves and >>>not get into accidents? >> >>Well actually, Daniel old chum, IBM actually has! They have invented >>something called 'autonomic computing', where the database actually heals >>itself, so you don't *need* all those expensive people who know what they're >>doing to have a system that runs perfectly, 365x24x7. > > > Oh great, like I'm not redundant enough. > > Art S. Kagel Interesting how the best interests of developers and DBAs is not always in line with the best interests of the software companies. When has that ever happened before? ;-) I make my choices based on what puts food in the fridge and pays the mortgage. Apparently someone designing software thinks we will blindly support their attempts to put us all in an unemployment line. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)