Re: Whatcha' wanta have?????

Mark, I don't know Oracle well enough to talk competently about redo logs, but it's my limited understanding they are a bit different than the logical logs in Informix. As I understand it Oracle people live and die with creative log shipping that most Informix people would never even think of doing with logical logs. This is a good thing about Oracle, as I understand it, but the comparison is not quite apples to apples. What I think was one of Informix's greatest strengths, the ability to control tranactional journaling, along with really great tools like onstat, made it superior in performance over the others. Now I'm stuck with a lot of choices in the market that literally hide logical log management, and that makes me nervous about my choices. But if the vendor has a high-speed loader, and good tunable parameters, it overcomes some of the fear of living without that logging control. And I agree, you're right, in many shops it's a good thing the customer doesn't have the control, they're better off without it. SQL-Server for all its simplicity is quite appropriate in most of the environments that use it simply because the talent taking care of it has no idea what they're missing. :-) Tim "Obnoxio The Clown" <obnoxio@hotmail.com> wrote in message news:c0cm0s$14qef5$1@ID-64669.news.uni-berlin.de... > 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 th

All - I appreciate all of the input, but let's try to avoid letting this turn into an Oracle vrs. IDS thread. We're seeing a lot of really good ideas and I appreciate the input. Thanks M.P. "Tim Schaefer" <tim@spamethnot.com> wrote in message news:<90qWb.77458$Ux4.15283@fe10.usenetserver.com>... > Mark, > > I don't know Oracle well enough to talk competently about redo logs, > but it's my limited understanding they are a bit different than the > logical logs in Informix. As I understand it Oracle people live and > die with creative log shipping that most Informix people would never > even think of doing with logical logs. This is a good thing about > Oracle, as I understand it, but the comparison is not quite apples > to apples. > > What I think was one of Informix's greatest strengths, the ability > to control tranactional journaling, along with really great tools > like onstat, made it superior in performance over the others. Now > I'm stuck with a lot of choices in the market that literally hide > logical log management, and that makes me nervous about my choices. > > But if the vendor has a high-speed loader, and good tunable parameters, > it overcomes some of the fear of living without that logging control. > And I agree, you're right, in many shops it's a good thing the customer > doesn't have the control, they're better off without it. SQL-Server > for all its simplicity is quite appropriate in most of the environments > that use it simply because the talent taking care of it has no idea > what they're missing. :-) > > Tim > > "Obnoxio The Clown" <obnoxio@hotmail.com> wrote in message news:c0cm0s$14qef5$1@ID-64669.news.uni-berlin.de... > > 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