登入資料庫hang住
[[email protected] ~]$ sqlplus scott/tiger
SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 15 19:22:25 2014
Copyright (c) 1982, 2009, Oracle. All rights reserved.
。。。。
hang在這裡沒有反應
用sys登入沒有異常
檢視hang住的session 的event
SQL> select sid,username,event,p1,p2,p3 from v$session where status='ACTIVE' and username is not null;
SID USERNAME EVENT P1 P2
---------- ------------------------- ------------------------------------------------------- ---------- ----------
P3
----------
36 SYS SQL*Net message to client 1650815232 1
0
59 SCOTT write complete waits 5 176
0
76 SYS Streams AQ: waiting for messages in the queue 12884 1388097736
1
這個等待一般是由於IO效能引起的，或者dbwr程序工作量大導致，跟我的情況明顯不同
測試庫上沒有跑任何作業或者其他的操作
作業系統的負載也很低，幾乎沒有
這個等待的P1 ,P2分別是file#，block#
SQL> select name,parameter1,parameter2,parameter3,wait_class from v$event_name where name='write complete waits';
NAMEPARAMETER1PARAMETER2PARAMETER3WAIT_CLASS
--------------------------------------------------------------------------------
write complete waitsfile#block#
檢視等待的物件是什麼
SQL> select owner,segment_name, segment_type
2 from dba_extents
3 where file_id = &file_id
4 and &block_id between block_id and block_id + blocks - 1;
Enter value for file_id: 5
old 3: where file_id = &file_id
new 3: where file_id = 5
Enter value for block_id: 176
old 4: and &block_id between block_id and block_id + blocks - 1
new 4: and 176 between block_id and block_id + blocks - 1
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------------------------------------ -------------------- ------------------------------------
SYS _SYSSMU14_277467141$ TYPE2 UNDO
同時發現此時很多操作無法完成
如flush buffer_cahce，switch logfile等
檢視alter日誌發現：
Fri Jan 10 20:07:17 2014
Suspending MMON action 'undo usage' for 82800 seconds
Fri Jan 10 22:00:01 2014
Setting Resource Manager plan SCHEDULER[0x3007]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Fri Jan 10 22:00:01 2014
Starting background process VKRM
Fri Jan 10 22:00:01 2014
VKRM started with pid=38, OS id=13518
Fri Jan 10 22:34:33 2014
DW00 started with pid=51, OS id=14090, wid=2, job SCOTT.SYS_EXPORT_SCHEMA_01
Fri Jan 10 22:47:38 2014
Suspending MMON slave action kewrmrfsa_ for 82800 seconds
Fri Jan 10 22:49:52 2014
DW00 started with pid=54, OS id=14344, wid=2, job SCOTT.SYS_EXPORT_SCHEMA_01
Fri Jan 10 23:15:20 2014
Suspending MMON slave action kewrmafsa_ for 82800 seconds
Sat Jan 11 19:29:00 2014
Suspending MMON action 'undo usage' for 82800 seconds
Sat Jan 11 23:05:39 2014
Suspending MMON slave action kewrmafsa_ for 82800 seconds
Sun Jan 12 00:35:17 2014
Suspending MMON slave action kewrmrfsa_ for 82800 seconds
Sun Jan 12 18:43:51 2014
Suspending MMON action 'undo usage' for 82800 seconds
Sun Jan 12 23:11:10 2014
Suspending MMON slave action kewrmafsa_ for 82800 seconds
Mon Jan 13 00:35:04 2014
Suspending MMON slave action kewrmrfsa_ for 82800 seconds
Mon Jan 13 18:00:27 2014
Suspending MMON action 'undo usage' for 82800 seconds
Mon Jan 13 23:13:24 2014
Suspending MMON slave action kewrmafsa_ for 82800 seconds
發現2個值得注意的地方
1，Setting Resource Manager plan SCHEDULER[0x3007]:DEFAULT_MAINTENANCE_PLAN via scheduler window
2，Suspending MMON slave action kewrmrfsa_ for 82800 seconds
Suspending MMON action 'undo usage' for 82800 seconds
關於1，有文章說可能是Resource Manager plan引起的bug，
resouce manager的bug：
Oracle Support - March 31, 2012 10:35:20 AM GMT-04:00 [ODM Action Plan]
The hang analyze shows several chains where the blocking session is waiting on resmgr:cpu quantum.
Please disable resource manager and check it the issue still occurs.
這裡跟我的情況不太一樣
2，MMON程序異常，MMON程序跟awr有關，可以kill，這裡是測試環境，所以我直接kill了這個程序
[
grid 4414 0.0 0.6 419584 13084 ? Ss Jan10 0:00 asm_mmon_+ASM2
grid 4749 0.0 1.4 306724 30028 ? Sl Jan10 1:09 /opt/app/grid/product/11.2.0/jdk/jre//bin/java -Doracle.supercluster.cluster.server=eonsd -Djava.net.preferIPv4Stack=true -Djava.util.logging.config.file=/opt/app/grid/product/11.2.0/srvm/admin/logging.properties -classpath /opt/app/grid/product/11.2.0/jdk/jre//lib/rt.jar:/opt/app/grid/product/11.2.0/jlib/srvm.jar:/opt/app/grid/product/11.2.0/jlib/srvmhas.jar:/opt/app/grid/product/11.2.0/jlib/supercluster.jar:/opt/app/grid/product/11.2.0/jlib/supercluster-common.jar:/opt/app/grid/product/11.2.0/ons/lib/ons.jar oracle.supercluster.impl.cluster.EONSServerImpl
oracle 5054 0.0 4.8 992696 100980 ? Ss Jan10 0:06 ora_mmon_rac2
oracle 26959 0.0 0.0 3920 664 pts/5 R+ 19:21 0:00 grep mmon
[
[[email protected] trace]$ ps aux | grep mmon
grid 4414 0.0 0.6 419584 13084 ? Ss Jan10 0:00 asm_mmon_+ASM2
grid 4749 0.0 1.4 306724 30028 ? Sl Jan10 1:09 /opt/app/grid/product/11.2.0/jdk/jre//bin/java -Doracle.supercluster.cluster.server=eonsd -Djava.net.preferIPv4Stack=true -Djava.util.logging.config.file=/opt/app/grid/product/11.2.0/srvm/admin/logging.properties -classpath /opt/app/grid/product/11.2.0/jdk/jre//lib/rt.jar:/opt/app/grid/product/11.2.0/jlib/srvm.jar:/opt/app/grid/product/11.2.0/jlib/srvmhas.jar:/opt/app/grid/product/11.2.0/jlib/supercluster.jar:/opt/app/grid/product/11.2.0/jlib/supercluster-common.jar:/opt/app/grid/product/11.2.0/ons/lib/ons.jar oracle.supercluster.impl.cluster.EONSServerImpl
oracle 26961 0.0 0.0 3920 664 pts/5 R+ 19:21 0:00 grep mmon
alter日誌：
Wed Jan 15 19:23:45 2014
Restarting dead background process MMON
Wed Jan 15 19:23:45 2014
MMON started with pid=24, OS id=27085
Wed Jan 15 19:26:33 2014
但是kill後發現還是無法正常登入系統
檢查是否有其他異常session的阻塞
SQL> select BLOCKING_INSTANCE,BLOCKING_SESSION from v$session where sid=59;
BLOCKING_INSTANCE BLOCKING_SESSION
----------------- ----------------
2 18
SQL> select sid,username,event,BLOCKING_INSTANCE,BLOCKING_SESSION from v$session where sid=18;
no rows selected
session 59 被session 18阻塞，但是沒有session 18的資訊
決定重啟一下rac2的例項
[[email protected] ~]$ srvctl stop instance -d rac -n rac2
這裡等待了幾分鐘，發現沒有任何反應
檢視alter日誌，只有一條資訊：
Wed Jan 15 19:26:33 2014
PMON failed to delete process, see PMON trace file
檢查pmon tracefile資訊：
*** 2014-01-15 19:27:43.564
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
*** 2014-01-15 19:27:57.503
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
*** 2014-01-15 19:28:11.474
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
*** 2014-01-15 19:28:25.360
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
*** 2014-01-15 19:28:39.244
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
*** 2014-01-15 19:28:53.137
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
PMON waiting for 1000 csecs
*** 2014-01-15 19:29:06.990
found process 0x52bcce2c pid=34 serial=6 ospid = 10671 dead
*** 2014-01-15 19:29:06.990
deleting process 0x52bcce2c pid=34 serial=6 priority=0
need redo log switch, current log full
need redo log switch, current log full
need redo log switch, current log full
need redo log switch, current log full
need redo log switch, current log full
need redo log switch, current log full
deletion of process 52bcce2c pid=34 seq=6 prog=FALSE unsuccessful
從pmon資訊可以看出來，need redo log switch, current log full
current redo log 需要切換，但是無法完成
檢視歸檔日誌資訊：
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/archivelog
Oldest online log sequence 794
Next log sequence to archive 794
Current log sequence 796
SQL> select dest_name,status,error,target,process from v$archive_dest where dest_name=1;
DEST_NAME STATUS ERROR
------------------------------ ------------------ --------------------
TARGET PROCESS
-------------- --------------------
LOG_ARCHIVE_DEST_1 ERROR ORA-19502: write
error on file "",
block number
(block size=)
PRIMARY ARCH
SQL> ! df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 23G 16G 5.5G 75% /
/dev/sda1 99M 12M 83M 12% /boot
tmpfs 1014M 614M 400M 61% /dev/shm
發現歸檔路徑有錯誤，ORA-19502
才檢視磁碟，磁碟還有5個多G空間，完全沒有問題，後來測試了磁碟的讀寫許可權，也沒有問題
這就比較奇怪
重新指定一個歸檔路徑
SQL> alter system set log_archive_dest_1='location=/home/oracle/';
System altered
SQL> alter system switch logfile;
System altered.
發現可以正常切換日誌了
此時普通使用者也可以正常連線
[[email protected] archivelog]$ sqlplus scott/tiger
SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 15 19:42:18 201
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL>
相關推薦
登入資料庫hang住
登入測試資料庫，發現普通使用者登入就hang住沒反應 [[email protected] ~]$ sqlplus scott/tiger SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 15 19:22:25
NDMCDB資料庫hang住故障分析
問題描述： 上午剛剛到辦公室，就有監控人員郵件反饋，昨晚NDMCDB407資料庫被重啟過，讓我分析一下資料庫重啟的原因。由於昨晚業務有版本上線，所以簡訊警告關閉了，所以沒有簡訊下發到我手機上，而且故障時相關人員也沒有通知到我。 1 檢查alert日誌 從alert
Oracle資料庫監聽非常慢，基本hang住故障處理
測試人員郵件反饋： 訂購資料庫的連線非常慢，甚至是無法連線，想要我檢檢視看。 經檢視： [email protected]:~/app/admin/wdadb/adump> lsnrctl status LSNRCTL for Linux: Version
【翻譯自mos文章】當點擊完 finishbutton後，dbca 或者dbua hang住
cat queue class pop trace rom base done automatic 當點擊完 finishbutton後，dbca 或者dbua hang住 來源於： DBCA/DBUA APPEARS TO HANG AFTER CLICKIN
python操作資料庫，實現使用者名稱、密碼登入資料庫，首次登入自行設定密碼，並返回工資表明細。
python操作資料庫，實現使用者名稱、密碼登入資料庫，首次登入自行設定密碼，並返回工資表明細。 1 #!/usr/bin/env python3 2 # -*- coding: utf-8 -*- 3 4 # 匯入依賴包 5 import psycopg2 6 7 print("營
網頁登入資料庫（七）
<%@ page language="java" import="java.sql.*" contentType="text/html;charset=utf-8"%> <html> <head>
網頁註冊登入資料庫（六）
<%@ page language="java" import="java.sql.*" contentType="text/html;charset=utf-8"%> <html> <head>
網頁註冊登入資料庫（五）
<%@ page language="java" import="java.util.*" contentType="text/html;charset=utf-8"%> <html> <head> <title>登陸成功&l
網頁登入資料庫（四）
註冊檢驗 <%@ page language="java" import="java.sql.*" contentType="text/html;charset=utf-8"%> <html> <head> &nb
網頁註冊登入資料庫（二）
註冊頁面 <%@ page language="java" import="java.util.*" contentType="text/html;charset=utf-8"%> <html> <head>
網頁註冊登入資料庫（一）
登入頁面 <%@ page language="java" import="java.util.*" contentType="text/html;charset=utf-8"%> <html> <head> <title>使用者登入<
phpstudy設定遠端登入資料庫
Windows下phpstudy設定允許遠端訪問mysql資料庫1、在phpstudy中選擇mysql命令列 2、輸入Mysql 管理員root 的密碼 , 右擊貼上就可以 3、執行 use mysql 回車 4、然後執行grant all pr
python 64式: 第17式、死鎖或程序hang住除錯方法
步驟1:下載python-debuginfo 如果已經發現有/etc/yum.repos.d/xxx-Debuginfo.repo,就不需要下載 修改 /etc/yum.repos.d/xxx-Debuginfo.repo 將其中的 enabled=0 修改為 enabled=1 步驟2:下載gd
一次匯入hang住的處理記錄--statement suspended
Tue Nov 20 04:37:47 2018 statement in resumable session 'SYS.SYS_IMPORT_SCHEMA_06.1' was suspended due to
oracle故障處理之刪除大表空間hang住
背景 資料庫分割槽表資料越來越大，需要對過期話的資料進行遷移，以及大的分割槽表需要進行資料的清理和刪除，達到釋放磁碟空間的目的。 問題說明 環境：linux 6.X 資料庫：oracle 11.2.0.4 （PSU為2016年6月份的） 問題說明： S_T_RTNRP_STATUS_2017是分割槽表，每
MySQL所有操作hang住了，怎麼破？
作者介紹 王鬆磊，現任職於UCloud，從事MySQL資料庫核心研發工作。主要負責UCloud雲資料庫udb的核心故障排查工作以及資料庫新特性的研發工作。 系統環境 CentOS release 6.7 MySQL社群版MySQL-5.5.24 故障簡述 首先收到故障告警，所有的監控無法讀取到資料。
Selenium 點選button 出現Windows視窗時候Selenium會Hang住！！！
1. 問題描述 使用Selenium webDriver 點選頁面一個按鈕,出現Print windows視窗,這時候 程式會掛住在Click操作上. 解決辦法： 使用執行緒結合AutoItX.jar去關閉windows視窗,這樣Selenium就會繼續執行下面的測試指令碼
厲害！蘇寧通過citus打造分散式資料庫抗住DB高負載
關注“資料和雲”，精彩不容錯過內容來源：2017 年 10 月 20 日，蘇寧雲商IT總部資深技
分析多執行緒併發寫HashMap執行緒被hang住的原因
public class TestLock { private final HashMap map = new HashMap(); public TestLock() { final Thread t1 = new Thread() { @Overri
查詢Oracle資料庫鎖住的表Sql
1，查詢Oracle資料庫鎖住的表Sql select 'alter system kill session ''' || b.session_id || ',' || c.serial# || ''';' killString, &nb