SEO

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

"Madison Pruet" <mpruet@comcast.net> wrote in message
news:yCVUb.239099$xy6.1249571@attbi_s02...
> 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.
>

OK...

1. Ability to be able to change the owner of anything.
2. Ability to be able to rename anything.

Surely these are fairly simple?

Harder ones...

1. If have have a down chunk the ability to be able to restore just that
chunk and the rollforward
logs on just that chunk. ala Oracle recover datafile

2. Transportable table..I mean dbspaces...ala Oracle

3. That onmode -B to flush stuff to disk (useful to reduce checkpoint
times) to be
documented and supported

4. Fix that bug listing in PTS where oncheck does not check everything it
could
i.e. a better oncheck.





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

When indexes, constraints, etc are disabled, still there are some operations
that cannot be performed. For example, if you want to change a table to raw
state, you must drop the constraints, not just disable them. It's a flipping
nuisance.

Since a disabled constraint or index is going to be rebuilt anyway, why not
treat it as "gone" for the purposes mentioned above?

On the subject of raw tables, you cannot change their schema. Catch 22 when
you are trying dirty tricks to quickly administer large tables. We all know
we need to take a real level zero afterwards...

Similar vein: under ER, changes of schema, disabling constraints and a few
other oddities are blocked or cause administration problems. Changing a
table quickly without having to resyncronize is a hassle. Can't a change of
schema be accommodated? If the "select *" in the replicants was treated as
an expanded list of columns, then adding a column at either end shouldn't
have any effect on the replication. I suppose there are housekeeping issues.
Are there any scientific reasons against allowing this?

Let us add a column at one end, change it later at the other end, and we'll
worry about sync if the column needs it. When it doesn't, the process should
be a lot lighter than it currently is.

oooooh yeah - here's a must-have admin facility: add a new state that is not
online, not quiescent, but which will allow SPECIFIC users to connect and do
work. The list could be just informix by default, or a short list of users
defined elsewhere. On some sites, if you bring the engine online to do some
SQL admin, the bloody over-enthusiastic users will connect and make a mess
of your administration.

Related: the ability to bring up or shutdown connectors - eg we could also
control administration by making all users connect via a tcp or ipc
connector. Only administrators get local connectivity with shm connectors.
Therefore, if we can dynamically shutdown the tcp and ipc connectors
(gracefully or immediately) then we have another alternative to
administration. If ER is used on the site, then perhaps ER connections could
be allowed to stay running. This implies that the connectors are still
listening, but they are refusing connections to most attempts.

Madison Pruet wrote:

> 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.

How about the the ability to rename a database? (That's one for our older
viewers... )

Online index builds? (Nasty, I know.)
Better support for extended data types with HDR and remote access.

--
"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

Andrew Hamm wrote:
>[...]
> oooooh yeah - here's a must-have admin facility: add a new state that is
not
> online, not quiescent, but which will allow SPECIFIC users to connect and
do
> work. The list could be just informix by default, or a short list of users
> defined elsewhere. On some sites, if you bring the engine online to do
some
> SQL admin, the bloody over-enthusiastic users will connect and make a mess
> of your administration.

This would be beautiful! I've also had over-enthusiastic users get in the
way... forced me to show my dark side. Of course, I could have disabled
their login ids (having the root password has its advantages)... or gone
through some other motions with the network. But the new state that Andrew
suggests would be a very nice option.

--
June Hunt

Madison Pruet wrote:

> 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.

Since no one else took the opportunity: "marketing". )

--
"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

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.

- Built-in table compression/reorg command that in a transaction
rewrites rows filling partial and empty pages, releaseing empty
extents and truncating extents that are partially used (perhaps with a
given slack factor, but not neccessarily explicit say leave up to NEXT
SIZE free in the last extent) - COMPRESS TABLE tablename <IN PLACE>
.....; The IN PLACE option controls whether new extents are allocated
to make the table more contiguous or existing extents are simply
compressed.

- Use the logical log rollforward from the online index build to make
an online index/constraint enable option as long as the needed logical
logs are still online. If not a full index rebuild is needed which
an be performed using the full online index build code.

- Better support for using ER for HA replication, perhaps a database
level replication which would permit DDL to be replicated as well.

- Support for multiple HDR replicants.

- Support for concurrent connection to primary and at least one
replicant and passing of transaction information in HDR from primary
to replicant for seamless failover. If sufficient information and
data has been passed to the replicant, then transactions can continue
on the alternative connection unhindered assuming all the needed data
has been passed from the primary (see later on). If a recovery
rollback is triggered on the replicant that affects a particular
transaction that transaction alone will receive a replication error
and its transaction will be marked invalid. Missing data can be
verified by the primary passing transaction management data OOB to the
client. If the transaction progress stamp from the client is later
than that which the replicant finds in its logs after taking over then
the transaction is trashed due to data not transferred from the
primary prior to failure. Basically then an open transaction, after a
primary server failure, is handled more like a 2-Phase Commit problem
with the client acting as transaction coordinator in part. If the
client is lost the transaction has to be rolled back or committed
regardless using standard lost connection rules. It might even be
possible to support this in ER with sychronous replication.

Art S. Kagel

Madison Pruet wrote:

> 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
>
>

"Madison Pruet" <mpruet@comcast.net> wrote in message
news:yCVUb.239099$xy6.1249571@attbi_s02...
> 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.

- How about allowing the administrator the option to skip logical recovery
at database startup time? Obviously, you'd want to restirct it to people
who know what they're doing. Like me! Perhaps you'd have to type in your
Informix Certified Professional ID to enable it ....
- Truncate table, as previously mentioned.
- More information about the progress of long utilities, like ALTER
FRAGMENT...INIT IN
- Is there an inherent reason to prevent querying of a logged database from
an unlogged one?
- Better integration with HP Data Protector (but I'm in Dreamland now).

Would that we DDL or DML, logged or not logged?
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

Let's avoid that discussion in this thread. -- ;-)

As I mentioned earlier, I'm sure that is a top priority in everyone's mind.
But I need to get the functionality that you guys want to have in the
product.

Thanks -

M.P.


"Obnoxio The Clown" <obnoxio@hotmail.com> wrote in message
news:c08ah9$13r4o0$1@ID-64669.news.uni-berlin.de...
> Madison Pruet wrote:
>
> > 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.
>
> Since no one else took the opportunity: "marketing". )
>
> --
> "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
> - Coluche