一个升级迁移11g到19c使用xtts遇到的小问题

本文主要是介绍一个升级迁移11g到19c使用xtts遇到的小问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

oracle11.2.0.4到19.21

1.系统权限和对象权限，由于大小写对象名问题，如果使用expdp方式迁移可能存在丢失

迁移后需比对对象、权限，避免遗漏

set pagesize 0
set long 90000
set feedback off
set echo off
spool ddl.sql
select dbms_metadata.get_ddl('TABLE','TAB_NAME','SCOTT') from dual; 
select dbms_metadata.get_ddl('VIEW','VIEW_NAME','SCOTT') from dual; 
select dbms_metadata.get_ddl('INDEX','IDX_NAME','SCOTT') from dual;
spool off;

2.、DBA_SCHEDULER_JOBS中系统默认的job误删除问题

不删除系统默认的job，用户自定义的job可以删除后impdp include=job的方式导入，系统默认的不支持导入。

drop PROCEDURE jyc.MY_PROCEDURE;
EXECUTE DBMS_SCHEDULER.STOP_JOB('JYC.MY_JOB');
EXECUTE DBMS_SCHEDULER.DROP_JOB('JYC.MY_JOB');
drop PACKAGE jyc.MY_PACKAGE;
drop PACKAGE BODY jyc.MY_PACKAGE;
drop view jyc.MY_VIEW;

只能使用如下方式处理（不记得默认job时，可查找同版本的环境获得默认job_name）：

如何重建DBMS_SCHEDULER默认的job和任务 - 墨天轮

3、由于数据量大，手动统计信息所需时间太长，可以考虑迁移后直接导入测试时候的统计信息。

 这样直接从3小时缩短到3分钟。

由于手动收集统计信息时间较长，为快速提升数据库性能，使用之前测试的统计信息导入导目标库以快速还原统计信息（统计信息结果和实际数据相当)，可保证割接后性能正常。
1.一体机测试库（模拟割接的19c）导出统计信息：（注意不是11g的生产库）
expdp \'/ as sysdba\' directory=DMP dumpfile=meta_stat.dmp LOGFILE=meta_stat.log content=metadata_only PARALLEL=1 CLUSTER=N INCLUDE=STATISTICS SCHEMAS=OWNER1,OWNER22.一体机割接正式库（19c)导入统计信息：
impdp \'/ as sysdba\' directory=DMP dumpfile=meta_stat.dmp LOGFILE=meta_stat_imp.log content=metadata_only PARALLEL=1 CLUSTER=N FULL=Y
导入后，登录数据库解锁统计信息：（做成@unlock_stat.sql执行）
sqlplus / as sysdba
EXEC DBMS_STATS.unlock_schema_stats(ownname => 'OWNER');	3.检查是否已经导入统计信息：有记录和时间说明正常导入
select owner,table_name,num_rows,last_analyzed from dba_tables where owner not in('SYS','SYSTEM','OWBSYS_AUDIT','OWBSYS','APEX_PUBLIC_USER','APEX_030200','FLOWS_FILES','SPATIAL_CSW_ADMIN_USR','SPATIAL_WFS_ADMIN_USR','MDDATA','OLAPSYS','ORDDATA','ORDPLUGINS','SI_INFORMTN_SCHEMA','MDSYS','ORDSYS','XDB','ANONYMOUS','CTXSYS','EXFSYS','WMSYS','APPQOSSYS','DBSNMP','ORACLE_OCM','DIP','OUTLN','MGMT_VIEW','XS$NULL','SYSMAN');
检查是否有被锁定的表：查询结果为空表示正常没有被锁定。
SELECT OWNER,TABLE_NAME,PARTITION_NAME,SUBPARTITION_NAME,OBJECT_TYPE FROM DBA_TAB_STATISTICS WHERE STATTYPE_LOCKED IN('ALL', 'DATA', 'CACHE') and owner not in('SYS','SYSTEM','OWBSYS_AUDIT','OWBSYS','APEX_PUBLIC_USER','APEX_030200','FLOWS_FILES','SPATIAL_CSW_ADMIN_USR','SPATIAL_WFS_ADMIN_USR','MDDATA','OLAPSYS','ORDDATA','ORDPLUGINS','SI_INFORMTN_SCHEMA','MDSYS','ORDSYS','XDB','ANONYMOUS','CTXSYS','EXFSYS','WMSYS','APPQOSSYS','DBSNMP','ORACLE_OCM','DIP','OUTLN','MGMT_VIEW','XS$NULL','SYSMAN');

