Re: Whatcha' wanta have?????

#21

See below

Quote:

From: Art S. Kagel [mailto:kagel (AT) erols (DOT) com]

Keep moving us towards a no-down-time server as much as possible.
Such as (some mentioned by others):

- Online index build - without locking the table - A dirty read is
used to build the index then logical log records are replayed to clean
up keys that were added, rolled back, or deleted during the build.
During the build the index is marked disabled and is reenabled once
the build is completed.

Dirty read is not enough to build index 'online'.
One can use mechanism similar to what ONTAPE is doing during archiving:
one can keep old copies of data pages in temporary dbspace,
and, during index build, take 'backuped' copies of those pages,
which timestamp exceeds the 'index build start' timestamp.

Then, Logical log can really be used to roll forward subsequent changes.

'Online' build should be specified as a special option of
'CREATE INDEX' SQL statement, line 'CREATE INDEX ... NONBLOCKING'

That would be a really cool feature which is really needed
for 24x7 systems (like mine). I couldn't even dream about it,
this is why I didn't mention it in my proposal.

The other feature highly desirable for 24x7 is:
GET RID OF ERROR 710!!!! (After alter table, build index, etc)

That is, after executing any DDL statement that changes table
version all prepared SQL statements, open cursors and stored procedures
related to that table became invalid, and user session get -710 error.

If these two features (online index build and online alter table)
get implemented in 9.60, IDS will became THE BEST RDBMS FOR 24x7 SYSTEMS!!!

Best regards,
Alexey Sonkin
sending to informix-list

#22

See below

Quote:

From: Art S. Kagel [mailto:kagel (AT) erols (DOT) com]

Keep moving us towards a no-down-time server as much as possible.
Such as (some mentioned by others):

- Online index build - without locking the table - A dirty read is
used to build the index then logical log records are replayed to clean
up keys that were added, rolled back, or deleted during the build.
During the build the index is marked disabled and is reenabled once
the build is completed.

Dirty read is not enough to build index 'online'.
One can use mechanism similar to what ONTAPE is doing during archiving:
one can keep old copies of data pages in temporary dbspace,
and, during index build, take 'backuped' copies of those pages,
which timestamp exceeds the 'index build start' timestamp.

Then, Logical log can really be used to roll forward subsequent changes.

'Online' build should be specified as a special option of
'CREATE INDEX' SQL statement, line 'CREATE INDEX ... NONBLOCKING'

That would be a really cool feature which is really needed
for 24x7 systems (like mine). I couldn't even dream about it,
this is why I didn't mention it in my proposal.

The other feature highly desirable for 24x7 is:
GET RID OF ERROR 710!!!! (After alter table, build index, etc)

That is, after executing any DDL statement that changes table
version all prepared SQL statements, open cursors and stored procedures
related to that table became invalid, and user session get -710 error.

If these two features (online index build and online alter table)
get implemented in 9.60, IDS will became THE BEST RDBMS FOR 24x7 SYSTEMS!!!

Best regards,
Alexey Sonkin
sending to informix-list

sending to informix-list

#23

See below

Quote:

From: Art S. Kagel [mailto:kagel (AT) erols (DOT) com]

Keep moving us towards a no-down-time server as much as possible. Such
as (some mentioned by others):

- Online index build - without locking the table - A dirty read is
used to build the index then logical log records are replayed to clean
up keys that were added, rolled back, or deleted during the build.
During the build the index is marked disabled and is reenabled once
the build is completed.

Dirty read is not enough to build index 'online'.
One can use mechanism similar to what ONTAPE is doing during archiving: one
can keep old copies of data pages in temporary dbspace, and, during index
build, take 'backuped' copies of those pages, which timestamp exceeds the
'index build start' timestamp.

Then, Logical log can really be used to roll forward subsequent changes.

'Online' build should be specified as a special option of 'CREATE INDEX' SQL
statement, line 'CREATE INDEX ... NONBLOCKING'

That would be a really cool feature which is really needed
for 24x7 systems (like mine). I couldn't even dream about it, this is why I
didn't mention it in my proposal.

The other feature highly desirable for 24x7 is:
GET RID OF ERROR 710!!!! (After alter table, build index, etc)

That is, after executing any DDL statement that changes table version all
prepared SQL statements, open cursors and stored procedures related to that
table became invalid, and user session get -710 error.

