备份出错

显示全部楼层 · 2014-2-19 11:55:14

> > 原有系统为alpha小型机（digital系统）oracle 8.06，新系统为IBM小型机（AIX
>4.3.3.0 64位）oracle
>9.2.0.1，于一年前做了系统的数据迁移。当时据服务商工程师说已经做好，实际情况有所出入。在近几天做数据的export操作时不成功，才发现问题。
> > 相关oracle工程师已经做过以下动作：
> > 1、检查字符集，尝试从客户端导出数据，同样出现错误（错误情况见附件）
> > 2、尝试不导全库，只导自己测试时所建立的一个简单表，仍不能成功。
> >
>3、在另一台aix机器上安装oracle应用程序，把原有系统数据冷备后拷贝到新安装的系统，做相应控制文件修改后，做export操作，故障一样。
> > 4、尝试重新运行export正常工作所需要运行的脚本，仍然无法成功，故障依旧。
> >

千问 · 2014-2-19 11:55:14

alert.log文件错误内容:
Fri Jan9 22:54:33 2004
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Fri Jan9 22:54:35 2004
ALTER DATABASE MOUNT
Fri Jan9 22:54:40 2004
Successful mount of redo thread 1, with mount id 4073075820.
Fri Jan9 22:54:40 2004
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Fri Jan9 22:54:41 2004
ALTER DATABASE OPEN
Fri Jan9 22:54:41 2004
Thread 1 opened at log sequence 394
Current log# 3 seq# 394 mem# 0: /oradata1/oradata/ora9/redo03.log
Successful open of redo thread 1.
Fri Jan9 22:54:41 2004
SMON: enabling cache recovery
Fri Jan9 22:54:43 2004
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Fri Jan9 22:54:43 2004
SMON: enabling tx recovery
Fri Jan9 22:54:43 2004
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN
Fri Jan9 22:58:03 2004
ORA-000060: Deadlock detected. More info in file /oracle/admin/dgm85a/udump/ora9_ora_16014.trc.
Fri Jan9 23:02:00 2004
Thread 1 advanced to log sequence 395
Current log# 1 seq# 395 mem# 0: /oradata1/oradata/ora9/redo01.log
Fri Jan9 23:05:59 2004
Thread 1 advanced to log sequence 396
Current log# 2 seq# 396 mem# 0: /oradata1/oradata/ora9/redo02.log
Fri Jan9 23:10:50 2004
Thread 1 advanced to log sequence 397
Current log# 3 seq# 397 mem# 0: /oradata1/oradata/ora9/redo03.log
Fri Jan9 23:14:16 2004
Thread 1 advanced to log sequence 398
Current log# 1 seq# 398 mem# 0: /oradata1/oradata/ora9/redo01.log
Fri Jan9 23:49:02 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_16068.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:04 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_57360.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:04 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_47800.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:05 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_57624.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:06 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_63674.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:07 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_55070.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:08 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_32562.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:09 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_29990.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:10 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_32840.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Fri Jan9 23:49:11 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_14674.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Sat Jan 10 04:00:47 2004
Errors in file /oracle/admin/dgm85a/udump/ora9_ora_55858.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Sat Jan 10 15:56:29 2004
/* OracleOEM */ ALTER TABLESPACE "SYSTEM" ADD DATAFILE '/oradata1/oradata/ora9/system02.dbf'SIZE400M
Sat Jan 10 15:57:01 2004
Completed: /* OracleOEM */ ALTER TABLESPACE "SYSTEM" ADD DATA
Sat Jan 10 15:57:44 2004
/* OracleOEM */ ALTER TABLESPACE "XDB" ADD DATAFILE '/oradata1/oradata/ora9/xdb02.dbf'SIZE50M
Sat Jan 10 15:57:47 2004
Completed: /* OracleOEM */ ALTER TABLESPACE "XDB" ADD DATAFIL
Sat Jan 10 15:58:20 2004
/* OracleOEM */ ALTER TABLESPACE "TEMP" ADD TEMPFILE '/oradata1/oradata/ora9/temp02.dbf'SIZE1014M
Sat Jan 10 15:58:20 2004
Completed: /* OracleOEM */ ALTER TABLESPACE "TEMP" ADD TEMPFI

