数据库恢复服务微信: dbservice1234

Oracle 12c可插拔数据库通用架构图

2015/03/19 by admin Leave a Comment

Oracle 12c可插拔数据库通用架构图

Filed Under: Oracle 12c新特性

Oracle12c新增强特性学习列表

2015/03/19 by admin Leave a Comment

Oracle12c新增强特性学习列表

Filed Under: Oracle

Oracle到MySQL的模式schema转换迁移conversation/migration

2015/03/16 by admin Leave a Comment

针对来自Oracle的不同的schema元素，是否存在自动转换到MYSQL的可能呢？这里我们列出了相关的元素的转换情况。

SELECT:

子句	自动转换？	细节
WITH	No	使用自定义存储过程来做准备数据，或重写查询以避免with子句
AS	No
SELECT	Yes
DISTINCT \| UNIQUE \| ALL	Yes
select_list	Yes
BULK COLLECT INTO	No	用INTO替代
INTO	Yes
record_name	No
FROM	Yes
@dblink	No
materialized view	No
TABLE (collection_expression)	No
MODEL	No	MySQL 不支持MODEL
START WITH	No	MySQL 不支持树形查询，要用存储过程替代
CONNECT BY	No	MySQL 不支持树形查询，要用存储过程替代
PIVOT	No
XML	No
UNPIVOT	No
WHERE	Yes
GROUP BY	Yes
CUBE	No	要用存储过程替代
GROUPING SETS	No	要用存储过程替代
HAVING	Yes
ORDER BY	Yes
SIBLINGS	No
NULLS FIRST \| NULLS LAST	No	MySQL 不支持 NULLS FIRST and NULLS LAST. 用order by 加case实现
FOR UPDATE	Yes
OF	No	要用 FOR UPDATE 替代 FOR UPDATE OF.
NOWAIT \| WAIT	No	MySQL 不支持 WAIT and NOWAIT 子句. 要用FOR update就不能加nowait\|wait
SKIP LOCKED	No	用 FOR UPDATE without SKIP LOCKED替代
UNION	Yes
INTERSECT \| MINUS]	Yes

INSERT

子句	自动转换？	细节
INTO table	Yes
PARTITION	Yes
PARTITION FOR	No
SUBPARTITION	No	要么插入数据到叠加分区，要么对INSERT做手动转换
VIEW	No	用目标表替换INSERT语句涉及的VIEW。若目标是视图上有INSTEAD OF触发器，解析并执行INSTEAD OF 触发器代码
MATERIALIZED VIEW	No	做手动转换
subquery	No	直接对底层面做操作
WITH table_collection_expression	No
column …	Yes
VALUES	Yes
subquery	Yes
RETURNING … INTO	No	.
LOG ERRORS	No	可以在意外处理中加上对error记录插入到日志表的处理。

UPDATE

子句	自动转换？	细节
UPDATE [hint]	Yes
table	Yes
PARTITION	Yes
PARTITION FOR	No
SUBPARTITION	No	Either insert data into the overlying partition, or perform a manual transformation using the UPDATE statement.
VIEW	No	Perform an update on the underlying tables instead.
MATERIALIZED VIEW	No
subquery	No	Perform this operation on the underlying tables instead.
WITH	No
table_collection_expression	Yes
SET	Yes
VALUE
WHERE condition	Yes
RETURNING … INTO	No	To perform this operation, divide the UPDATE statement with the RETURNING clause into an UPDATE statement with following INSERT statements that have the specified key conditions in the SELECT part.
LOG ERRORS	No	You can add error records by inserting them into the log in the exception block. Iterate through the errors in the exception block, add them to the log, and use the EXIT command when finished.

DELETE

Clause	Automatically Converted	Details
DELETE	Yes
FROM	Yes
PARTITION	Yes
PARTITION FOR	No	Either insert data into the overlying partition, or perform a manual transformation using the DELETE statement.
SUBPARTITION	No
VIEW	No	Perform a manual conversion.
MATERIALIZED VIEW	No	Perform a manual conversion.
subquery	No	Perform this operation on the underlying tables instead.
WITH	No
table_collection_expression	Yes
WHERE condition	Yes
RETURNING … INTO	No	To perform this operation, divide the DELETE statement with the RETURNING clause into a DELETE statement with following INSERT statements and use the same key conditions in each SELECT.
LOG ERRORS	No	You can add error records by inserting them into the log in the exception block. Iterate through the errors in the exception block, add them to the log, and use the EXIT command when finished.

