分庫目的:
2) 新庫公升級oracle10.2.0.1到10.2.0.4, 資料庫本身修復了很多bug, 增強了資料庫的穩定性.
3) 調整定時任務, 把原先的定時任務由crontab/job方式改為oracle scheduler.
大概操作步驟如下:
--1) 提前安裝oracle10.2.0.4, 並部署streams複製(schema複製)
--4) 取消源庫定時任務(包括crontab/job)
--5) 核查源庫是否還有連線
select streams_name,
streams_type,
cumulative_message_count,
first_message_time,
xidusn,
xidslt,
xidsqn,
last_message_time,
total_message_count
from v$streams_transaction
order by 3 desc;
--7) 從源庫獲得重建序列語句, streams複製這點特別注意, 因為streams本身不會去同步序列值
|| decode (order_flag, 'n', ' noorder ', ' order ')
|| ';' stmt
--9) 源庫和目標庫重新整理同義詞, 把同義詞指向新的dblink, 同義詞指令碼提前準備好
--源庫
@e:\使用者遷移\sour_synonyms.sql
--目標庫
@e:\使用者遷移\dest_synonyms.sql
--10) 源庫和目標庫重新編譯失效物件
@?/rdbms/admin/utlrp.sql
exec uts.get_invalid;
--11) 各業務系統更改資料庫連線指向, 並啟動各業務系統
--12) 測試業務系統啟動情況
--13) 刪除流配置
exec dbms_streams_adm.remove_streams_configuration;
--14) 其它收尾工作, 如各開發人員查詢使用者的授權等等.
--end--
**
記一次生產報too man open files
有一天私有雲無法訪問，馬上聯絡廠商，最後廠商發現好多容器不停重啟，經過日誌檢視發現平台開啟檔案控制代碼太多，很奇怪，就開始排查，最後發現乙個埠，定位到應用spring actuator.這個應用是我為了監控微服務而發布的乙個監控應用，馬上看日誌，發現應用報錯，too many open files，...
一次生產事故的優化經歷
跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。在搶標過程中繼續觀察，...
一次生產事故的優化經歷
原 一次生產事故的優化經歷 跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開...