Re: Whatcha' wanta have?????

#41

Andrew Hamm wrote:

Quote:

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.

#42

How could i forget this one?

case insensitive comparisons and collating order!

I don't want that applied to CHAR and VARCHAR types, since they are
fast'n'mean byte-wise datatypes. However, since NCHAR and NVARCHAR fields
can have a GLS locales applied, they are ideal for this little extension.

I cannot find an English Locale that has case-insensitive collation. I don't
know about other european GLS locales, but I'd wager they are case sensitive
too, but could profit from caseless.

I'm not sure that everyone would WANT all strings to be caseless; for us we
would want codes to be sensitive but many description strings to be
insensitive, but we could get away with using CHAR and NCHAR as appropriate.
People using French, German, et. al. would not have that luxury.

Therefore i think that GLS locales need to be provided with an inbuilt
alternative to the case sensitivity of the collation, and then NCHAR and
NVARCHAR fields could have an optional WITH NO CASE (c.f. NOT NULL) to set
the field to one style or the other.

Once again, to repeat, plain ole' CHAR fields should not be affected in any
way.

#43

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 (AT) mail (DOT) com> wrote

Quote:

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.

#44

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:

Quote:

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 (AT) mail (DOT) com> wrote

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.

#45

Mark Townsend wrote:

Quote:

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?

)

On a more serious note, I don't see why competent DBAs should be punished
for my cock-ups... I mean, er, ...

Quote:

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 (AT) mail (DOT) com> wrote in message
news:c0cb7h$15c82c$1 (AT) ID-79573 (DOT) 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

#46

Quote:

- a way to tell in what file one wants output of
SET EXPLAIN ON

I like this one, but would suggest a step further (if it makes any sense):
Some kind of API to get the explain from the client side. Currently we have to get file system access to the server where the instance is...

Regards.

#47

As for 9.6 I see 2 important things:
1. Web services
2. BLOB literals

ad. 1
Idea behind stored procedures in SQL database is very similar to that of Web
services. So it seems quite natural that database should expose its stored
procedures as WEB services.
I see that this is:
- useful even in Intranet,
- becoming standard.
Currently in my company we will migrate our database application to .NET.
Even for me as the beginner in .NET concept of exposing application API in
Web Services instead of stored procedures seems straightforward. It would be
even easier if database would support it natively.

It is becoming standard. DB2 and Oracle already have it. Also BEA Tuxedo
middleware. MSSQL and Sybase announced. Don't let Informix be an isolated
data island!

There are some peculiarities with Web services: there are two different
reference platforms:
- .Net
- Apache-Tomcat (java).
As Informix works not only on NT then choice is clear. I'm only afraid about
java: I would prefer implementation not based on java if possible. I just
prefer simpler but faster and more reliable solution.

DB2 also have interesting extension: you can use web service similar as
stored procedure.
In Informix it extends stored procedure implementation method. Currently
Informix have:
- SPL;
- J/SQL (Internet Foundation only);
- C databalades.
I want to add to this list:
- Web Services.

ad 2.
For BYTE, TEXT, CLOB, and BLOB types there are no literals. Why? It just
complicates simple things.
For TEXT and CLOB it would be the same literal as for char(30000) column.
For BYTE and BLOB it have to be some hex literal.

Best Regards,

Robert Sosnowski

IT specialist CK BZ WBK,
e-mail: Robert.Sosnowski (AT) bzwbk (DOT) pl
ul. Pl. Andersa 5, 61-894 Poznañ
phone +48 61 856 54 09
fax +48 61 856 52 36

Quote:

As a mild diversion from the IDS-DB2 conversion thread, its time for one
of
my more favorite exercises. ;-)

We are nearing the end of the coding cycle for IDS 9.5. We've got a whole
bunch of really cool stuff in place and - well - its time to get input
from
you guys as to what you want to see in the 9.6 release.

