Re: Whatcha' wanta have?????

Andrew Hamm wrote: > Jonathan Leffler wrote: >> Basically, I lost this argument - and I'm still being a sort loser >> about it, because I think it is fundamentally b******t that we >> can recover from dropping a table and not from truncating it. >> However, here's an external contrary view, so I'm seeking to know why >> it is not critical to recover from a truncated table, even though you >> can recover from a dropped table.] > > I agree with your point of view that IDS has established practice > where everything is logged. I also agree that some operations > probably should not be logged, or only optionally. I have to revisit this - I've moved completely to Jonathans side on this one. I cannot support the case for unlogged commands in IDS. Just because a few enthusiastic DB/2 engineers are now on the committee doesn't mean IDS has to start doing odd little actions the DB/2 way. IDS has always logged everything not just so we can do a ROLLBACK WORK, but in case an engine or machine crash occurs. Without logging, fast recovery can be compromised. Now, if you put a TRUNCATE TABLE command into the engine, then some sites are going to use it and they'll probably like it so much, they'll use it a lot. They are just begging for a disaster to cause their fast recovery to fail; at which point they get the opportunity to test how good their backup procedures are :-/ I do not want an unlogged TRUNCATE TABLE command putting engines at risk. I do not want to spend a night recovering an engine when I could have been sleeping. Please do not put something dangerous in the hands of people who often will not know the risks. I do see a very effective compromise however. We already have raw tables in IDS, specifically for the people who like to live dangerously. Clearly, a TRUNCATE TABLE applied to a raw table will not be logged. If my other idea about raw tables was implemented (ie allowing raw tables to still have disabled indexes etc attached to them) then this gives to everyone, and fits in quite nicely with the characteristics of raw tables. PS - regarding raw tables; putting a table to raw should CAUSE the indexes, constraints etc to be automatically disabled imho. It's a nuicance having to find them all, record their definitions, destroy them and then rebuild them later.

