關於資料庫中的死鎖。如果在應用中碰到都會毫不猶豫轉交給dba，但是從目前我接到的deadlock的問題來看，和oracle官方的描述基本都是一致的。
死鎖在oracle中處理時，會自動事務相關的dml語句撤銷。換句話說，就是oracle對於死鎖 問題的處理時乙個主動的過程，會主動切斷其中乙個session的事務鎖。
先來看乙個簡單的死鎖案例。
我們建立兩個表lock_test1,lock_test2，然後使用兩個session來說明。
session1:
首先在session1中先建立兩個表,lock_test1,lock_test2
n1@test11g> create table lock_test1 as select *from cat;
table created.
n1@test11g> create table lock_test2 as select *from cat;
table created.
然後嘗試對lock_test1做delete操作。
n1@test11g> delete from lock_test1;
20 rows deleted.
session2:
然後切換到session2,對lock_test2做delete操作。
n1@test11g> delete from lock_test2;
21 rows deleted.
緊接著，在session1中對lock_test2做delete操作，這個時候出現阻塞的情況，一直沒有響應。
session1:
n1@test11g> delete from lock_test2;
我們在session2中，繼續對錶lock_test1做delete操作，這個時候會有短暫的停頓，就會發現session1中的事務被強行撤銷了。
session2:
n1@test11g> delete from lock_test1;
session1中的日誌如下，可以看到這個時候session1中的事務被強行撤銷了。
n1@test11g> delete from lock_test2;
delete from lock_test2
error at line 1:
ora-00060: deadlock detected while waiting for resource
這個問題可以簡單用下面的步驟來說明。
?session a table1
?session b table2
?session a table 2
?session b table1
到此為止我們可以看到，死鎖產生的影響是很大的，當然，問題還不止於此，在多個表之間很可能存在死鎖現象，對於乙個表，也有可能出現死鎖現象。
我們來簡單說明示例一下。
session1:
create table test as select *from user_tables;
n1@test11g> delete from test where table_name='lock_test1';
1 row deleted.
session2:
n1@test11g> delete from test where table_name='lock_test2';
1 row deleted.
session1:
n1@test11g> delete from test where table_name='lock_test2';
session2:
n1@test11g> delete from test where table_name='lock_test1';
這個時候還是會出現一樣的死鎖問題，這個時候在對應的行上會有相應的鎖。在session2中會有短暫的停頓，然後把session1中的
給撤銷了，產生的日誌如下：
delete from test where table_name='lock_test2'
error at line 1:
ora-00060: deadlock detected while waiting for resource
可見死鎖的問題還是很容易產生的，在程式設計中處理多併發的處理時還是需要多多注意。
《迷失》觀後感 r5筆記第96天
迷失這個 出了6個季，每季都差不多有15集左右，看這部美劇也是斷斷續續，其中還包括跳過了一些部分沒有看，最近直接切到了第6季，然後花了好幾周的時間才把它看完。覺得似乎需要寫點什麼，但是說實話，從開始到看完，整個過程中似乎自己都沒怎麼看明白，一直到最後一集，好像懂了，又沒看懂的感覺，對於我來說，似乎也...
曲折的dump匯入及問題分析 r5筆記第47天
sql select count from csm ben count sql select count from csm account count 這個時候看問題就比較明顯了，很顯然在外鍵列所在的表csm account中竟然沒有資料，為什麼會出現這種問題,我也懷疑是不是dump出問題了，而只是...
重啟資料庫的一場鬧劇 r5筆記第68天
在幾周前，某個測試環境在嘗試impdp匯入dump的時候報了錯誤，有個dba立馬做了kill session的操作，但是持續了5個小時，session狀態還是killed,於是他們就在等待session被pmon 結果又等了幾個小時，還是killed狀態。最後兩撥dba在交接的時候把這個問題就說明了...