I am not an Oracle supporter, but because of this, it is very important
for me to check these facts for accuracy. How bad will it be if we
accuse Oracle of something, and find that it is not true.

The pdf document mentions the following on page 8, regarding data
partitioning:

Oracle does provide the ability to attach and detach new partitions. The
"ALTER TABLE . . . DROP PARTITION" marks all partitions of the global
index unusable. This means that any reorganization to the partitioning
of a table will cause major down time since you will have to rebuild
your indexes.


My question: is this true ? Does it really mean downtime ? I am
asking this, because our Oracle DBA confirms that in Oracle you do not
need downtime for this, that you can build partition indexes which
eliminates the need for downtime.

Any comments ?


Dirk


-----Original Message-----
From: owner-informix-list@iiug.org [mailtowner-informix-list@iiug.org]
On Behalf Of Obnoxio The Clown
Sent: 22 November 2005 11:20 AM
To: Michael Martin
Cc: informix-list@iiug.org
Subject: Re: Informix versus Oracle Spatial

Michael Martin said:
>
> Can anybody say that Informix is better than Oracle in terms of
spatial
> capability? Is there any references on the web where I can compare the
> two?

I can say it. In fact, I think anybody who has worked with the two
products WILL say it.

I am fairly certain Jacques Roy touches on this very subject here:
http://www.IIUG.org/resources/articl...sOracle10g.pdf (Look in the
"Indexing" section discussion about R-trees.)

--
Bye now,
Obnoxio

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

did i mention i like nulls? heck, i even go so far as to say that all
columns in a table except the primary key could/should be nullable. this
has certain advantages, for example, if you need to insert a child
record
and you don't have a parent row for it, just do an insert into the
parent
table with the primary key value (everything else null), and voila,
relational integrity is preserved. but this is, admittedly, a bit
controversial among modellers.

--r937, dbforums.com
sending to informix-list
sending to informix-list

This is awesome work. I think it touches on some very salient points,
especially regarding virtual processors and threading. It is amazing
that Oracle technology could have gone so wrong despite the amount of
money they have as a company, and how they could not come up with a
better engine--or why haven't they dumped the current engine and made a
new one that is actually better than any other product. Simply amazing.
All that money and they can't find anyone to make their technology better
than it is. They must have their priorities wrong, spending so much money
on sales and marketing. :-)

RE: http://www.IIUG.org/resources/articl...sOracle10g.pdf

Dirk Moolman wrote:
> I am not an Oracle supporter, but because of this, it is very important
> for me to check these facts for accuracy. How bad will it be if we
> accuse Oracle of something, and find that it is not true.
>
> The pdf document mentions the following on page 8, regarding data
> partitioning:
>
> Oracle does provide the ability to attach and detach new partitions. The
> "ALTER TABLE . . . DROP PARTITION" marks all partitions of the global
> index unusable. This means that any reorganization to the partitioning
> of a table will cause major down time since you will have to rebuild
> your indexes.
>
>
> My question: is this true ? Does it really mean downtime ? I am
> asking this, because our Oracle DBA confirms that in Oracle you do not
> need downtime for this, that you can build partition indexes which
> eliminates the need for downtime.
>


You can rebuild them online, but I don't think this is supported by
Oracle as it can put a lot of stress on the shared pool which in turn
can cause core dumps and possibe unforseen/unrequired downtime. The
official work around of which is to do the rebuilds offline. I think it
is quite a 'buggy' problem, and apparently fixed in later versions of
9i and in 10g. I've not used partitioning in either of those versions
so not able to confirm their fix.

RollForward Wizard wrote:

> This is awesome work.

We love this document. Please continue to use it in as many competitive
situations as you can.

Dirk Moolman wrote:

>
> My question: is this true ? Does it really mean downtime ? I am
> asking this, because our Oracle DBA confirms that in Oracle you do not
> need downtime for this, that you can build partition indexes which
> eliminates the need for downtime.
>
> Any comments ?

>

It's a carefully chosen statement - if you build a global index, and if
you don't partition the global index on the same key(s) as the data
paritition, then dropping a partition will of necessity invalidate those
global indexes that spanned the partition. If you are using local
indexes (or even a global composite that has the same partitioning key
at some level) then of course you can drop/add partitions without impact.

We love this document. Please continue to use it in as many competitive
situations as you can.

Simon wrote:

>
> You can rebuild them online, but I don't think this is supported by
> Oracle as it can put a lot of stress on the shared pool which in turn
> can cause core dumps and possibe unforseen/unrequired downtime.


You can rebuild what online ? The indexes that don't get invalidated ?

The
> official work around of which is to do the rebuilds offline.

WTF is an offline index rebuild ? How would you do this in Oracle ?

I think it
> is quite a 'buggy' problem, and apparently fixed in later versions of
> 9i and in 10g.

