Oracle 项目就是那回事 数据库迁移（1）

     做数据库迁移是一件蛋疼的事，做数据库设计的人，往往不考虑数据构架的可扩展性，因为做数据库迁移的人不是做数据库设计的人。

之前做了这样的一个数据库迁移，要求大概如下

   1.晚上大概有5个小时的宕机时间，可以做整库（A机）迁移操作。

   2.数据的数据量在900G左右。

   3.同样的操作系统和数据库版本

   4.迁移的时候，需要更改数据库名和实例名。

   5.客户现场没有数据备份磁带或磁盘设备。

   6.可用的就是一台硬件升级过的小机（B机），用来运行迁移后的数据库，没有共享存储。

  看到这个要求我心里大概有些谱了。

    5个小时的宕机时间，900G的数据，做数据库的导入导出估计没戏。基本上定调做数据恢复来实现。再加上没有磁带备份，如果使用RMAN做备份和恢复

1.较为复杂，步骤繁多，多异出错  2。没有磁带备份设备，如果在数据库备份时可能会影响生产库。

    这样一来基本上就定位在用户管理下的一致性数据库迁移。

  具体的实施计划由于公司有规定不得公开。不过大致把过程说了一下。

  1. 早上就到数据中心，看到IBM的小机和存储，记录了系统参数和配置，就开始重装系统，划分LVM，和裸设备。

  2.做完这个，就中午1点了到了吃饭时间。买了个汉堡，塞到嘴里回去接着干。开始安装ORACLE 10 G FOR AIX。

  3.安装完成 也就到了下午五点，头昏老胀出去转了一圈。顺便吃了饭，准备晚上夜宵。

  4.再次回到机房，将B机上的目录结构做好，配置上数据实例。并开始检查环境，是否有问题，比如监听器是否正常，到A机到B机的网络是否连通等等。中间出了点小问题。稍后再说。

  5.幸好机房里一起加班的人还真挺多，也就同这些IT宅男 七零八碎的忽悠起来，除非就是感叹人生，思考人生，其中有个南方来的北漂，说起武汉的热干面

差点都没有痛哭流涕，最后还来了一句，飘飘何所似，天地一沙鸥。 哥们太有才了！

  6.到了11点 我就去跟数据库管理员忽悠，希望他能提前发通知，让数据库shutdown,我就可以多一个小时做操作，心里也轻松些。 管理员在哪玩着QQ游戏，斗着地主，玩的正High，看我到了跟前，不情不愿的起身。11点了，也没有什么业务操作了，给各个业务部门打了电话，发了通知。这下我可以动手了！

  将A机上数据库Shutdown 通过SFTP 开始将小的数据文件传输到B机。同时用公司的磁盘做物理拷贝。一个多小时后复制完成。

  7.由于没有建库，直接通过初始化文件，控制文件，口令文件，日志文件，和数据文件恢复，速度很快，不过要是其中文件有损坏，就得直接重新复制。

 总体来说，操作还算顺利，不过中间出了这几个问题。

 1.将B库的数据库重命名。

     方案1：有点想当然， 更改了初始化文件中的DB_NAME,Backgroud_dump_dest,core_dump_dest,user_dump_dest，audit_file_dest中文件路径后，

再更改control_files 名称.使用orapwd重新新建了用户口令文件。就开始启动数据库。

     

SQL> startup mount
ORACLE instance started. 

Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 71304572 bytes
Database Buffers 88080384 bytes
Redo Buffers 7139328 bytes
ORA-01103: database name 'xxx' in control file is not 'XXX'

   没辙，在启动时使用的控制文件使用了原来的数据库名。只有使用方案2

     方案2：先按原来数据名加载，然后通过重建控制文件更改数据库名。

--改回来原来的DB_NAME
SQL>startup mount
SQL> alter database backup controlfile to trace; 

Database altered.

SQL> select c.value || '\' || d.instance_name || '_ora_' || a.spid || '.trc' trace
2 from v$process a,v$session b, v$parameter c, v$instance d
3 where a.addr = b.paddr
4 and b.audsid = userenv('sessionid')
5 and c.name = 'user_dump_dest'
6 /

TRACE
-----------------------------------------------------------
/ORACLE/PRODUCT/10.2.0/ADMIN/ORCL/UDUMP/orcl_ora_4012.trc

    生成的控制文件Trace 来得到生成控制文件的语句。将其中的db_name后，执行alter database open resetlogs

 2.在执行alter database open resetlogs.发生如果错误

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file1: '/opt/oracle/oradata/XXX/system01.dbf'

  没有头绪，从报错来看由于数据文件与控制文件文件不一致造成。难道是A库关闭时出现问题，导致控制文件中的SCN同数据文件的SCN 不一致造成？

 不确定。登上A库，启动A库，果然不出我料。启动数据库失败。

