最近的幾個技術問題總結和答疑（七

今天抽空整理，發現近期問我資料恢復，災備的問題還比較多，我簡單整理了一下。

問題1：

能請教乙個問題麼？我們用was鏈結的oracle資料庫，是不是不建議在was上設定statementcachesize的引數？我們目前設定的是200，發現資料庫中那個session都會持有200個游標，有工程師建議把這個引數設定為0

這個問題著實還問到我了，不過我問了下專業的中介軟體工程師，答覆如下：

問題2：關於異機資料恢復

有個朋友說在伺服器a中做了rman備份，想在異機恢復，但是控制檔案忘了備份了。問能不能恢復回來。

這個問題其實要明確一點，就是資料檔案是否最近有變化，如果沒有那就很簡單，甚至我們都可以自己建立乙個控制檔案出來。

異機恢復是完全可行的，不要看到ora錯誤就害怕。

比如在現有的庫中生成控制檔案的trace,直接部署到異機。

問題3：

有乙個朋友問我說，他碰到乙個問題

oracle 11.0.2的庫，有乙個檢視，關聯了幾十張表，檢視有三百個字段，查詢select * 的時候報錯，但是select count(*) 的時候就可以，然後將檢視中刪除一張表select *就能查出來。截圖如下：

對於這個問題，有幾個思路可供參考。

1.看錯誤描述，感覺是乙個bug

2.檢視關聯幾十個表，上百個字段，本身設計上就有一些問題

3.這類問題是否可以復現是乙個關鍵，如果能夠復現，最好還是做一些細緻的trace，看看問題邊界，因為沒有模擬環境，所以只能建議了。

問題4：

我如果不用rose ha或oracle active data guard的ha軟體，直接用shelle指令碼實現ha功能，這樣有什麼風險嗎

data guard如果不考慮更多的特性，就如同標準版的dg所做的，技術上實現是完全沒有問題的。早期的data guard就是這麼幹的，很多老dba就是寫指令碼，傳歸檔，恢復

問題5：

rac環境中，業務是資料庫倉庫，乙個節點跑儲存過程在頻繁dml乙個表，同時在另乙個節點也在另乙個儲存過程頻繁dml同一張表

在db層面,哪這種情況如何避免呢，這種情況下rac2個節點之間的資料同步或快取cache fusion如何評估

這種情況下，會把rac的限制放大。節點間頻繁更新同步資料庫，效能和鎖影響都是全域性的。

db層面，可以根據業務把這種操作做切分，甚至只在單節點執行，效果都比雙節點強。也就是業務的不同模板配置不同的service，這樣就把應用的不同模板連線到rac不同節點了。如果配置service,設定策略，這種比較推薦，對應用來說，看到的是業務層面的資料庫，其實是各個節點。

有些場景下，我們原來的電信客戶，為了穩妥，用的active-passive模式，只啟用乙個節點，oltp，另乙個就用作高可用臨時切換

問題5：

我這個oracle10t,每天生成1t日誌，目前是每天全備，每小時備份日誌，但是還是未能滿足12小時恢復，我想在每天全備基礎上，12小時做次增量，滾日誌就能少500g, 這樣是否恢復能快些

在這種場景下，每天增備的日誌量還是不小的，為了滿足12小時恢復，其實data guard就是乙個不錯的選擇，可以設定延遲歸檔應用，恢復相比全量的恢復要快得多。

還有一種思路就是使用第三方的恢復軟體，我知道的actinfo的那個軟體不錯，一次全量，永遠增量。增量的幅度設定的頻度可以略微頻繁一些。

問題6：

一主多備的搭建，有伺服器abc,有網友使用伺服器a switchover到伺服器b,然後基於伺服器b搭建備庫c

但是恢復的時候碰到了一些問題。環境是10gr2

其實這個問題看起來思路還蠻有挑戰，實踐起來也很順手的，理論上來說其實有更多更好的方法，上面的方案是比較常規的方案。

因為是10gr2，沒法用11g優越的duplicate方式，但是使用rman備份恢復是完全沒有問題的，有幾個建議可供參考。

1.主備庫的管理，建議配置dg broker,這樣很多操作都能直接忽略了，手工搭建備庫看起來還是有些技術含量的，用了dg broker，發現沒有一點技術含量了。

2.主庫rman，恢復到備庫，肯定會有gap,只是這個gap的大與小而已，對於備庫恢復而言，我們完全不需要關心備份後的臨界點在**，在備庫恢復之後，備庫會從主庫去比對差距，然後通過rfs來同步歸檔，所以無需手工來傳遞歸檔，手工設定臨界恢復的log_seq等。