FW: Informix versus Oracle Spatial
Posted in 2005
A reader questioned a claim in the IIUG "IDS 10 vs Oracle 10g" comparison paper: that in Oracle, dropping a table partition invalidates global indexes and therefore forces major downtime for index rebuilds. His own Oracle DBA disagreed. Oracle's Mark Townsend replied that the statement is carefully worded but only applies to global indexes not partitioned on the same key as the data; with local indexes (or a global composite using the same partitioning key) partitions can be added/dropped with no impact. Another poster cited an older bug with online rebuilds of partitioned indexes, which others dismissed as applying only to obsolete versions. The thread drifts into Informix-vs-Oracle sniping, but the factual point is answered.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Server Administration
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 [mailto:owner-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/articles/IDS10vsOracle10g.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/articles/IDS10vsOracle10g.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/plsql/ml2_documents.showDocument?p_database_id=NOT&p_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)