Now, I know that everyone's favorite thing is going to be "marketing", but
I'm in development. So I need to talk features and functionality. So
feel
free to send them on in.

Just an FYI - I'll be away for a while and won't be able to get email via
my
comcast email address. But, I'll be following the newsgroup rather
closely.

Also, next week I'll be in some planning meeting. So getting responses
back
fairly quickly would really help.

Thanks

M.Pruet

===========================
Wiadomo¶æ ta oraz wszelkie za³±czone do niej pliki s± poufne i mog± byæ prawnie chronione.
Je¿eli nie jest Pan/Pani zamierzonym adresatem niniejszej wiadomo¶ci, nie mo¿e Pan/Pani jej ujawniaæ,
kopiowaæ, dystrybuowaæ ani te¿ w ¿aden inny sposób udostêpniaæ lub wykorzystywaæ.
O b³êdnym zaadresowaniu wiadomo¶ci prosimy niezw³ocznie poinformowaæ nadawcê i usun±æ wiadomo¶æ.
===========================
This email and any attached files are confidential and may be legally privileged.
If you are not the intended recipient, any disclosure, reproduction, copying, distribution,
or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

sending to informix-list

#48

As for 9.6 I see 2 important things:
1. Web services
2. BLOB literals

ad. 1
Idea behind stored procedures in SQL database is very similar to that of Web
services. So it seems quite natural that database should expose its stored
procedures as WEB services.
I see that this is:
- useful even in Intranet,
- becoming standard.
Currently in my company we will migrate our database application to .NET.
Even for me as the beginner in .NET concept of exposing application API in
Web Services instead of stored procedures seems straightforward. It would be
even easier if database would support it natively.

It is becoming standard. DB2 and Oracle already have it. Also BEA Tuxedo
middleware. MSSQL and Sybase announced. Don't let Informix be an isolated
data island!

There are some peculiarities with Web services: there are two different
reference platforms:
- .Net
- Apache-Tomcat (java).
As Informix works not only on NT then choice is clear. I'm only afraid about
java: I would prefer implementation not based on java if possible. I just
prefer simpler but faster and more reliable solution.

DB2 also have interesting extension: you can use web service similar as
stored procedure.
In Informix it extends stored procedure implementation method. Currently
Informix have:
- SPL;
- J/SQL (Internet Foundation only);
- C databalades.
I want to add to this list:
- Web Services.

ad 2.
For BYTE, TEXT, CLOB, and BLOB types there are no literals. Why? It just
complicates simple things.
For TEXT and CLOB it would be the same literal as for char(30000) column.
For BYTE and BLOB it have to be some hex literal.

Best Regards,

Robert Sosnowski

IT specialist CK BZ WBK,
e-mail: Robert.Sosnowski (AT) bzwbk (DOT) pl
ul. Pl. Andersa 5, 61-894 Poznañ
phone +48 61 856 54 09
fax +48 61 856 52 36

Quote:

As a mild diversion from the IDS-DB2 conversion thread, its time for one
of
my more favorite exercises. ;-)

We are nearing the end of the coding cycle for IDS 9.5. We've got a whole
bunch of really cool stuff in place and - well - its time to get input
from
you guys as to what you want to see in the 9.6 release.

Now, I know that everyone's favorite thing is going to be "marketing", but
I'm in development. So I need to talk features and functionality. So
feel
free to send them on in.

Just an FYI - I'll be away for a while and won't be able to get email via
my
comcast email address. But, I'll be following the newsgroup rather
closely.

Also, next week I'll be in some planning meeting. So getting responses
back
fairly quickly would really help.

Thanks

M.Pruet