SQL> startup 
ORACLE 例程已经启动。 
Total System Global Area 293601280 bytes 
Fixed Size 1248624 bytes 
Variable Size 121635472 bytes 
Database Buffers 167772160 bytes 
Redo Buffers 2945024 bytes 
数据库装载完毕。 
ORA-01122: 数据库文件 1 验证失败 
ORA-01110: 数据文件 1: 
'F:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\XXX\SYSTEM01.DBF' 
ORA-01207: 文件比控制文件更新 - 旧的控制文件 

只能在A库上做数据库控制文件的恢复，ORACLE中的文档给出的步骤是:

Cause: The control file change sequence number in the datafile is greater than the number in the control file. This implies that the wrong control file is being used. Note that repeatedly causing this error can make it stop happening without correcting the real problem. Every attempt to open the database will advance the control file change sequence number until it is great enough. 
Action: Use the current control file or do BACKUP CONTROLFILE RECOVERY to make the control file current. Be sure to follow all restrictions on doing a BACKUP CONTROLFILE RECOVERY. 
Solution： 
1． Check alert file，kill monitor process 
2． Startup mount， 
3． “alter database backup control to trace” 
4． Find the trace file,and open it 
5． Startup nomount 
6． recreate controlfile using resetlogs 
7． “recover database using backup controlfile” 
8． “alter database open resetlogs;” 
9． “alter tablespace temp add tempfile '.dbf' reuse;” 

执行完成后，启动成功，重新备份到B机，恢复，成功。

 3.中间启动时出现了一个小问题

SQL> startup pfile=$ORACLE_HOME/dbs/initRACDB.ora
ORACLE instance started.

Total System Global Area  218103808 bytes
Fixed Size                  1218604 bytes
Variable Size              71305172 bytes
Database Buffers          142606336 bytes
Redo Buffers                2973696 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/data/oradata/racdb/system01.dbf'

进行了recover database ;恢复失败，连接被强行断开，查看alert.log日志文件，发现由于initxx.ora 初始化配置文件配置错误，更改后启动。OK。

进行数据的测试，没有丢失，GameOver!

4.在开始启动时遇到的一个小问题

A database is started in EXCLUSIVE mode by default. Therefore, the 
ORA-01102 error is misleading and may have occurred due to one of the 
following reasons: 

- there is still an "sgadef<sid>.dbf" file in the "ORACLE_HOME/dbs" 
directory 
- the processes for Oracle (pmon, smon, lgwr and dbwr) still exist 
- shared memory segments and semaphores still exist even though the 
database has been shutdown 
- there is a "ORACLE_HOME/dbs/lk<sid>" file 

The "lk<sid>" and "sgadef<sid>.dbf" files are used for locking shared memory. 
It seems that even though no memory is allocated, Oracle thinks memory is 
still locked. By removing the "sgadef" and "lk" files you remove any knowledge
oracle has of shared memory that is in use. Now the database can start.

POSSIBLE SOLUTION:
Verify that the database was shutdown cleanly by doing the following: 

1. Verify that there is not a "sgadef<sid>.dbf" file in the directory 
"ORACLE_HOME/dbs". 

% ls $ORACLE_HOME/dbs/sgadef<sid>.dbf 

If this file does exist, remove it. 

% rm $ORACLE_HOME/dbs/sgadef<sid>.dbf 

2. Verify that there are no background processes owned by "oracle" 

% ps -ef | grep ora_ | grep $ORACLE_SID 

If background processes exist, remove them by using the Unix 
command "kill". For example: 

% kill -9 <Process_ID_Number> 

3. Verify that no shared memory segments and semaphores that are owned 
by "oracle" still exist 

% ipcs -b 

If there are shared memory segments and semaphores owned by "oracle", 
remove the shared memory segments 

% ipcrm -m <Shared_Memory_ID_Number> 

and remove the semaphores 

% ipcrm -s <Semaphore_ID_Number> 

NOTE: The example shown above assumes that you only have one 
database on this machine. If you have more than one 
database, you will need to shutdown all other databases 
before proceeding with Step 4. 

4. Verify that the "$ORACLE_HOME/dbs/lk<sid>" file does not exist 

5. Startup the instance 

good luck,