Andrew, Just some trivia, not arguing for or against your points. The ability to control logging is what makes IDS the most totally controlable database on the planet. None of the other databases worth mentioning, except maybe possibly Oracle has the flexibility when it comes to transaction logs. I'm not discounting or dismissing your points, but maybe only pointing out please appreciate the difference IDS brought to the table, for me at least, it's now all academic. The idea, the luxury of arguing the ability to log or not to log, it makes me cry. :-( SQL-Server/Sybase - absolutely no control over logging or size of logs. Everything is logged, no control over size of logs or how many, but you can specify what the size of "the" log should start out at. Inside "the log" file, SQL-Server determines how many logs, when checkpoints occur, how big it gets, etc. Pretty pathetic, totally automatic. DB2 - some ability but not really a planned or thought out ability. Almost no docs on logging at all. Last I checked it's always on. MySQL - Either you use MyISAM with limited low-level "non-logged" logging or InnoDB always-logged. No "dbspaces". MyISAM still has a 4GB limit on tables on Linux. Informix - logged, non-logged, number of logs, size of logs. ondblog, onlog, etc. Totally flexible, checkpoint management, really great monitoring, onstats. Unmatched for DBA control. Lousy backup/restore options. Oracle - has the infamous redo logs, which puts it pretty much Informix's only equal as even coming remotely close to the flexibility of Informix. Gawd I miss Informix for log control, but c'est la vie life goes on. Imagine a world without Informix and you will only begin to understand what it's like out there. LRUs?? Physical Log? Fagetabotit. I'm sure IBM is depending on market ignorance of log control at this point, and also on reverse-ignorance of the Informix community who are so myopic and in many cases Neanderthal about other products. Just this one ability will be lost and quietly forgotten when Informix finally disappears. Enjoy the acedemics while the product lingers, once it's gone, well, it's really the end of a great product. Tim "Andrew Hamm" <ahamm@mail.com> wrote in message news:c0cb7h$15c82c$1@ID-79573.news.uni-berlin.de... > Andrew Hamm wrote: > > Jonathan Leffler wrote: > >> Basically, I lost this argument - and I'm still being a sort loser > >> about it, because I think it is fundamentally b******t that we > >> can recover from dropping a table and not from truncating it. > >> However, here's an external contrary view, so I'm seeking to know why > >> it is not critical to recover from a truncated table, even though you > >> can recover from a dropped table.] > > > > I agree with your point of view that IDS has established practice > > where everything is logged. I also agree that some operations > > probably should not be logged, or only optionally. > > I have to revisit this - I've moved completely to Jonathans side on this > one. I cannot support the case for unlogged commands in IDS. Just because a > few enthusiastic DB/2 engineers are now on the committee doesn't mean IDS > has to start doing odd little actions the DB/2 way. > > IDS has always logged everything not just so we can do a ROLLBACK WORK, but > in case an engine or machine crash occurs. Without logging, fast recovery > can be compromised. > > Now, if you put a TRUNCATE TABLE command into the engine, then some sites > are going to use it and they'll probably like it so much, they'll use it a > lot. They are just begging for a disaster to cause their fast recovery to > fail; at which point they get the opportunity to test how good their backup > procedures are :-/ > > I do not want an unlogged TRUNCATE TABLE command putting engines at risk. I > do not want to spend a night recovering an engine when I could have been > sleeping. Please do not put something dangerous in the hands of people who > often will not know the risks. > > I do see a very effective compromise however. We already have raw tables in > IDS, specifically for the people who like to live dangerously. Clearly, a > TRUNCATE TABLE applied to a raw table will not be logged. If my other idea > about raw tables was implemented (ie allowing raw tables to still have > disabled indexes etc attached to them) then this gives to everyone, and fits > in quite nicely with the characteristics of raw tables. > > PS - regarding raw tables; putting a table to raw should CAUSE the indexes, > constraints etc to be automatically disabled imho. It's a nuicance having to > find them all, record their definitions, destroy them and then rebuild them > later. > >