4.索引nologging的坑，查不到数据

dba_indexes where logging='NO'

重建nologging相关索引，可以使用rebuild方式，(最好使用drop和create index方式可修复索引损坏问题)，并行后台操作，例子：

alter session set parallel_force_local=true;
alter session set workarea_size_policy=manual;
alter session set sort_area_size=1073741820;
alter session set sort_area_retained_size=1073741820;
alter session set db_file_multiblock_read_count=128;
--drop index xxx;
--create index xxx on table(col) logging online parallel 32 compute statistics;
alter index xxx.xxx_PK rebuild logging online parallel 32 compute statistics;
alter index xxx.xxx_PK noparallel;

注意检查nologging的对象问题：

Check For Logging / Nologging On DB Object(s) [ID 269274.1]

Two example methods of querying the database for this information:select tablespace_name, logging
from dba_tablespaces[TABLE]
select distinct owner,object_name,object_type from dba_objects
where object_type='TABLE' and
owner not in
('SYS','SYSTEM','SYSMAN','XDB','DBSNMP','EXFSYS','OLAPSYS','MDSYS','WMSYS',
'WKSYS','DMSYS','ODM','EXFSYS','CTXSYS','LBACSYS','ORDPLUGINS','SQLTXPLAIN',
'OUTLN','TSMSYS')
and
object_name in
(select table_name
from dba_tables
where logging='NO');[INDEX]
select distinct owner,object_name,object_type from dba_objects
where object_type='INDEX' and
owner not in
('SYS','SYSTEM','SYSMAN','XDB','DBSNMP','EXFSYS','OLAPSYS','MDSYS','WMSYS',
'WKSYS','DMSYS','ODM','EXFSYS','CTXSYS','LBACSYS','ORDPLUGINS','SQLTXPLAIN',
'OUTLN','TSMSYS')
and
object_name in
(select index_name
from dba_indexes
where logging='NO'); [LOB]select owner,table_name,column_name,tablespace_name from dba_lobs where logging='NO' and owner not in ('SYS','SYSTEM','SYSMAN','XDB','DBSNMP','EXFSYS','OLAPSYS','MDSYS','WMSYS',
'WKSYS','DMSYS','ODM','EXFSYS','CTXSYS','LBACSYS','ORDPLUGINS','SQLTXPLAIN',
'OUTLN','TSMSYS') order by owner,table_name,column_name;
NOLOGGING means whatever operations are performed on the object with the NOLOGGING option set, will NOT be recorded in archive logs. You will have to get a full backup of the database AFTER the NOLOGGING is turned off. The current archive logs will be useless for recovery as there have been changes made to the database that the archives do not know about.Even though you can set the NOLOGGING attribute for a table, partition, index, or tablespace, this mode does not apply to every operation performed on the schema object for which you set the NOLOGGING attribute.There is no interaction between discrete transactions, which always generate redo, and the NOLOGGING mode, which applies only to direct path operations. Discrete transactions can therefore be issued against tables that have the NOLOGGING attribute set.The following operations can make use of NOLOGGING mode:direct load (SQL*Loader)
direct-load INSERT
CREATE TABLE ... AS SELECT
CREATE INDEX
ALTER TABLE ... MOVE PARTITION
ALTER TABLE ... SPLIT PARTITION
ALTER INDEX ... SPLIT PARTITION
ALTER INDEX ... REBUILD
ALTER INDEX ... REBUILD PARTITION
INSERT, UPDATE, and DELETE on LOBs in NOCACHE NOLOGGING mode stored out of lineThe following operations are a few that cannot make use of NOLOGGING mode:Table redefinition cannot be done NOLOGGING
Tempfiles are always set to NOLOGGING mode.

5.上线后遇到.net程序操作blob字段ora-600问题：

