oracle进行主备数据库切换

[chinaboycj]

硬件环境：两台数据库服务器 无存储共享，每台服务器容量为6*250G,操作平台非cluster 网络连接 .
一台web服务器
软件环境：Turbolinux server 10.5 +oracle10g
目的：1、通过web查询的数据存放在两台数据库服务器上的数据一致。
2、主库与备库的切换.。

请大家指教，初学oracle，就接触比较难搞的东西。

需要linux和oracle下需要安装额外的包吗？怎么配置？希望大虾们给一个方案和步骤，谢谢了。

[IndependentDeveloper]

我看到这个第一个想法就是做个standby,看其他人有什么好的建议

[傻儿哥]

1.
安装oracle 流复制服务,指定源和目标.
在两套服务器上安装两套数据库,再配置服务(传播,捕获,应用服务)
平时只有主库可以使用,主库失败后,可以切换到备库.
不需要额外的软件包,
2.安装oracle dataguard服务,
1楼说的 standby 和primary.
这个分为物理 dataguard和逻辑dataguard.
建议采用物理的.(配置相对简单)

[Dave]

楼主 先搭配个DATA guard环境，在切换。

Windows 下 Oracle 10GR2 DataGuard 实例
http://user.qzone.qq.com/251097186/blog/1247229475

-----------------------------------------------------------------------
主备库切换

1. switchover

一般SWITCHOVER切换都是计划中的切换，特点是在切换后，不会丢失任何的数据，而且这个过程是可逆的，整个DATA GUARD环境不会被破坏，原来DATA GUARD环境中的所有物理和逻辑STANDBY都可以继续工作。 在进行DATA GUARD的物理STANDBY切换前需要注意：
确认主库和从库间网络连接通畅；
确认没有活动的会话连接在数据库中；
PRIMARY数据库处于打开的状态，STANDBY数据库处于MOUNT状态；
确保STANDBY数据库处于ARCHIVELOG模式；
如果设置了REDO应用的延迟，那么将这个设置去掉；
确保配置了主库和从库的初始化参数，使得切换完成后，DATA GUARD机制可以顺利的运行。

主库：
1. 查看switchover 状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
to standby
附： A:switchover_status出现session active/not allowed
当出现session active的时候表示还有活动的session,则运行
Alter database commit to switchover to physical standby with session shutdown;
当出现not allowed时，在官方文档说转换会不成功，但是我测试的时候成功了，如果大家在测试不成功的时候再和我说，让我看看在什么情况下会不成功。

B.ora- 01153: an incompatible media recovery is active
运行下面代码
Alter database recover managed standby database finish;
或者Alter database recover managed standby database finish force;
Alter database recover managed standby database disconnect from session;
2 切换成备库
SQL>Alter database commit to switchover to physical standby with session shutdown;
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
Database altered.

3 启动到mount和应用日志状态
SQL> SHUTDOWN IMMEDIATE
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

4. 查看数据库模式
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status;
SQL>select status,database_mode from v$archive_dest_status;

备库：

1.查看switchover状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
TO PRIMARY
附：若不是用此语句切换：ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY with session shutdown
2. 切换成主库
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
SQL> shutdown immediate;
SQL> startup;
SQL> alter system switch logfile;
3. 查看数据库模式
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status;
SQL>select status,database_mode from v$archive_dest_status;

注意地方:
如果做了switchover,主库参数设置成以下方式，会触发ora-16009错误
Alert system set log_archive_dest_2=’service=primary
DB_UNIQUE_NAME=orcl’ scope=spfile;
然后再alert_orcl.log 日志中会出现以下错误内容
Thu Nov 27 10:19:12 2008
Redo Shipping Client Connect
-- Connected User is Valid
RFS[2]: Assigned to RFS process 1292
RFS[2]: Database mount ID mismatch [0x4781d95f:0x47823be1]
RFS[2]: Client instance is standby database i
RFS[2]: Not using real app
Thu Nov 27 10:19Errors in file
d:\oracle\product\10.2.0\admin\orcl\udump\orc
ORA-16009: 远程归档日
从metalink上查到:
* fact: Oracle Server - Enterprise Edition 9
* symptom: Errors appears in alert.log on primary database
* symptom: RFS: client instance is standby database instead
* symptom: RFS: Not using real application clusters
* symptom: Errors appear in alert.log on standby database
* symptom:
database
standby database
primary database
* symptom: Standby redo log files are defined on the standby database
* cause: The standby redo log files are synchronously filled with redo
from the primary database. When a logswitch occur on the primary database,
those files are archived on the standby database before being applyed on
it. The archiving process on the standby database should only archive to
the local disks on tprimarfix:
Disable the remote archiving on the standby databasExample: alter system set log_archive_dest_2 = ''
是因为没有把standby 上的log_archive_dest_2 清空导致的。
另外也有可
bug 4676659
Standby may not be recognised (ORA-16009)
When the log transport is LGWR ASYNC and logical standby has
LOG_ARCHIVE_DEST setting VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE)
ORA-16009 is reportedregular interWorkaround:
There is no workaround to prevent ORA-16009 from appearing in alert logs.

2. Failovers：
FAILOVER切换一般是PRIMARY数据库发生故障后的切换，这种情况是STANDBY数据库发挥其作用的情况。这种切换发生后，可能会造成数据的丢失。而且这个过程不是可逆的，DATA GUARD环境会被破坏。
由于PRIMARY数据库已经无法启动，所以FAILOVER切换所需的条件并不多，只要检查STANDBY是否运行在最大保护模式下，如果是的话，需要将其置为最大性能模式，否则切换到PRIMARY角色也无法启动。


1.查看是否有日志GAP,没有应用的日志：
SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
　　SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
　　如果有，则拷贝过来并且注册
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径';
重复查看直到没有应用的日志：
2. 然后停止应用归档：
　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
　　Database altered.
3. 下面将STANDBY数据库切换为PRIMARY数据库：
　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
或 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
　　Database altered.
　　SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
　　DATABASE_ROLE
　　----------------
　　PHYSICAL STANDBY
　　SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
　　Database altered.
SQL> ALTER DATABASE OPEN; 或者 shutdown immediate+startup
　　Database altered.

　　检查数据库是否已经切换成功：
　　SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
　　DATABASE_ROLE
　　----------------
　　PRIMARY
　　至此，FAILOVER切换完成。这个时候应该马上对新的PRIMARY数据库进行备份。

[傻儿哥]

某项目用户级别流复制配置过程
http://blog.csdn.net/csucxcc/archive/2009/08/14/4446582.aspx
此项目采用了grid control来维护两台机器的流复制,曾经出现网络断流导致
服务失败的情况,直接用grid control 重新apply 应用就解决了

[ccsion]

学习了！不错！

[jieki]

各位大侠真牛啊

[ruihuahan]

Data guard