MERGE

语句	自动转换？	细节
MERGE	No	用独立的INSERT,UPDATE,DELETE 语句来实现MERGE

TRUNCATE

子句	自动转换？	细节
TRUNCATE TABLE	Yes
PRESERVE MATERIALIZED VIEW LOG	No
PURGE MATERIALIZED VIEW LOG	No
DROP STORAGE	No
REUSE STORAGE	No

锁表

子句	自动转换？	细节
PARTITION	No
SUBPARTITION	No
NOWAIT	No

存储过程

元素	自动转换？	细节
LOCK TABLE	No	MYSQL在存储过程中不支持锁表
dbms_output.put_line	No	将其表现修改为记录到日志表中，可以使用 PD_ORACLE_EXT.PUT_LINE.
dbms_output.put	No	将其表现修改为记录到日志表中，可以使用 PD_ORACLE_EXT.PUT_LINE.

Clause	Automatically Converted	Details
GOTO	No
FORALL	No	Try using a WHILE DO statement.
EXECUTE IMMEDIATE	No
BULK COLLECT	No
RETURNING BULK COLLECT INTO	No
LABEL	No	Try rewriting variables without using labels.

Filed Under: Oracle

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

1 问题现象描述

2015年3月20日接运维同事反馈南宁富士康工厂有异常，前台web界面输入账号密码无反应，这边试了下登录数据库发现数据库无监听，登录外协厂服务器检查发现数据库挂了。

2 问题根因说明

事前巡检同事发现南宁富士康系统存储有异常，有个盘处于即将失效状态，存储中只剩下一个热备盘，如果该盘失效后热备盘将会启用，期间将不允许坏第二块盘。根据事件的紧急层度决定把配件交由将会去南宁的同事帮忙带过去。备件送达南宁工厂但由于工厂流程问题未能及时更换。存储中另一块硬盘损坏，热备盘给启用，该天下午，即将失效的磁盘失效，导致数据库异常系统无法启动。定位到是存储一个硬盘异常导致数据库DATA文件缺失，无法启动数据库。

3 问题判断方法

1、定位到是存储一个硬盘异常导致数据库DATA文件缺失，无法启动数据库。

2、找南宁富士康同事把寄过去的存储备件插上，发现由于之前的备份盘已经给使用了，无备份盘，导致一块硬盘数据缺失，找公司负责存储的同事分析确认通过常规手段恢复不了了，只能把盘拔出来找数据恢复公司恢复了。

3、DBA检查发现由于磁盘损坏数据库无法启动，需要根据备份文件恢复，与DBA沟通，把损坏的磁盘从映射的主机组中去除，并把新到的存储备件插入开始划分LUN并格式化，

预计3个小时能格式化完。格式化完后DBA开始帮忙把新LUN添加到数据库文件组中，并开始根据备份文件还原数据库。

4、DBA检查控制文件发现参数异常没有备份成功，并且数据文件备份好像也有些问题，无法通过备份文件恢复，DBA帮忙协调资源看能否在磁盘损坏的情况下把数据库mount起来，至于丢失数据通过业务方案来补充。

5、DBA通知根据他们那边能协调到的资源无法在部分磁盘损坏的情况下启动数据库，需要项目组看看能否找oracle顾问能否解决。

6、项目组召开紧急会议决定，为了尽快恢复工厂的生产，在原来南宁富士康工厂的服务器上面新建instance，重新部署系统。

4 解决方案

阶段一：恢复产线生产

异常当天组织技术讨论发现无法快速的恢复异常的数据库，项目组决定给南宁富士康工厂新建数据库来使用。DBA开始帮忙新建DATA组并创建instance。新数据库部署完毕，开始导入数据文件，初始化sequence。数据库表结构导入完成，修改was数据源测试通过。开始开始跑数据库的脚本及新系统的部署。系统部署完成，内部及工厂产线开始验证。
内部及工厂产线开始验证完成，工厂开始根据业务方案进行返工处理。

阶段二：对故障库进行数据恢复

1、数据库存储中有一块硬盘损坏，通过raid机制无法对其数据进行恢复，需要找专业的磁盘恢复公司进行硬盘修复。通过公司采购流程采购了存储设备修复服务，将损坏硬盘恢复为能正常使用的硬盘，未对硬盘内部底层数据进行更改。

