How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema_1030426.6
Applies to:
Oracle Database - Enterprise Edition - Version 9.0.1.0 and laterInformation in this document applies to any platform.
*** Checked for relevance 17-NOV-2011 ***
Purpose
Problem Description:
If the same data dictionary object has been created under both user SYS and SYSTEM schema then errors will often occur when trying to use the database features associated with these objects.
Problem Explanation:
During the installation of Oracle many scripts are run which create the underlying data dictionary objects. Most of these scripts are run at database creation time, but others are only run if specific database features (such as replication or shared pool management) are needed. These scripts are usually run manually after the database has been created.
Running SQL scripts manually increases the chance of error greatly. One such common problem is running the SQL script as the wrong Oracle user.
Most SQL scripts located in the $ORACLE_HOME/rdbms/admin directory should be run as SYS (or internal) and not SYSTEM.
If you happen to run a SQL as the wrong user it is very hard to clean up from this situation as the number of objects that a script creates can be very large as well as there are no delivered scripts to drop the incorrect objects.
Details
In order to clean up the duplicate objects you need to issue a SQL script to find out the names of the duplicate objects.
You can then manually drop the objects or use a 'SQL generating SQL' script to generate a list of drop commands.
Below is a SQL*Plus script that will list all objects that have been created in both the SYS and SYSTEM schema:
column object_name format a30
select object_name, object_type
from dba_objects
where object_name||object_type in
(select object_name||object_type
from dba_objects
where owner = 'SYS')
and owner = 'SYSTEM';
The output from this script will either be 'zero rows selected' or will look something like the following:
OBJECT_NAME OBJECT_TYPE
------------------------------ -------------
ALL_DAYS VIEW
CHAINED_ROWS TABLE
COLLECTION TABLE
COLLECTION_ID SEQUENCE
DBA_LOCKS SYNONYM
DBMS_DDL PACKAGE
DBMS_SESSION PACKAGE
DBMS_SPACE PACKAGE
DBMS_SYSTEM PACKAGE
DBMS_TRANSACTION PACKAGE
DBMS_UTILITY PACKAGE
If the select statement returns any rows then this is an indication that at least 1 script has been run as both SYS and SYSTEM.
Since most data dictionary objects should be owned by SYS (see exceptions below) you will want to drop the objects that are owned by SYSTEM in order to clear up this situation.
EXCEPTION TO THE RULE
THE REPLICATION SCRIPTS (XXX) CORRECTLY CREATES OBJECTS WITH THE SAME NAME IN THE SYS AND SYSTEM ACCOUNTS. LISTED BELOW ARE THE OBJECTS USED BY REPLICATION THAT SHOULD BE CREATED IN BOTH ACCOUNTS. DO NOT DROP THESE OBJECTS FROM THE SYSTEM ACCOUNT IF YOU ARE USING REPLICATION. DOING SO WILL CAUSE REPLICATION TO FAIL!
The following objects are duplicates that will show up (and should not be removed) when running this script in 8.1.x and higher.
Without replication installed:
INDEX AQ$_SCHEDULES_PRIMARY
TABLE AQ$_SCHEDULES
If replication is installed by running catrep.sql:
INDEX AQ$_SCHEDULES_PRIMARY
PACKAGE DBMS_REPCAT_AUTH
PACKAGE BODY DBMS_REPCAT_AUTH
TABLE AQ$_SCHEDULES
When database is upgraded to 11g using DBUA, following duplicate objects are also created
OBJECT_NAME OBJECT_TYPE
------------------------------ -------------
Help TABLE
Help_Topic_Seq Index
The objects created by sqlplus/admin/help/hlpbld.sql must be owned by SYSTEM because when sqlplus retrieves the help information, it refers to the SYSTEM schema only. DBCA runs this script as SYSTEM user when it creates the database but DBUA runs this script as SYS user when upgrading the database (reported as an unpublished BUG 10022360). You can drop the ones in SYS schema.
Now that you have a list of duplicate objects you will simply issue the appropriate DROP command to get rid of the object that is owned by the SYSTEM user.
If the list of objects is large then you may want to use the following SQL*Plus script to automatically generate an SQL script that contains the appropriate DROP commands:
set pause off
set heading off
set pagesize 0
set feedback off
set verify off
spool dropsys.sql
select 'DROP ' || object_type || ' SYSTEM.' || object_name || ';'
from dba_objects
where object_name||object_type in
(select object_name||object_type
from dba_objects
where owner = 'SYS')
and owner = 'SYSTEM';
spool off
exit
You will now have a file in the current directory named dropsys.sql that contains all of the DROP commands. You will need to run this script as a normal SQL script as follows:
$ sqlplus
SQL*Plus: Release 3.3.2.0.0 - Production on Thu May 1 14:54:20 1997
Copyright (c) Oracle Corporation 1979, 1994. All rights reserved.
Enter user-name: system
Enter password: manager
SQL> @dropsys
Note: You may receive one or more of the following errors:
ORA-2266 (unique/primary keys in table referenced by enabled foreign keys):
If you encounter this error then some of the tables you are dropping have constrints that prevent the table from being dropped. To fix this problem you will have to manually drop the objects in a different order than the script does.
ORA-2429 (cannot drop index used for enforcement of unique/primary key):
This is similar to the ORA-2266 error except that it points to an index. You will have to manually disable the constraint associated with the index and then drop the index.
ORA-1418 (specified index does not exist):
This occurs because the table that the index was created on has already been dropped which also drops the index. When the script tries to drop the index it is no longer there and thus the ORA-1418 error. You can safely ignore this error.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/17252115/viewspace-1079410/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Metlink:How to clean up a failed CRS/ClusterwareAI
- How to Clean Up After a Failed Oracle Clusterware (CRS) InstallationAIOracle
- 10g RAC: How to Clean Up After a Failed CRS InstallAI
- Metlink:10g RAC How to Clean Up After a Failed CRS InstallAI
- how to clean failed crsAI
- Clean up a failed CRS installAI
- SVN中clean up的含義
- How to set up Software raid1 configuration on a running systemAI
- How to set up printers for GUI?GUI
- initialize or clean up your unittest within .net unit test
- How to perform FULL System Export/ImportsORMExportImport
- system sys,sysoper sysdba 的區別
- JavaScript’s “this”: how it works, where it can trip you upJavaScript
- How to Duplicate a Database in NOARCHIVELOG mode (Doc ID 275480.1)DatabaseHive
- How to get and set the system socket buffer in AIXAI
- How to Resolve Invalid Objects in a Database [ID 158185.1]ObjectDatabase
- 修改sys ,system使用者密碼密碼
- sys.allocation_units與sys.system_internals_allocation_units的差別
- Clean up After a Failed (successful) Oracle Clusterware Install on Win_341214.1AIOracle
- How To Pin Objects in Your Shared Pool [ID 1012047.6]Object
- Oracle中sys和system的區別小結Oracle
- How to copy a datafile from ASM to a file system not using RMANASM
- SYS,SYSTEM,DBA,SYSDBA,SYSOPER的區別與聯絡
- Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM (70)Database
- monitor sys and system user(轉自http://www.oracle.com)HTTPOracle
- sys使用者與system使用者的區別
- 將SYS和SYSTEM的物件都KEEP到shared pool物件
- How to move Oracle Spatial objects from SYSAUX tablespace to a user defined tablespace [ID 1119758.1OracleObjectUX
- How does the system determine the quantity structure for the cost estimate (CK11N)?Struct
- ObjectsObject
- 500GPM Mud Recycling System with Hydraulic Jack up to Australia Brisbane
- EF Core – Owned Entity Types & Complex Types
- 《Clean Code》
- 2 Sets 500GPM Mud Recycling System with Hydraulic Jack up to Australia Brisbane
- How To Restore 12cR1DB to New Host File System using RMAN(一)REST
- How to Restore CRS after accidentally run localconfig on RAC system_747415.1RESTIDE
- 2.5.2 保護資料庫:為SYS和SYSTEM使用者指定密碼資料庫密碼
- ORA-31633: unable to create master table "SYSTEM.SYS_EXPORT_FULL_XX"ASTExport