| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Migration from HP-UX 10.20 to HP-UX 11 and Oracle 7.3.4 t
Ron,
I believe this is the problem you are referring to and it doesn't address the 32 bit/64 bit issue.
Bill
Alert: Database may crash after upgrade to 8.1.6 (Oracle8i Release2)
This alert describes some essential checks to perform if upgrading to Oracle 8.1.6 from an earlier release.
Oracle 8.1.6 is the first server release to perform block checking for dictionary objects by default. This block checking can detect problems which went un-noticed in earlier releases of Oracle.
In particular <Bug:839342> , which affects Oracle releases 7.3 to 8.1.5 inclusive, may have silently introduced a minor corruption in the data dictionary. If a database with this corruption is upgraded to 8.1.6 or higher then the new block checking code can notice the corruption causing the instance to be aborted or the dictionary block to be marked as permanently corrupt.
Versions of Oracle Affected
Upgrade path Potentially affected?
Note, if a database is upgraded from 7.3.4 to 8.1.6 via 8.0.X
(i.e. it has been run under 8.0.X) it is potentially affected by this
problem.
Platforms Affected
Description
The space leak is benign per se, and on Oracle versions up to (and including) 8.1.5 is likely to go unnoticed as long as the database instance is running WITHOUT any special block checking events.
Under 8.1.6, block checking is automatically enabled for data objects in the SYSTEM tablespace. If a block in the SYS.C_TS# cluster was previously corrupted then the database may crash after the block is modified in 8.1.6 .
Likelihood of Occurrence
It can affect databases upgraded from earlier 8.0 or 8.1 releases. The likelihood of the database crashing as described here is high if the dictionary contains any logically corrupt data blocks. This can be checked prior to upgrade as described in the section "Checking for Corruptions" below.
Databases migrated DIRECTLY from 7.3.4 to 8.1.6 will not be affected by this problem as the data dictionary objects (including SYS.C_TS#) are rebuilt during migration.
Possible Symptoms
(1) Recursive DML that modifies the datablock raises:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a
data block
ORA-00600: internal error code, arguments:
[kcoapl_blkchk] [afn] [block]
(2) Database writer process may terminate with:
ORA-00600: internal error code, arguments:
[kcbzpb_2] [afn] [block]
Where 'afn' is the absolute datafile number, and 'block' is the datablock in that datafile.
If you see either of these symptoms contact your local support centre for advice on what steps to take.
Checking for corruptions
BEFORE upgrading to 8.1.6, Oracle Support strongly recommends that you
check the data dictionary objects for possible corruptions. A SQL
script to do this can be generated as follows from SQL*PLUS (connected as
SYS):
(Spool to an appropriately named file for your platform. This example
uses Unix file naming conventions)
set head off feedback off pagesize 500 echo off
spool /tmp/analyze_objects.sql
select 'ANALYZE TABLE "'||table_name||'" VALIDATE STRUCTURE
CASCADE;'
from dba_tables
where tablespace_name='SYSTEM'
and owner='SYS';
from dba_clusters
where tablespace_name='SYSTEM'
and owner='SYS';
Because 8.1.6 enables block checking for all SYSTEM tablespace objects, it would be worthwhile running a script that analyzes ALL (SYS and non-SYS owned) objects in this tablespace. Although it is bad practice to use the SYSTEM tablespace for non-SYS objects, it is not an uncommon one. To generate a script that analyzes all SYSTEM tablespace objects, execute the following SQL:
set head off feedback off pagesize 500 echo off
spool /tmp/analyze_objects.sql
select 'ANALYZE TABLE "'||owner||'"."'||table_name||
'" VALIDATE STRUCTURE CASCADE;'
from dba_tables
where tablespace_name='SYSTEM';
select 'ANALYZE CLUSTER "'||owner||'"."'||cluster_name||
'" VALIDATE STRUCTURE CASCADE;'
from dba_clusters
where tablespace_name='SYSTEM';
Edit /tmp/analyze_objects.sql to remove everything but the ANALYZE
commands,
and run the script, connected as a privileged user.
If ANALYZE fails for any of the tables or clusters,
RAISE A SUPPORT CALL WITH ORACLE SUPPORT BEFORE PROCEEDING WITH
THE UPGRADE. If ANALYZE detects a leaked byte in a cluster,
it will create a trace file (which should be saved) and fail
with the following error:
ORA-1498: block check failure - see trace file
ANALYZE CLUSTER SYS.C_TS# VALIDATE STRUCTURE CASCADE; What should I do I an "ANALYZE .. VALIDATE.." reports an error ?
following:
Workaround / Patches
Articles
Corruption detection features in Oracle <Note:32969.1> Parameter reference: DB_BLOCK_CHECKING <Note:68483.1> -----Original Message----- From: Ron Rogers [mailto:RROGERS_at_galottery.org] Sent: Friday, August 18, 2000 2:15 PM To: Multiple recipients of list ORACLE-L Subject: RE: Migration from HP-UX 10.20 to HP-UX 11and Oracle 7.3.4 t
If I understand correctly, 8.0.x can be 32/64 bit but migrating to 8.1.x causes data dict corruption id the 8.0.x is 64 bit. The 8.1.x can only be 32 bit.
Is this correct? I thought that it is what I was told ay an application users group meeting.
2bits: Ron ROgers DBA OCP Atl.GA >>> lkoivu_at_qode.com 08/18/00 11:44AM >>> Dick, you say that 64-bit is faster than 32-bit. We recently had to investigate whether or not to go 64-bit (we are also HP/UX 11.0) with the O/S and the RDBMS. I searched the net exhaustively trying to find something other than 'you can have an SGA larger than 2GB' for a reason to choose 64bit. I read that 64-bit was only really beneficial to very large OLTP systems (which we aren't, really). Can you substantiate your statement below? I would be interested in any metrics, white papers, ANYTHING that would explain this in more detail. I understand the difference between 32-bit and 64-bit, I just am at a loss to understand what exactly this buys me. I was also wary of choosing 64-bit for the RDBMS because we are HP/UX, the second tier for patches, upgrades, etc. Undesirable situation to be in, to begin with (in my opinion). I thought if we then went 64-bit RDBMS we would have to wait even longer for patches and upgrades. Thanks in advance for your comments. Happy Friday everyone, I'm off to Vegas!! Lisa Ft. Lauderdale, FL, USA -----Original Message----- Sent: Friday, August 18, 2000 10:17 AM To: Multiple recipients of list ORACLE-L Rafiq, It depends on whether your going to be on HP-UX 11 32 or 64 bit. HP-UX 10.2 was strictly 32 bit, but HP-UX 11 gives you a choice, somewhat dependent on the hardware. If your remaining on older HP9000 E,G,K class machines then your stuck with 32 bit. If your headed for the newer L & N class then you have a choice (BTW: take 64 bit if it's available, it is faster). Now, from an Oracle perspective, If your staying with 32 bit then the datafiles are compatible & it's just a version upgrade. If it's 64 bit, then an export, database rebuild & import will be required. BUT, since you state that your headed for new hardware (of whatever flavor) in the first place, this is an optimum time for a little house cleaning so take it. Golden opportunities like this are few & far between. Dick Goulet ____________________Reply Separator____________________ Author: "Mohammad Rafiq" <rafiq9857_at_hotmail.com> Date: 8/17/00 12:17 PM Hi Gurus I need expert guidance for our future move to HP-UX 11 fromHP-UX 10.20.
Existing setup: Platform HP HP-UX 10.20 Oracle 7.3.4.5 Oracle Financials 10.7(Char) with Oracle Manufacturing/Bill Of Materials Customized forms(2.3) and reports(2.5) Future Move: Platform HP New Machine HP-UX 11 Oracle 8.1.6 Oracle Financials Release 11i Conversion of Customized Forms & Reports to Forms/Reports 6i Please advise your experience or opinion to carry out above migration smoothly as Oracle Support guidance is so far contradictory. Regards Rafiq ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail athttp://www.hotmail.com
-- Author: Mohammad Rafiq INET: rafiq9857_at_hotmail.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access /Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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). -- Author: INET: dgoulet_at_vicr.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access /Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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). -- Author: Ron Rogers INET: RROGERS_at_galottery.org Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access /Mailing Lists
 |
 |