Mengapa saya mendapatkan kesalahan basis data ini ketika saya memperbarui tabel?
GALAT di baris 1: ORA-00054: sumber daya sibuk dan memperoleh dengan NOWAIT ditentukan atau batas waktu habis
Mengapa saya mendapatkan kesalahan basis data ini ketika saya memperbarui tabel?
GALAT di baris 1: ORA-00054: sumber daya sibuk dan memperoleh dengan NOWAIT ditentukan atau batas waktu habis
Jawaban:
Meja Anda sudah dikunci oleh beberapa permintaan. Sebagai contoh, Anda mungkin telah mengeksekusi "select for update" dan belum melakukan / rollback dan memecat kueri pemilihan lain. Lakukan komit / rollback sebelum menjalankan kueri Anda.
dari sini ORA-00054: sumber daya sibuk dan dapatkan dengan NOWAIT yang ditentukan
Anda juga dapat mencari sql, nama pengguna, mesin, informasi port dan sampai ke proses aktual yang memegang koneksi
SELECT O.OBJECT_NAME, S.SID, S.SERIAL#, P.SPID, S.PROGRAM,S.USERNAME,
S.MACHINE,S.PORT , S.LOGON_TIME,SQ.SQL_FULLTEXT
FROM V$LOCKED_OBJECT L, DBA_OBJECTS O, V$SESSION S,
V$PROCESS P, V$SQL SQ
WHERE L.OBJECT_ID = O.OBJECT_ID
AND L.SESSION_ID = S.SID AND S.PADDR = P.ADDR
AND S.SQL_ADDRESS = SQ.ADDRESS;
Tolong Bunuh Sesi Oracle
Gunakan kueri di bawah ini untuk memeriksa info sesi aktif
SELECT
O.OBJECT_NAME,
S.SID,
S.SERIAL#,
P.SPID,
S.PROGRAM,
SQ.SQL_FULLTEXT,
S.LOGON_TIME
FROM
V$LOCKED_OBJECT L,
DBA_OBJECTS O,
V$SESSION S,
V$PROCESS P,
V$SQL SQ
WHERE
L.OBJECT_ID = O.OBJECT_ID
AND L.SESSION_ID = S.SID
AND S.PADDR = P.ADDR
AND S.SQL_ADDRESS = SQ.ADDRESS;
bunuh seperti
alter system kill session 'SID,SERIAL#';
(Misalnya alter system kill session '13,36543'
,;)
Referensi http://abeytom.blogspot.com/2012/08/finding-and-fixing-ora-00054-resource.html
CONNECT
dan RESOURCE
, tapi tidak apa pun yang dibutuhkan, dengan akun yang saya miliki, dan katakan ORA-00942: table or view does not exist
. Tidak semua orang yang membaca utas ini akan memiliki SYS
akun.
alter system kill session '13,36543'
akan habis dan sesi tidak akan mati. Dalam hal ini, lihat: stackoverflow.com/a/24306610/587365
connection object
di python
saya mendapat beberapa kesalahan. Kemudian python script
ditutup tanpa menutup dengan benar connection object
. Sekarang saya mendapatkan kesalahan "LOCKWAIT" ketika saya mencoba untuk menjatuhkan tabel di sesi lain. Ketika saya coba kill session
saya tidak memiliki cukup privilage. Apa lagi yang bisa dilakukan untuk menyingkirkan ini?
Ada cara yang sangat mudah untuk mengatasi masalah ini.
Jika Anda menjalankan jejak 10046 di sesi Anda (google this ... terlalu banyak menjelaskan). Anda akan melihat bahwa sebelum operasi DDL, Oracle melakukan hal berikut:
LOCK TABLE 'TABLE_NAME' TANPA TUNGGU
Jadi, jika sesi lain memiliki transaksi terbuka Anda mendapatkan kesalahan. Jadi, perbaiki adalah ... drum roll tolong. Keluarkan kunci Anda sendiri sebelum DDL dan tinggalkan 'NO WAIT'.
Catatan Khusus:
jika Anda melakukan pemecahan / menjatuhkan partisi oracle hanya mengunci partisi. - jadi kamu hanya bisa mengunci sub partisi partisi.
Jadi ... Langkah-langkah berikut memperbaiki masalah.
Pernyataan DML akan 'menunggu' atau sebagai pengembang menyebutnya 'hang' saat tabel dikunci.
Saya menggunakan ini dalam kode yang dijalankan dari pekerjaan untuk menjatuhkan partisi. Ini bekerja dengan baik. Itu dalam database yang terus-menerus memasukkan pada tingkat beberapa ratus sisipan / detik. Tidak ada kesalahan
jika Anda bertanya-tanya. Melakukan ini dalam 11g. Saya telah melakukan ini dalam 10g sebelumnya juga di masa lalu.
KILL SESSION
adalah jawaban yang tepat untuk orang-orang ini.
set_ddl_timeout
dan untuk apa itu?
Kesalahan ini terjadi saat sumber daya sibuk. Periksa apakah Anda memiliki kendala referensial dalam kueri. Atau bahkan tabel yang telah Anda sebutkan dalam kueri mungkin sibuk. Mereka mungkin terlibat dengan beberapa pekerjaan lain yang pasti akan tercantum dalam hasil permintaan berikut:
SELECT * FROM V$SESSION WHERE STATUS = 'ACTIVE'
Temukan SID,
SELECT * FROM V$OPEN_CURSOR WHERE SID = --the id
ORA-00942: table or view does not exist
.
Ini terjadi ketika sesi selain yang digunakan untuk mengubah tabel menahan kemungkinan karena DML (perbarui / hapus / sisipkan). Jika Anda mengembangkan sistem baru, kemungkinan Anda atau seseorang di tim Anda mengeluarkan pernyataan pembaruan dan Anda dapat mematikan sesi tanpa banyak konsekuensi. Atau Anda dapat melakukan dari sesi itu setelah Anda tahu siapa yang memiliki sesi terbuka.
Jika Anda memiliki akses ke sistem admin SQL, gunakan untuk menemukan sesi yang menyinggung. Dan mungkin membunuhnya.
Anda dapat menggunakan v $ session dan v $ lock dan lainnya tetapi saya sarankan Anda google cara menemukan sesi itu dan kemudian cara membunuhnya.
Dalam sistem produksi, itu sangat tergantung. Untuk oracle 10g dan lebih tua, Anda bisa mengeksekusi
LOCK TABLE mytable in exclusive mode;
alter table mytable modify mycolumn varchar2(5);
Dalam sesi terpisah tetapi siapkan yang berikut jika perlu waktu terlalu lama.
alter system kill session '....
Tergantung pada sistem apa yang Anda miliki, sistem yang lebih lama lebih cenderung untuk tidak melakukan setiap waktu. Itu masalah karena mungkin ada kunci yang berdiri lama. Jadi kunci Anda akan mencegah kunci baru dan menunggu kunci yang tahu kapan akan dirilis. Itu sebabnya Anda memiliki pernyataan lain yang siap. Atau Anda bisa mencari skrip PLSQL di luar sana yang melakukan hal serupa secara otomatis.
Dalam versi 11g ada variabel lingkungan baru yang menetapkan waktu tunggu. Saya pikir itu mungkin melakukan sesuatu yang mirip dengan yang saya jelaskan. Pikiran Anda bahwa masalah penguncian tidak hilang.
ALTER SYSTEM SET ddl_lock_timeout=20;
alter table mytable modify mycolumn varchar2(5);
Akhirnya mungkin yang terbaik adalah menunggu sampai ada beberapa pengguna dalam sistem untuk melakukan pemeliharaan semacam ini.
alter system kill session '....
jika Anda tidak memiliki akses ke pandangan manajemen?
Dalam kasus saya, saya cukup yakin itu adalah salah satu sesi saya sendiri yang menghalangi. Karena itu, aman untuk melakukan hal berikut:
Saya menemukan sesi menyinggung dengan:
SELECT * FROM V$SESSION WHERE OSUSER='my_local_username';
Sesi ini tidak aktif , tetapi entah bagaimana masih memegang kunci. Perhatikan, bahwa Anda mungkin perlu menggunakan beberapa kondisi WHERE lain dalam kasus Anda (mis. Coba USERNAME
atau MACHINE
bidang).
Membunuh sesi menggunakan ID
dan SERIAL#
diperoleh di atas:
alter system kill session '<id>, <serial#>';
Diedit oleh @thermz: Jika tidak ada pertanyaan sesi terbuka sebelumnya yang berfungsi, coba yang ini. Kueri ini dapat membantu Anda menghindari kesalahan sintaksis saat mengakhiri sesi:
SELECT 'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||''' immediate;' FROM V$SESSION WHERE OSUSER='my_local_username_on_OS'
Cukup periksa proses memegang sesi dan Bunuh itu. Kembali normal.
Di bawah ini SQL akan menemukan proses Anda
SELECT s.inst_id,
s.sid,
s.serial#,
p.spid,
s.username,
s.program FROM gv$session s
JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id;
Kalau begitu bunuh saja
ALTER SYSTEM KILL SESSION 'sid,serial#'
ATAU
beberapa contoh yang saya temukan online tampaknya memerlukan instance id dan juga mengubah sesi sistem kill '130.620, @ 1';
Masalah Anda sepertinya Anda mencampur operasi DML & DDL. Lihat URL ini yang menjelaskan masalah ini:
select
c.owner,
c.object_name,
c.object_type,
b.sid,
b.serial#,
b.status,
b.osuser,
b.machine
from
v$locked_object a,
v$session b,
dba_objects c
where
b.sid = a.session_id
and
a.object_id = c.object_id;
ALTER SYSTEM KILL SESSION 'sid,serial#';
Saya berhasil mengenai kesalahan ini ketika hanya membuat tabel! Jelas tidak ada masalah pertengkaran di atas meja yang belum ada. The CREATE TABLE
pernyataan berisi CONSTRAINT fk_name FOREIGN KEY
klausul referensi meja yang penduduknya. Saya harus:
novalidate
klausa ke alter table add constraint
. Ini entah bagaimana membiarkannya berjalan, tetapi terkunci. Kemudian saya melihat kunci sesi untuk mengetahui sesi mana yang dikunci. Dan kemudian saya membunuh sesi itu.
Saya memiliki kesalahan ini terjadi ketika saya memiliki 2 skrip yang saya jalankan. Saya punya:
Saya menjalankan setetes tabel, lalu membuat tabel sebagai akun # 1. Saya menjalankan pembaruan tabel pada sesi akun # 2. Tidak melakukan perubahan. Menjalankan ulang skrip drop / pembuatan tabel sebagai akun # 1. Terjadi kesalahan pada drop table x
perintah.
Saya menyelesaikannya dengan menjalankan COMMIT;
sesi SQL * Plus di akun # 2.
COMMIT;
. Jika Anda bahkan tidak bisa menjatuhkan meja, Anda tidak memiliki izin untuk mengubah apa pun yang akan membawa Anda ke masalah ini sejak awal.
Saya juga menghadapi Masalah serupa. Tidak ada programmer yang harus dilakukan untuk menyelesaikan kesalahan ini. Saya memberi tahu tim DBA oracle saya. Mereka membunuh sesi dan bekerja seperti pesona.
Solusi yang diberikan oleh tautan Shashi adalah yang terbaik ... tidak perlu menghubungi dba atau orang lain
buat cadangan
create table xxxx_backup as select * from xxxx;
hapus semua baris
delete from xxxx;
commit;
masukkan cadangan Anda.
insert into xxxx (select * from xxxx_backup);
commit;