客户生产系统需要更好的主机，于是事情就落到我的脑袋上了。这次是开发充当了菜鸟DBA，还好成功了。从下午6点折腾到第二天凌晨3点。打的回家花了我91块，还好能报销。要不郁闷死。以下是我记录下来的方案步骤。
XXXXLIFE数据库迁移步骤
总体迁移方案：
为了确保本次XXXXLIFE的数据库迁移顺利完成，推荐采用二套方案，一套为主迁移方案，一套为备用的方案。当第一套方案迁移失败时，立即采取第二套方案继续迁移。
方案一：
采用停机拷贝的方法将原生产数据库迁移到新生产数据库
1、
停掉到原生产系统的应用，停掉数据库的监听，停掉数据库系统。顺序要依次执行。
2、
备份新数据库的软件安装目录及数据库安装目录。
3、
将原生产数据库的软件安装目录及数据库安装目录拷贝到新生产数据库对应的目录中。
4、
修改数据库相关文件及数据库监听。
5、
启动新的生产数据库，检查数据正确性。
方案二：
在方案一执行完第三步时，启动原生产数据库，以表为单位导出数据。
导出的数据作为备用，当方案一失败时，将导出的数据文件FTP到新生产数据库服务，再执行导入。
本次迁移没有用到第二方案
数据库服务器版本问题
旧服务器为32位服务器ip 为xxxxxxxxx，
旧服务器数据库版本
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
新服务器为64位服务器ip为xxxxxxxxx 。
新服务器数据库版本
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
建议升级时安装 10.2.0.4.0的版本。
因为版本问题，迁移碰到了ora-07445问题，延迟了3个小时。最后查了官方文档，发现这个是oracle的版本bug.需要移除olap，再重新安装olap.如果安装的是10.2.0.4.0的版本，没有这个问题。
预处理环境准备
预先准备 2台新旧机器间建立了nfs共享。这个可以让机房人员先处理完成。如果不行就得使用ftp方式。还是nfs方便处理。
Oracle 64位的数据库已经安装好。最好其sid和用户都和32位旧数据库一致。
处理步骤1、
停掉到原生产系统的应用，停掉数据库的监听，停掉数据库系统。顺序要依次执行。
oracle$ lsnrctl stop
oracle$ sqlplus '/ AS SYSDBA'
SQL> shutdown immediate
2、
备份新数据库的软件安装目录及数据库安装目录。
先将原生产库/xxxxlife/oracle/app/oracle/oradata/ebus/下的所有文件压缩并拷贝到NFS目录中。
例如：tar –zxvf ebpltbs_01.dbf.tar/xxxxlife/server3/
然后将原生产库ORACLE_HOME下的dbs、network目录打成tar包并拷贝到NFS目录中。
$ORACLE_HOME/tar –cvf dbs.tar./dbs
$ORACLE_HOME/tar –cvf network.tar./network
cp *.tar /xxxxlife/server3/
备注：使用tar命令可以把文件权限一起打包备份。
3、
备份原生产数据库的软件安装目录及数据库安装目录到新生产数据库对应的目录中。
备份新生产库ORACLE_HOME下的dbs、network目录，在新生产数据库的$ORACLE_HOME下执行：
tar -cvf dbs01.tar ./dbs
tar -cvf network01.tar ./network
在新生产服务器上建立迁移所需的目录
mkdir /xxxxlife/oracle/app/oracle/oradata/ebus/
mkdir /xxxxlife/oracle/app/oracle/admin/ebus/adump
mkdir /xxxxlife/oracle/app/oracle/admin/ebus/bdump
mkdir /xxxxlife/oracle/app/oracle/admin/ebus/cdump
mkdir /xxxxlife/oracle/app/oracle/admin/ebus/udump
mkdir /xxxxlife/oracle/app/oracle/admin/ebus/dpdump
将xxxxlife/server3下的文件解压到对应的目录
tar -zxvf ebpltbs_01.dbf.tar -C /xxxxlife/oracle/app/oracle/oradata/ebus/
…………………………..其它的文件解压省略
tar -zxvf dbs.tar -C /xxxxlife/oracle/app/oracle/product/10.2.0/db_1
tar –zxvf network.tar -C /xxxxlife/oracle/app/oracle/product/10.2.0/db_1
漫长的复制过程
基本是原目录->nfs->新服务器目录。
4、
修改数据库相关文件及数据库监听。
修改新服务器 .Bash_profile文件
修改其sid=和旧数据库sid一致
用 . .bash_profileexport出oracle环境变量设置
5、
启动新的生产数据库，运行数据库更换环境升级必须运行的2个脚本
Shutdown immediate
Startup upgrade
SQL>@C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlirp.sql;
Shutdown immediate
Startup
SQL>@C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlrp.sql;
Shutdown immediate
startup
启动应用，应用把数据库连接主机全部修改，进行测试。做一个当天交易并当日撤单。没有问题。迁移成功。
注：版本bug处理
在升级后发现ORACLE的OLAP组件存在无效对像，无法正常使用，在日志的相应TRACE文件中报如果下错误：
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x2b978032ff, PC: [0x2a955720a8,
_intel_fast_memcpy.A()+10]
*** 2010-04-07 23:28:33.935
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Address not mapped to object]
[0x2B978032FF] [] []
Current SQL statement for this session:
declare
rc sys_refcursor;
begin
:1 := "SYS"."OLAPIMPL_T"."ODCITABLEDESCRIBE"(:2 ,'SYS.AWMD duration
query','olapsys.ALL_OLAP2_AW_METADATA_T','ACTIVE_CATALOG ''ALL_OLAP2_AW_PHYS_OBJ'' ''ALL''','MEASURE AWOWNER FROM
sys.awmd!AWOWNER
MEASURE AWNAME FROM sys.awmd!AWNAME
MEASURE AWOBJECT FROM sys.awmd!AWOBJECT
MEASURE COL1 FROM sys.awmd!AWOBJECTTYPE
MEASURE COL2 FROM sys.awmd!AWOBJECTDATATYPE
DIMENSION AWMDKEY FROM sys.awmd!AWMDKEY');
end;
通过在ORACLE官方网站METALINK中查询到可以通过如下步骤来重新安装OLAP组件
1. Remove OLAP:
At the system prompt 'cd' to the ORACLE_HOME/olap/admin directory then:
SQL> @?/olap/admin/catnoamd.sql
SQL> @?/olap/admin/catnoaps.sql
SQL> @?/olap/admin/catnoxoq.sql
SQL> @?/olap/admin/olapidrp.plb
2. Add OLAP
Add the OLAP option to an existing Enterprise Edition Database
Assuming that you created your database manually or via DBCA, Enterprise
Edition in Oracle Database 10g:
SQL> connect SYS as SYSDBA
SQL> Spool olap.log
SQL> @?/olap/admin/olap.sql SYSAUX TEMP;
3. Recompile any invalid objects:
SQL> @?/rdbms/admin/utlrp
4. Check for any invalid OLAPSYS objects:
select owner, object_name, object_type, status from dba_objects where status = 'INVALID' and OWNER = 'OLAPSYS' ;
后记：为啥copy这么慢？后来咨询客户所在的网络托管服务商。才发现，做迁移时机器是在DMZ区。。。。为了能让我们能远程操作。哎。。。
[ 本帖最后由 qinzhh 于 2010-5-31 14:52 编辑 ]
|