If these two features (online index build and online alter table) get
implemented in 9.60, IDS will became THE BEST RDBMS FOR 24x7 SYSTEMS!!!

Best regards,
Alexey Sonkin

sending to informix-list

#24

See below

Quote:

From: Art S. Kagel [mailto:kagel (AT) erols (DOT) com]

Keep moving us towards a no-down-time server as much as possible. Such
as (some mentioned by others):

- Online index build - without locking the table - A dirty read is
used to build the index then logical log records are replayed to clean
up keys that were added, rolled back, or deleted during the build.
During the build the index is marked disabled and is reenabled once
the build is completed.

Dirty read is not enough to build index 'online'.
One can use mechanism similar to what ONTAPE is doing during archiving: one
can keep old copies of data pages in temporary dbspace, and, during index
build, take 'backuped' copies of those pages, which timestamp exceeds the
'index build start' timestamp.

Then, Logical log can really be used to roll forward subsequent changes.

'Online' build should be specified as a special option of 'CREATE INDEX' SQL
statement, line 'CREATE INDEX ... NONBLOCKING'

That would be a really cool feature which is really needed
for 24x7 systems (like mine). I couldn't even dream about it, this is why I
didn't mention it in my proposal.

The other feature highly desirable for 24x7 is:
GET RID OF ERROR 710!!!! (After alter table, build index, etc)

That is, after executing any DDL statement that changes table version all
prepared SQL statements, open cursors and stored procedures related to that
table became invalid, and user session get -710 error.

If these two features (online index build and online alter table) get
implemented in 9.60, IDS will became THE BEST RDBMS FOR 24x7 SYSTEMS!!!

Best regards,
Alexey Sonkin

sending to informix-list

sending to informix-list

#25

encrypted communication between HDR pair. Would be nice.

esteban.-

"Madison Pruet" <mpruet (AT) comcast (DOT) net> wrote

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

#26

David Williams wrote:

Quote:

2. create table..with no first extent size specified should not allocate an
extent
(why waste space if the table is not used by this particular customer
e.g. SAP/Baan
etc with 40,000 tables!!)
Uhum.. yep heard about that one.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

#27

Auto Update Statistics (i.e A set and forget option)

To be done under some logical and meaningful circumstances
- Change in number of rows by x%
- Update of index columns by y%

Optionally, this to be selectable so certain tables can be eliminated from the list of Auto Statistics (Default = All Tables).
Optionally, this can be restricted to certain time of day intervals (Default = All Times).

When corrupt column distributions are found, the table is flagged for update statistics and the distributions are ignored for this sql - rather than returning the Invalid Distributions error code to the application.

MW

sending to informix-list

#28

Auto Update Statistics (i.e A set and forget option)

To be done under some logical and meaningful circumstances
- Change in number of rows by x%
- Update of index columns by y%

Optionally, this to be selectable so certain tables can be eliminated from the list of Auto Statistics (Default = All Tables).
Optionally, this can be restricted to certain time of day intervals (Default = All Times).

When corrupt column distributions are found, the table is flagged for update statistics and the distributions are ignored for this sql - rather than returning the Invalid Distributions error code to the application.

MW

sending to informix-list

sending to informix-list

#29

Quote:

-----Original Message-----
From: Alexey Sonkin [mailto:alexeis (AT) grandvirtual (DOT) com]

snipped

The other feature highly desirable for 24x7 is:
GET RID OF ERROR 710!!!! (After alter table, build index, etc)

That is, after executing any DDL statement that changes table
version all
prepared SQL statements, open cursors and stored procedures
related to that
table became invalid, and user session get -710 error.

Related: Implement outstanding feature request to run "set optimization low"
from the *server* side.

Also, I will "second" the earlier request to increase ER usability in an HA
environment.

Paul Mosser
sending to informix-list

#30

Quote:

-----Original Message-----
From: Alexey Sonkin [mailto:alexeis (AT) grandvirtual (DOT) com]

snipped

The other feature highly desirable for 24x7 is:
GET RID OF ERROR 710!!!! (After alter table, build index, etc)

That is, after executing any DDL statement that changes table
version all
prepared SQL statements, open cursors and stored procedures
related to that
table became invalid, and user session get -710 error.

Related: Implement outstanding feature request to run "set optimization low"
from the *server* side.

Also, I will "second" the earlier request to increase ER usability in an HA
environment.

Paul Mosser
sending to informix-list

sending to informix-list