I was just wondering if setting compatible back to 8.1.7 for the CBO reasons was still necessary? 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Paul Drake
Sent: Friday, December 12, 2003 4:49 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: for security patches - going to 9.2.0.4

Paula,
 
since you use the export utility - patch to 9.2.0.4.
a full export will throw an error in 9.2.0.3, on W2K and on RH 8.0.
regarding security, I haven't yet applied the 8.1.7.4.13 patchset (its not yet available) or the SSL-related issues in Oracle Security Alert #62. but the patchset 9.2.0.4.0 is still a pre-requisite for this, as the one-off patchset for 9.2.0.3.0 is not yet available.
 
As far as setting compatible back to 8.1.7, the key thing is not whether you have locally managed tablespaces, but a locally managed _SYSTEM_ tablespace. just wanted to make that clear.
 
Paul

[EMAIL PROTECTED] wrote:
That is the case.  I do have tablespaces that are locally managed - I did the migrate with compatible set to 8.1.7.  I did startup the database.  However, my system tablespace is dictionary managed - all others are not. 
 
The migration worked.  I have large databases and have been using Oracle's migration utility from 7 - 8 and 8 - 9.  Yes, it is quirky and tricky but better than export/import on large databases.
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Paul Drake
Sent: Thursday, December 11, 2003 7:04 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: for security patches - going to 9.2.0.4

Paula,
 
I hope that you are just confused.
AFAIK, if you have created a database with a locally managed system tablespace, that you cannot set compatible to anything lower than 9.0.1.
Ok, you can set it, but oracle will complain during instance startup and you won't have a database instance to attach to. But this might be a myth of mine, its awhile since I last read the upgrade/migration guide.
 
I can see setting the init.ora parameter
optimizer_features_enable = 8.1.7
if the 9.2 CBO acts quite differently from its older brother did, back in 8.1.7.
 
But compatible? I seriously doubt it.
If you migrated your db from 8.1.7 to 9.2 and the system tablespace is still dictionary managed - that is a completely different matter.
 
I've been lucky enough that most dbs were small enough to just use exp/imp and move data into a clean, newly created db.
 
Paul


[EMAIL PROTECTED] wrote:
Guys,

I saved all of your writing including Todd Boxx, Richard Foote, Wolfgang... about issues with 9.2.0.4. We are currently on 9.2.0.3 and I understand (although have not hit it yet) that in this version we could get locks when building indexes. Also, that basically you need to set your compatible parameter to 8.1.7. On some databases we have compatible set to 9.2.0.0.

Question:

-any bugs/problems going to 9.2.0.4 and...
-should we really change compatible from 9.X to 8.1.7?????

We are currently migrating a large database to 9.X and I want to know if I should use the latest patchset 9.2.0.4 - for security and performance reasons?

Also, we have some dev/test databases where once they go into production performance could be an issue - should we change the compatible param. to 8.1.7 proactively????

Thanks,
Paula
--
Please! ! see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: <[EMAIL PROTECTED]
INET: [EMAIL PROTECTED]

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).


Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing


Do you Yahoo!?
Free Pop-Up Blocker - Get it now

Reply via email to