10g升级至11g exp的问题解决

昨天升级数据库，从10.2.0.5.0升级到11.2.0.2.0.

按照预定的步骤很快就操作完了。升级完成后，开始跑一些应用和Job.有一个Job开始报错，Job是一个自动的同步job,中会有exp的动作，而且里面用到了consistent=y的选项，这样exp就大体如下：

exp xxxx/xxxx file=xxx.dmp tables=xxxx consistent=y

报错如下：

Export: Release 11.2.0.2.0 - Production on Mon Sep 23 16:43:12 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Produ
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in TH8TISASCII character set and UTF8 NCHAR character set
About to export specified tables via Conventional Path ...
. . exporting table xxxx 2201 rows exported
EXP-00008: ORACLE error 1466 encountered
ORA-01466: unable to read data - table definition has changed
Export terminated successfully with warnings.

1.初步的感觉是时间的问题，

最先想到的系统时间的问题

> hwclock

dateTue 24 Sep 2013 07:29:54 AM ICT  -0.564711 seconds

> date

Tue Sep 24 07:29:54 ICT 2013

但是查询物理时间和系统时间，都没问题。顺便提一句，如果在9i等版本中出现这个问题，很可能是物理时间和系统时间不同步造成的。这在tom大师的帖子中也有印证。

http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:704225010478

2.排除这个问题，可能是object级的时间问题

MOS上看到有可能是creation_date比系统时间还要晚，用如下的sql来排除

select to_char(created,'dd-mm-yyyy hh24:mi:ss')

"CREATION TIME", object_name, object_type, object_id

from dba_objects where created > sysdate; 

但是我这个例子没有任何输出，所以这个问题应该不是这个原因。

3.我查询alert日志，发现这么一句，感觉很蹊跷

Mon Sep 23 15:58:26 2013

ORA-1466 (RO Tx began: 09/23/2013 08:58:25, Last DDL: 09/23/2013 11:14:16, Curr Time: 09/23/2013 08:58:26)

Mon Sep 23 15:58:38 2013

4.对于ORA-1466的解决方法，MOS上的一些建议是重建数据库，这也太狠了。

5.最后在TOM的帖子里找到了灵感，他是这么写的。

you mentioned out of sync clocks, that is what caught my eye on that note.

It could even be a TIMEZONE issue.  The dedicated server you are running might have a different TZ 

than the environment the export is running in.  Consider:

[tkyte@xtkyte-pc tkyte]$ echo $TZ

[tkyte@xtkyte-pc tkyte]$ plus

SQL*Plus: Release 9.2.0.5.0 - Production on Mon Jun 6 12:53:04 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.5.0 - Production

ops$tkyte@ORA9IR2> select to_char(sysdate,'dd-mon-yyyy hh24:mi:ss' ) from dual; 

