一、環境
主庫：oracle根目錄：/data/db/oracle
sid:qyq
資料檔案路徑/data/db/oracle/oradata/qyq
歸檔檔案路徑：/data/db/oracle/archive'
備庫：sid:qyq
二、備庫不同步的問題檢查方法
1、檢查主備兩邊的序號
select max(sequence#) from v$log; ---檢查發現一致
3、檢查備庫是否開啟實時應用
select recovery_mode from v$archive_dest_status where dest_id=2;
4、檢查備庫狀態
select switchover_status from v$database; --發現狀態not allowed
3、看看程序mrp是否存在
ps aux|grep mrp --發現程序不存在
4、如果不存在執行以下：
alter database recover managed standby database using current logfile disconnect;
alter database recover managed standby database disconnect from session; --後台執行
alter database recover managed standby database --前台執行，執行這個可以看到報錯的情況
如果有報錯，檢視alert日誌和log.xml日誌
5、驗證是否正常
select process,status from v$managed_standby;
select process,status,sequence# from v$managed_standby;
如果看到mrp0正常
6、以上步驟處理好後，如果資料還不正常，接著處理
關閉備庫，接著處理：
把主庫上 undotbs01.dbf 檔案，物理的重拷到備庫機上以前undotbs01.dbf 所在目錄下；
$scp /data/oracle/oradata/voip/undotbs01.dbf 192.168.122.204:/data/oracle/oradata/voip
再在主庫上重新生成乙個standby control file ，拷到備庫機上相應目錄下，
alter database create standby controlfile as '/data/oracle/oradata/voip/qyqdg01.ctl'
$scp /data/oracle/oradata/voip/qyqdg01.ctl 192.168.122.204:/data/oracle/oradata/voip
$ mv qyqdg01.ctl control01.ctl
$ cp control01.ctl /data/oracle/flash_recovery_area/qyq/
$cd /data/oracle/flash_recovery_area/qyq/
$ mv control01.ctl control02.ctl
接著startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
--------------------------------------
session恢復完成後，重啟開啟備庫；
alter database open read only;
另外附上檢查dg是否正常的幾種方法：
檢視dg是否正常的四個方法：
一、看備庫的告警日誌，正在恢復的日誌號是否對應得上
二、看三個程序是否都已經啟動
sql>select process from v$managed_standby;
在備庫顯示:
arch、mrpo和rfs
都有表示正常
在主庫顯示:
process
---------
arch
arch
arch
arch
lns沒有rfs程序和mrp程序
三、先切換一次日誌，再進到歸檔目錄裡，看兩邊的歸檔檔案號是否對得上
四、用命令檢視兩邊歸檔是否對得上
nhibernate連線11g資料庫
我框架的資料對映用 nhibernate連線多資料庫，這次又增加了oracle11g，負責開發的同事始終連線不上，悲催的sharepoint除錯是在不方便。下面描述下問題的解決，細節問題有3個 1.nhibernate.dialect.oracle10gdialect 不管是11還是10，據說12也...
ORACLE資料庫11g減少宕機
今天去乙個朋友公司，正好碰到他們的生產線宕機，問了一下原因，原來是資料庫過於複雜，一點點人為操作的失誤，就造成了災難性的後果。老闆大發雷霆，譴責資料部門，問他們為什麼用這麼糟糕的資料庫，為什麼不用oracle，技術員可憐巴巴地說，預算有限，所以只能用某國產品牌。這下輪到老闆有點小尷尬了。其實，作為乙...
ORACLE資料庫11g減少宕機
今天去乙個朋友公司，正好碰到他們的生產線宕機，問了一下原因，原來是資料庫過於複雜，一點點人為操作的失誤，就造成了災難性的後果。老闆大發雷霆，譴責資料部門，問他們為什麼用這麼糟糕的資料庫，為什麼不用oracle，技術員可憐巴巴地說，預算有限，所以只能用某國產品牌。這下輪到老闆有點小尷尬了。其實，作為乙...