2、硬盘恢复好后插回原存储中，找DBA帮忙对数据库进行修复和启动。
经过努力，现在grid已经能够起来，几个disk group也已mount上去，但是在打开数据库的时候报ora 600 [2662]错误，这个是由于当前的scn远小于数据块的scn号：
尝试使用了alter session set events ‘10015 trace name adjust_scn level X’;方法来提升scn号，遇到如下问题：

由于出现了ora-00283和ora-16433，尝试重建了控制文件，再重新进行操作，在open的时候它会要求必须使用resetlogs或noresetlogs选项：

最后还是报了ora 600 [2662]错误，scn看上去也没有提升上去。

其实还有一种方式可以提升scn号，即把数据库反复的shutdown和open，但是这只适用于当前scn号与数据文件中的scn号相差不大的场景，这个案例中的当前scn号是4150989410,需要提升到的scn号是4151687346，相差69万多，而每次启停数据库仅能提升4，意味着要打开需要启停10几万次，因此人工方式是不现实的。

这个问题有点棘手，常规方法试了都不起作用，按理说这已经是恢复数据库的最后一步了，但不知道打开后还会不会有其他的问题，恢复出来的磁盘上的数据组织形式是否正确只有在打开后才能验证。

3、针对数据库无法启动异常，咨询了公司相关技术专家都无法处理，找oracle原厂顾问咨询他们也不支持这块业务，最后只能通过公司自行采购流程找到了数据库异常数据恢复的供应商进行处理。供应商技术人员通过技术手段打开了数据库，但是华为DBA在进行导出是发现无法对数据库进行操作，无法导出数据文件。

a.）rman备份到最后报了ORA-19566 exceeded limit of 0 corrupt block问题，有2个数据文件好像有问题，但是没截图。
b.) 想通过expdp导出，但是新建directory时报错

c.) expdp导出一晚上没反应，日志一直都是这样，数据库session见截图，早上以为是临时表空间满了，加大了也没用，帮忙看看

专家到现场进行处理。通过exp导出了大部分表。但是个别表通过oracle自带的exp无法进行导出，技术人员通过工具进行抽取来导出数据。最终所有表都顺利导出数据文件。

4、由于南宁富士康原库恢复出来的数据安装《终端TGMES系统数据归档管理规范V0100》恢复数据将不再导入到南宁富士康现在的生产库中。数据给搬迁还原到TGMES项目归档库中。

如果需要对2015年3月15日之前数据进行查询或者提取，需要提业务数据变更电子流，电子流走到项目组会安排人在后台数据库进行导出。

5 经验总结
1、服务器或存储上面需要做好冗余，需要保障一定量的备份盘并做好RAID机制。
2、硬件如果出现告警，需要第一时间升级并及时得到解决。
3、对数据库备份文件需定期的检查参数并尝试进行还原，防止备份文件不可还原的情况。
4、对数据库这样重要的应用需要有专人进行维护，现所有外协厂都完成的服务器后移至数据中心，数据库由公司专职DBA进行维护。

Filed Under: Oracle

用友NC HR系统后台Oracle备份恢复维护方案

2015/03/15 by admin Leave a Comment

很多用友ERP NC/HR系统的后台 ORACLE 数据库都处于无备份且未打开归档的状态，由于一般企业对于NC或HR系统的后台数据库没有专职的DBA维护，所以实际也不推荐真的开归档并基于归档做备份维护，因为这样做会多一点维护的工作量（如果你是大企业那么理应打开归档并维护归档以满足自身的备份恢复要求，例如大企业要求数据能回溯到一个月前，那么有归档才是合适的。）