TO_CHAR(SYSDATE,'DD-

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

06-jun-2005 12:53:15

ops$tkyte@ORA9IR2> !

[tkyte@xtkyte-pc tkyte]$ export TZ=PST

[tkyte@xtkyte-pc tkyte]$ plus 

SQL*Plus: Release 9.2.0.5.0 - Production on Mon Jun 6 16:53:23 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.5.0 - Production

ops$tkyte@ORA9IR2>  select to_char(sysdate,'dd-mon-yyyy hh24:mi:ss' ) from dual;                                                                               

TO_CHAR(SYSDATE,'DD-

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

06-jun-2005 16:53:33

One thing to check would be that the TZ of the export session is consistent with the rest of the 

sessions. 

排除了系统级的timezone问题，我觉得可能是db级的timezone问题。

最后发现升级timezone的时候没有把步骤做完。

SQL> select *from v$timezone_file;

FILENAME                VERSION

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

timezlrg_4.dat                4

SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value

FROM DATABASE_PROPERTIES

WHERE PROPERTY_NAME LIKE 'DST_%'

ORDER BY PROPERTY_NAME;  

PROPERTY_NAME                  VALUE

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

DST_PRIMARY_TT_VERSION         4

DST_SECONDARY_TT_VERSION       0

DST_UPGRADE_STATE              NONE

最后给出完整的解决方法（升级timezone)

Timezone数据库层面的升级。
注意：该步骤是否执行是和Step 6中的检查结果相关的，只有当Timezone的版本小于14时，才需要执行该步骤。
主要参考：Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using DBMS_DST [ID 977512.1]
1）Timezone升级前的准备工作：
先检查一下当前的timezone版本：
conn / as sysdba
SELECT version FROM v$timezone_file;
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME;
一个典型的输出是：
PROPERTY_NAME                  VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION         4
DST_SECONDARY_TT_VERSION       0
DST_UPGRADE_STATE              NONE
然后开始准备工作：
alter session set "_with_subquery"=materialize;
exec DBMS_DST.BEGIN_PREPARE(14);
接着检查准备状态：
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;
一个典型的输出是：
PROPERTY_NAME                  VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION         4
DST_SECONDARY_TT_VERSION       14
DST_UPGRADE_STATE              PREPARE
-- truncate logging tables if they exist.
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;
TRUNCATE TABLE sys.dst$affected_tables;
TRUNCATE TABLE sys.dst$error_table;
-- log affected data
set serveroutput on
BEGIN
DBMS_DST.FIND_AFFECTED_TABLES
(affected_tables => 'sys.dst$affected_tables',
log_errors => TRUE,
log_errors_table => 'sys.dst$error_table');
END;
/
下面的语句都不能有返回结果：
SELECT * FROM sys.dst$affected_tables;
SELECT * FROM sys.dst$error_table;
SELECT * FROM sys.dst$error_table where ERROR_NUMBER= '1883';
SELECT * FROM sys.dst$error_table where ERROR_NUMBER= '1878';
SELECT * FROM sys.dst$error_table where ERROR_NUMBER not in ('1878','1883');
-- end prepare window, the rows above will stay in those tables.
EXEC DBMS_DST.END_PREPARE;
-- check if this is ended
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;
一个典型的输出是：
PROPERTY_NAME                  VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION         4
DST_SECONDARY_TT_VERSION       0
DST_UPGRADE_STATE              NONE

2）真正开始升级Timezone
conn / as sysdba
shutdown immediate;
startup upgrade;
set serveroutput on
purge dba_recyclebin;
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;
TRUNCATE TABLE sys.dst$affected_tables;
TRUNCATE TABLE sys.dst$error_table;
alter session set "_with_subquery"=materialize;
EXEC DBMS_DST.BEGIN_UPGRADE(14);
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;
一个典型的输出是：
PROPERTY_NAME                  VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION         14
DST_SECONDARY_TT_VERSION       4
DST_UPGRADE_STATE              UPGRADE
下面这条语句应该没有返回结果：
SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE_IN_PROGRESS='YES';
重启数据库：
shutdown immediate
startup
升级相关的table：
alter session set "_with_subquery"=materialize;
set serveroutput on
VAR numfail number
BEGIN
DBMS_DST.UPGRADE_DATABASE(:numfail,
parallel => TRUE,
log_errors => TRUE,
log_errors_table => 'SYS.DST$ERROR_TABLE',
log_triggers_table => 'SYS.DST$TRIGGER_TABLE',
error_on_overlap_time => FALSE,
error_on_nonexisting_time => FALSE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/
如果没有错误，则结束升级：
VAR fail number
BEGIN
DBMS_DST.END_UPGRADE(:fail);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :fail);
END;
/
最后一次检查：
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;
典型输出是：
PROPERTY_NAME                  VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION         14
DST_SECONDARY_TT_VERSION       0
DST_UPGRADE_STATE              NONE
SELECT * FROM v$timezone_file;
FILENAME                VERSION
-------------------- ----------
timezlrg_14.dat              14

升级完成后，可以用如下的方式来进行验证

> exp prdrefwork/petrefwork file=a.dmp tables=csm_offer consistent=y

Export: Release 11.2.0.2.0 - Production on Tue Sep 24 07:25:24 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export done in TH8TISASCII character set and UTF8 NCHAR character set

About to export specified tables via Conventional Path ...

. . exporting table                      xxxxxx    2201 rows exported

Export terminated successfully without warnings.

这次就不会跑错了。大功告成。

时间： 2024-10-23 08:47:07

10g升级至11g exp的问题解决的相关文章

10g升级至11g需要考虑的参数优化

10g升级至11g除了需要做一个详尽的计划, 需要采集10g系统的负载情况,做一个整体的把握,在升级之后,再做负载分析. 保证不会出现大的问题,sql的执行计划不会有大的变动. 参数优化方面,需要考虑下面3个方面. à对于 deprecated Parameter in 11G The following parameters are deprecated from 11G onwards, need suggestion for these parameters. Name Note    

关于create database语句在10g，11g中的不同

最近抽空练习了下手工建库,在10g的时候基本都在20分钟搞定,在11g中其实还可以更快,因为10g中需要配置的admin目录,需要创建bdump,udump之类的目录等等,在11g都被adr给默认替代了,只要提供了$ORACLE_BASE,就会默认在$ORACLE_BASE下生成对应的目录结构. 其它步骤完全可以按照10g的脚本来使用,没有任何问题,但是如果反过来,在11g里使用的一些语句在10g中可能会有一些问题,这一点也是在今天的测试中发现的一个小细节. 首先我在11g的库中创建了一个数据库

oracle 10g和11g版本数据库重建awr的例子

由于某种原因,比如数据异常断电,导致awr数据严重不一致,awr部分表损坏等情况,需要重建awr,可以参考如下步骤进行重建,本文主要针对目前主流的10g和11g版本数据库,12c未进行测试 停止awr自动收集信息 方法1:参数调整 sqlplus /nolog connect / as sysdba create pfile='/tmp/pfile.xifenfei' from spfile; alter system set shared_pool_size = 200m scope = sp

[20141029]10g和11G视图DBA_CONSTRAINTS

[20141029]10g和11G视图DBA_CONSTRAINTS.txt --上午同事讲一下表从10g导入11g时,一些约束没有导入,感觉不可能出现这种情况,我在10g下查看一些约束的状态是是disabled,但是 --type显示的是问号(在toad下).想起来我以前遇到的问题, --[20140131]toad看constraints的问题.txt http://blog.itpub.net/267265/viewspace-1076597/ --很容易明白这些表是没有主键,不过在11g

【sessions】Oracle中sessions和processes的大小关系（10g和11g不同）

[sessions]Oracle中sessions和processes的大小关系(10g和11g不同) 1  BLOG文档结构图 BLOG_Oracle_lhr_[sessions]Oracle中sessions和processes的大小关系(10g和11g不同).pdf 2  前言部分 2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① sessions和processes的大小设置,10g和11g不同(重点

10g和11g中的一些差别

最近有时候看官方文档,感觉11g里面已经有了很多的变化,无论是使用还是安装上的细节上,11g似乎总是能够带给我更多的惊喜.而从以往的使用情况中感觉10g已经足够了,但是越多的使用11g,逐渐的改变了自己的固有思维,很多原来不好,不方便的操作习惯都得到了很大的改善.我就从10g和11g共有的一些细节之处来一窥两个版本中的差别.细节还是太多,我就扒出小部门. 大体会从下面几个部分进行对比和说明,有一些部分已经写了一些文章了,所以突然回顾一下会发现原来这些看似清汤寡水的文章里面还是有值得推敲的东西.

使用带dblink方式的datapump迁移Oracle 10g到11g

      对于从Oracle 10g下迁移数据库到Oracle 11g,除了使用RMAN方式之外,我们可以使用带dblink的datapump方式来实现基于逻辑上的迁移.其步骤也相对简单,而且不会产生中间过程生成的dump文件.本文即针对如何使用该方法给出了示例,供大家参考.   1.确保源数据库和目标数据库处于可用状态 --环境描述 --源库: mftst Oracle 10.2.0.3 + Enterprise Linux Enterprise Linux Server release 5

从Oracle 10g到11g，到底该升不该升？

    话题 Topic Oracle 10gR2目前运行比较平稳,从你的角度来说说,是否有升级的必要性?可从正反两方面来讨论,先抛出论点,再阐述论据.(本期话题贡献人:杨志洪)    正方:升  彭小波:在今年的7月份,我们10多套生产库从10g升级到了11g,高版本是下兼容的,10g在市场运行了这么多年,是相当稳定了.但是11g中改进了很多优化器的算法,也增加很多新特性.不管是从优化,还是管理上,对DBA来说都是一大福音.在升级的过程,我们也遇到一点小问题.   1.在10g升级到11g时,

生产环境oracle10g升级至11g准备工作

最近需要生产系统从10.2.0.5.升级到11.2.0.2.0 做了不少的准备工作,硬是在周末自己搭了测试环境,照着自己准备的升级步骤练习了一番. 除过基本的检查,从Metalink上下载了最新的psu,和公司的资深dba确认后,提供了给了客户.这样数据库就算是升级到11.2.0.2.10 主要有以下的步骤 : 1.new ORACLE_HOME(11g), old ORACLE_HOME (10g) --这些需要提前提供给客户,作为基本的约定 2.install oracle software