Self? deadlocking in BDB 4.8
Hello,
We have experienced a kind a deadlock, which could only be solved by a "db_recover". IMHO this
happens by a parallel insert. We always insert after the last value (database already open):
- environment->txn_begin( DNV, NULL, &transaction, DB_TXN_WRITE_NOSYNC );
- database->cursor( database, transaction, &cursor, 0 );
- cursor->c_get( cursor, &last_key, &unused, DB_LAST );
- cursor->c_close( cursor );
- database->put( database, transaction, &key, &data, DB_NOOVERWRITE );
- transaction->commit( transaction, 0 );
During inserts we have quite much of reads (all DB_READ_UNCOMMITTED).
Once a minute a checkpoint writes the dirty data to the database (a mutex prevents
that more than one checkpoint is called at any time).
Sorry, I forgot to make a coredump, so we have only the glibc `backtrace()`.
Thanks
================================================================================
[0xb80d1400]
[0xb80d1424]
/lib/tls/i686/cmov/libc.so.6(__sched_yield+0xc) [0xb775d9dc]
/lib/tls/i686/cmov/libpthread.so.0(pthread_yield+0x14) [0xb7bcde84]
/usr/local/lib/libdb-4.8.so(__os_yield+0x81) [0xb808d731]
/usr/local/lib/libdb-4.8.so [0xb7f2090b]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7f206da]
/usr/local/lib/libdb-4.8.so(__memp_fget+0x9cf) [0xb807478b]
/usr/local/lib/libdb-4.8.so(__bam_search+0x15a0) [0xb7f49995]
/usr/local/lib/libdb-4.8.so [0xb7f31acb]
/usr/local/lib/libdb-4.8.so [0xb7f2f85e]
/usr/local/lib/libdb-4.8.so(__dbc_iput+0x261) [0xb801008e]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x198) [0xb800fe20]
/usr/local/lib/libdb-4.8.so [0xb800fae9]
/usr/local/lib/libdb-4.8.so [0xb800eb93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb800fdac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7ffdbe1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb801e25c]
================================================================================
[0xb7faf400]
[0xb7faf422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7aaf0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7dff27d]
/usr/local/lib/libdb-4.8.so [0xb7dfe951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7dfe6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7ec3b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7ec2246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7f027e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7e25de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7e264e0]
/usr/local/lib/libdb-4.8.so [0xb7e0facb]
/usr/local/lib/libdb-4.8.so [0xb7e0b031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7eec1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7eebc83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7eeedd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7efe227]
================================================================================
[0xb7ff5400]
[0xb7ff5422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7af50e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7e4527d]
/usr/local/lib/libdb-4.8.so [0xb7e44951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7e446da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7f09b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7f08246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7f487e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7e6bde5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7e6c4e0]
/usr/local/lib/libdb-4.8.so [0xb7e55acb]
/usr/local/lib/libdb-4.8.so [0xb7e51031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7f321d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7f31c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7f34dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7f44227]
================================================================================
[0xb80ca400]
[0xb80ca422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7bca0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7f1a27d]
/usr/local/lib/libdb-4.8.so [0xb7f19951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7f196da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7fdeb2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7fdd246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb801d7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7f40de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7f414e0]
/usr/local/lib/libdb-4.8.so [0xb7f2aacb]
/usr/local/lib/libdb-4.8.so [0xb7f26031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb80071d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb8006c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb8009dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb8019227]
================================================================================
[0xb7f0e400]
[0xb7f0e422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a0e0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7d5e27d]
/usr/local/lib/libdb-4.8.so [0xb7d5d951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7d5d6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e22b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e21246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7e617e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7d84de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7d854e0]
/usr/local/lib/libdb-4.8.so [0xb7d6eacb]
/usr/local/lib/libdb-4.8.so [0xb7d6a031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7e4b1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7e4ac83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7e4ddd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7e5d227]
================================================================================
[0xb7f21400]
[0xb7f21422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a210e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7d7127d]
/usr/local/lib/libdb-4.8.so [0xb7d70951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7d706da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e35b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e34246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7e747e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7d97de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7d984e0]
/usr/local/lib/libdb-4.8.so [0xb7d81acb]
/usr/local/lib/libdb-4.8.so [0xb7d7d031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7e5e1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7e5dc83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7e60dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7e70227]
================================================================================
[0xb804d400]
[0xb804d422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7b4d0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7e9d27d]
/usr/local/lib/libdb-4.8.so [0xb7e9c951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7e9c6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7f61b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7f60246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7fa07e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x530) [0xb7ec4200]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7ec44e0]
/usr/local/lib/libdb-4.8.so [0xb7eadacb]
/usr/local/lib/libdb-4.8.so [0xb7ea9031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7f8a1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7f89c83]
/usr/local/lib/libdb-4.8.so [0xb7f8b97a]
/usr/local/lib/libdb-4.8.so [0xb7f8ab93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb7f8bdac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7f79be1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb7f9a25c]
================================================================================
[0xb8020400]
[0xb8020422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7b200e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7e7027d]
/usr/local/lib/libdb-4.8.so [0xb7e6f951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7e6f6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7f34b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7f33246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7f737e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7e96de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7e974e0]
/usr/local/lib/libdb-4.8.so [0xb7e80acb]
/usr/local/lib/libdb-4.8.so [0xb7e7c031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7f5d1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7f5cc83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7f5fdd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7f6f227]
================================================================================
[0xb8054400]
[0xb8054422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7b540e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7ea427d]
/usr/local/lib/libdb-4.8.so [0xb7ea3951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7ea36da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7f68b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7f67246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7fa77e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7ecade5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7ecb4e0]
/usr/local/lib/libdb-4.8.so [0xb7eb4acb]
/usr/local/lib/libdb-4.8.so [0xb7eb0031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7f911d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7f90c83]
/usr/local/lib/libdb-4.8.so [0xb7f9297a]
/usr/local/lib/libdb-4.8.so [0xb7f91b93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb7f92dac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7f80be1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb7fa125c]
================================================================================
[0xb7f79400]
[0xb7f79422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a790e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7dc927d]
/usr/local/lib/libdb-4.8.so [0xb7dc8951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7dc86da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e8db2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e8c246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7ecc7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7defde5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7df04e0]
/usr/local/lib/libdb-4.8.so [0xb7dd9acb]
/usr/local/lib/libdb-4.8.so [0xb7dd5031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7eb61d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7eb5c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7eb8dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7ec8227]
================================================================================
[0xb7fba400]
[0xb7fba422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7aba0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7e0a27d]
/usr/local/lib/libdb-4.8.so [0xb7e09951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7e096da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7eceb2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7ecd246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7f0d7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7e30de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7e314e0]
/usr/local/lib/libdb-4.8.so [0xb7e1aacb]
/usr/local/lib/libdb-4.8.so [0xb7e16031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7ef71d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7ef6c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7ef9dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7f09227]
================================================================================
[0xb80aa400]
[0xb80aa422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7baa0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7efa27d]
/usr/local/lib/libdb-4.8.so [0xb7ef9951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7ef96da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7fbeb2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7fbd246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7ffd7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7f20de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7f214e0]
/usr/local/lib/libdb-4.8.so [0xb7f0aacb]
/usr/local/lib/libdb-4.8.so [0xb7f06031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7fe71d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7fe6c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7fe9dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7ff9227]
================================================================================
[0xb80ae400]
[0xb80ae422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7bae0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7efe27d]
/usr/local/lib/libdb-4.8.so [0xb7efd951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7efd6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7fc2b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7fc1246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb80017e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7f24de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7f254e0]
/usr/local/lib/libdb-4.8.so [0xb7f0eacb]
/usr/local/lib/libdb-4.8.so [0xb7f0a031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7feb1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7feac83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7feddd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7ffd227]
================================================================================
[0xb7f9d400]
[0xb7f9d422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a9d0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7ded27d]
/usr/local/lib/libdb-4.8.so [0xb7dec951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7dec6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7eb1b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7eb0246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7ef07e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7e13de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7e144e0]
/usr/local/lib/libdb-4.8.so [0xb7dfdacb]
/usr/local/lib/libdb-4.8.so [0xb7df9031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7eda1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7ed9c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7edcdd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7eec227]
================================================================================
[0xb7f04400]
[0xb7f04422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a040e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7d5427d]
/usr/local/lib/libdb-4.8.so [0xb7d53951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7d536da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e18b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e17246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7e577e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x530) [0xb7d7b200]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7d7b4e0]
/usr/local/lib/libdb-4.8.so [0xb7d64acb]
/usr/local/lib/libdb-4.8.so [0xb7d60031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7e411d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7e40c83]
/usr/local/lib/libdb-4.8.so [0xb7e4297a]
/usr/local/lib/libdb-4.8.so [0xb7e41b93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb7e42dac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7e30be1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb7e5125c]
================================================================================
[0xb80d8400]
[0xb80d8422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7bd80e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7f2827d]
/usr/local/lib/libdb-4.8.so [0xb7f27951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7f276da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7fecb2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7feb246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb802b7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7f4ede5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7f4f4e0]
/usr/local/lib/libdb-4.8.so [0xb7f38acb]
/usr/local/lib/libdb-4.8.so [0xb7f34031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb80151d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb8014c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb8017dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb8027227]
================================================================================
[0xb80af400]
[0xb80af422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7baf0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7eff27d]
/usr/local/lib/libdb-4.8.so [0xb7efe951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7efe6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7fc3b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7fc2246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb80027e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x530) [0xb7f26200]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7f264e0]
/usr/local/lib/libdb-4.8.so [0xb7f0facb]
/usr/local/lib/libdb-4.8.so [0xb7f0b031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7fec1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7febc83]
/usr/local/lib/libdb-4.8.so [0xb7fed97a]
/usr/local/lib/libdb-4.8.so [0xb7fecb93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb7feddac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7fdbbe1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb7ffc25c]
================================================================================
[0xb8066400]
[0xb8066422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7b660e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7eb627d]
/usr/local/lib/libdb-4.8.so [0xb7eb5951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7eb56da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7f7ab2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7f79246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7fb97e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7edcde5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7edd4e0]
/usr/local/lib/libdb-4.8.so [0xb7ec6acb]
/usr/local/lib/libdb-4.8.so [0xb7ec2031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7fa31d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7fa2c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7fa5dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7fb5227]
================================================================================
[0xb7f86400]
[0xb7f86424]
/lib/tls/i686/cmov/libc.so.6(__select+0x2d) [0xb762877d]
/usr/local/lib/libdb-4.8.so [0xb7f42783]
/usr/local/lib/libdb-4.8.so(__os_yield+0x7a) [0xb7f4272a]
/usr/local/lib/libdb-4.8.so(__memp_sync_int+0x545) [0xb7f3ce57]
/usr/local/lib/libdb-4.8.so(__txn_checkpoint+0x3ab) [0xb7f55926]
/usr/local/lib/libdb-4.8.so(__txn_checkpoint_pp+0x1b6) [0xb7f55532]
================================================================================
[0xb7f6e400]
[0xb7f6e422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a6e0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7dbe27d]
/usr/local/lib/libdb-4.8.so [0xb7dbd951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7dbd6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e82b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e81246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7ec17e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7de4de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7de54e0]
/usr/local/lib/libdb-4.8.so [0xb7dceacb]
/usr/local/lib/libdb-4.8.so [0xb7dca031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7eab1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7eaac83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7eaddd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7ebd227]
================================================================================
[0xb7f5e400]
[0xb7f5e422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a5e0e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7dae27d]
/usr/local/lib/libdb-4.8.so [0xb7dad951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7dad6da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e72b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e71246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7eb17e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7dd4de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7dd54e0]
/usr/local/lib/libdb-4.8.so [0xb7dbeacb]
/usr/local/lib/libdb-4.8.so [0xb7dba031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7e9b1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7e9ac83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7e9ddd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7ead227]
================================================================================
[0xb80d1400]
[0xb80d1424]
/lib/tls/i686/cmov/libc.so.6(__sched_yield+0xc) [0xb775d9dc]
/lib/tls/i686/cmov/libpthread.so.0(pthread_yield+0x14) [0xb7bcde84]
/usr/local/lib/libdb-4.8.so(__os_yield+0x81) [0xb808d731]
/usr/local/lib/libdb-4.8.so [0xb7f2090b]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7f206da]
/usr/local/lib/libdb-4.8.so(__memp_fget+0x9cf) [0xb807478b]
/usr/local/lib/libdb-4.8.so(__bam_search+0x15a0) [0xb7f49995]
/usr/local/lib/libdb-4.8.so [0xb7f31acb]
/usr/local/lib/libdb-4.8.so [0xb7f2f85e]
/usr/local/lib/libdb-4.8.so(__dbc_iput+0x261) [0xb801008e]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x198) [0xb800fe20]
/usr/local/lib/libdb-4.8.so [0xb800fae9]
/usr/local/lib/libdb-4.8.so [0xb800eb93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb800fdac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7ffdbe1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb801e25c]
================================================================================
[0xb7fa6400]
[0xb7fa6422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7aa60e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7df627d]
/usr/local/lib/libdb-4.8.so [0xb7df5951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7df56da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7ebab2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7eb9246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7ef97e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7e1cde5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7e1d4e0]
/usr/local/lib/libdb-4.8.so [0xb7e06acb]
/usr/local/lib/libdb-4.8.so [0xb7e02031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7ee31d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7ee2c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7ee5dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7ef5227]
================================================================================
[0xb7f77400]
[0xb7f77422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a770e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7dc727d]
/usr/local/lib/libdb-4.8.so [0xb7dc6951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7dc66da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e8bb2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e8a246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7eca7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x530) [0xb7dee200]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7dee4e0]
/usr/local/lib/libdb-4.8.so [0xb7dd7acb]
/usr/local/lib/libdb-4.8.so [0xb7dd3031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7eb41d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7eb3c83]
/usr/local/lib/libdb-4.8.so [0xb7eb597a]
/usr/local/lib/libdb-4.8.so [0xb7eb4b93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb7eb5dac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7ea3be1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb7ec425c]
================================================================================
[0xb8051400]
[0xb8051422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7b510e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7ea127d]
/usr/local/lib/libdb-4.8.so [0xb7ea0c3b]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_readlock+0x20) [0xb7ea0a42]
/usr/local/lib/libdb-4.8.so(__memp_fget+0xa6b) [0xb7ff4827]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x7a5) [0xb7f8e434]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7f8dc83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7f90dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7fa0227]
================================================================================
[0xb7ef2400]
[0xb7ef2422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb79f20e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7d4227d]
/usr/local/lib/libdb-4.8.so [0xb7d41951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7d416da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e06b2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e05246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7e457e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7d68de5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7d694e0]
/usr/local/lib/libdb-4.8.so [0xb7d52acb]
/usr/local/lib/libdb-4.8.so [0xb7d4e031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7e2f1d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7e2ec83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7e31dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7e41227]
================================================================================
[0xb7f47400]
[0xb7f47422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7a470e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7d9727d]
/usr/local/lib/libdb-4.8.so [0xb7d96951]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7d966da]
/usr/local/lib/libdb-4.8.so(__lock_get_internal+0x14df) [0xb7e5bb2a]
/usr/local/lib/libdb-4.8.so(__lock_get+0xc0) [0xb7e5a246]
/usr/local/lib/libdb-4.8.so(__db_lget+0x2dc) [0xb7e9a7e3]
/usr/local/lib/libdb-4.8.so(__bam_get_root+0x115) [0xb7dbdde5]
/usr/local/lib/libdb-4.8.so(__bam_search+0xeb) [0xb7dbe4e0]
/usr/local/lib/libdb-4.8.so [0xb7da7acb]
/usr/local/lib/libdb-4.8.so [0xb7da3031]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x548) [0xb7e841d7]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7e83c83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7e86dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7e96227]
================================================================================
[0xb80d1400]
[0xb80d1424]
/lib/tls/i686/cmov/libc.so.6(__sched_yield+0xc) [0xb775d9dc]
/lib/tls/i686/cmov/libpthread.so.0(pthread_yield+0x14) [0xb7bcde84]
/usr/local/lib/libdb-4.8.so(__os_yield+0x81) [0xb808d731]
/usr/local/lib/libdb-4.8.so [0xb7f2090b]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_lock+0x20) [0xb7f206da]
/usr/local/lib/libdb-4.8.so(__memp_fget+0x9cf) [0xb807478b]
/usr/local/lib/libdb-4.8.so(__bam_search+0x15a0) [0xb7f49995]
/usr/local/lib/libdb-4.8.so [0xb7f31acb]
/usr/local/lib/libdb-4.8.so [0xb7f2f85e]
/usr/local/lib/libdb-4.8.so(__dbc_iput+0x261) [0xb801008e]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x198) [0xb800fe20]
/usr/local/lib/libdb-4.8.so [0xb800fae9]
/usr/local/lib/libdb-4.8.so [0xb800eb93]
/usr/local/lib/libdb-4.8.so(__dbc_put+0x124) [0xb800fdac]
/usr/local/lib/libdb-4.8.so(__db_put+0x615) [0xb7ffdbe1]
/usr/local/lib/libdb-4.8.so(__db_put_pp+0x25e) [0xb801e25c]
================================================================================
[0xb8051400]
[0xb8051422]
/lib/tls/i686/cmov/libpthread.so.0(pthread_cond_wait+0x95) [0xb7b510e5]
/usr/local/lib/libdb-4.8.so(__db_pthread_mutex_lock+0x1c5) [0xb7ea127d]
/usr/local/lib/libdb-4.8.so [0xb7ea0c3b]
/usr/local/lib/libdb-4.8.so(__db_tas_mutex_readlock+0x20) [0xb7ea0a42]
/usr/local/lib/libdb-4.8.so(__memp_fget+0xa6b) [0xb7ff4827]
/usr/local/lib/libdb-4.8.so(__dbc_iget+0x7a5) [0xb7f8e434]
/usr/local/lib/libdb-4.8.so(__dbc_get+0xa0) [0xb7f8dc83]
/usr/local/lib/libdb-4.8.so(__dbc_pget+0x349) [0xb7f90dd7]
/usr/local/lib/libdb-4.8.so(__dbc_pget_pp+0x148) [0xb7fa0227]
Hi Josef,
Could you try reproducing this with debug and diagnostics enabled libraries and collect the locking statistics at the moment you see this issue? (use the enable-debug and enable-diagnostic options when building)
This will help getting the process IDs/thread IDs in the locking statistics. If the environment region files (__db.NNN files) are still around, collect the locking statistics (db_stat -C o)
I assume deadlock handling is correctly implemented. Were there any errors reported (i.e. DB_LOCK_DEADLOCK)?
To enhance error reporting in the application see:
Error support
Run-time error information
Regards,
Andrei
Similar Messages
-
Get blocker from the (self) deadlock trace file
Hi,
Recently I had an issue on a 10.2.0.4 single instance database where deadlocks were occurring. The following test case reproduces the problem (I create three parent tables, one child table with indexed foreign keys to all three parent tables and a procedure which performs an insert into the child table in an autonomous transaction):
create table parent_1(id number primary key);
create table parent_2(id number primary key);
create table parent_3(id number primary key);
create table child( id_c number primary key,
id_p1 number,
id_p2 number,
id_p3 number,
constraint fk_id_p1 foreign key (id_p1) references parent_1(id),
constraint fk_id_p2 foreign key (id_p2) references parent_2(id),
constraint fk_id_p3 foreign key (id_p3) references parent_3(id)
create index i_id_p1 on child(id_p1);
create index i_id_p2 on child(id_p2);
create index i_id_p3 on child(id_p3);
create or replace procedure insert_into_child as
pragma autonomous_transaction;
begin
insert into child(id_c, id_p1, id_p2, id_p3) values(1,1,1,1);
commit;
end;
insert into parent_1 values(1);
insert into parent_2 values(1);
commit;And now the action that causes the deadlock:
SQL> insert into parent_3 values(1);
1 row created.
SQL> exec insert_into_child;
BEGIN insert_into_child; END;
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at "SCOTT.INSERT_INTO_CHILD", line 4
ORA-06512: at line 1My question is: how can I determine which table the insert into CHILD was waiting on? It could be waiting on PARENT_1, PARENT_2, PARENT_3, a combination of them or even on CHILD if I tried to insert a duplicate primary key in CHILD. Since we have the full testcase we know that it was waiting on PARENT_3 (or better said, it was waiting for the "parent" transaction to perform a commit/rollback), but is it possible to determine that solely from the deadlock trace file? I'm asking that because to pinpoint the problem I had to perform redo log mining, pl/sql tracing with DBMS_TRACE and manual debugging on a clone of the production database which was restored to a SCN just before the deadlock occurred. So, I had to do quite a lot of work to get to the blocker table and if this information is already in the deadlock trace file, it would have saved me a lot of time.
Below is the deadlock trace file. From the "DML LOCK" part I guess that the child table (tab=227042) holds a mode 3 lock (SX), all the other three parent tables have mode 2 locks (SS), but from this extract I can't see that parent_3 (tab=227040) is blocking the insert into child:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00070029-00749150 23 476 X 23 476 S
session 476: DID 0001-0017-00000003 session 476: DID 0001-0017-00000003
Rows waited on:
Session 476: obj - rowid = 000376E2 - AAA3biAAEAAA4BwAAA
(dictionary objn - 227042, file - 4, block - 229488, slot - 0)
Information on the OTHER waiting sessions:
End of information on OTHER waiting sessions.
Current SQL statement for this session:
INSERT INTO CHILD(ID_C, ID_P1, ID_P2, ID_P3) VALUES(1,1,1,1)
----- PL/SQL Call Stack -----
object line object
handle number name
3989eef50 4 procedure SCOTT.INSERT_INTO_CHILD
391f3d870 1 anonymous block
SO: 397691978, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
DML LOCK: tab=227042 flg=11 chi=0
his[0]: mod=3 spn=35288
(enqueue) TM-000376E2-00000000 DID: 0001-0017-00000003
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
res: 0x398341fe8, mode: SX, lock_flag: 0x0
own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x398341ff8
SO: 397691878, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
DML LOCK: tab=227040 flg=11 chi=0
his[0]: mod=2 spn=35288
(enqueue) TM-000376E0-00000000 DID: 0001-0017-00000003
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
res: 0x3983386e8, mode: SS, lock_flag: 0x0
own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x3983386f8
SO: 397691778, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
DML LOCK: tab=227038 flg=11 chi=0
his[0]: mod=2 spn=35288
(enqueue) TM-000376DE-00000000 DID: 0001-0017-00000003
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
res: 0x398340f58, mode: SS, lock_flag: 0x0
own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x398340f68
SO: 397691678, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
DML LOCK: tab=227036 flg=11 chi=0
his[0]: mod=2 spn=35288
(enqueue) TM-000376DC-00000000 DID: 0001-0017-00000003
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
res: 0x39833f358, mode: SS, lock_flag: 0x0
own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x39833f368
----------------------------------------Thank you in advance for any comments,
JureHi Jonathan,
thank you very much for your reply which more than answers my question. I think it actually clears a lot of doubts I had about TX locks, since your mentioning of "undo segment header transaction table" pointed me in the right direction for further research on this topic (honestly, I didn't know what's "behind" TX locks). So if I understood correctly, to determine which table is the blocker (in the testcase presented above), you have to have some kind of history of executed SQL statements (e.g. by mining redo logs)?
The statement you wrote:
At this point, and with your example, the waiting session is waiting on a TX (transaction) lock - this means it has not idea (and no interest) in the actual data involved, it is merely waiting for an undo segment header transaction table slot to clear. and the example with the savepoint you gave, made me think of some of the consequences of that behaviour. That is probably the reason why it is not possible to get the "blocker" table from v$lock (although sometimes it's possible to get it from v$session.row_wait_obj#) when a session tries to change a row another session holds in exclusive mode, e.g.:
create table t1 (id number);
insert into t1 values (1);
commit;
Session 126:
SID = 126> update t1 set id=2 where id=1;
1 row updated.
Session 146:
SID = 146> update t1 set id=2 where id=1;
{session hangs}
In a separate session:
SQL> SELECT CASE
2 WHEN TYPE = 'TM'
3 THEN (SELECT object_name
4 FROM user_objects
5 WHERE object_id = l.id1)
6 END object_name,
7 SID, TYPE, id1, id2, lmode, request, BLOCK
8 FROM v$lock l
9 WHERE SID IN (126, 146)
10 ORDER BY SID, TYPE, 1
11 /
OBJECT_NAME SID TY ID1 ID2 LMODE REQUEST BLOCK
T1 126 TM 68447 0 3 0 0
126 TX 262153 4669 6 0 1
T1 146 TM 68447 0 3 0 0
146 TX 262153 4669 0 6 0The only thing I can tell from this output is that session 146 is trying to get a TX lock in exclusive mode, and session 126 is blocking it, the reason of the blocking being unknown from this view alone.
Since I'd like to get a better understanding on the mechanics behind this (e.g. why the blocked session can't know the segment that is waiting for, since it has to go to the same segment's data block to find the address of the undo segment header transaction table slot? ; can we get the content/structure of the transaction table in the data block - probably by making a block dump?), do you have any source where a more in depth explanation what happens "behind the scenes" is available (perhaps in Oracle Core?)? Some time ago I found a link on your blog http://jonathanlewis.wordpress.com/2010/06/21/locks/ which points to Franck Pachot's article where he nicely explains the various locking modes: http://knol.google.com/k/oracle-table-lock-modes#. There I also found Kyle Hailey's presentation about locks http://www.perfvision.com/papers/09_enqueues.ppt where slide 23 nicely depicts what's going on when acquiring TX locks. Of course I'll try to search on my own, but any other source (especially from an authority like you) is more than welcome.
Thank you again and regards,
Jure -
Berkeley DB SELF DEADLOCK AND RECOVERY
My berkeley db version is 6.0.20. OS is windows. c++ api.
key words:
DbEnv* m_pDbEnv = new DbEnv(0);
m_pDbEnv->set_cachesize(0, 134217728, 1);
m_pDbEnv->set_mp_mmapsize(1024*1024*1024);
m_pDbEnv->set_timeout(5000000, DB_SET_LOCK_TIMEOUT);
m_pDbEnv->open("c:\\PICSS_HOME", DB_CREATE | DB_INIT_CDB | DB_INIT_MPOOL | DB_THREAD, 0);
m_pDb = new Db(m_pDbEnv, 0);
m_pDb->set_flags(DB_DUP);
m_pDb->open(NULL, "c:\\PICSS_HOME\\picss.db", NULL, DB_BTREE, DB_CREATE|DB_THREAD, 0);
Dbt key(name, (u_int32_t)strlen(name));
Dbt data(buff, length); // length may large than 10*1024*1024
int ret = m_pDb->put(NULL, &key, &data, 0);
if (ret != 0)
// do some thing and log
return;
m_pDb->sync(0);
I have two probrem.
1. sometimes, when execute m_pDb->put(), it dose not return. I got a dump file and found It is executeing:
retry : MUTEX_LOCK(env, hp->mtx_hash) // mp_fget.c, line 256
hp->mtx_hash is 0x2016. I really do not know why It can not be locked.
I used db_deadlock.exe, but do not work.
I got this problem one time a week nearly.
2. sometimes, m_pDb->put() throw an exception, BDB0087 DB_RUNRECOVERY, fatal error, run database recovery
it seems something with db environment, is that right? why i got this happened?
Addtional, when i stop program, delete __db.001, __db.002, __db.003, and start program ,all will be ok.
How will I resolve these two problems? Any idea is worthy.
Thanks.
James.
消息编辑者为：8b488b74-a71b-4eb1-8af5-8d9c312bbac1Hi James,
on point #1 - spurious errors are difficult to debug. About the only way that we can effectively over the forum is with a reproducible test case. If you can create this and post it then we can take a look at it. Since your record size is very large, you should be using a database page size that will fit at least one of your records.
on point #2 - if you get a DB_RUNRECOVERY error message then it means that the code detected something wrong with the database. There are too many possible reasons to list them here. There is generally more information than just the return value, this would be useful to know. Are there any other error messages? Have you tried running a db_verify after getting the error message -- this will check for inconsistencies in the db files themselves.
thanks
mike -
Required patch for BDB 4.7.25 that Oracle refuses to post
I would like to know why Oracle continues to refuse to post the patch necessary to make BDB 4.7.25 workable (at least in my experience). You can find the patch at:
http://www.openldap.org/devel/cvsweb.cgi/~checkout~/build/db.4.7.25.patch?rev=1.1.2.1&hideattic=1&sortbydate=0
Note that this patch was provided by Oracle.
Any user of OpenLDAP we have who tries to use BDB 4.7 finds it unworkable without this patch, and we have to continue to direct users to use it, since they of course don't find it on the Oracle download site. It would seem to me that such a critical patch would be released to the public at large on Oracles site, instead of being generally unknown.
--QuanahAgain, we apologize for the confusion.
The patch is now available on OTN. The delay was due in part to the time it takes to test and validate an issue and the fix. The OpenLDAP team was graciously helping us do that (as is common in open source development) which is why they had an early copy of the patch.
[patch.4.7.25.2|http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.2] addresses ITS#5707 SR#16415 "DB_ENV->lock_get may self deadlock if user defined locks are used and there is only one lock partition defined." and should be used rather than the similar patch within the OpenLDAP CVS archives.
If in the future there is a similar discrepancy or any confusion please email me or Ashok directly and we will work to address it promptly.
cheers,
-greg
Product Manager, Oracle Berkeley DB, [email protected] -
BDB vxworks 6.6 kernel port error
Hello,
I have Berkeley DB 4.7.25 compiled in kernel. When I try the example in txn_guide.c, I have got the following error:
Error opening environment: S_dosFsLib_FILE_NOT_FOUND
I'm all done.
value = 10 = 0xa
I traced the source code it fails in __rep_reset_init() when it tries to open file __db.rep.init. How can I fix this? Thanks.
Allan
#ifdef HAVE_REPLICATION
if ((ret = __rep_reset_init(env)) != 0 ||
(ret = __env_remove_env(env)) != 0 ||
#else
Have I missed anything? Thanks.
/* File: txn_guide.c */
/* We assume an ANSI-compatible compiler */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <db.h>
#ifdef _WIN32
#include <windows.h>
#define PATHD '\\'
extern int getopt(int, char * const *, const char *);
extern char *optarg;
typedef HANDLE thread_t;
#define thread_create(thrp, attr, func, arg) \
(((*(thrp) = CreateThread(NULL, 0, \
(LPTHREAD_START_ROUTINE)(func), (arg), 0, NULL)) == NULL) ? -1 : 0)
#define thread_join(thr, statusp) \
((WaitForSingleObject((thr), INFINITE) == WAIT_OBJECT_0) && \
GetExitCodeThread((thr), (LPDWORD)(statusp)) ? 0 : -1)
typedef HANDLE mutex_t;
#define mutex_init(m, attr) \
(((*(m) = CreateMutex(NULL, FALSE, NULL)) != NULL) ? 0 : -1)
#define mutex_lock(m) \
((WaitForSingleObject(*(m), INFINITE) == WAIT_OBJECT_0) ? 0 : -1)
#define mutex_unlock(m) (ReleaseMutex(*(m)) ? 0 : -1)
#else
#include <pthread.h>
#include <unistd.h>
#define PATHD '/'
typedef pthread_t thread_t;
#define thread_create(thrp, attr, func, arg) \
pthread_create((thrp), (attr), (func), (arg))
#define thread_join(thr, statusp) pthread_join((thr), (statusp))
typedef pthread_mutex_t mutex_t;
#define mutex_init(m, attr) pthread_mutex_init((m), (attr))
#define mutex_lock(m) pthread_mutex_lock(m)
#define mutex_unlock(m) pthread_mutex_unlock(m)
#endif
/* Run 5 writers threads at a time. */
#define NUMWRITERS 5
* Printing of a thread_t is implementation-specific, so we
* create our own thread IDs for reporting purposes.
int global_thread_num;
mutex_t thread_num_lock;
/* Forward declarations */
int count_records(DB *, DB_TXN *);
int open_db(DB **, const char *, const char *, DB_ENV *, u_int32_t);
int usage(void);
void writer_thread(void );
/* Usage function */
int
usage()
fprintf(stderr, " [-h <database_home_directory>]\n");
return (EXIT_FAILURE);
#if 0
int
main(int argc, char *argv[])
/* Initialize our handles */
DB *dbp = NULL;
DB_ENV *envp = NULL;
thread_t writer_threads[NUMWRITERS];
int ch, i, ret, ret_t;
u_int32_t env_flags;
char *db_home_dir;
/* Application name */
const char *prog_name = "txn_guide";
/* Database file name */
const char *file_name = "mydb.db";
/* Parse the command line arguments */
#ifdef _WIN32
db_home_dir = ".\\";
#else
db_home_dir = "./";
#endif
while ((ch = getopt(argc, argv, "h:")) != EOF)
switch (ch) {
case 'h':
db_home_dir = optarg;
break;
case '?':
default:
return (usage());
#endif
void myDbTest(char *home)
/* Initialize our handles */
DB *dbp = NULL;
DB_ENV *envp = NULL;
thread_t writer_threads[NUMWRITERS];
int ch, i, ret, ret_t;
u_int32_t env_flags;
char *db_home_dir;
/* Application name */
const char *prog_name = "txn_guide";
/* Database file name */
const char *file_name = "mydb.db";
/* Parse the command line arguments */
#ifdef _WIN32
db_home_dir = ".\\";
#else
db_home_dir = "./";
#endif
db_home_dir = home;
/* Create the environment */
ret = db_env_create(&envp, 0);
if (ret != 0) {
fprintf(stderr, "Error creating environment handle: %s\n",
db_strerror(ret));
goto err;
* Indicate that we want db to perform lock detection internally.
* Also indicate that the transaction with the fewest number of
* write locks will receive the deadlock notification in
* the event of a deadlock.
ret = envp->set_lk_detect(envp, DB_LOCK_MINWRITE);
if (ret != 0) {
fprintf(stderr, "Error setting lock detect: %s\n",
db_strerror(ret));
goto err;
envp->set_shm_key(envp, 10);
env_flags =
DB_CREATE | /* Create the environment if it does not exist */
DB_RECOVER | /* Run normal recovery. */
DB_INIT_LOCK | /* Initialize the locking subsystem */
DB_INIT_LOG | /* Initialize the logging subsystem */
DB_INIT_TXN | /* Initialize the transactional subsystem. This
* also turns on logging. */
DB_INIT_MPOOL | /* Initialize the memory pool (in-memory cache) */
DB_THREAD; /* Cause the environment to be free-threaded */
/* Now actually open the environment */
ret = envp->open(envp, db_home_dir, env_flags, 0);
if (ret != 0) {
fprintf(stderr, "Error opening environment: %s\n",
db_strerror(ret));
goto err;
* If we had utility threads (for running checkpoints or
* deadlock detection, for example) we would spawn those
* here. However, for a simple example such as this,
* that is not required.
/* Open the database */
ret = open_db(&dbp, prog_name, file_name,
envp, DB_DUPSORT);
if (ret != 0)
goto err;
/* Initialize a mutex. Used to help provide thread ids. */
(void)mutex_init(&thread_num_lock, NULL);
/* Start the writer threads. */
for (i = 0; i < NUMWRITERS; i++)
(void)thread_create(
&writer_threads, NULL, writer_thread, (void *)dbp);
/* Join the writers */
for (i = 0; i < NUMWRITERS; i++)
(void)thread_join(writer_threads[i], NULL);
err:
/* Close our database handle, if it was opened. */
if (dbp != NULL) {
ret_t = dbp->close(dbp, 0);
if (ret_t != 0) {
fprintf(stderr, "%s database close failed: %s\n",
file_name, db_strerror(ret_t));
ret = ret_t;
/* Close our environment, if it was opened. */
if (envp != NULL) {
ret_t = envp->close(envp, 0);
if (ret_t != 0) {
fprintf(stderr, "environment close failed: %s\n",
db_strerror(ret_t));
ret = ret_t;
/* Final status message and return. */
printf("I'm all done.\n");
return (ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
* A function that performs a series of writes to a
* Berkeley DB database. The information written
* to the database is largely nonsensical, but the
* mechanism of transactional commit/abort and
* deadlock detection is illustrated here.
void *
writer_thread(void *args)
static char *key_strings[] = {
"key 1", "key 2", "key 3", "key 4", "key 5",
"key 6", "key 7", "key 8", "key 9", "key 10"
DB *dbp;
DB_ENV *envp;
DBT key, value;
DB_TXN *txn;
int i, j, payload, ret, thread_num;
int retry_count, max_retries = 20; /* Max retry on a deadlock */
dbp = (DB *)args;
envp = dbp->get_env(dbp);
/* Get the thread number */
(void)mutex_lock(&thread_num_lock);
global_thread_num++;
thread_num = global_thread_num;
(void)mutex_unlock(&thread_num_lock);
/* Initialize the random number generator */
srand(thread_num);
/* Write 50 times and then quit */
for (i = 0; i < 50; i++) {
retry_count = 0; /* Used for deadlock retries */
* Some think it is bad form to loop with a goto statement, but
* we do it anyway because it is the simplest and clearest way
* to achieve our abort/retry operation.
retry:
/* Begin our transaction. We group multiple writes in
* this thread under a single transaction so as to
* (1) show that you can atomically perform multiple writes
* at a time, and (2) to increase the chances of a
* deadlock occurring so that we can observe our
* deadlock detection at work.
* Normally we would want to avoid the potential for deadlocks,
* so for this workload the correct thing would be to perform our
* puts with autocommit. But that would excessively simplify our
* example, so we do the "wrong" thing here instead.
ret = envp->txn_begin(envp, NULL, &txn, 0);
if (ret != 0) {
envp->err(envp, ret, "txn_begin failed");
return ((void *)EXIT_FAILURE);
for (j = 0; j < 10; j++) {
/* Set up our key and values DBTs */
memset(&key, 0, sizeof(DBT));
key.data = key_strings[j];
key.size = (u_int32_t)strlen(key_strings[j]) + 1;
memset(&value, 0, sizeof(DBT));
payload = rand() + i;
value.data = &payload;
value.size = sizeof(int);
/* Perform the database put. */
switch (ret = dbp->put(dbp, txn, &key, &value, 0)) {
case 0:
break;
* Our database is configured for sorted duplicates,
* so there is a potential for a KEYEXIST error return.
* If we get one, simply ignore it and continue on.
* Note that you will see KEYEXIST errors only after you
* have run this program at least once.
case DB_KEYEXIST:
printf("Got keyexists.\n");
break;
* Here's where we perform deadlock detection. If
* DB_LOCK_DEADLOCK is returned by the put operation,
* then this thread has been chosen to break a deadlock.
* It must abort its operation, and optionally retry the
* put.
case DB_LOCK_DEADLOCK:
* First thing that we MUST do is abort the
* transaction.
(void)txn->abort(txn);
* Now we decide if we want to retry the operation.
* If we have retried less than max_retries,
* increment the retry count and goto retry.
if (retry_count < max_retries) {
printf("Writer %i: Got DB_LOCK_DEADLOCK.\n",
thread_num);
printf("Writer %i: Retrying write operation.\n",
thread_num);
retry_count++;
goto retry;
* Otherwise, just give up.
printf("Writer %i: ", thread_num);
printf("Got DB_LOCK_DEADLOCK and out of retries.\n");
printf("Writer %i: Giving up.\n", thread_num);
return ((void *)EXIT_FAILURE);
* If a generic error occurs, we simply abort the
* transaction and exit the thread completely.
default:
envp->err(envp, ret, "db put failed");
ret = txn->abort(txn);
if (ret != 0)
envp->err(envp, ret,
"txn abort failed");
return ((void *)EXIT_FAILURE);
} /** End case statement **/
} /** End for loop **/
* print the number of records found in the database.
* See count_records() for usage information.
printf("Thread %i. Record count: %i\n", thread_num,
count_records(dbp, NULL));
* If all goes well, we can commit the transaction and
* exit the thread.
ret = txn->commit(txn, 0);
if (ret != 0) {
envp->err(envp, ret, "txn commit failed");
return ((void *)EXIT_FAILURE);
return ((void *)EXIT_SUCCESS);
* This simply counts the number of records contained in the
* database and returns the result. You can use this function
* in three ways:
* First call it with an active txn handle.
* Secondly, configure the cursor for uncommitted reads (this
* is what the example currently does).
* Third, call count_records AFTER the writer has committed
* its transaction.
* If you do none of these things, the writer thread will
* self-deadlock.
* Note that this function exists only for illustrative purposes.
* A more straight-forward way to count the number of records in
* a database is to use DB->stat() or DB->stat_print().
int
count_records(DB dbp, DB_TXN txn)
DBT key, value;
DBC *cursorp;
int count, ret;
cursorp = NULL;
count = 0;
/* Get the cursor */
ret = dbp->cursor(dbp, txn, &cursorp,
DB_READ_UNCOMMITTED);
if (ret != 0) {
dbp->err(dbp, ret,
"count_records: cursor open failed.");
goto cursor_err;
/* Get the key DBT used for the database read */
memset(&key, 0, sizeof(DBT));
memset(&value, 0, sizeof(DBT));
do {
ret = cursorp->get(cursorp, &key, &value, DB_NEXT);
switch (ret) {
case 0:
count++;
break;
case DB_NOTFOUND:
break;
default:
dbp->err(dbp, ret,
"Count records unspecified error");
goto cursor_err;
} while (ret == 0);
cursor_err:
if (cursorp != NULL) {
ret = cursorp->close(cursorp);
if (ret != 0) {
dbp->err(dbp, ret,
"count_records: cursor close failed.");
return (count);
/* Open a Berkeley DB database */
int
open_db(DB **dbpp, const char progname, const char file_name,
DB_ENV *envp, u_int32_t extra_flags)
int ret;
u_int32_t open_flags;
DB *dbp;
/* Initialize the DB handle */
ret = db_create(&dbp, envp, 0);
if (ret != 0) {
fprintf(stderr, "%s: %s\n", progname,
db_strerror(ret));
return (EXIT_FAILURE);
/* Point to the memory malloc'd by db_create() */
*dbpp = dbp;
if (extra_flags != 0) {
ret = dbp->set_flags(dbp, extra_flags);
if (ret != 0) {
dbp->err(dbp, ret,
"open_db: Attempt to set extra flags failed.");
return (EXIT_FAILURE);
/* Now open the database */
open_flags = DB_CREATE | /* Allow database creation */
DB_READ_UNCOMMITTED | /* Allow dirty reads */
DB_AUTO_COMMIT; /* Allow autocommit */
ret = dbp->open(dbp, /* Pointer to the database */
NULL, /* Txn pointer */
file_name, /* File name */
NULL, /* Logical db name */
DB_BTREE, /* Database type (using btree) */
open_flags, /* Open flags */
0); /* File mode. Using defaults */
if (ret != 0) {
dbp->err(dbp, ret, "Database '%s' open failed",
file_name);
return (EXIT_FAILURE);
return (EXIT_SUCCESS);More information: After I create the DB, DB put works fine. The db_stat is OK.
After reboot the processor, db_stat gives error. After running db_recover, it gives errors.
Before reboot:
-> ls
CfgDbEr.log
__db.001
log.0000000001
OpvCfg.db
value = 0 = 0x0
-> db_stat "-h /bk1/db -d OpvCfg.db"
THU AUG 14 18:12:23 2008 Local time
53162 Btree magic number
9 Btree version number
Big-endian Byte order
Flags
2 Minimum keys per-page
4096 Underlying database page size
1007 Overflow key/data size
1 Number of levels in the tree
1 Number of unique keys in the tree
1 Number of data items in the tree
0 Number of tree internal pages
0 Number of bytes free in tree internal pages (0% ff)
1 Number of tree leaf pages
4058 Number of bytes free in tree leaf pages (0% ff)
0 Number of tree duplicate pages
0 Number of bytes free in tree duplicate pages (0% ff)
0 Number of tree overflow pages
0 Number of bytes free in tree overflow pages (0% ff)
0 Number of empty pages
0 Number of pages on the free list
value = 0 = 0x0
After reboot, it points out error:segment /bk1/db/__db.001 does not exist
-> db_stat "-h /bk1/db -d OpvCfg.db"
db_stat: segment /bk1/db/__db.001 does not exist
THU JAN 01 00:01:32 1970 Local time
53162 Btree magic number
9 Btree version number
Big-endian Byte order
Flags
2 Minimum keys per-page
4096 Underlying database page size
1007 Overflow key/data size
1 Number of levels in the tree
1 Number of unique keys in the tree
1 Number of data items in the tree
0 Number of tree internal pages
0 Number of bytes free in tree internal pages (0% ff)
1 Number of tree leaf pages
4058 Number of bytes free in tree leaf pages (0% ff)
0 Number of tree duplicate pages
0 Number of bytes free in tree duplicate pages (0% ff)
0 Number of tree overflow pages
0 Number of bytes free in tree overflow pages (0% ff)
0 Number of empty pages
0 Number of pages on the free list
value = 0 = 0x0
The result of running db_recover:
db_recover "-c -h /bk1/db"db_recover: segment /bk1/db/__db.001 does not exist
db_recover: /bk1/db/log.0000000002: log file unreadable: S_dosFsLib_FILE_NOT_FOU
ND
db_recover: PANIC: S_dosFsLib_FILE_NOT_FOUND
db_recover: PANIC: fatal region error detected; run recovery
db_recover: dbenv->close: DB_RUNRECOVERY: Fatal error, run database recovery
value = 1 = 0x1 -
Deadlock detected...without any info after"Information on the OTHER waiting
i got ORA-00060: Deadlock detected.
My trace file is as the follow:
Current SQL statement for this session:
UPDATE APPLSYS.FND_FORMULA_PARAMETERS SET PARAM_NAME_FRPAR = :B5 , DESC_PARAM_FRPAR = :B4 , TYPE_FRPAR = :B3 , INOUT_FRPAR = :B2 WHERE FRML_FRML_ID = :B1 The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00050018-00002c3f 28 501 X 28 501 X
session 501: DID 0001-001C-00000459 session 501: DID 0001-001C-00000459
Rows waited on:
Session 501: obj - rowid = 0000CAD7 - AAAMrXAAFAAAGIQAAE
(dictionary objn - 51927, file - 5, block - 25104, slot - 4)
Information on the OTHER waiting sessions:
End of information on OTHER waiting sessions.
As you see there isn't any info after *"Information on the OTHER waiting sessions:"*
what is the cause of this deadlock?user13344656 wrote:
i got ORA-00060: Deadlock detected.
My trace file is as the follow:
Current SQL statement for this session:
UPDATE APPLSYS.FND_FORMULA_PARAMETERS SET PARAM_NAME_FRPAR = :B5 , DESC_PARAM_FRPAR = :B4 , TYPE_FRPAR = :B3 , INOUT_FRPAR = :B2 WHERE FRML_FRML_ID = :B1 The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00050018-00002c3f 28 501 X 28 501 X
session 501: DID 0001-001C-00000459 session 501: DID 0001-001C-00000459
Rows waited on:
Session 501: obj - rowid = 0000CAD7 - AAAMrXAAFAAAGIQAAE
(dictionary objn - 51927, file - 5, block - 25104, slot - 4)
*Information on the OTHER waiting sessions:*
*End of information on OTHER waiting sessions.*-----------------------------------------------------------------
As you see there isn't any info after *"Information on the OTHER waiting sessions:"*
what is the cause of this deadlock?I believe that what you are seeing is termed a self deadlock. Such a deadlock could be caused by an autonomous transaction.
Take a look at the following Asktom thread:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1528515465282
In the above thread, search for: August 24, 2004 - 9am Central time zone
Read down to at least the comment that was posted on: September 21, 2004 - 2pm Central time zone
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Deadlock issue in Oracle 10g Partitioned Tables
Hi ALL,
I am facing an issue of Deadlock while inserting data into a partitioned table.
I get an error "ORA-00600: Deadlock detected". when i see the trace files, following lines are appearing in them:
"Single resource deadlock: blocking enqueue which blocks itself".
Here is the detail of my test case:
1. I have a list-partitioned table, with partitioning defined on some business codes.
2. I have a query that merges data into partitioned table (actually compares unique keys between temporary table and partitioned table and then issue an insert if keys not matched, no update part).
3. The temporary table contains transactional data against many business codes.
3. when calling the above query from multiple (PL/SQL) sessions, i observe that when we merge data in same partition (from different sessions) than deadlock issue occurs, otherwise it is OK.
4. Note that all sessions are executed at same time. Also note that Commit is called after each session is completed. Each session contains 2-3 more queries after the mentioned merge statement.
Is there an issue with oracle merge/insert on same partition (from different sessions)? What is the locking mechanism for this particular case (partitioned tables)?
My oracle version is Oracle 10g (10.2.0.4). Kindly advice.
Thanks,
QQ.Could you print the deadlock tree so we can see the type and mode of the locking. (Please use the 'code' tags - see FAQ at top right of screen - to showthe output in fixed font). can you list any SQL operated by this session that gets reported in the trace file.
Does the table reference itself in a foreign key.
Is this table involved in any referential integrity constraints.
Do you have a global primary key index, or a local primary key index ?
Are there any triggers on the table - if so do they contain autonomous transactions.
At present the only though that springs to mind is that the merge command has to lock the target table to do the insert/update, but it also has to lock any child table. The mode of the child lock depends on whether it has a suitable index or not, and whether the child table IS also the parent table. If you have two merges to the same partition one partition may get its locks, and the other partition may be in a state where it can't get one of the locks because it's wait for the other. (This shouldn't be a self-deadlock, though, but the scenario might be heading in the right direction for a self-deadlock).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking) -
Parallel query worker thread was involved in a deadlock
Hi,
We are getting deadlock issue in MSSQL 2012 enterprise edition. By enabling the trace we could find the MORE number messages as below:
"parallel query worker thread was involved in a deadlock"
Along with this there are some other entries with dead lock information ( chain, graph) .
Please suggest.
Thank youOP, I think that article posted by Saeid is exactly about your situation, although SQL2012 might have changed the message slightly.
What the article says is bad news - you have done nothing wrong, yet SQL Server is messed up. The only "fix" recommended is eliminating parallelism by using a hint "option (maxdop 1)" at the end of your query. This should do the trick, but may
run more slowly.
You can try to reduce the odds of it happening by adding indexes. Actually, ANY change to your plan or data model may make just enough changes to come up with another plan that does NOT get these self-deadlocks. Any query that is more efficient,
should reduce the odds of a deadlock.
You can also try to analyze the deadlock as you would any deadlock, it may suggest another way to write the query.
Josh -
Deadlock ORA-00060 with Transformations
Hi everyone,
we are on SP 10 together wih Oracle 10.2.0.2.0. In our development system I made already some big test loads (~Mio entries) from Data Store to cube. As sometimes in 3.0B we get a self-deadlock because processes killed each other, but now it happens more often. The bad thing with such an error from a Data Store to cube, that there is no possibility to make a manual update so a restart is necessary.
Has anyone suffered the same? Any proposals others than too less data or use PSA and Update-rules?
My current solution is to set the data-package size so high that the load is done in one package, what is really not a good solution. Is there a possibility to reduce the paralellility to one at a cube load other than my method?
Best regards
Harald.Hi Harald,
Kindly look into the following notes :
980555 ORA 600 [kdtdelrow-2] during insert with deadlock
1015152 ORA 600 [kdtdelrow-2] during insert in Oracle 10.2.0.2
1003217 ORA-600 [kdiblLockRange:not validated] during an insert
hope this helps,
Regards
KK -
Query execute() API goes for inifinite wait (Hang)
Hi
I am using BDB XML 2.4 in Fedora core-4. when I execute xquery update operation followed by FLWOR get query, the execute() API goes for infinite wait. We have tried setting NOWAIT flags to see if it waits for lock, but the program is in INFINITE wait (hang) state.
Below is the sample code and query I have used.
#include <dbxml/DbXml.hpp>
using namespace DbXml;
int
main(int argc, char **argv)
std::string containerName = "myContainer.dbxml";
std::string docFilename = "./NECB1.xml"; // the filename
std::string queryString1 = "declare namespace SWI='SWI'; <getBulkResult> { let $i :=collection()//SWI:wmanIfBsOfdmaDownlinkChannelTable return ($i)} </getBulkResult>";
std::string queryString = "replace node collection()//SWI:wmanIfBsOfdmaDownlinkChannelTable/SWI:wmanIfBsOfdmaDownlinkChannelEntry[@ifIndex='2']/SWI:wmanIfBsOfdmaDownlinkCenterFreq with <SWI:wmanIfBsOfdmaDownlinkCenterFreq>3</SWI:wmanIfBsOfdmaDownlinkCenterFreq>";
try {
u_int32_t env_flags=DB_CREATE|DB_INIT_LOCK|DB_INIT_LOG|DB_INIT_MPOOL|DB_AUTO_COMMIT|DB_RECOVER|DB_INIT_TXN;
DbEnv *clEnv = new DbEnv(0);
clEnv->open("/tmp",env_flags,0);
XmlManager mgr;
if (mgr.existsContainer(containerName))
mgr.removeContainer(containerName);
// Now it is safe to create the container
XmlContainer cont = mgr.createContainer(containerName);
u_int32_t cf =1000; //time out value in micro seconds
clEnv->set_timeout(cf,DB_SET_LOCK_TIMEOUT);
// All Container modification operations need XmlUpdateContext
XmlUpdateContext uc = mgr.createUpdateContext();
// Create the file input stream
XmlInputStream *myStream = mgr.createLocalFileInputStream(docFilename);
// Put the document in the container
cont.putDocument(docFilename, myStream, uc, 0); //TODO try without last parm(0)
std::cout << "File loaded" << std::endl;
// Querying requires an XmlQueryContext
XmlQueryContext qc = mgr.createQueryContext();
qc.setDefaultCollection(containerName);
qc.setNamespace("SWI","SWI");
std::cout << "update query " << std::endl;
XmlQueryExpression expr = mgr.prepare(queryString, qc);
XmlResults res = expr.execute(qc); //modify
std::cout << "get query " << std::endl;
XmlQueryExpression expr1 = mgr.prepare(queryString1, qc);
XmlResults res1 = expr1.execute(qc); //getbulk
std::cout << "The query modify, '" << expr.getQuery() << "' returned " <<
res.size() << " result(s)" << std::endl;
XmlValue value;
std::cout << "Result 1: " << std::endl;
while (res.next(value)) {
std::cout << "\t" << value.asString() << std::endl;
std::cout << "The query 2 bulk , '" << expr1.getQuery() << "' returned " <<
res1.size() << " result(s)" << std::endl;
XmlValue value1;
std::cout << "Result 2: " << std::endl;
while (res1.next(value1)) {
std::cout << "\t" << value1.asString() << std::endl;
} catch (XmlException &xe) {
std::cout << "XmlException: " << xe.what() << std::endl;
return 0;
Sample output:
===========
[root@localhost santhosh]# ./query
File loaded
update query
get query
^C
Please let me know what could be the issue. Do I need to set any transaction related flags? I hope it should through exception if any setting/query is wrong.
Thanks,
SanthoshHi Santhosh,
Because you aren't using explicit transactions, your update query is being auto-transacted, and the read-only query is running without a transaction. This is very bad, and is giving you a self-deadlock situation. You should use an explicit transaction for your queries.
John -
what's __db_tas_mutex_lock() mean?
after my program run fro servral days, it seems to stop doing anying with allmost 100% cpu usage.
i use gdb to attach it, and i get the following results:
$gdb --pid=22323
info thread
thread .... in __db_tas_mutex_lock() from /usr/lib64/libdb_cxx-4.8.so
and db_stat seems to print nothing unusual.
is that means a deadlock happend?
i configured my db using
dbenv->set_lk_detect(DB_SET_LOCK_OLDEST)
and i tried
$ db_deadlock -h envhome -a o
$ db_deadlock -h envhome
and nothing happended.
i have no idea what's wrong with it now. please someone help me.
thank you
Edited by: 863811 on 2011-6-6 上午2:27what's __db_tas_mutex_lock() mean? __db_tas_mutex_lock is called when we need to acquire a lock on a mutex. Look it up in the BDB 4.8.26 tree; the method is in db-4.8.26/mutex/mut_tas.c, line 244. If you are using 4.8.26, please try to switch to the latest 4.8 patch release, which is 4.8.30; see the Berkeley DB downloads page.
after my program run fro servral days, it seems to stop doing anying with allmost 100% cpu usage.
i use gdb to attach it, and i get the following results:
$gdb --pid=22323
info thread
thread .... in __db_tas_mutex_lock() from /usr/lib64/libdb_cxx-4.8.so
and db_stat seems to print nothing unusual.
is that means a deadlock happend? Have you examined the locking statistics? Collect them using db_stat -Co or -CA and look for any deadlocks or potential self-deadlocks.
See the following section in the Berkeley DB Programmer's Reference Guide:
Deadlock detection, Deadlock debugging.
i configured my db using
dbenv->set_lk_detect(DB_SET_LOCK_OLDEST)
and i tried
$ db_deadlock -h envhome -a o
$ db_deadlock -h envhome
and nothing happended.
i have no idea what's wrong with it now. please someone help me.
thank you
Edited by: 863811 on 2011-6-6 上午2:27If you still this issue, attach to the process, get the stacks of the threads in the process, collect the locking statistics with db_stat -CA, the CPU utilization data using top, sar or mpstat (if on SMP - multiple CPU - system) and post them here. A short guide on finding out Linux CPU utilization is here.
If you need to limit the CPU usage per process, you could use cpulimit.
It would be useful if you could reproduce this with debug and diagnostic enabled libraries so that we have the process id and thread ids in the locking statistics.
Regards,
Andrei -
Frequent but unpredictable DB_PAGE_NOTFOUND corruption
Hi,
We have developed a multi-process data processing engine that uses BDB as state storage to store queues of pointers to datums in on-disk flat files. The engine is written in Perl, using the standard BerkeleyDB CPAN module as its interface to BDB.
Platform: Red Hat Enterprise Linux 5.1 x86-64
Perl: 5.8.8 (with 64-bit support)
BDB: 4.3.29 (the default for this version of RHEL)
After running in production for some time without any errors, occasionally one of the data queues (a Btree database) has started to corrupt after a few hours of record creation/deletion by forked children. The error (which is elicited after subsequent db_put() calls is "DB_PAGE_NOTFOUND: Requested page not found"), and running db_verify on the database returns:
"db_verify: Page 1: internal page is empty and should not be
db_verify: queue.db: DB_VERIFY_BAD: Database verification failed"
Worse, is that the error cannot be recreated on any of our development or staging environments - it just intermittently occurs in production, now maybe every 3 to 8 hours.
Some background:
Roughly - the child processes that seem to be causing the corruption read a bunch of key/values via a cursor, and then delete the keys from the DB.
The environment is created with: DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_THREAD | DB_INIT_TXN
The database is created with: DB_CREATE|DB_THREAD
The parent process closes all Env & DB handles before forking children, then re-opens upon returning from fork().
The child processes all open their own Env & DB handles after fork().
There are usually around 5-8 children running in parallel, and will execute the deletes on the DB in parallel.
Before exiting, the child processes always explicitly call db_sync() before calling db_close() - probably overkill.
Here's where my understanding of deadlocking in BDB gets shaky:
DB_INIT_LOCK should implement multiple-writer locking semantics, and because of the way the parent process distributes the work to the child processes, children are never competing to delete the same keys.
I suspect the reason for the corruption is that BDB's locking may be page-based, not key (record) based, and if (say) child A deleting a key causes an underlying page split (?) whilst child B is also deleting a key stored on that same page, corruption occurs. Am I on the right track here? The app is not yet doing any deadlock detection or resolution - we haven't yet gone down that route because nowhere are any errors regarding deadlocks being surfaced in the statuses of any DB calls, or the output of db_stat().
Interestingly, none of the db_del() calls in any of children fail, with deadlock errors or otherwise - the corruption is only noticed by calls to db_put() into the same database during a subsequent processing run - obviously after the in-memory cache has been synced to disk.
We haven't yet gone for upgrading BDB to 4.7 (or even 4.4) , but will attempt to do this if no other fix is forthcoming.
An alternative, quicker fix we're trying out is to use DB_INIT_CDB to enforce single-writer semantics on the children, or to move the responsibility of writing back up to the parent process, and have no multiple-writers at all.
I know my understanding of the pitfalls of deadlocking and how they relate to the underlying Btree store aren't great and suspect herein lies the real problem. Many thanks in advance for anyone with advice or recommendations here.Thanks Michael. I'll engage here for the sake of Googlers and also follow up by email.
- Yes, the same flags are used to open the environments and db in the children; all processes use the same storage class that wraps the BDB access.
- db_sync() before db_close() was paranoia on my part - noted and understood that it's unnecessary.
- The db_verify output is indeed all it reports. <tt>db_dump -qa queue.db</tt> on a corrupt DB reports:
<tt>
In-memory DB structure:
btree: 0x120200 (duplicates, open called, read-only)
bt_meta: 0 bt_root: 1
bt_maxkey: 0 bt_minkey: 2
bt_compare: 0x30b2222900 bt_prefix: 0x30b2222970
bt_lpgno: 0
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
page 0: btree metadata level: 0 (lsn.file: 0 lsn.offset: 1)
magic: 0x53162
version: 9
pagesize: 8192
type: 9
keys: 0 records: 0
free list: 2, 0
last_pgno: 2
flags: 0x1 (duplicates)
uid: 5f 0 db 4 0 fd 0 0 1b d6 75 51 bf 5c 0 0 0 0 0 0
maxkey: 0 minkey: 2
root: 1
page 1: btree internal level: 2 records: 0 (lsn.file: 0 lsn.offset: 1)
entries: 0 offset: 8192
page 2: invalid level: 0 (lsn.file: 0 lsn.offset: 1)
prev: 0 next: 0 entries: 0 offset: 8192
</tt>
There are records in the queue.db, though - viewing it reveals recognisable keys.
Other things I ought to mention, which may be giveaways:
- Although creating the environment with DB_INIT_TXN, the app does not perform any transaction handling or checkpointing - in effect it is in auto-commit mode.
- Since modifying the storage to use DB_INIT_CDB overnight, there has been (so far!) no corruption.
Thanks again. -
Dead Lock what made by another user!(patition table)
I have a question about Dead-Lock!
Our Situation is ..
User "A" made a Patition Table, ACNT_WONJANG
(without any Trigger,Function, Procedure)
When "B" - another user - tried to drop its Partition,
Dead-Lock invoked.
but A droped it's Partition well.
What can i Do?
this is the trace file.
/oracle/home/admin/ACNT/udump/ora_44478_acnt.trc
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
ORACLE_HOME = /oracle/home
System name: AIX
Node name: acnt
Release: 3
Version: 4
Machine: 000C962D4C00
Instance name: ACNT
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 44478, image: oracle@acnt (TNS V1-V3)
*** SESSION ID:(16.394) 2001-10-04 15:00:41.829
A self-deadlock among DDL and parse locks
is detected. In most cases, this self-deadlock
is handled internally.
This should be reported to Oracle Support
ONLY IF an error is signalled back to the
user on a command-line or screen.
The following information may aid in finding
user on a command-line or screen.
The following information may aid in finding
the problem.
ORA-04020: deadlock detected while trying to lock object
F03P.ACNT_WONJANG
session: 440786b4 request: X
LIBRARY OBJECT HANDLE: handle=43108348
name=F03P.ACNT_WONJANG
hash=76b93583 timestamp=NULL
namespace=TABL/PRCD/TYPE flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0001-0001 lock=S pin=S latch=0
lwt=43108360[43108360,43108360] ltm=43108368[43108368,43108368]
pwt=43108378[43108378,43108378] ptm=431083d0[431083d0,431083d0]
ref=43108350[43108350,43108350] lnd=431083dc[4310824c,425b7ec4]
LIBRARY OBJECT: object=431080d0
flags=NEX[0002] pflags= [00] status=VALD load=0
DATA BLOCKS:
data# heap pointer status pins change
0 431082d8 43108154 I/P/A 0 NONE
HEAP DUMP OF DATA BLOCK 0:
HEAP DUMP heap name="library cache" desc=0x431082d8
HEAP DUMP heap name="library cache" desc=0x431082d8
extent sz=0x224 alt=32767 het=8 rec=9 flg=2 opc=0
parent=30000030 owner=431080d0 nex=0 xsz=0x0
EXTENT 0
Chunk 431080c0 sz= 196 perm "perm "
alo=196
431080C0 500000C5 00000000 00000000 000000C4 [P...............]
431080D0 43108348 431080D4 431080D4 431080DC [C..HC...C...C...]
431080E0 431080DC 00000000 00000000 00020100 [C...............]
431080F0 00000000 00000000 00000000 00000000 [................]
43108100 43108144 00000000 00000000 00000000 [C..D............]
43108110 00000000 00000000 00000000 00000000 [................]
Repeat 2 times
43108140 00000000 431082D8 00000000 43108154 [....C.......C..T]
43108150 00000000 00000000 00000000 00000000 [................]
Repeat 1 times
43108170 00000000 00000000 00000019 00000000 [................]
43108180 00000000 [....]
Total heap size = 196
FREE LISTS:
Bucket 0 size=0
Total free space = 0
UNPINNED RECREATABLE CHUNKS (lru first):
Total free space = 0
UNPINNED RECREATABLE CHUNKS (lru first):
PERMANENT CHUNKS:
Chunk 431080c0 sz= 196 perm "perm "
alo=196
Permanent space = 196carlyfromal wrote:
Here's the thing I myself have an Ipad 3 that I got from Ebay that is activation locked and I have the same issue. Can't get the info. Well,since Apple conveniently decided to discontinue selling the Ipad 3 the only way I could get one was to buy a used one,so it looks to me like they could have some mercy and help a person unlock the thing. We're not dishonest people that go around stealing things,yet because of Apple's brilliant(I use that term sarcastically) idea to put this stupid new crap in place people like us who have to buy second-hand products have to suffer and get screwed out of money we had to save up to buy this stuff! And all anyone can come up with is "well boohoo" or "tough luck" or whatever! But,what about the rights of the rest of us?! Some of you may find this a tad rude, but oh well,tough luck!
On the other hand, there are those of us that appreciate the theft protection provided by the latest IOS.
There are certain things to watch out for when purchasing used devices of any sort, the first of which is to ensure that you're not buying stolen property. Since you are unable to obtain cooperation from the seller, perhaps your device was stolen! -
PL/SQL Trying to update a table through trigger on the same table
Hi everyone my name is Edwin and I'm new to this forum. I hope I can learn a lot from this community and over time contribute to it.
The problem I'm facing at the moment is a tough one. I need to update a table (table a) with a value called block_id. This block_id is generated by a procedure I have written myself, the end result is stored in another table (table b). This block_id needs to be generated after certain rows of table a get updated with a trans_id. The trans_id is all the same for these rows in table a, but the generated block_id isn't. In my code I use an after update on collumn a of table a trigger. So if the the collumn gets updated the trigger fires. The trigger calls the procedure that generates the block_id and the procedure generates table b with all the block_id's. But then I want to update the rows in table a with the generated block_id in table b. The problem is that this self-deadlocks.
You might think that this would call a recursive trigger, but I have written code in the trigger that checks if the block_id isn't allready filled in on table a.
Also I really need all the values wich get updated (table a), so I believe a before update is also out of the question.
And the first update of table a is done through an erp-packet and I can't get at that code, otherwise I would just have run my code from there.
Message was edited by:
user625855CREATE OR REPLACE TRIGGER block_id_trigger AFTER UPDATE ON unload_details_tab
DECLARE
current_transport_id NUMBER;
check_value NUMBER;
check_block_id NUMBER;
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
current_transport_id := get_curent_trans_id; --function that gets the current transport_id
check_value := check_site_and_directive(current_transport_id); --function checks if this transport_id should have a block_id
check_block_id := check_for_block_id(current_transport_id); --function checks if there isn't allready a block_id set.
IF check_value = 1 AND check_block_id = 0 THEN
create_blok_id_table(current_transport_id); --this procedure creates the blok_id in temptable
UPDATE unload_details_tab a SET a.block_id = (SELECT DISTINCT b.blok_id FROM temptable b WHERE b.mark = a.mark_1) WHERE a.transport_id = current_transport_id; --this statement should update the table back, if I leave it out everything works fine, but when I leave it I get the self-deadlock error.
ELSE
null;
END IF;
END block_id_trigger;
Ok, I cleaned the code somewhat.
user625855 -
ORA-30657: error when debbugging mapping
someone know, why it tell me: not supported function on an external table.
what is wrong I defined every thi g rightDo you think it might be a bug? I mean, External Tables and Pivot operator may become way too difficult for Oracle to handle....
Self-Deadlocks occurs when a session try to get a lock on a resource that is already locked by this session. It also depends on the DB version you are using (there was a Bug in releases earlier than 9i). Is this mapping altering any object (maybe, disabling/enabling indexes) before/after load? If so, try to remove this part of the code and test.
Also check if this Mapping has circular references to invalid objects. That could cause this error. Use query bellow to check:
column "dependant name" format a20 ;
column "dependant owner" format a15;
column "parent owner" format a15;
select d_obj#,
doa.object_name "dependant name",
doa.owner "dependant owner",
doa.status "dep status",
p_obj#,
dob.object_name "parent name",
dob.owner "parent owner"
from dba_objects doa,
dba_objects dob,
dependency$ dp
where (dp.d_obj#, dp.p_obj#)
in (select dpb.p_obj#, dpb.d_obj# from dependency$ dpb)
and dp.d_obj#=doa.object_id
and dp.p_obj#=dob.object_id
and dob.status = 'INVALID';
Anyway, this error generates a trace file in the user_dump_dest location. You check this trace file and try to find out if there's some usefull information.
Regards,
Marcos
Maybe you are looking for
-
What to do when trying to log into my iCloud and it says "this apple iD is valid, but it's not an iCloud account"?
-
Hello All, Is there a way to have a drop shadow on 2 sides of an object? I want it to look like this: I have been using two objects with the shadow on 1 side and then putting them on top of each other. Would like to do it with 1 object. Can it be
-
when I start DBConsole , its giving the following error (Window based services). ?Windows could not start the OracleDBConsolertlg on local computer. For more information, please review the system event log. If this is a non-Microsoft service, contact
-
How to Load Progressive-Download Video just when I press Play?
I have set the Progressive-Download video instead of Streaming-Video (because my webserver provider "aruba.it" doesn't offer streaming videos), in Flash CS4 Professional, and exported to Dreamweaver CS4. I have also inserted the HTML code in Dreamwea
-
Illustrator changing to the pen tool when I zoom on a Wacom tablet
Is there a way to make Illustrator stop changing to the pen tool whenever I zoom in or out? I rarely need this tool when I'm zooming in or out and it wastes my time to have to keep changing the tool back to what I want every single time, it is the mo