最近在做新系統的建置,結果在測試資料庫連線時,遇到一些問題,筆記一下,也提供有緣人未來遇到時可以縮短處理的時間。
在Oracle連線中,我們常會透過tnsnames.ora來設定client 連線Oracle各個資料庫的連線資訊,
有時候會遇到ora-12154 與 ora-12545的錯誤,這邊分別說明可能遇到的原因:
ORA-12154 could not resolve the connect identifier specified
中文:
最近在做新系統的建置,結果在測試資料庫連線時,遇到一些問題,筆記一下,也提供有緣人未來遇到時可以縮短處理的時間。
在Oracle連線中,我們常會透過tnsnames.ora來設定client 連線Oracle各個資料庫的連線資訊,
有時候會遇到ora-12154 與 ora-12545的錯誤,這邊分別說明可能遇到的原因:
ORA-12154 could not resolve the connect identifier specified
中文:
今天在工作時遇到一件奇怪的問題,
user反映明明欄位開了CHAR(6 byte),但裡面的文字卻只呈現5個byte,使用length去算整個欄位長度,卻顯示是6,
好吧,就來查查看是遇到甚麼問題了。
select dump(BEFORECOSIGNEREMPNO) from A.test
where NURSEGIVEDRUGIDSE IN (289839402,289769909) AND BEFORECOSIGNEREMPNO IS not NULL;

oracle的學習過程,會發現其實官方很會在新版本中放入新的功能(也許是先試試水溫),但也因為這樣,引發出後續的一些問題,造成系統的不穩定,接下來,來分享一下一下最近在系統問題處理上困擾很久的狀況。
系統最近不太乖(還特別去檢查了一下乖乖有沒有過期?)常常會遇到像下面這樣commit量衝夭壽高的狀況,所以開始一連串的處理,最後調整了一個隱藏參數,目前持續觀察中。下面就針對log file sync這個等待事件,來做深入的解說,可以做為未來系統診斷除錯的思路。
Lamport SCN vs immediate commit propagation (BOC):
在Oracle RAC數據庫中,為了讀一致性,需要將Commit SCN同步/傳播到所有的節點上。SCN同步/傳播的主要方法有兩種:Lamport SCN 和immediate commit propagation (BOC)。
10gR1 及以下版本默認使用Lamport SCN,Lamport SCN方式即一個節點上的commit SCN 不保證立刻同步/傳播到所有節點,也就是說可能延時同步/傳播,在RAC節點上,這樣有時候會早成資料讀取不一致的問題,對於一些實時性要求高的RAC數據庫Lamport SCN方式是無法滿足的。
通過查詢UNDO段來抽取所有已變化的記錄細節,在此基礎之上再構造和執行能夠倒退這些變化的語句
表閃回通過執行倒退變化的語句並且該執行是一個事務,所有常用規則在該事務上起作用。
表閃回時,表上的觸發器缺省被禁用,即該表上的DML觸發器將暫時失效,可以在閃回時指定觸發器是否失效。
通常用於檢索一條記錄的所有版本,倒退單獨的事務或者倒退從指定時間以來對特定表的所有變化
Flashback Query的所有形式取決於UNDO表表空間,關於UDNO表空間請參考:Oracle 回滾(ROLLBACK)和撤銷(UNDO)
--1.閃回查詢(Flashback Query)語法
SELECT <column_name_list>
過去要追蹤稽核使用者表格的異動,都會使用trigger來記錄,
但有時候trigger的作動會讓系統在尖峰時刻更加忙碌,
oracle11g之後提供了flashback archive的功能,可以將表格異動存儲在特定表空間裡,
且可自訂rota的頻率。本文記錄一下整個操作的過程,期望未來可以慢慢地捨棄掉"使用trigger來記錄資料異動的過程",
當然啦,比較好還是能夠採購更專業的資料庫稽核軟體是最好的。
因為同事有需求要限制使用者輸入文字時使用enter(/n),
想起Oracle中有提供check這個限制物件,
這邊就簡單紀錄一下測試的過程。
在Oracle中,enter鍵在win系統裡是 chr(13) ,
所以我們要針對這個符號來做限制。
在Oracle資料庫中,有關於重建索引是否對效能有所幫助,已經進行了許多的討論。一般來說,需要重建b-tree索引的場景非常少,主要是因為b-tree 索引很大程度上是自我管理或自我平衡的。
重建索引的最常見理由是:

expdp之所以會變慢,可能發生的原因是在auto SGA的設定下,stream pool 與 buffer cache間的資料移動有關(是個bug),Oracle在11g之後導入了新的演算法,但這個演算法還不夠完善,所以偶而會發生stream pool 回收(shrink)時異常。
特徵:
expdp期間會有"Streams AQ: enqueue blocked on low memory"的wait event.
SQL> select shrink_phase_knlasg from X$KNLASG;
SHRINK_PHASE_KNLASG

最近在做系統轉碼,結果使用了secureCRT連線使用vi後,使用root登入使用vi卻都正常,換成user登入會發現,
在控制列使用控制命令時(ex: i (insert)),
都會有亂碼跑出來,找了好久問題終於發現是linux locate 中的編碼與secureCRT編碼設定不同,
linux上root的locale:
[root~]# locale
CREATE TABLE kart_bilgileri (
id NUMBER NOT NULL,
musteri_id NUMBER NOT NULL,
kart_no NUMBER NOT NULL,
kart_string VARCHAR2(19) NOT NULL,
常常在做Oracle DataGuard 切換的時候,會在alert log中看到類似的錯誤:
ORA-02062: distributed recovery received DBID 4cbc54f8, expected b0033682
這個錯誤是由於該SQL使用DBLINK在做資料異動操作,但是因為切換後,該SQL無法完整執行完,所以系統中會一直報ORA-02062的錯誤,
不過這個錯誤對系統部會有甚麼影像,解決方法就是把該操作從archive log中給purge掉就好。
操作程序: