潛水珽的異想世界

最近在做新系統的建置,結果在測試資料庫連線時,遇到一些問題,筆記一下,也提供有緣人未來遇到時可以縮短處理的時間。

在Oracle連線中,我們常會透過tnsnames.ora來設定client 連線Oracle各個資料庫的連線資訊,

今天在工作時遇到一件奇怪的問題,

user反映明明欄位開了CHAR(6 byte),但裡面的文字卻只呈現5個byte,使用length去算整個欄位長度,卻顯示是6,

oracle的學習過程,會發現其實官方很會在新版本中放入新的功能(也許是先試試水溫),但也因為這樣,引發出後續的一些問題,造成系統的不穩定,接下來,來分享一下一下最近在系統問題處理上困擾很久的狀況。

系統最近不太乖(還特別去檢查了一下乖乖有沒有過期?)常常會遇到像下面這樣commit量衝夭壽高的狀況,所以開始一連串的處理,最後調整了一個隱藏參數,目前持續觀察中。下面就針對log file sync這個等待事件,來做深入的解說,可以做為未來系統診斷除錯的思路。

通過查詢UNDO段來抽取所有已變化的記錄細節，在此基礎之上再構造和執行能夠倒退這些變化的語句
表閃回通過執行倒退變化的語句並且該執行是一個事務，所有常用規則在該事務上起作用。

通常用於檢索一條記錄的所有版本，倒退單獨的事務或者倒退從指定時間以來對特定表的所有變化
Flashback Query的所有形式取決於UNDO表表空間，關於UDNO表空間請參考：Oracle 回滾(ROLLBACK)和撤銷(UNDO)

過去要追蹤稽核使用者表格的異動,都會使用trigger來記錄,

但有時候trigger的作動會讓系統在尖峰時刻更加忙碌,

因為同事有需求要限制使用者輸入文字時使用enter(/n),

想起Oracle中有提供check這個限制物件,

在Oracle資料庫中,有關於重建索引是否對效能有所幫助，已經進行了許多的討論。一般來說，需要重建b-tree索引的場景非常少，主要是因為b-tree 索引很大程度上是自我管理或自我平衡的。

重建索引的最常見理由是：

-索引變得碎片化
-索引不斷增長-刪除空間不被重複使用
-索引聚簇因子變得不同步

expdp之所以會變慢,可能發生的原因是在auto SGA的設定下,stream pool 與 buffer cache間的資料移動有關(是個bug),Oracle在11g之後導入了新的演算法,但這個演算法還不夠完善,所以偶而會發生stream pool 回收(shrink)時異常。

特徵:

最近在做系統轉碼,結果使用了secureCRT連線使用vi後,使用root登入使用vi卻都正常,換成user登入會發現,

在控制列使用控制命令時(ex: i (insert)),