xception [type: SIGSEGV, Invalid permissions for mapped object] [ADDR:0x7F34D79CC000] [PC:0x725749E, __intel_avx_rep_memcpy()+222] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/trace/JYCDB1_ora_346792.trc  (incident=208633):
ORA-07445: 出现异常错误: 核心转储 [__intel_avx_rep_memcpy()+222] [SIGSEGV] [ADDR:0x7F34D79CC000] [PC:0x725749E] [Invalid permissions for mapped object] []
Incident details in: /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/incident/incdir_208633/JYCDB1_ora_346792_i208633.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2024-01-27T09:07:41.114149+08:00
Dumping diagnostic data in directory=[cdmp_20240127090741], requested by (instance=1, osid=346792), summary=[incident=208633].
2024-01-27T09:07:43.985415+08:00
Errors in file /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/trace/JYCDB1_ora_346818.trc  (incident=208681):
ORA-00600: 内部错误代码, 参数: [17147], [0x7F50D23F0AD0], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/incident/incdir_208681/JYCDB1_ora_346818_i208681.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2024-01-27T09:07:45.351010+08:00
Dumping diagnostic data in directory=[cdmp_20240127090745], requested by (instance=1, osid=346818), summary=[incident=208681].
2024-01-27T09:07:47.375313+08:00
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x7258D10, __intel_avx_rep_memset()+400] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/trace/JYCDB1_ora_346818.trc  (incident=208682):
ORA-07445: 出现异常错误: 核心转储 [__intel_avx_rep_memset()+400] [SIGSEGV] [ADDR:0x0] [PC:0x7258D10] [SI_KERNEL(general_protection)] []
Incident details in: /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/incident/incdir_208682/JYCDB1_ora_346818_i208682.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2024-01-27T09:07:48.749975+08:00
Dumping diagnostic data in directory=[cdmp_20240127090748], requested by (instance=1, osid=346818), summary=[incident=208682].
2024-01-27T09:07:54.697856+08:00
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x13271E75, kpobii()+245] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/trace/JYCDB1_ora_385848.trc  (incident=205057):
ORA-07445: 出现异常错误: 核心转储 [kpobii()+245] [SIGSEGV] [ADDR:0x0] [PC:0x13271E75] [SI_KERNEL(general_protection)] []
Incident details in: /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/incident/incdir_205057/JYCDB1_ora_385848_i205057.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2024-01-27T09:07:54.737352+08:00
WARNING: too many parse errors, count=123 SQL hash=0x84116851
PARSE ERROR: ospid=251793, error=942 for statement: 
Additional information: hd=0x9e0078d0 phd=0x9abf75a8 flg=0x20 cisid=81 sid=81 ciuid=81 uid=81 sqlid=8bkrn5q212u2j
...Current username=HTJYC
...Application: ClientHost.exe Action: 
2024-01-27T09:07:55.584489+08:00
Dumping diagnostic data in directory=[cdmp_20240127090755], requested by (instance=1, osid=385848), summary=[incident=205057].
2024-01-27T09:08:19.749063+08:00
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x7257783, __intel_avx_rep_memcpy()+963] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/trace/JYCDB1_ora_346787.trc  (incident=197409):
ORA-07445: 出现异常错误: 核心转储 [__intel_avx_rep_memcpy()+963] [SIGSEGV] [ADDR:0x0] [PC:0x7257783] [SI_KERNEL(general_protection)] []
Incident details in: /u01/app/oracle/diag/rdbms/jycdb/JYCDB1/incident/incdir_197409/JYCDB1_ora_346787_i197409.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2024-01-27T09:08:28.006776+08:00
Dumping diagnostic data in directory=[cdmp_20240127090828], requested by (instance=1, osid=346787), summary=[incident=197409].
2024-01-27T09:08:53.642760+08:00

重启实例解决：rac环境一个一个节点重启即可。

srvctl stop service -db db -service dbdg
srvctl stop instance -d db -i db1 -o immediate
srvctl start instance -d db -i db1
srvctl stop instance -d db -i db2 -o immediate
srvctl start instance -d db -i db2
注意检查集群各服务是否都正常
crsctl stat res -t
crsctl stat res -t -init

这篇关于一个升级迁移11g到19c使用xtts遇到的小问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---