===========================
Wiadomo¶æ ta oraz wszelkie za³±czone do niej pliki s± poufne i mog± byæ prawnie chronione.
Je¿eli nie jest Pan/Pani zamierzonym adresatem niniejszej wiadomo¶ci, nie mo¿e Pan/Pani jej ujawniaæ,
kopiowaæ, dystrybuowaæ ani te¿ w ¿aden inny sposób udostêpniaæ lub wykorzystywaæ.
O b³êdnym zaadresowaniu wiadomo¶ci prosimy niezw³ocznie poinformowaæ nadawcê i usun±æ wiadomo¶æ.
===========================
This email and any attached files are confidential and may be legally privileged.
If you are not the intended recipient, any disclosure, reproduction, copying, distribution,
or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

sending to informix-list

sending to informix-list

#49

As for 9.6 I see 2 important things:
1. Web services
2. BLOB literals

ad. 1
Idea behind stored procedures in SQL database is very similar to that of Web
services. So it seems quite natural that database should expose its stored
procedures as WEB services.
I see that this is:
- useful even in Intranet,
- becoming standard.
Currently in my company we will migrate our database application to .NET.
Even for me as the beginner in .NET concept of exposing application API in
Web Services instead of stored procedures seems straightforward. It would be
even easier if database would support it natively.

It is becoming standard. DB2 and Oracle already have it. Also BEA Tuxedo
middleware. MSSQL and Sybase announced. Don't let Informix be an isolated
data island!

There are some peculiarities with Web services: there are two different
reference platforms:
- .Net
- Apache-Tomcat (java).
As Informix works not only on NT then choice is clear. I'm only afraid about
java: I would prefer implementation not based on java if possible. I just
prefer simpler but faster and more reliable solution.

DB2 also have interesting extension: you can use web service similar as
stored procedure.
In Informix it extends stored procedure implementation method. Currently
Informix have:
- SPL;
- J/SQL (Internet Foundation only);
- C databalades.
I want to add to this list:
- Web Services.

ad 2.
For BYTE, TEXT, CLOB, and BLOB types there are no literals. Why? It just
complicates simple things.
For TEXT and CLOB it would be the same literal as for char(30000) column.
For BYTE and BLOB it have to be some hex literal.

Best Regards,

Robert Sosnowski

IT specialist CK BZ WBK,
e-mail: Robert.Sosnowski (AT) bzwbk (DOT) pl
ul. Pl. Andersa 5, 61-894 Poznañ
phone +48 61 856 54 09
fax +48 61 856 52 36

Quote:

As a mild diversion from the IDS-DB2 conversion thread, its time for one
of
my more favorite exercises. ;-)

We are nearing the end of the coding cycle for IDS 9.5. We've got a whole
bunch of really cool stuff in place and - well - its time to get input
from
you guys as to what you want to see in the 9.6 release.

Now, I know that everyone's favorite thing is going to be "marketing", but
I'm in development. So I need to talk features and functionality. So
feel
free to send them on in.

Just an FYI - I'll be away for a while and won't be able to get email via
my
comcast email address. But, I'll be following the newsgroup rather
closely.

Also, next week I'll be in some planning meeting. So getting responses
back
fairly quickly would really help.

Thanks

M.Pruet

===========================
Wiadomo¶æ ta oraz wszelkie za³±czone do niej pliki s± poufne i mog± byæ prawnie chronione.
Je¿eli nie jest Pan/Pani zamierzonym adresatem niniejszej wiadomo¶ci, nie mo¿e Pan/Pani jej ujawniaæ,
kopiowaæ, dystrybuowaæ ani te¿ w ¿aden inny sposób udostêpniaæ lub wykorzystywaæ.
O b³êdnym zaadresowaniu wiadomo¶ci prosimy niezw³ocznie poinformowaæ nadawcê i usun±æ wiadomo¶æ.
===========================
This email and any attached files are confidential and may be legally privileged.
If you are not the intended recipient, any disclosure, reproduction, copying, distribution,
or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

sending to informix-list

sending to informix-list
sending to informix-list

#50

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 (AT) hotmail (DOT) com> wrote

Quote:

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?

)

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 (AT) mail (DOT) com> wrote in message
news:c0cb7h$15c82c$1 (AT) ID-79573 (DOT) 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