Skip to Main Content

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Jan.

Asked: April 09, 2002 - 12:18 pm UTC

Last updated: March 14, 2005 - 1:01 pm UTC

Version: 8.1.7

Viewed 1000+ times

You Asked

Tom,

how do 24/7 shops handle schema/application updates? Reason for asking, a project manager asked me to think about a way to make schema updates without stopping user access to the database. This by making a copy of the current schema, apply changes to the copy, then synq up the schemas and switch the user over to the new updated schema. This all under the motto: "This application can't handle downtime. We are 24/7!"
I'm wondering how 24/7 shops handle this. I rather take a 15 or 30 minutes outage myself :-)

jan

and Tom said...

See
</code> http://www.oracle.com/pls/db901/db901.to_toc?pathname=server.901/a90117/tables.htm#12458 <code>

for the 9i answer. There is a brief moment where an exclusive table lock is mandatory but other then that, you can redefine online.

So -- I have a question for you as well -- if you update the schema (say, add a column) don't you need to update the CODE as well. In order to do that, you will have to stop using the code (not possible to update code currently in action). I see some downtime in your future for application updates.

Rating

  (9 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Changing code...

Jan, April 09, 2002 - 2:51 pm UTC

Yes, the code will change as well. So in the project manager's view there would be a *short* outage while the application server is being switched from the one with the old code to the one with the new code.
My problem however is the database. What for example if mandatory fields are added, or constraints that change... We would have to write code that pulls over data and transforms it. Or replay the transactions that have come in... Trying to get to the point where the two schemas are in sync again as far as the data is concerned. Then cut off the "old" appserver and switch over to the new one. And not lose more than the currently uncommitted transactions...
My initial reaction is "nightmare"!

Tom Kyte
April 09, 2002 - 3:26 pm UTC

That is what 9i with dbms_redefinition is all about -- it does that sync'ing for you.

Interesting...

Jan, April 09, 2002 - 5:28 pm UTC

Very interesting. Another reason to upgrade to 9i :-)

Upgrading an 8i (24x7) db to 9i with no downtime

Logan Palanisamy, October 22, 2003 - 12:51 pm UTC

Tom,

Ours is a 24x7 e-commerce shop. Can't afford any downtime. Currently we are on 8i and would like to upgrade to 9iR2.

Is there anyway to do the upgrade without downtime? I don't think so. Just want to double check with you.

Tom Kyte
October 22, 2003 - 6:15 pm UTC

there will be some amount of downtime, you can minimize it -- but there will be some.

10g will support rolling upgrades using data guard -- meaning we will be able to virtually eliminate downtime during an upgrade.

URL gives a 404

Andy Todd, October 23, 2003 - 5:35 am UTC

Tom,

Thanks for the answer, but because the URL you mentioned now gives a 404 I had to search for quite a while to find the actual feature.

I believe what you were talking about is the DBMS_REDEFINITION package which was introduced in Oracle 9i and discussed in the PL/SQL supplied packages and Administrators Guide (in a section entitled "Managing Tables")

URL pointing wrongly

Ashiq Shamsudeen A, March 24, 2004 - 2:15 am UTC

Tom

The URL which you given pointing wrongly.

Minimal downtime for upgrades

JHT, May 07, 2004 - 8:52 am UTC

Tom,

Thanks for all the good information you provide on this website. In the response to 8i to 9i oracle upgrade, you said

"there will be some amount of downtime, you can minimize it -- but there will be some"

What is your recommendation for minimal downtime? We have a set of spare disks/servers for our upgrade. I was thinking of using 8i dataguard to instantiate a new database on the new server. Then at time of upgrade, break the connection and open the new db as read/write. Upgrade it to 9i. In the mean time, the original 8i db is still being written to. How could I get those changes across? I was thinking of using "logical" standby or oracle streams but that is a 9i feature (and by the way, would that be the appropriate thing to do in the future when I upgrade 9i to 10g?).

So what could I do for 8i to 9i? And for future reference, what about 9i to 10g? And you mention that 10g supports rolling upgrades using dataguard. Does that mean that we could use that feature for 9i to 10g upgrades or for 10g to future upgrades?


Tom Kyte
May 07, 2004 - 9:06 am UTC

streams won't work from 8i to 9i, streams is new with 9iR2.

with 9iR2 to 10g, you can use streams

with 10g, you'll be able to use data guard directly (rolling upgrades starting with 1gr1 on up)

In 8i -> 9i, you might be able to use this technique:

</code> http://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:17309172009134 <code>

using read only replication (simple snapshots) to minimize downtime.

MV with prebuilt tables

JHT, May 13, 2004 - 4:00 pm UTC

Tom,

Your method of creating MV with prebuilt table works great when replicating 8i tables to a 9i db.  I am planning to use this method when upgrading an 8i db to a 9i db as you have suggested.  The problem is that not all of our tables have primary keys...and it fails when using "rowid". 

SQL> create materialized view ABC
  on prebuilt table refresh fast with rowid as 
  select * from ABC@db8i;
                                    
ERROR at line 2:
ORA-12058: materialized view cannot use prebuilt table

I can just not use the prebuilt table clause, but then when I drop the MV, the base table is also dropped.  This is not what I want, because I want the base table to remain after my 8i to 9i migration.  Any other suggestions? 

Tom Kyte
May 14, 2004 - 9:47 am UTC

(please test it test it test it. It is a technique).....


if you have tables -- you sort of need primary keys no? what kind of tables do you have that do not have primary keys.

Last time I saw that -- well, that was two weeks ago. Tuning a query. I said "if I can make the assumption that x,y in t is the primary key - this query flies.", Developer says "oh yeah, thats the key -- no worries.". I query the data -- 352 dups out of 250,000.... HMMM... they have a primary key now (old query was not only slow, it was returning the wrong answer due to the duplications -- and it was hidden nicely since they had a group by and sum in there -- they added stuff up twice).

So, I guess my advice would be to take advantage of the fact you are changing to fix the lack of primary keys?

24X7

J. Steele, March 14, 2005 - 9:27 am UTC

We are currently running 8i and are upgrading to 9i in a few weeks. Our new contract now requires 24x7 operation; however, we also migrate a new version of the front end each month. Most of the time there are db changes such as column adds/drops, datatype changes, new/drop tables, etc.

Is there a way to provide a "real" 24x7 database in 9i? If so... what steps are needed to make our changes?

If 9i can't do it... can 10g ?

Tom Kyte
March 14, 2005 - 9:49 am UTC

a real 24x7 database would be "frozen"

think about it -- adds, drops, datatype changes, new tables etc. You sort of need a maintenance window somewhere.

We can do many things online (using dbms_redefinition for example) but think about the APPLICATION itself that needs to be stopped, reinstalled, restarted.

Application is in DB

Matthias Rogel, March 14, 2005 - 11:13 am UTC

hallo Tom,

sounds as a good example for the Argument that the
APPLICATION should be in DB:
no need to
stop, reinstall, restart,
or do I miss something ?

When you add a Column to the Schema of your asktom-application,
will there be any donwtime in the app (I doubt that) ?

Tom Kyte
March 14, 2005 - 1:01 pm UTC

When I make an application upgrade -- there most certainly is downtime involved, the code that is running must STOP running before any structural changes take place.