千问 · 2014-2-19 11:55:14

Connected to: Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set
About to export the entire database ...
.. exporting tablespace definitions
.. exporting profiles
.. exporting user definitions
.. exporting roles
.. exporting resource costs
.. exporting rollback segment definitions
.. exporting database links
.. exporting sequence numbers
.. exporting directory aliases
.. exporting context namespaces
.. exporting foreign function library names
.. exporting PUBLIC type synonyms
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
EXP-00000: Export terminated unsuccessfully

千问 · 2014-2-19 11:55:14

anyone here?

千问 · 2014-2-19 11:55:14

ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
那位大哥有metalink帐户的帮忙查查可以否?

千问 · 2014-2-19 11:55:14

最初由 husthxd 发布
[B]ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
那位大哥有metalink帐户的帮忙查查可以否? [/B]
跟java有关系,已经解决
上面的exp问题就比较讨厌了
有谁遇到过吗?

千问 · 2014-2-19 11:55:14

Bookmark Fixed fontGo to End
Doc ID:Note:147731.1
Subject:RDBMS release 9.0.1 fix - JDBC Thin Driver (ORA-600 when pre-9i talking to 9i)
Type:BULLETIN
Status:PUBLISHED
Content Type:TEXT/PLAIN
Creation Date:29-MAY-2001
Last Revision Date:04-SEP-2002

PURPOSE The JDBC Thin Driver provided as part of the Oracle8i releases, cannot be used to connect and run against an Oracle9i database. SCOPE & APPLICATION Developers using the JDBC Thin Driver (pre-9i) to connect to an Oracle9iDatabase will see ORA-600 [ttcgcshnd-1] exceptions.RDBMS release 9.0.1 fix - JDBC Thin Driver: ===========================================The JDBC Thin Driver, provided as part of the Oracle8i releases, cannot be used to connect and run against an Oracle9i database. You will need to download and install a JDBC thin patch in order to connect toan Oracle9i back-end. This is patch 1725012.The location of patch 1725012 and associated information can be found onMetaLink at http://metalink.oracle.com.After logging on to MetaLink, selectthe 'Patches' link to go the Patches Download page, and then select the link for patches released after February 19, 2001. Search for patch number 1725012. Select the appropriate patch for your operating system.The download contains instructions to install the patch. If you install JDBC 8.1.7.1, or RDBMS 8.1.7.1, or RDBMS 8.1.7.1b, after installing the JDBC patch, you will need to re-install the JDBC Thin patch inorder to connect to an Oracle9i backend. References: ===========
.
--------------------------------------------------------------------------------

Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.

千问 · 2014-2-19 11:55:14

最初由 husthxd 发布
[B]Connected to: Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set
About to export the entire database ...
.. exporting tablespace definitions
.. exporting profiles
.. exporting user definitions
.. exporting roles
.. exporting resource costs
.. exporting rollback segment definitions
.. exporting database links
.. exporting sequence numbers
.. exporting directory aliases
.. exporting context namespaces
.. exporting foreign function library names
.. exporting PUBLIC type synonyms
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
EXP-00000: Export terminated unsuccessfully [/B]

coolyl,遇到过上面的问题没有?
机器不在我这边,是否是某些dbms包没有成功编译呢?
btw : 有两台主机,一台对外网上业务,一台对内,用高级复制同步

千问 · 2014-2-19 11:55:14

Oracle Server-Enterprise and Standard Edition/DBA Administration Technical Forum

Displayed below are the messages of the selected thread.

