分类： Oracle
2008-04-28 20:33:38
|
作者：中联集团技术总监 甘荃
创新性应用
应用一：在同一主机上把一个数据库分拆成2个数据库的应用
Oracle数据库分离操作步骤如下：
备份源数据库步骤： 关闭数据库；备份数据文件(datafiles)；备份控制文件 ；备份redo log；
备份当前归档日志；备份口令和参数文件；打开数据库。
创建目标数据库步骤：创建一新文件系统存放原ORACLE安装产品；创建一个用户设置一个新的ORACLE_HOME；恢复数据文件到一个新的路径；恢复控制文件到一个新的路径；恢复redo log到一个新的路径；恢复当前归档日志到一个新的路径；恢复口令和参数文件到一个新的路径；修改参数文件；打开数据库。
配置目标数据库的rman备份：配置listener；配置tnsnames.ora；创建新的catalog信息；
备份/恢复脚本编写：ha脚本；oracle的启动脚本；oracle的停止脚本 。
行业借鉴经验
经验一：数据库分离方案
在金融行业由于交易量比较大，查询打印的交易也比较多。如果在同一数据库中既有OLTP交易，又有查询打印交易，将大大影响数据库性能。所以很多客户都提出数据库分离的需求。一个数据库处理OLTP交易，另外一个数据库处理查询打印类交易。针对这个需求，有很多种方案：
采用存储技术实现，例如，分割镜像是磁盘卷的一个相同而独立的副本，可附属于不同的系统，并且具有多种用途，如填充测试系统、作为数据库的热备用副本以及从主机中清除备份。分割镜像对硬件没有特殊要求。如 IBM Enterprise Storage Server (ESS)，即 "Shark"™，以及 EMC®Symmetrix®3330。由于使用了 FlashCopy™ 技术，ESS 能完全在内部建立准瞬时的数据副本。Symmetrix 上的 EMC TimeFinder®软件的瞬时分割特性也能以类似的方式分割镜像。
采用数据库的复制技术，例如 DB2的SQL复制，Oracle的高级复制等。
采用第三方数据库复制软件，例如：DSG公司的RealSync、QUEST公司的产品、realtime公司的产品等。
经验二：基于软件的数据备份技术
在应用软件进行灾难备份的解决方案中，应从下面三个层次考虑：
用户应用程序
客户机软件
数据库引擎
其中用户应用程序和客户机软件一般不包含关键数据，几乎所有数据都由数据库引擎管理并放置在数据库服务器中。在这三者之中，数据库中的数据保护最为重要。
一般情况下，用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份，当灾难发生时，可以通过这些备份重新安装和配置用户应用程序和客户机软件。
对数据库的备份，如果采用硬件级灾难备份有两种方法：一是采用备份的方法，即定期地将数据备份到硬盘和磁带/磁带库上，这些磁带可以通过运输的方式运到远程，以防磁带在本地的灾难中发生毁坏。这种方法的缺陷是实时性较差，恢复时间较长；另一种做法就是硬件镜像的做法，这种做法在硬件的投资上较大，对两点间的网络带宽有较大的要求。那么，有没有一种两者兼顾的解决方案呢？数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。在前面提到的灾难恢复方案的7个层次中属于第5或第6层次。
数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。目前已有的产品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。
IBM DB2 HADR是High Availability Disaster Recovery 的缩写，HADR 将HA(高可用性)和INFORMIX DR的技术紧密结合起来。INFORMIX HDR是High Availability Data Replication的缩写。
HDR的工作原理是通过将主数据库服务器(简称为A)的逻辑日志缓冲区复制到备份数据库服务器(简称为B)，而且能在主数据库服务器操作失败时自动切换到备份数据库服务器。复制方式有同步方式和异步方式两种。我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。
正常状态下，主数据库服务器做数据库的读写操作，备份数据库服务器为只读方式。当主数据库服务器失败时，备份数据库服务器会自动接管主数据库服务器的事务处理。此时，备份数据库服务器作为主数据库服务器进行数据库的读写操作。当主数据库服务器被修复后，主数据库服务器作为新的备份数据库服务器。
数据库复制对硬件的要求相对较低，只要主数据库服务器和备份数据库服务器的硬件配置相同即可，不是必须使用高端存储设备，例如IBM ESS等。主数据库服务器和备份数据库服务器的距离不受限制，而且对网络的压力并不大，但需要更强的数据库管理能力。
应用难点技巧
技巧一：DB2 UDB 从V6.1升级到V8.1之后，发现应用程序频繁出现了锁超时的现象。通过抓取当时的快照发现主要是一些next key lock引起，后来通过设置db2set DB2_RR_TO_RS=yes，重新启动了数据库和应用之后，使得该问题得到解决。最后通过查看相关的资料发现在DB2升级，应该对索引做“db2 reorg indexes all for table $TABNAME convert”。将索引类型从type-1转换成type-2，这样可以减少next key lock.
技巧二：数据库查询中的几个大表关联的查询语句的性能优化，由于应用的局限性有时很难对这种语句进行调整。针对oracle数据库的解决办法是把这个些表尽可能的驻留到内存中，性能可以得到明显的提高。
技巧三：在应用中使用informix 9.4和cics5.1，如果在应用中不对cursor进行关闭和释放，将导致cics region异常down。最后建议在数据库应用程序中需要对cursor进行关闭和释放。
测试用例：
#include
$include sqlca;
main( void )
{
$char jshzh[23];
char *CommArea;
EXEC CICS ADDRESS EIB( dfheiptr );
EXEC CICS ADDRESS COMMAREA( CommArea );
memset(jshzh,0,sizeof(jshzh));
strcpy(jshzh,"1234567890123456789012");
jshzh[22]='\0';
printf("************ zh[%s]\n",jshzh);
EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz
where zh=:jshzh for update;
if (sqlca.sqlcode !=0) {
printf("declare zh_cur1 err zh[%s]\n",jshzh);
EXEC CICS SYNCPOINT ROLLBACK;
EXEC CICS RETURN;
}
EXEC SQL open zh_cur1;
if (sqlca.sqlcode !=0) {
printf("open zh_cur1 err sqlca.sqlcode[%s]\n",sqlca.sqlcode);
EXEC CICS SYNCPOINT ROLLBACK;
EXEC CICS RETURN;
}
EXEC SQL close zh_cur1;
if (sqlca.sqlcode !=0) {
printf("close zh_cur1 err sqlca.sqlcode[%s]\n",sqlca.sqlcode);
EXEC CICS SYNCPOINT ROLLBACK;
EXEC CICS RETURN;
}
EXEC SQL free zh_cur1;
if (sqlca.sqlcode !=0) {
printf("free zh_cur1 err sqlca.sqlcode[%s]\n",sqlca.sqlcode);
EXEC CICS SYNCPOINT ROLLBACK;
EXEC CICS RETURN;
}
EXEC CICS RETURN;
}
使用测试用例进行上述测试，从测试结果中发现
在cics和informix一阶段时：
如果minserver 本文出自 51CTO.COM技术博客 如果minserver=maxserver时，进行测试时，如果对定义和打开的cursor不close 和 free cursor，当cics region系统空闲时，cicsas个数从maxserver下降时，cics region 正常。
在cics和informix二阶段时：
如果minserver 技巧四：在DB2数据库备份时出现了SQL1015的错误
检查数据库的状态，能够正常连接数据库，表空间的状态都是normal。但是对数据库做备份的时候出现了SQLCODE 1015的错误。通过分析错误，对数据库做了db2 restart db $DBNAME，发现数据库中存在了indoubt transactions。通过使用db2 list indoubt transactions with prompting 处理了相关的indoubt transactions，然后成功地对数据库进行了备份。
技巧五：解决oracle rman不能使用tsm备份到磁带库上的问题，
RMAN> backup incremental level 0 database plus archivelog delete all input tag=W
eekly_level_0_Backup;
Starting backup at 2005-07-26 20:06:36
current log archived
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 07/26/2005 20:06:37
ORA-03113: end-of-file on communication channel
但能够成功备份到磁盘上，执行dsmc，出现了coredump。分析问题应该在tsm上。查看core文件
gjjb>dbx dsmc core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
IOT/Abort trap in pthread_kill at 0x9000000004f3158 ($t1)
0x9000000004f3158 (pthread_kill+0x9c) e8410028 ld r2,0x28(r1)
(dbx) where
pthread_kill(??, ??) at 0x9000000004f3158
_p_raise(??) at 0x9000000004f2b84
raise.raise(??) at 0x900000000042f64
abort() at 0x9000000000502a4
psAbort__Fv() at 0x100006f8c
psTrapHandler__FiT1P12__sigcontext() at 0x100006f28
strcpy.strcpy() at 0x10000b84c
StrCpy__FPcPCc() at 0x100008d10
最后，把tsm从5.2.2.9升级到5.2.4，dsmc可以正常使用，同时oracle rman成功备份到磁带库上。
技巧六：Recovering a Backup Made Before a RESETLOGS的步骤
obtain primary key of old incarnation ：LIST INCARNATION OF DATABASE syrun.
RMAN> list incarnation of database syrun;
List of Database Incarnations
DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 28 SYRUN 3143198795 NO 1 2005-06-18:17:43:39
1 2 SYRUN 3143198795 NO 109807 2005-06-20:00:49:06
1 16715 SYRUN 3143198795 YES 14102235 2005-07-28:11:56:06
1 1428 SYRUN 3143198795 NO 14104660 2005-07-27:16:33:36
RESET DATABASE TO INCARNATION 2;
恢复脚本：
run {
shutdown immediate;
startup nomount;
set until time='2005-07-27:14:03:54';
RESTORE CONTROLFILE;
alter database mount;
restore database;
recover database;
alter database open resetlogs;
}
数据库恢复之后需要执行如下步骤，例如：
ALTER TABLESPACE "GJJTMP" ADD TEMPFILE '/dev/rora_gjjtmp' size 6000M REUSE;
ALTER TABLESPACE "TEMP" ADD TEMPFILE '/dev/rora_tmp' size 250M REUSE; |
