LaGiPusHinGWitH ---- IT

Navigation

Home |

Monthly Archives

Most recent entries

Syndicate

RSS 2.0
Atom

Site Credits

Design by:
BlogMoxie

Checking User Lock

userLock.txt

Seringkali dalam menangani sebuah server database, seorang DBA mengalami/mendapatkan server-nya
crash/hang. Ini pula yang terkadang saya alami, ada laporan dari department lain bahwa database tidak
dapat diakses untuk input data maupun melihat data (database hanya diam tidak menunjukkan reaksi apapun juga).

Dan ini merupakan tanggung jawab seorang DBA untuk melakukan analisa serta mencari tahu apa permasalahannya.
Singkat cerita, saya langsung melakukan pemeriksaan dan berdasarkan pengalaman biasanya yang menyebabkan
hal ini adalah masalah di size, SGA memori, Object Lock, User Lock, dll.

Dari semua kemungkinan tersebut didapatkan bahwa permasalahan disebabkan oleh User Lock, maksudnya disini
ada user-user yang menggunakan resource pada database tetapi proses dari user tersebut terkunci oleh database
dan hal ini akan membuat database menjadi crash.

Technical Review :

1. Seperti biasa jalankan SQlplus dan login ke database dengan role DBA
2. Lihat field-field yang ada pada tabel sistem dba_locks

SQL> desc dba_locks;
Name Null? Type
----------------------------------------- -------- ----------------------------
SESSION_ID NUMBER
LOCK_TYPE VARCHAR2(26)
MODE_HELD VARCHAR2(40)
MODE_REQUESTED VARCHAR2(40)
LOCK_ID1 VARCHAR2(40)
LOCK_ID2 VARCHAR2(40)
LAST_CONVERT NUMBER
BLOCKING_OTHERS VARCHAR2(40)

3. Lihat session-session pada database yang memiliki kemungkinan terkunci

SQL> select * from dba_locks where mode_held = ‘Exclusive’;

SESSION_ID LOCK_TYPE MODE_HELD MODE_REQUESTED LOCK_ID1 LOCK_ID2 LAST_CONVERT BLOCKING_OTHERS

3 Redo Thread Exclusive None 1 0 38934 Not Blocking
9 Transaction Exclusive None 196645 3730106 6714 Not Blocking
13 Transaction Exclusive None 1703965 3655 0 Not Blocking
13 Distributed Xaction Exclusive None 66 0 0 Not Blocking
274 Transaction Exclusive None 458799 2187103 7527 Blocking
282 Transaction Exclusive None 131115 3026301 5534 Not Blocking
329 Transaction Exclusive None 589833 2876171 4621 Not Blocking
377 Transaction Exclusive None 393240 2944259 4041 Not Blocking
467 Transaction Exclusive None 983041 12005 724 Not Blocking

9 rows selected.

Terlihat ada 9 session yang memiliki kemunginan dan kita lihat pada field BLOCKING_OTHERS, session yang sudah pasti terkunci
dan kemungkinan besar penyebab permasalahan ini. Dari data yang ada terlihat bahwa session dengan ID 274 memilki type transaksi
dan status ‘BLOCKING’

4. Dari sini kita lanjutkan dengan mencari siapa pemilik session ID tersebut, Lihat field-field pada
tabel sistem v$session

SQL> desc v$session;

SQL> select * from v$session where sid = ‘274’;

SADDR SID SERIAL# AUDSID PADDR USER# USERNAME STATUS SERVER SCHEMA# SCHEMANAME OSUSER PROCESS MACHINE TERMINAL
---------------- ---------- ---------- ---------- ---------------- ---------- ------------------------------ ---------- ---------- ---------------- ---------------- -------- -----
00000003C7E8B458 274 70 4700007 00000003C7CC8E88 795 XXXXX INACTIVE DEDICATED 795 XXXXX Gugun 5916:5248 DATABASE\GUNAWAN GUNAWAN

Ok...tidak semua data pada field di perlihatkan karena terlalu banyak dan juga user saya edit, tetapi ini sudah cukup untuk mendapatkan data yang diperlukan:

Dari data ini bisa terlihat bahwa status user ini Tidak Aktif/INACTIVE.

5. Langkah terakhir adalah kita ‘membunuh’ session yang tidak diperlukan ini,
dan parameter yang diperlukan adalah SID dan SADDR.

SQL> alter system kill session ‘274,00000003C7E8B458’; --> alter system kill session ‘SID,SADDR’;

Selesai....akhirnya database dapat berjalan lagi dengan lancar.

PS : 1. Sebelum kill session kita harus yakin bahwa session tersebut sudah tidak aktif
2. Setelah proses ini berjalan lakukan analisa mengapa session ini bermasalah agar tidak terulang kembali.</pre>

Posted by roninmorgue on 12/09 at 10:56 PM
Computer DataBase • (0) Comments • (409) Trackbacks • Permalink