Thread Status: Closed
From: Don King 10-Dec-03 16:18
Subject: Database Char. set conversions-for Exports
RDBMS Version: Oracle 9.2
Operating System and Version: Windows XP Pro v1a
Error Number (if applicable): 6552
Product (i.e. SQL*Loader, Import, etc.): Export/Import
Product Version: 9.2
Database Char. set conversions-for Exports
I have Oracle Standard Ed. running on a Win2000 Adv. server and also on my workstation for testing, experimenting, etc. I have one database in which the front-end application is being developed by an outside consulting firm. Their env. is Win2000 workstations and the database resides on an Solaris Unix server. All of their databases are created using the US7ASCII char. set. For some reason, by them, I'm new here, our database was created using WE8MSWIN1252 char. set. They are wanted an export to import into their database to check the test data. This is what I have attempted so far to convert the database:
SQL>select name c1, value$ c1 from sys.props$;
... This displays system properties and the NLS_CHARACTERSET displays as WE8MSWIN1252. I changed it to US7ASCII using the following SQL statement.
SQL>update sys.props$ set value$='US7ASCII' where name='NLS_CHARACTERSET';
... then issueing the following statements
SQL>column c1 format a30;
SQL>select name c1, value$ c1 from sys.props$;
...the NLS_CHARACTERSET is changed to US7ASCII. Then COMMIT and SHUTDOWN and STARTUP then export and receive the following output before the export terminates...
Connected to: Oracle9i Release 9.2.0.1.0 - Production
JServer Release 9.2.0.1.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
About to export the entire database ...
. exporting tablespace definitions
. exporting profiles
. exporting user definitions
. exporting roles
. exporting resource costs
. exporting rollback segment definitions
. exporting database links
. exporting sequence numbers
. exporting directory aliases
. exporting context namespaces
. exporting foreign function library names
. exporting PUBLIC type synonyms
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
EXP-00000: Export terminated unsuccessfully
Is the server char. set the problem? I set the environmental variable NLS_LANG on the server and the workstation to American_America.US7ASCII but that didn't help.
Any help appreciated,
Don

--------------------------------------------------------------------------------
From: Arun Mathur 10-Dec-03 16:25
Subject: Re : Database Char. set conversions-for Exports

Hi Don,
You shouldn't have to modify sys.prop$. When exporting, set your NLS_LANG to the characterset you want to import to. See Metalink note 227332.1 for more information.
Arun

--------------------------------------------------------------------------------
From: Oracle, George Angster 10-Dec-03 20:21
Subject: Re : Database Char. set conversions-for Exports

Don,
Arun is correct you should not change sys.props$, the note that was referenced would also be helpful.
Depending on what characters are stored in your database prior to the export you maybe be able to change the NLS_LANG to US7ASCII and import into the new US7ASCII database without any issues. If you do have characters beyond the US7ASCII limit ( 0 to 127 )they will be displayed as unrecognized characters in the new US7ASCII database.
Hope this is helpful.
George

--------------------------------------------------------------------------------
From: Don King 11-Dec-03 15:22
Subject: Re : Re : Database Char. set conversions-for Exports

George,
I'll do a little more research. When you say change the NLS_LANG to US7ASCII, do you mean the env. var. on the server/workstation you are performing the export on? If that is what you are referring to, that doesn't work. That was my first solution, I changed the env. var. SET NLS_LANG=US7ASCII. The export still exported using the char. set WE8MSWIN1252.
Tks,
Don

--------------------------------------------------------------------------------
From: Oracle, George Angster 11-Dec-03 15:50
Subject: Re : Database Char. set conversions-for Exports

Don,
You are correct I mixed them up....sorry.
How should NLS_LANG be set when using export?
In general it's usualy best to set to character set part of NLS_LANG to the same character set as the character set of the database you are exporting. That way no conversion will take place and the exportfile will be created in the same character set as the orginal database. Even if the plan is to import this into a database with a different character set later the conversion can be postponed until the import.
How should NLS_LANG be set when using import?
If the source and target database have the same character set, the
character set part of the NLS_LANG should be set to that same character seton both the export and the import. Even if the character sets are not the same the best thing is to leave the character set part of NLS_LANG the same on both export and import. It should either be set to the same as the source database character set (prefered)
or the same as the target database character set. That way conversion only takes place once, either on export or on import
This is from the referenced note.
George

--------------------------------------------------------------------------------
From: Arun Mathur 11-Dec-03 21:49
Subject: Re : Database Char. set conversions-for Exports

Don,
Set your NLS_LANG environment on the client machine you are doing the export on, not the server where the database resides.

--------------------------------------------------------------------------------
From: Oracle, George Angster 16-Dec-03 15:52
Subject: Re : Database Char. set conversions-for Exports

Don,
NLS_LANG needs to be set on the box (client) you are running the export from.
George

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.

千问 · 2014-2-19 11:55:14

你的oracle9201有没有打patch到高的版本过？