Stop thinking. Start knowing

I've not used partitioning in either of those versions
> so not able to confirm their fix.
>

So you know SFA, yet you comment.

Ok, sorry wrong word, I meant index rebuild with downtime. i.e. no
users connected. Which is what I beleive "This means that any
reorganization to the partitioning
of a table will cause major down time since you will have to rebuild
your indexes. " was referring to.

There IS an issue, bug or whatever with ONLINE (with users connected)
index rebuilds of partitioned indexes, which was the point I was
making, having experienced this on pre 9i/10g oracle versions.

https://metalink.oracle.com/metalink...id= 2835542.8
refers to what I obviously know SFA about having experienced it first
hand. Obviously I realise I know SFA about partitioning on 9i/10g
because I've never been at a site where they have partitioning on these
versions and I'm sure partitioning must be really quite different on
these later versions than pre 9i...!

Apologies for the (admittedly) inappropriate choice of word word

Simon wrote:

> You can rebuild them online, but I don't think this is supported by
> Oracle as it can put a lot of stress on the shared pool which in turn
> can cause core dumps

Nonsense.

and possibe unforseen/unrequired downtime. The
> official work around of which is to do the rebuilds offline. I think it
> is quite a 'buggy' problem, and apparently fixed in later versions of
> 9i and in 10g.

Also known as the currently supported versions of the product.

Referring back, with any product, to Cretaceous or Jurassic versions
will always let you criticize. The thigs I could tell you about
Informix 1.0 ....
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

Is SQL*Plus: Release 9.2.0.1.0 a Cretaceous or Jurassic version ????

create table nullix( a int, b char(10));
create unique index ixienull on nullix (a);

insert into nullix (b) values ('One ');
insert into nullix (b) values ('One Dupl');
insert into nullix (b) values ('Two Dupl');

select count(*) , a from nullix
group by a

gives back 3 so i get 3 nulls in my table where the index is
unique.....
informix (V 9.30) pukes at the second insert ... duplicate....

if obstacle can't even keep their pants up with normal indices i will
not trust
them at all with exotic things.

you will probably tell me that the above is how it should work...
right??
having multiple null values in a unique index....

Superboer.



DA Morgan schreef:

> Simon wrote:
>
> > You can rebuild them online, but I don't think this is supported by
> > Oracle as it can put a lot of stress on the shared pool which in turn
> > can cause core dumps
>
> Nonsense.
>
> and possibe unforseen/unrequired downtime. The
> > official work around of which is to do the rebuilds offline. I think it
> > is quite a 'buggy' problem, and apparently fixed in later versions of
> > 9i and in 10g.
>
> Also known as the currently supported versions of the product.
>
> Referring back, with any product, to Cretaceous or Jurassic versions
> will always let you criticize. The thigs I could tell you about
> Informix 1.0 ....
> --
> Daniel A. Morgan
> http://www.psoug.org
> damorgan@x.washington.edu
> (replace x with u to respond)

my knowledge about Oracle is minimal.

Could it be because Oracle does not index null values.

"Superboer" <superboer7@planet.nl> wrote in message
news:1133422691.225324.315430@o13g2000cwo.googlegr oups.com...
> Is SQL*Plus: Release 9.2.0.1.0 a Cretaceous or Jurassic version ????
>
> create table nullix( a int, b char(10));
> create unique index ixienull on nullix (a);
>
> insert into nullix (b) values ('One ');
> insert into nullix (b) values ('One Dupl');
> insert into nullix (b) values ('Two Dupl');
>
> select count(*) , a from nullix
> group by a
>
> gives back 3 so i get 3 nulls in my table where the index is
> unique.....
> informix (V 9.30) pukes at the second insert ... duplicate....
>
> if obstacle can't even keep their pants up with normal indices i will
> not trust
> them at all with exotic things.
>
> you will probably tell me that the above is how it should work...
> right??
> having multiple null values in a unique index....
>
> Superboer.
>
>
>
> DA Morgan schreef:
>
>> Simon wrote:
>>
>> > You can rebuild them online, but I don't think this is supported by
>> > Oracle as it can put a lot of stress on the shared pool which in turn
>> > can cause core dumps
>>
>> Nonsense.
>>
>> and possibe unforseen/unrequired downtime. The
>> > official work around of which is to do the rebuilds offline. I think it
>> > is quite a 'buggy' problem, and apparently fixed in later versions of
>> > 9i and in 10g.
>>
>> Also known as the currently supported versions of the product.
>>
>> Referring back, with any product, to Cretaceous or Jurassic versions
>> will always let you criticize. The thigs I could tell you about
>> Informix 1.0 ....
>> --
>> Daniel A. Morgan
>> http://www.psoug.org
>> damorgan@x.washington.edu
>> (replace x with u to respond)
>