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

今天抽空整理，發現近期問我資料恢復，災備的問題還比較多，我簡單整理了一下。
問題1：
能請教一個問題麼？我們用was連結的oracle資料庫，是不是不建議在was上設定statementcachesize的引數？我們目前設定的是200，發現資料庫中那個session都會持有200個遊標，有工程師建議把這個引數設定為0

這個問題著實還問到我了，不過我問了下專業的中介軟體工程師，答覆如下：
Statement Cache Size是指有多少個prepared statement或者callable statement可以被快取，在遇到對這些statement的請求時會重用快取中的statement而不會重新載入。這個不能為0吧，一般設定大於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等。