对于中小企业使用用友NC或HR系统而言，视乎系统后台ORACLE数据库的大小和可容忍的数据丢失时间，可以自主选择逻辑备份周期。这里说的逻辑备份主要是指ORACLE自带的EXPDP 数据泵导出工具，一般来说目前的用友NC/HR用户的后台ORACLE数据库都是大于版本9i的版本（例如10g和11g等），则都可以选择使用EXPDP，其好处是逻辑导出备份要比传统export/import工具的exp速度上要快很多，且其导出格式也比exp周全。
 
 一般来说中小企业大多可以容忍一天到半天的数据丢失，这部分的数据丢失一般可以基于财务或人力部分的同事通过手工补录来弥补，则对于这种场景下可以规划每12小时或24小时做一次逻辑备份：注意逻辑备份的频率就决定了数据丢失的量，因为逻辑备份是就是一次对数据的全量备份，每一次逻辑备份都是对现有数据的全量备份；所以周一中午12点备份的数据，在周二上午12点备份前的周一下午6点发生了数据库损坏/毁灭等问题，则周一中午到下午6点间产生的数据将可能丢失。
 
 对于逻辑备份而言，其实维护的命令很简单：
 expdp DIRECTORY=(备份存放的目录，需要在ORACLE内以CREATE DIRECTORY创建) dumpfile=(备份的文件名，会放在DIRECTORY下) schemas=(NC或HR所在的Schema) logfile=(日志的文件名，会放在DIRECTORY下） parallel=2
 例如 备份的目录叫DMP，NC或HR所在schema伟NC1和SHR1 则
 expdp DIRECTORY=DMP dumpfile=nc50_20170315.dmp schemas=NC1,shr1 logfile=exp_20170315.log parallel=2
 
 对于Windows可以使用计划任务，对于Unix/Linux可以使用crontab自动调度以上备份脚本；另脚本内一般要考虑删除多久之前的备份文件。
 此外要考虑 逻辑备份一般都是备份在数据库所在服务器，若服务器出现主机故障则恢复将较为麻烦，因此一般会考虑则EXPDP逻辑备份后FTP或COPY到其他远程服务器的磁盘上，以便冗余备份。
 例如在 Linux下 定期备份并传到到FTP服务器上：
 
 #!/bin/sh 
 ORACLE_HOME=/home/app/oracle/product/11.2.0/dbhome_1 
 export ORACLE_HOME 
 export PATH=$ORACLE_HOME/bin:$PATH 
 ORACLE_SID=orcl; export ORACLE_SID 
 HOST='IP地址' 
 USER='ftpuser' 
 PASSWD='password' 
 expdp NC/SHITANRUANJIAN DIRECTORY=backdir DUMPFILE=NC-$(date +%Y%m%d%H) VERSION=10.2 LOGFILE=NCLOG-$(date +%Y%m%d%H).log 
 zip -r /home/app/oracle/admin/orcl/dpdump/NC-$(date +%Y%m%d%H).zip /home/app/oracle/admin/orcl/dpdump/NC-$(date +%Y%m%d%H).dmp 
 cat /home/app/oracle/admin/orcl/dpdump/NCLOG-$(date +%Y%m%d%H).log | mutt -s "NC Backup" NC@tiger.com 
 cd /home/app/oracle/admin/orcl/dpdump 
 ftp -n -v $HOST << EOT 
 binary 
 user $USER $PASSWD 
 prompt 
 put NC-$(date +%Y%m%d%H).zip 
 bye 
 EOT 
 find /home/app/oracle/admin/orcl/dpdump -name "NC*" -mtime +10 -type f -exec rm {} ;

如上脚本首先备份NC用户并FTP到备份服务器上，最后删除10天前的备份。

如上描述了对用友NC的备份方案，之后谈一下恢复方案；使用EXPDP的备份方案后,若出现大规模的数据库问题例如ORACLE数据库打不开或出现大量坏块或ORACLE
所在服务器出现故障无法启动。则可以在必要的可用服务器上安装与之前ORACLE版本一样的ORACLE数据库软件，之后使用DBCA工具创建新的数据库，最后
使用IMPDP工具将之前的备份导入数据库中。

导入命令也十分简单：

impdp DIRECTORY=(备份所存放的目录，需要在ORACLE内以CREATE DIRECTORY创建) dumpfile=(备份的文件名) logfile=(日志的文件名，会放在DIRECTORY下） parallel=2 full=y

其他的一些恢复场景下的恢复方案：
由于 NC/HR 运行在 NOARCHIVELOG 模式下，针对不同的故障场景下可以采取以下恢复策略：
1. SPFILE 初始化参数文件物理损坏：
从 PFILE 中重新生成一个 SPFILE
CREATE SPFILE=’’ FROM PFILE=’’
或者从备份中恢复
RESTORE SPFILE TO PFILE=’’;
RESTORE SPFILE;
RESTORE SPFILE FROM AUTOBACKUP;
2. Control File 文件部分物理损坏：
关闭数据库，将其它完整的控制文件复制到已损坏的控制文件，重启数据库
3. Control File 文件全部物理损坏在数据库关闭时或者出于 mounted 时，即数据库处于一致性状态时 control file 全部物理损坏，则执行 create controlfile 命令重新创建控制文件，如果处于非一致性状态时损坏，则通过最新的物理备份全库恢复，然后追加备份发生时到故障点之间的数据。
4. 非 CURRENT 在线日志文件物理损坏执行 alter database clear logfile 语句重新创建该损坏的非 CURRENT 在线日志文件
5. CURRENT 在线日志文件物理损坏
SQL> startup mount
SQL> recover database until cancel; #(cancel immediately)
SQL> alter database open resetlogs;

6. SYSTEM,SYSAUX,UNDO 表空间物理文件物理损坏：
通过最新的逻辑备份全库恢复

7. TEMP 表空将物理文件物理损坏
执行＂alter database”重新创建 temp 物理文件
8. 用户数据表空间物理文件物理损坏
通过最新的逻辑备份全库恢复
9. 用户索引表空间物理文件物理损坏
重新创建用户索引表空间，然后 rebuilt 相应的索引
10. 物理快损坏
如果该损坏块为用户索引，则 rebuilt 相应的索引
如果该损坏块为用户表，则通过设置 event 将没有损坏的数据正常读出来（损坏块中的数据库会丢失）或者通过关键表的逻辑备份恢复
如果该损坏块为系统数据，通过最新的逻辑备份全库恢复
11. 用户表数据不正常更新(INSERT、UPDATE、DELETE)
可以通过关键表的逻辑备份恢复，或者相应的 flashback 技术恢复
12. 用户表不正常删除(drop)
可以通过关键表的逻辑备份恢复，或者 flashback drop 技术恢复

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

Filed Under: Oracle

关于ROW CR特性_ROW_CR

2015/03/10 by admin Leave a Comment

ROW CR确实是10g以后引入的一个新特性，该特性针对fetch by key的数据访问优化减少一致性读Consistent read。但该特性也造成了一些问题例如出现ORA-600错误、SQL性能下降等。

有不少客户选择关闭了 “_ROW_CR”特性，其性能影响主要体现在 fetch by key的查询的逻辑读可能略微上升。

注：实际上这类问题已经登记过bug 10425196，但最后oracle认定为“not a bug”

From the customers point of view, the root cause of this is the ROW_CR optimization. ROW_CR is enabled by default.

Solution:
Either
require some sort of application changes to avoid such issue;
OR
go back to the original behavior where row_cr is not implemented. To this you would need to run with _row_cr=false.
The developers explain that this is not a bug but an intended behavio

The behavior you are seeing is indeed due to ROW_CR. This optimisation
was brought with the aim of reducing consistent read rollbacks. What
happens is that for a transaction doing a query that has at least
one “fetch-by-key” row-source in it, we advance the snapshot forward; So,
in this example execution of the cursor for the select using the index
picks a snapshot with an scn of (lets call it) “S1” with row-cr turned
on. “S1” is then advanced (across the commit of the update) to “S2″ due to
ROW_CR. That’s why in your testcase the fetches from the cursor pick values
post-commit.

Q1. If disable parameter _row_cr, will it impact the database performance and function which is upgraded from 10g(10.2.0.4 and before) to 11g(11.2.0.3)?
A1. Disabling row_cr has no impact to function but it maybe impact performance.
_ROW_CR is only applicable to queries which use an unique index to determine the row in the table.
The most promising direction of the fix is to reduce the number of Cleanouts and rollbacks by doing ROW CR on the index blocks for Fetch BY Key operations.

The default value of _ROW_CR in 10.2.0.4 or lower is false (non-RAC). Turn off of this optimization in 11g so that things will work exactly as they used to work in 10.2.0.4.

Q2. To RAC, in which version _row_cr is set to true by default?
A2: It is from release 10.2.0.1

Q3. If we disable _row_cr, in which scenario will cause performance issue?
A3. Disabling row_cr could impact the whole database, but the degree of the impact will depend on how much consistent read (where we have to generate undo) the application does.
Monitoring consistent read undo requests would be necessary to really determine the extent of this.

If a block is modified heavily by one application, which does not commit for a long time, all queries on non modified records in the same block by other sessions have
to do a lot of CR rollback. The upcoming SQLs, which access the same block and are using INDEX UNIQUE SCAN, will be impacted and will need extra rollbacks to construct a CR block.

In RAC, when a select has to perform consistent read potentially you have to construct undo from the local and remote instances.
Potentially if a large number of index blocks have been changed then you can arrive at a situation where there’s a lot of cross instance shipping of blocks going on.

Q4. If we disable _row_cr, what’s the possible impact can be seen in AWR report?(RAC/Non RAC)
A4. In AWR part Instance Activity Stats,”CR blocks created” and “deferred (CURRENT) block cleanout applications” maybe will be increased.

（1）该问题是row cr特性导致，且该特性是一个“优化”，不是“bug”。如果不需要使用该特性，可以考虑通过设置_row_cr=false.关闭该特性。
（2）对于从10g升级到11g的单实例，可以关闭该特性，没有功能和性能方面的影响。
（3）对于从10g升级到11g的RAC，由于10g RAC默认是开启该特性的，是否在11g中关闭该特性，需要分析可能存在的隐患。

Filed Under: Oracle, Oracle SQL性能调优

TTS ORACLE Transporting Tablespaces传输表空间统计信息

2015/03/10 by admin Leave a Comment

1. 使用expdp+TRANSPORT_TABLESPACES时默认会导出相关表空间上对象的统计信息。可以用exclude=TABLE_STATISTICS,INDEX_STATISTICS禁止导出统计信息。
2. 使用dbms_stats.lock_table_stats锁住的统计信息，在TTS导入后仍保持锁定状态

SQL>
SQL> create tablespace fortts datafile size 20M;

表空间已创建。

SQL> conn maclean/oracle
已连接。
SQL> create table tvbs as select * from dba_objects;

表已创建。

SQL> exec dbms_stats.gather_table_stats(USER,’TVBS’);

PL/SQL 过程已成功完成。

SQL> alter table tvbs move tablespace fortts;

表已更改。
SQL> alter tablespace fortts read only;

表空间已更改。
C:\Users\xiangbli>expdp maclean/oracle TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts.dmp

Export: Release 11.2.0.3.0 – Production on 星期五 2月 8 10:26:49 2013

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
启动 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_01″: maclean/******** TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts.dmp
处理对象类型 TRANSPORTABLE_EXPORT/PLUGTS_BLK
处理对象类型 TRANSPORTABLE_EXPORT/TABLE
处理对象类型 TRANSPORTABLE_EXPORT/TABLE_STATISTICS
处理对象类型 TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
已成功加载/卸载了主表 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_01″
******************************************************************************
MACLEAN.SYS_EXPORT_TRANSPORTABLE_01 的转储文件集为:
C:\TTS.DMP
******************************************************************************
可传输表空间 FORTTS 所需的数据文件:
C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_.DBF
作业 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_01″ 已于 10:27:41 成功完成
C:\Users\xiangbli>expdp maclean/oracle TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts1.dmp exclude=TABLE_STATISTICS,INDEX_STATISTICS

Export: Release 11.2.0.3.0 – Production on 星期五 2月 8 10:28:25 2013

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
启动 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_02″: maclean/******** TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts1.dmp exclude=TABLE_STATISTICS,INDEX_STATISTICS
处理对象类型 TRANSPORTABLE_EXPORT/PLUGTS_BLK
处理对象类型 TRANSPORTABLE_EXPORT/TABLE
处理对象类型 TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
已成功加载/卸载了主表 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_02″
******************************************************************************
MACLEAN.SYS_EXPORT_TRANSPORTABLE_02 的转储文件集为:
C:\TTS1.DMP
******************************************************************************
可传输表空间 FORTTS 所需的数据文件:
C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_.DBF
作业 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_02″ 已于 10:28:57 成功完成
copy C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_.DBF C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_1.DBF

C:\Users\xiangbli>impdp maclean/oracle TRANSPORT_DATAFILES=C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_1.DBF dumpfile=temp:tts.dmp

Import: Release 11.2.0.3.0 – Production on 星期五 2月 8 10:36:14 2013

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
已成功加载/卸载了主表 “MACLEAN”.”SYS_IMPORT_TRANSPORTABLE_01″
启动 “MACLEAN”.”SYS_IMPORT_TRANSPORTABLE_01″: maclean/******** TRANSPORT_DATAFILES=C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_1.DBF dumpfil
e=temp:tts.dmp
处理对象类型 TRANSPORTABLE_EXPORT/PLUGTS_BLK
处理对象类型 TRANSPORTABLE_EXPORT/TABLE
处理对象类型 TRANSPORTABLE_EXPORT/TABLE_STATISTICS
处理对象类型 TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
作业 “MACLEAN”.”SYS_IMPORT_TRANSPORTABLE_01″ 已于 10:36:18 成功完成
SQL> select NUM_ROWS,blocks ,LAST_ANALYZED from dba_tables where table_name=’TVBS’ and owner=’MACLEAN’;

NUM_ROWS BLOCKS LAST_ANALYZED
———- ———- ————–
75356 1099 08-2月 -13

2. 使用dbms_stats.lock_table_stats锁住的统计信息，在TTS导入后仍保持锁定状态
SQL> exec dbms_stats.lock_table_stats(‘MACLEAN’,’TVBS’);

PL/SQL 过程已成功完成。

C:\Users\xiangbli>expdp maclean/oracle TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts2.dmp

Export: Release 11.2.0.3.0 – Production on 星期五 2月 8 10:39:44 2013

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
启动 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_01″: maclean/******** TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts2.dmp
处理对象类型 TRANSPORTABLE_EXPORT/PLUGTS_BLK
处理对象类型 TRANSPORTABLE_EXPORT/TABLE
处理对象类型 TRANSPORTABLE_EXPORT/TABLE_STATISTICS
处理对象类型 TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
已成功加载/卸载了主表 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_01″
******************************************************************************
MACLEAN.SYS_EXPORT_TRANSPORTABLE_01 的转储文件集为:
C:\TTS2.DMP
******************************************************************************
可传输表空间 FORTTS 所需的数据文件:
C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_1.DBF
作业 “MACLEAN”.”SYS_EXPORT_TRANSPORTABLE_01″ 已于 10:40:15 成功完成
SQL> drop tablespace fortts including contents;

表空间已删除。
impdp maclean/oracle TRANSPORT_DATAFILES=C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_2.DBF dumpfile=temp:tts2.dmp

Import: Release 11.2.0.3.0 – Production on 星期五 2月 8 10:42:02 2013

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
已成功加载/卸载了主表 “MACLEAN”.”SYS_IMPORT_TRANSPORTABLE_01″
启动 “MACLEAN”.”SYS_IMPORT_TRANSPORTABLE_01″: maclean/******** TRANSPORT_DATAFILES=C:\APP\XIANGBLI\ORADATA\TESTMAC\DATAFILE\O1_MF_FORTTS_8K8RGX6W_2.DBF dumpfil
e=temp:tts2.dmp
处理对象类型 TRANSPORTABLE_EXPORT/PLUGTS_BLK
处理对象类型 TRANSPORTABLE_EXPORT/TABLE
处理对象类型 TRANSPORTABLE_EXPORT/TABLE_STATISTICS
处理对象类型 TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
作业 “MACLEAN”.”SYS_IMPORT_TRANSPORTABLE_01″ 已于 10:42:04 成功完成

SQL> exec dbms_stats.gather_table_stats(‘MACLEAN’,’TVBS’);
BEGIN dbms_stats.gather_table_stats(‘MACLEAN’,’TVBS’); END;

*
第 1 行出现错误:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: 在 “SYS.DBMS_STATS”, line 23829
ORA-06512: 在 “SYS.DBMS_STATS”, line 23880
ORA-06512: 在 line 1

11g使用10g的统计信息，由于优化器和统计信息算法的更新可能导致部分SQL执行计划不佳，发生的概率有但是较小。

可以考虑升级到11g后重新收集大部分不是非常大的表的统计信息和执行dbms_stats.gather_fixed_objects_stats，耗时最多的大表在后续可用时段收集。

对于SQL执行计划，可以考虑使用SQL PROFILE、SQL PLAN Management、Hint等技术固定。

Filed Under: Oracle, Oracle 11g新特性

Oracle RAC/Clusterware 多种心跳heartbeat机制介绍 RAC超时机制分析

2015/03/10 by admin 1 Comment

ORACLE RAC中最主要存在2种clusterware集群件心跳 & RAC超时机制分析：

1、Network Heartbeat 网络心跳每秒发生一次； 10.2.0.4以后网络心跳超时misscount为60s,；11.2以后网络心跳超时misscount为30s。

2、Disk Heartbeat 磁盘心跳每秒发生一次； 10.2.0.4以后磁盘心跳超时DiskTimeout为200s。

注意不管是磁盘心跳还是网络心跳都依赖于cssd.bin进程来实施这些操作，在真实世界中任何造成cssd.bin这个普通用户进程无法正常工作的原因均可能造成上述2种心跳超时，原因包括但不局限于 CPU无法分配足够的时间片、内存不足、SWAP、网络问题、Votedisk IO问题、本次磁盘IO问题等等（askmac.cn)。

此外在使用ASM的情况下，DB作为ASM实例的Client客户； ASM实例会对DB实例的ASMB等进程进行监控，以保证DB与ASM之间通信正常。若DB的ASMB进程长期无响应(大约为200s)则ASM实例将考虑KILL DB的ASMB进程，由于ASMB是关键后台进程所以将导致DB实例重启。

也存在其他可能的情况，例如由于ASMB 被某些latch block, 会阻塞其他进程，导致PMON进行强制清理。

综上所述不管是Clusterware的 cssd.bin进程还是ASMB进程，他们都是OS上的普通用户进程，OS本身出现的问题、超时、延迟均可能造成它们无法正常工作导致。建议在确认对造成OS长时间的网络、IO延时的维护操作，考虑先停止节点上的Clusterware后再实施。

另可以考虑修改misscount、Disktimeout等心跳超时机制为更大值，但修改这些值并不能保证就可以不触发Node Evication。

关于RAC /CRS对于本地盘的问题，详见如下的SR回复：

Does RAC/CRS monitor Local Disk IO ?

Oracle software use local ORACLE_HOME / GRID_HOME library files for main process operations.

There are some socket files under /tmp or /var/tmp needed for CRS communication.

Also, the init processes are all depending on the /etc directory to spawn the child processes.

Again, this is a complicated design for a cluster software which mainly rely on the OS stability including local file system.

Any changes to storage / OS are all recommended to stop CRS services since those are out of our release Q/A tests.

由于10.2的环境已经超出我们开发的支持服务期限，建议考虑升级到11.2.0.3来获得更全面的技术支持。

Filed Under: Oracle, Oracle RAC Tagged With: asmb, heartbeat

诗檀软件成功帮助山西某公安系统恢复了超过3TB的数据库

2015/03/08 by admin 1 Comment

诗檀软件成功帮助山西某公安系统恢复了超过3TB的数据库

由于客户数据库使用裸设备，且数据量高达3T。这里仅对整个system表空间文件及部分数据文件头进行备份。
相应备份被放置在/oracle/backup目录下。

1) 备份spfile
create pfile='/home/oracle/pfile1' from spfile;

2) 备份system表空间文件及数据文件头
SQL> select bytes/1024/1024 from v$datafile where file#=1;  --  2040
$ mkdir /oracle/backup

$ dd if=/dev/rrac_system01 of=/oracle/backup/rrac_system01.bak bs=1024000

$ dbv file=rrac_system01.bak blocksize=8192

SQL> set echo off
SQL> set heading off
SQL> set linesize 300 pagesize 0
SQL> select 'dd if='||name||' of=/oracle/backup/header_'||file# || ' bs=1024000 count=10' from v$datafile;

3) 备份控制文件
$ dd if=/dev/rrac_ctrol01 of=/oracle/backup/rrac_ctrol01 bs=1024000

2. 现场报错及启库操作

在数据救援中发现以下报错
Errors in file
/oracle/product/admin/orcl/udump/orcl2.ora_160642.trc:
ORA-00600: internal error code, arguments: [2662], [4], [4186310893], [4], [4186345409], [58720264], [],…

Errors in file 
/oracle/product/admin/orcl/udump/orcl2_ora_136116.trc:
ORA-00600: internal error code, arguments: [2256],[0], [1073741824], [5],[3],[],[],[]

除了以上数据库SCN问题错误外，还存在online redo 日志讹误及Undo问题。诗檀软件工程师通过设置系统参数重新修正了SCN号，通过设置10513， 10231 event事件避免了相关检查报错，并使用恢复操作恢复了数据库。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复