FYI - there are many at Oracle that would also argue that the ability to control logging at a granular level is a Bad Thing (TM), especially after seeing some of the messes customers can get themselves into with nologging. This would make for an interesting industry debate at some stage. Tim Schaefer wrote: > Andrew, > > Just some trivia, not arguing for or against your points. > > The ability to control logging is what makes IDS the most totally > controlable database on the planet. None of the other databases > worth mentioning, except maybe possibly Oracle has the flexibility > when it comes to transaction logs. I'm not discounting or dismissing > your points, but maybe only pointing out please appreciate the difference > IDS brought to the table, for me at least, it's now all academic. The > idea, the luxury of arguing the ability to log or not to log, it makes > me cry. :-( > > SQL-Server/Sybase - absolutely no control over logging or size of logs. > Everything is logged, no control over size of logs > or how many, but you can specify what the size of > "the" log should start out at. Inside "the log" > file, SQL-Server determines how many logs, when > checkpoints occur, how big it gets, etc. Pretty > pathetic, totally automatic. > > DB2 - some ability but not really a planned or thought out ability. Almost > no docs on logging at all. Last I checked it's always on. > > MySQL - Either you use MyISAM with limited low-level "non-logged" logging > or InnoDB always-logged. No "dbspaces". MyISAM still has a 4GB > limit on tables on Linux. > > Informix - logged, non-logged, number of logs, size of logs. ondblog, onlog, etc. > Totally flexible, checkpoint management, really great monitoring, > onstats. Unmatched for DBA control. Lousy backup/restore options. > > Oracle - has the infamous redo logs, which puts it pretty much Informix's > only equal as even coming remotely close to the flexibility of > Informix. > > Gawd I miss Informix for log control, but c'est la vie life goes on. Imagine > a world without Informix and you will only begin to understand what it's like > out there. LRUs?? Physical Log? Fagetabotit. > > I'm sure IBM is depending on market ignorance of log control at this point, > and also on reverse-ignorance of the Informix community who are so myopic > and in many cases Neanderthal about other products. Just this one ability > will be lost and quietly forgotten when Informix finally disappears. > > Enjoy the acedemics while the product lingers, once it's gone, well, it's > really the end of a great product. > > Tim > > "Andrew Hamm" <ahamm@mail.com> wrote in message news:c0cb7h$15c82c$1@ID-79573.news.uni-berlin.de... > >>Andrew Hamm wrote: >> >>>Jonathan Leffler wrote: >>> >>>>Basically, I lost this argument - and I'm still being a sort loser >>>>about it, because I think it is fundamentally b******t that we >>>>can recover from dropping a table and not from truncating it. >>>>However, here's an external contrary view, so I'm seeking to know why >>>>it is not critical to recover from a truncated table, even though you >>>>can recover from a dropped table.] >>> >>>I agree with your point of view that IDS has established practice >>>where everything is logged. I also agree that some operations >>>probably should not be logged, or only optionally. >> >>I have to revisit this - I've moved completely to Jonathans side on this >>one. I cannot support the case for unlogged commands in IDS. Just because a >>few enthusiastic DB/2 engineers are now on the committee doesn't mean IDS >>has to start doing odd little actions the DB/2 way. >> >>IDS has always logged everything not just so we can do a ROLLBACK WORK, but >>in case an engine or machine crash occurs. Without logging, fast recovery >>can be compromised. >> >>Now, if you put a TRUNCATE TABLE command into the engine, then some sites >>are going to use it and they'll probably like it so much, they'll use it a >>lot. They are just begging for a disaster to cause their fast recovery to >>fail; at which point they get the opportunity to test how good their backup >>procedures are :-/ >> >>I do not want an unlogged TRUNCATE TABLE command putting engines at risk. I >>do not want to spend a night recovering an engine when I could have been >>sleeping. Please do not put something dangerous in the hands of people who >>often will not know the risks. >> >>I do see a very effective compromise however. We already have raw tables in >>IDS, specifically for the people who like to live dangerously. Clearly, a >>TRUNCATE TABLE applied to a raw table will not be logged. If my other idea >>about raw tables was implemented (ie allowing raw tables to still have >>disabled indexes etc attached to them) then this gives to everyone, and fits >>in quite nicely with the characteristics of raw tables. >> >>PS - regarding raw tables; putting a table to raw should CAUSE the indexes, >>constraints etc to be automatically disabled imho. It's a nuicance having to >>find them all, record their definitions, destroy them and then rebuild them >>later. >> >> > > > >

