RE: for security patches - going to 9.2.0.4

2003-12-15 Thread Paula_Stankus
Title: RE: for security patches - going to 9.2.0.4



Thanks 
so much.  This was very well explained and I appreciate the time you took 
to share it.  I will go through the Metalink and read this over and 
test.  
 
Thanks 
Again,
Paula

  -Original Message-From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]On Behalf Of Joze 
  SenegacnikSent: Monday, December 15, 2003 6:09 AMTo: 
  Multiple recipients of list ORACLE-LSubject: RE: for security 
  patches - going to 9.2.0.4
  Paula, 
  I had also bad experience when we upgraded one of our 
  applications from 8.1.7 to 9.2.0.1 There were some queries that executed 
  significantly slower then on 8.1.7. What we have done was: 
  1. We gathered system statistics with 
  dbms_system.gather_system_stats. This helps CBO to know on what kind of HW 
  configuration it is running on and also turns on the new cpu costing model. 
  The result were better execution plans. Please read Metalink Note: 153761.1 
  about system stats. I had also replied to several questions regarding system 
  stats on Metalink and I don't know for a case when gathering system stats 
  caused performance degradation. 
  2. We have installed the latest patch 9.2.0.4 which among 
  other bugs fixes also some optimizer bugs - some of them are still there ;) . 
  This also solved other performance problems and things were again under 
  control. 
  3. With manual setting system statistics (see the procedures 
  in dbms_stats package to do that) one can achieve the same execution plans as 
  on 8.1.7 version. If the mreadtim is 1.2 times higher than the sreadtim with a 
  multiblockreadcount (mbrc) set to 8, then the I/O cost part will be equivalent 
  to the Oracle8i I/O cost. I haven't tested this yet (there was no need to do 
  that and besides I currently don't have access to proper environment to do 
  that) but it sounds like setting the OPTIMIZER_INDEX_COST_ADJ in 8i to lower 
  values then default. 
  4. There are several settings related to CBO's behavior that 
  have changed the default value from false to true in 9iR2. Those 
  are:
  _b_tree_bitmap_plans = true _complex_view_merging = true _index_join_enabled = true _new_initial_join_orders = true _ordered_nested_loop = true _push_join_predicate = true _push_join_union_view = true _table_scan_cost_plus_one = true _unnest_subquery = true 
  We had several times problems with bitmap conversions for 
  b-tree indexes, so we changed _b_tree_bitmap_plans back to false as it was in 
  8i. The changed plans without this feature were executing faster.
  Regards, Joze 
  -Original Message- From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
  Sent: Friday, December 12, 2003 10:59 PM To: Multiple recipients of list ORACLE-L Subject: RE: for security patches - going to 9.2.0.4 
  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 paramete

RE: for security patches - going to 9.2.0.4

2003-12-15 Thread Joze Senegacnik
Title: RE: for security patches - going to 9.2.0.4





Paula,


I had also bad experience when we upgraded one of our applications from 8.1.7 to 9.2.0.1 There were some queries that executed significantly slower then on 8.1.7. What we have done was: 

1. We gathered system statistics with dbms_system.gather_system_stats. This helps CBO to know on what kind of HW configuration it is running on and also turns on the new cpu costing model. The result were better execution plans. Please read Metalink Note: 153761.1 about system stats. I had also replied to several questions regarding system stats on Metalink and I don't know for a case when gathering system stats caused performance degradation. 

2. We have installed the latest patch 9.2.0.4 which among other bugs fixes also some optimizer bugs - some of them are still there ;) . This also solved other performance problems and things were again under control. 

3. With manual setting system statistics (see the procedures in dbms_stats package to do that) one can achieve the same execution plans as on 8.1.7 version. If the mreadtim is 1.2 times higher than the sreadtim with a multiblockreadcount (mbrc) set to 8, then the I/O cost part will be equivalent to the Oracle8i I/O cost. I haven't tested this yet (there was no need to do that and besides I currently don't have access to proper environment to do that) but it sounds like setting the OPTIMIZER_INDEX_COST_ADJ in 8i to lower values then default. 

4. There are several settings related to CBO's behavior that have changed the default value from false to true in 9iR2. Those are:

_b_tree_bitmap_plans = true
_complex_view_merging = true
_index_join_enabled = true
_new_initial_join_orders = true
_ordered_nested_loop = true
_push_join_predicate = true
_push_join_union_view = true
_table_scan_cost_plus_one = true
_unnest_subquery = true


We had several times problems with bitmap conversions for b-tree indexes, so we changed _b_tree_bitmap_plans back to false as it was in 8i. The changed plans without this feature were executing faster.