Mark Townsend wrote: > FYI - there are many at Oracle that would also argue that the ability to > control logging at a granular level is a Bad Thing (TM), especially > after seeing some of the messes customers can get themselves into with > nologging. This would make for an interesting industry debate at some > stage. Ah, well, it's just customers, isn't it? :o) On a more serious note, I don't see why competent DBAs should be punished for my cock-ups... I mean, er, ... > Tim Schaefer wrote: >> Andrew, >> >> Just some trivia, not arguing for or against your points. >> >> The ability to control logging is what makes IDS the most totally >> controlable database on the planet. None of the other databases >> worth mentioning, except maybe possibly Oracle has the flexibility >> when it comes to transaction logs. I'm not discounting or dismissing >> your points, but maybe only pointing out please appreciate the difference >> IDS brought to the table, for me at least, it's now all academic. The >> idea, the luxury of arguing the ability to log or not to log, it makes >> me cry. :-( >> >> SQL-Server/Sybase - absolutely no control over logging or size of logs. >> Everything is logged, no control over size of logs >> or how many, but you can specify what the size of >> "the" log should start out at. Inside "the log" >> file, SQL-Server determines how many logs, when >> checkpoints occur, how big it gets, etc. Pretty >> pathetic, totally automatic. >> >> DB2 - some ability but not really a planned or thought out ability. >> Almost >> no docs on logging at all. Last I checked it's always on. >> >> MySQL - Either you use MyISAM with limited low-level "non-logged" logging >> or InnoDB always-logged. No "dbspaces". MyISAM still has a 4GB >> limit on tables on Linux. >> >> Informix - logged, non-logged, number of logs, size of logs. ondblog, >> onlog, etc. >> Totally flexible, checkpoint management, really great >> monitoring, >> onstats. Unmatched for DBA control. Lousy backup/restore >> options. >> >> Oracle - has the infamous redo logs, which puts it pretty much Informix's >> only equal as even coming remotely close to the flexibility of >> Informix. >> >> Gawd I miss Informix for log control, but c'est la vie life goes on. >> Imagine a world without Informix and you will only begin to understand >> what it's like >> out there. LRUs?? Physical Log? Fagetabotit. >> >> I'm sure IBM is depending on market ignorance of log control at this >> point, and also on reverse-ignorance of the Informix community who are so >> myopic >> and in many cases Neanderthal about other products. Just this one >> ability will be lost and quietly forgotten when Informix finally >> disappears. >> >> Enjoy the acedemics while the product lingers, once it's gone, well, it's >> really the end of a great product. >> >> Tim >> >> "Andrew Hamm" <ahamm@mail.com> wrote in message >> news:c0cb7h$15c82c$1@ID-79573.news.uni-berlin.de... >> >>>Andrew Hamm wrote: >>> >>>>Jonathan Leffler wrote: >>>> >>>>>Basically, I lost this argument - and I'm still being a sort loser >>>>>about it, because I think it is fundamentally b******t that we >>>>>can recover from dropping a table and not from truncating it. >>>>>However, here's an external contrary view, so I'm seeking to know why >>>>>it is not critical to recover from a truncated table, even though you >>>>>can recover from a dropped table.] >>>> >>>>I agree with your point of view that IDS has established practice >>>>where everything is logged. I also agree that some operations >>>>probably should not be logged, or only optionally. >>> >>>I have to revisit this - I've moved completely to Jonathans side on this >>>one. I cannot support the case for unlogged commands in IDS. Just because >>>a few enthusiastic DB/2 engineers are now on the committee doesn't mean >>>IDS has to start doing odd little actions the DB/2 way. >>> >>>IDS has always logged everything not just so we can do a ROLLBACK WORK, >>>but in case an engine or machine crash occurs. Without logging, fast >>>recovery can be compromised. >>> >>>Now, if you put a TRUNCATE TABLE command into the engine, then some sites >>>are going to use it and they'll probably like it so much, they'll use it >>>a lot. They are just begging for a disaster to cause their fast recovery >>>to fail; at which point they get the opportunity to test how good their >>>backup procedures are :-/ >>> >>>I do not want an unlogged TRUNCATE TABLE command putting engines at risk. >>>I do not want to spend a night recovering an engine when I could have >>>been sleeping. Please do not put something dangerous in the hands of >>>people who often will not know the risks. >>> >>>I do see a very effective compromise however. We already have raw tables >>>in IDS, specifically for the people who like to live dangerously. >>>Clearly, a TRUNCATE TABLE applied to a raw table will not be logged. If >>>my other idea about raw tables was implemented (ie allowing raw tables to >>>still have disabled indexes etc attached to them) then this gives to >>>everyone, and fits in quite nicely with the characteristics of raw >>>tables. >>> >>>PS - regarding raw tables; putting a table to raw should CAUSE the >>>indexes, constraints etc to be automatically disabled imho. It's a >>>nuicance having to find them all, record their definitions, destroy them >>>and then rebuild them later. -- "C'est pas parce qu'on n'a rien ''' dire qu'il faut fermer sa gueule" - Coluche