Regards, Joze




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 12, 2003 10:59 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: for security patches - going to 9.2.0.4



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 unders

Re: for security patches - going to 9.2.0.4

2003-12-15 Thread Mogens Nørgaard
We've had to set the _optimizer_features_enabled or whatever back to 
8.1.7 and/or _new_initial_join_order (which defaults to true in 9.2.0.4, 
at least) to false after seeing a lot of problems going from 8.1.7 to 
9.2.0.4. It's happened a couple of times, but I'm not sure if it's a 
trend or not.

Mogens

Paul Drake wrote:

if you have compatible set to 8.1.7, I'll bet that optimizer features 
from 9.2.0 aren't available.
you would have to decide if you want to use the 9.2 CBO or the 8.1.7 CBO.
The only reason that I can think of that you'd want to use the 8.1.7 
CBO is if your code ran well in 8.1.7 and some statements never finish 
(or run orders of magnitude slower) in 9.2.
 
Pd

*/[EMAIL PROTECTED]/* wrote:

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

RE: for security patches - going to 9.2.0.4

2003-12-12 Thread Paul Drake
if you have compatible set to 8.1.7, I'll bet that optimizer features from 9.2.0 aren't available.
you would have to decide if you want to use the 9.2 CBO or the 8.1.7 CBO.
The only reason that I can think of that you'd want to use the 8.1.7 CBO is if your code ran well in 8.1.7 and some statements never finish (or run orders of magnitude slower) in 9.2.
 
Pd[EMAIL PROTECTED] wrote:


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 DrakeSent: Friday, December 12, 2003 4:49 PMTo: Multiple recipients of list ORACLE-LSubject: 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 DrakeSent: Thursday, December 11, 2003 7:04 PMTo: Multiple recipients of list ORACLE-LSubject: 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 proactivelyThanks,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.comSan Diego, California -- Mailing list and web hosting services-To REMOVE yourself from this mailing list, send an E-Mail messageto: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe message BODY, include a line containing: UNSUB ORACLE-L(or the name of mailing list you want to be removed from). You mayalso 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
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

RE: for security patches - going to 9.2.0.4

2003-12-12 Thread Paula_Stankus



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 DrakeSent: 
  Friday, December 12, 2003 4:49 PMTo: Multiple recipients of list 
  ORACLE-LSubject: 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 
  DrakeSent: Thursday, December 11, 2003 7:04 PMTo: 
  Multiple recipients of list ORACLE-LSubject: 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 
proactivelyThanks,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.comSan Diego, California -- Mailing 
list and web hosting 
services-To 
REMOVE yourself from this mailing list, send an E-Mail messageto: 
[EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe 
message BODY, include a line containing: UNSUB ORACLE-L(or the name 
of mailing list you want to be removed from). You mayalso 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


RE: for security patches - going to 9.2.0.4

2003-12-12 Thread Paul Drake
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 DrakeSent: Thursday, December 11, 2003 7:04 PMTo: Multiple recipients of list ORACLE-LSubject: 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 proactivelyThanks,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.comSan Diego, California -- Mailing list and web hosting services-To REMOVE yourself from this mailing list, send an E-Mail messageto: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe message BODY, include a line containing: UNSUB ORACLE-L(or the name of mailing list you want to be removed from). You mayalso 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

RE: for security patches - going to 9.2.0.4

2003-12-12 Thread Paula_Stankus



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 DrakeSent: 
  Thursday, December 11, 2003 7:04 PMTo: Multiple recipients of list 
  ORACLE-LSubject: 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 proactivelyThanks,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.comSan Diego, California -- Mailing list 
and web hosting 
services-To 
REMOVE yourself from this mailing list, send an E-Mail messageto: 
[EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe 
message BODY, include a line containing: UNSUB ORACLE-L(or the name of 
mailing list you want to be removed from). You mayalso send the HELP 
command for other information (like subscribing).
  
  
  Do you Yahoo!?New 
  Yahoo! Photos - easier uploading and sharing


RE: for security patches - going to 9.2.0.4

2003-12-11 Thread Paul Drake
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 proactivelyThanks,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.comSan Diego, California -- Mailing list and web hosting services-To REMOVE yourself from this mailing list, send an E-Mail messageto: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe message BODY, include a line containing: UNSUB ORACLE-L(or the name of mailing list you want to be removed from). You mayalso send the HELP command for other information (like subscribing).
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

RE: for security patches - going to 9.2.0.4

2003-12-11 Thread Paula_Stankus
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).