- 浏览: 960813 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
孤星119:
好熟悉的数据库字段啊, 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace:
quxiaoyong 写道遇到个问题,网上一搜,全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong:
遇到个问题,网上一搜,全他妈这篇文章。你转来转去的有意思吗?
数据库连接错误ORA-28547 -
hctech:
关于version count过高的问题,不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace:
invalid 写道写的不错,我根据这个来安装,有点理解错误了 ...
AIX 配置vncserver
由于数据库上线过程中出现大量的RESMGR:cpu quantum等待事件,出现性能问题,关闭了resource manager功能,关闭过程如下:
ALTER SYSTEM SET “_resource_manager_always_on”=FALSE SCOPE=SPFILE SID='*';
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
#4 重启数据库使生效
重启后,resource manager 关闭,数据库不在出现RESMGR:cpu quantum等待事件。
但是数据库自动任务计划调度开始报错,后台报错如下:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SQ_SQL_SW_186"
ORA-29373: resource manager is not on
视图检查报错:
SQL> select client_name,window_name,job_name,job_status,job_start_time from dba_autotask_job_history ;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
-------------------- -------------------- ------------------------------ ------------------------------ ----------------------------------------
auto optimizer stats WEDNESDAY_WINDOW ORA$AT_OS_OPT_SY_102 FAILED 09-APR-14 10.00.01.582006 PM PRC
collection
auto optimizer stats FRIDAY_WINDOW ORA$AT_OS_OPT_SY_105 FAILED 11-APR-14 10.00.06.999466 PM PRC
collection
auto optimizer stats TUESDAY_WINDOW ORA$AT_OS_OPT_SY_99 FAILED 08-APR-14 10.00.07.885416 PM PRC
collection
三 前期故障排查
为了确认故障原因,我们对该报错进行打开29373 errorstack,收集了报错中的详细跟踪日志:
后台alert报错如下:
Sun May 04 06:00:04 2014
Dumping diagnostic data in directory=[cdmp_20140504060004], requested by (instance=1, osid=55167 (J001)), summary=[abnormal process termination].
Errors in file /oracle/database/diag/rdbms/nfdb/nfdb1/trace/nfdb1_j001_55167.trc:
ORA-29373: resource manager is not on
Errors in file /oracle/database/diag/rdbms/nfdb/nfdb1/trace/nfdb1_j001_55167.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY_271"
ORA-29373: resource manager is not on
Dumping diagnostic data in directory=[cdmp_20140504060009], requested by (instance=1, osid=55167 (J001)), summary=[abnormal process termination].
详细的trace跟踪报告如下:
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-29373: resource manager is not on
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
从trace文件中我们也只能确认是因为resource manager造成JOB无法调度
不过在检测中我们发现,管理resource manager的进程DBRM依旧在数据库中存在,
#ps –ef | grep dbrm
oracle 34920 1 0 Apr18 ? 00:00:59 ora_dbrm_nfdb1
这从一定程度上给予我们一定的怀疑方向,可能存在resource并没有完全关闭,而且从详细的trace文件中的从call stack trace里来看, 当前进程也没有没有关于resource manager的函数调用,而是一直在向另外一个进程post message。
所以,我们怀疑错误很有可能是由于DBRM没有正常关闭造成。
现对以上分析结果进行判断,获取可能依据
四 故障模拟
故障模拟一共分为如下几个部分:
步骤 操作 结果
Step1 和故障操作一样,设置“_resource_manager_always_on隐含参数,关闭resource manager windows 调用计划 后台报错
Step2 删除隐含参数,只设置resource manager windows 调用计划关闭 后台不报错
Step3 添加2个隐含参数,关闭resource manager windows 调用计划 后台不报错
详细测试过程如下:
测试我们采用将数据库时间设置到22点,让其自动调度JOB计划
4.1 模拟管理库故障环境
关闭数据库,调整时间,设置隐含参数,关闭windows 计划
关闭数据库:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
调整时间:
[root@rhel6 ~]# date -s 2014/05/14
[root@rhel6 ~]# date -s 21:57:00
[root@rhel6 ~]# clock -w
[root@rhel6 ~]# date
Wed May 14 21:57:35 CST 2014
添加隐含参数,启动至open:
SQL> ALTER SYSTEM SET "_resource_manager_always_on"=FALSE SCOPE=SPFILE;
SQL> startup force(测试环境,直接force启动,生产环境勿如此操作)
设置resource manager plan:
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
我们观察22点的alert信息,确实开始报错:
Wed May 14 22:00:03 2014
Errors in file /oracle/ora11g/base/diag/rdbms/ora11g/ora11g/trace/ora11g_j003_4452.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY_27"
ORA-29373: resource manager is not on
Wed May 14 22:00:03 2014
Errors in file /oracle/ora11g/base/diag/rdbms/ora11g/ora11g/trace/ora11g_j004_4454.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SA_SPC_SY_28"
ORA-29373: resource manager is not on
Wed May 14 22:00:03 2014
Errors in file /oracle/ora11g/base/diag/rdbms/ora11g/ora11g/trace/ora11g_j005_4456.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SQ_SQL_SW_29"
ORA-29373: resource manager is not on
Wed May 14 22:00:04 2014
XDB installed.
XDB initialized.
检查DBRM进程已经存在:
[root@rhel6 ~]# ps -ef | grep dbrm
ora11g 4346 1 0 21:57 ? 00:00:00 ora_dbrm_ora11g
检查后台JOB执行记录视图:
SQL> select CLIENT_NAME,WINDOW_NAME,JOB_NAME,JOB_STATUS,JOB_START_TIME from DBA_AUTOTASK_JOB_HISTORY where CLIENT_NAME='auto optimizer stats collection' order by JOB_START_TIME desc;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
----------------------------------- ------------------------------ ------------------------------ ------------------------------ ----------------------------------------
auto optimizer stats collection WEDNESDAY_WINDOW ORA$AT_OS_OPT_SY_27 FAILED 14-MAY-14 10.00.03.233570 PM PRC
模拟过程与生产管理库一致,结果也一致,DBRM进程已经存在。
4.2 模拟去除隐含参数
关闭数据库,调整时间,去除隐含参数,关闭windows 计划
关闭数据库:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
调整时间:
[root@rhel6 ~]# date -s 2014/05/14
[root@rhel6 ~]# date -s 21:57:00
[root@rhel6 ~]# clock -w
[root@rhel6 ~]# date
Wed May 14 21:57:35 CST 2014
去除隐含参数,启动至open:
隐含参数去除采用create pfile from spfile;
删除spfile,编辑pfile文件,删除隐含参数,以pfile启动数据库
设置resource manager plan:(由于前面已经设置过,无需再设置)
我们观察22点的alert信息,发现没有报错
Tue May 13 22:00:03 2014
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Tue May 13 22:00:05 2014
XDB installed.
XDB initialized.
检查 DBRM进程:
[root@rhel6 ~]# ps -ef | grep dbrm
ora11g 3844 1 0 21:55 ? 00:00:00 ora_dbrm_ora11g
说明:此时resource manager由于只是关闭了resource manager plan计划,没有真正关闭resource manager 因此该进程依旧存在。
检查后台JOB执行视图信息:
SQL> select CLIENT_NAME,WINDOW_NAME,JOB_NAME,JOB_STATUS,JOB_START_TIME from DBA_AUTOTASK_JOB_HISTORY where CLIENT_NAME='auto optimizer stats collection' order by JOB_START_TIME desc;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
---------------------------------------- ------------------------------ ------------------------- -------------------- ----------------------------------------
auto optimizer stats collection TUESDAY_WINDOW ORA$AT_OS_OPT_SY_24 SUCCEEDED 13-MAY-14 10.00.02.102741 PM PRC
说明在隐含参数除掉的情况下,JOB可以正常执行,后台没有报错。
4.3 模拟隐含参数及resource manager plan均存在的情况
关闭数据库,调整时间,添加隐含参数,关闭windows 计划
关闭数据库:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
调整时间:
[root@rhel6 ~]# date -s 2014/05/15
[root@rhel6 ~]# date -s 21:57:00
[root@rhel6 ~]# clock -w
[root@rhel6 ~]# date
Thu May 15 21:57:35 CST 2014
添加隐含参数,启动至open:
SQL> alter system set "_resource_manager_always_off"=true scope=spfile;
SQL> ALTER SYSTEM SET "_resource_manager_always_on"=FALSE SCOPE=SPFILE;
SQL> startup force(测试环境,直接force启动,生产环境勿如此操作)
设置resource manager plan:(由于前面已经设置过,无需再设置)
我们观察22点的alert信息,发现没有报错
Thu May 15 22:00:03 2014
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Thu May 15 22:00:05 2014
XDB installed.
XDB initialized.
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
检查 DBRM进程:
[root@rhel6 ~]# ps -ef | grep dbrm
root 4650 3647 0 21:58 pts/2 00:00:00 grep dbrm
说明:此时DBRM进程消失
检查后台JOB执行视图信息:
SQL> select CLIENT_NAME,WINDOW_NAME,JOB_NAME,JOB_STATUS,JOB_START_TIME from DBA_AUTOTASK_JOB_HISTORY where CLIENT_NAME='auto optimizer stats collection' order by JOB_START_TIME desc;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
----------------------------------- ------------------------------ ------------------------------ ------------------------------ ----------------------------------------
auto optimizer stats collection THURSDAY_WINDOW ORA$AT_OS_OPT_SY_30 SUCCEEDED 15-MAY-14 10.00.02.115232 PM PRC
说明在隐含参数两个都添加的情况下,完全屏蔽resource manager的的情况下,JOB可以正常执行,后台没有报错。
五 总结说明
以上测试结果证明,后台报错JOB执行失败原因应该是DBRM进程依旧活动,而DBRM进程是管理RESOURCE manager 当去除"_resource_manager_always_off"=true及"_resource_manager_always_on"=FALSE
或者将两个参数全部添加,均可避免该错误,统计信息自动收集也可以自动执行
由于管理数据库相对重要,且上线时候出现过严重的RESMGR:cpu quantum等待事件,建议不要移除隐含参数,而是添加"_resource_manager_always_off"=true隐含参数,重启数据库
当然,可以先在另外两套库上进行确认,再在管理库上进行操作
ALTER SYSTEM SET “_resource_manager_always_on”=FALSE SCOPE=SPFILE SID='*';
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
#4 重启数据库使生效
重启后,resource manager 关闭,数据库不在出现RESMGR:cpu quantum等待事件。
但是数据库自动任务计划调度开始报错,后台报错如下:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SQ_SQL_SW_186"
ORA-29373: resource manager is not on
视图检查报错:
SQL> select client_name,window_name,job_name,job_status,job_start_time from dba_autotask_job_history ;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
-------------------- -------------------- ------------------------------ ------------------------------ ----------------------------------------
auto optimizer stats WEDNESDAY_WINDOW ORA$AT_OS_OPT_SY_102 FAILED 09-APR-14 10.00.01.582006 PM PRC
collection
auto optimizer stats FRIDAY_WINDOW ORA$AT_OS_OPT_SY_105 FAILED 11-APR-14 10.00.06.999466 PM PRC
collection
auto optimizer stats TUESDAY_WINDOW ORA$AT_OS_OPT_SY_99 FAILED 08-APR-14 10.00.07.885416 PM PRC
collection
三 前期故障排查
为了确认故障原因,我们对该报错进行打开29373 errorstack,收集了报错中的详细跟踪日志:
后台alert报错如下:
Sun May 04 06:00:04 2014
Dumping diagnostic data in directory=[cdmp_20140504060004], requested by (instance=1, osid=55167 (J001)), summary=[abnormal process termination].
Errors in file /oracle/database/diag/rdbms/nfdb/nfdb1/trace/nfdb1_j001_55167.trc:
ORA-29373: resource manager is not on
Errors in file /oracle/database/diag/rdbms/nfdb/nfdb1/trace/nfdb1_j001_55167.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY_271"
ORA-29373: resource manager is not on
Dumping diagnostic data in directory=[cdmp_20140504060009], requested by (instance=1, osid=55167 (J001)), summary=[abnormal process termination].
详细的trace跟踪报告如下:
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-29373: resource manager is not on
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
从trace文件中我们也只能确认是因为resource manager造成JOB无法调度
不过在检测中我们发现,管理resource manager的进程DBRM依旧在数据库中存在,
#ps –ef | grep dbrm
oracle 34920 1 0 Apr18 ? 00:00:59 ora_dbrm_nfdb1
这从一定程度上给予我们一定的怀疑方向,可能存在resource并没有完全关闭,而且从详细的trace文件中的从call stack trace里来看, 当前进程也没有没有关于resource manager的函数调用,而是一直在向另外一个进程post message。
所以,我们怀疑错误很有可能是由于DBRM没有正常关闭造成。
现对以上分析结果进行判断,获取可能依据
四 故障模拟
故障模拟一共分为如下几个部分:
步骤 操作 结果
Step1 和故障操作一样,设置“_resource_manager_always_on隐含参数,关闭resource manager windows 调用计划 后台报错
Step2 删除隐含参数,只设置resource manager windows 调用计划关闭 后台不报错
Step3 添加2个隐含参数,关闭resource manager windows 调用计划 后台不报错
详细测试过程如下:
测试我们采用将数据库时间设置到22点,让其自动调度JOB计划
4.1 模拟管理库故障环境
关闭数据库,调整时间,设置隐含参数,关闭windows 计划
关闭数据库:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
调整时间:
[root@rhel6 ~]# date -s 2014/05/14
[root@rhel6 ~]# date -s 21:57:00
[root@rhel6 ~]# clock -w
[root@rhel6 ~]# date
Wed May 14 21:57:35 CST 2014
添加隐含参数,启动至open:
SQL> ALTER SYSTEM SET "_resource_manager_always_on"=FALSE SCOPE=SPFILE;
SQL> startup force(测试环境,直接force启动,生产环境勿如此操作)
设置resource manager plan:
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
我们观察22点的alert信息,确实开始报错:
Wed May 14 22:00:03 2014
Errors in file /oracle/ora11g/base/diag/rdbms/ora11g/ora11g/trace/ora11g_j003_4452.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY_27"
ORA-29373: resource manager is not on
Wed May 14 22:00:03 2014
Errors in file /oracle/ora11g/base/diag/rdbms/ora11g/ora11g/trace/ora11g_j004_4454.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SA_SPC_SY_28"
ORA-29373: resource manager is not on
Wed May 14 22:00:03 2014
Errors in file /oracle/ora11g/base/diag/rdbms/ora11g/ora11g/trace/ora11g_j005_4456.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SQ_SQL_SW_29"
ORA-29373: resource manager is not on
Wed May 14 22:00:04 2014
XDB installed.
XDB initialized.
检查DBRM进程已经存在:
[root@rhel6 ~]# ps -ef | grep dbrm
ora11g 4346 1 0 21:57 ? 00:00:00 ora_dbrm_ora11g
检查后台JOB执行记录视图:
SQL> select CLIENT_NAME,WINDOW_NAME,JOB_NAME,JOB_STATUS,JOB_START_TIME from DBA_AUTOTASK_JOB_HISTORY where CLIENT_NAME='auto optimizer stats collection' order by JOB_START_TIME desc;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
----------------------------------- ------------------------------ ------------------------------ ------------------------------ ----------------------------------------
auto optimizer stats collection WEDNESDAY_WINDOW ORA$AT_OS_OPT_SY_27 FAILED 14-MAY-14 10.00.03.233570 PM PRC
模拟过程与生产管理库一致,结果也一致,DBRM进程已经存在。
4.2 模拟去除隐含参数
关闭数据库,调整时间,去除隐含参数,关闭windows 计划
关闭数据库:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
调整时间:
[root@rhel6 ~]# date -s 2014/05/14
[root@rhel6 ~]# date -s 21:57:00
[root@rhel6 ~]# clock -w
[root@rhel6 ~]# date
Wed May 14 21:57:35 CST 2014
去除隐含参数,启动至open:
隐含参数去除采用create pfile from spfile;
删除spfile,编辑pfile文件,删除隐含参数,以pfile启动数据库
设置resource manager plan:(由于前面已经设置过,无需再设置)
我们观察22点的alert信息,发现没有报错
Tue May 13 22:00:03 2014
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Tue May 13 22:00:05 2014
XDB installed.
XDB initialized.
检查 DBRM进程:
[root@rhel6 ~]# ps -ef | grep dbrm
ora11g 3844 1 0 21:55 ? 00:00:00 ora_dbrm_ora11g
说明:此时resource manager由于只是关闭了resource manager plan计划,没有真正关闭resource manager 因此该进程依旧存在。
检查后台JOB执行视图信息:
SQL> select CLIENT_NAME,WINDOW_NAME,JOB_NAME,JOB_STATUS,JOB_START_TIME from DBA_AUTOTASK_JOB_HISTORY where CLIENT_NAME='auto optimizer stats collection' order by JOB_START_TIME desc;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
---------------------------------------- ------------------------------ ------------------------- -------------------- ----------------------------------------
auto optimizer stats collection TUESDAY_WINDOW ORA$AT_OS_OPT_SY_24 SUCCEEDED 13-MAY-14 10.00.02.102741 PM PRC
说明在隐含参数除掉的情况下,JOB可以正常执行,后台没有报错。
4.3 模拟隐含参数及resource manager plan均存在的情况
关闭数据库,调整时间,添加隐含参数,关闭windows 计划
关闭数据库:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
调整时间:
[root@rhel6 ~]# date -s 2014/05/15
[root@rhel6 ~]# date -s 21:57:00
[root@rhel6 ~]# clock -w
[root@rhel6 ~]# date
Thu May 15 21:57:35 CST 2014
添加隐含参数,启动至open:
SQL> alter system set "_resource_manager_always_off"=true scope=spfile;
SQL> ALTER SYSTEM SET "_resource_manager_always_on"=FALSE SCOPE=SPFILE;
SQL> startup force(测试环境,直接force启动,生产环境勿如此操作)
设置resource manager plan:(由于前面已经设置过,无需再设置)
我们观察22点的alert信息,发现没有报错
Thu May 15 22:00:03 2014
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Thu May 15 22:00:05 2014
XDB installed.
XDB initialized.
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
检查 DBRM进程:
[root@rhel6 ~]# ps -ef | grep dbrm
root 4650 3647 0 21:58 pts/2 00:00:00 grep dbrm
说明:此时DBRM进程消失
检查后台JOB执行视图信息:
SQL> select CLIENT_NAME,WINDOW_NAME,JOB_NAME,JOB_STATUS,JOB_START_TIME from DBA_AUTOTASK_JOB_HISTORY where CLIENT_NAME='auto optimizer stats collection' order by JOB_START_TIME desc;
CLIENT_NAME WINDOW_NAME JOB_NAME JOB_STATUS JOB_START_TIME
----------------------------------- ------------------------------ ------------------------------ ------------------------------ ----------------------------------------
auto optimizer stats collection THURSDAY_WINDOW ORA$AT_OS_OPT_SY_30 SUCCEEDED 15-MAY-14 10.00.02.115232 PM PRC
说明在隐含参数两个都添加的情况下,完全屏蔽resource manager的的情况下,JOB可以正常执行,后台没有报错。
五 总结说明
以上测试结果证明,后台报错JOB执行失败原因应该是DBRM进程依旧活动,而DBRM进程是管理RESOURCE manager 当去除"_resource_manager_always_off"=true及"_resource_manager_always_on"=FALSE
或者将两个参数全部添加,均可避免该错误,统计信息自动收集也可以自动执行
由于管理数据库相对重要,且上线时候出现过严重的RESMGR:cpu quantum等待事件,建议不要移除隐含参数,而是添加"_resource_manager_always_off"=true隐含参数,重启数据库
当然,可以先在另外两套库上进行确认,再在管理库上进行操作
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 521BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 441Oracle管理云服务(OMC)的大数据平台,自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 4242019年7月22日,受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 787某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1366性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 478从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 1927数据库的启动是一个相当复杂的过程。比如,Oracle在启动之前 ... -
怎么样彻底删除数据库?
2018-09-18 11:10 556Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 816LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1198“一朝被蛇咬,十年怕井绳”。在没被“蛇”咬之前,很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1092在DTCC 2018发表《如何落地智能化运维》演讲,主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 534问题一:ping不通问题 在虚拟机上安装好linux系统后, ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 896即日起,不定期更新《OracleDBA实战攻略》一书电子版,请 ... -
Oracle 12c新特性
2018-05-11 10:33 859查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3930操作系统:RHEL6.5 数据库版本:11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 63511g rac安装在二节点跑脚本一般会报此错误: 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 760故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
谈谈log file sync
2014-03-19 14:18 1680数据库中的log file sync等待事件指的是,当user ... -
谈谈buffer cache的优化思路
2014-03-05 11:22 1655BUFFER CACHE作为数据块缓冲区,不是一块简单的内存区 ...
相关推荐
c-resmgr ##项目说明本系统预测对数据库数据表资源进行管理,通过一系列的配置信息,可以根据配置生成资源表的增删改查的页面。 ###技术栈 vuejs + elementUI + thinkjs + mysql ##目录说明s-resmgr服务端目录 ...
每个子目录core 、 resmgr和product-base都有一个 makefile,用于构建zenoss/product-base镜像zenoss/product-base镜像必须首先构建。 该镜像包含和运行 Zenoss 所需的所有第三方服务(Zope、RabbitMQ、redis 等)...
课设毕设基于SSM的毕业生就业信息管理系统--LW+PPT+源码可运行
发了《STM32设置闹钟中断》一文后,大家都要问我要源码,其实我也找不到,当初也只是做设计时的一部分,根本没留单独的源代码,今天按博文特意重新整理了一下,有需要的自己下载吧。
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。
python爱心代码高级 python非常炫酷的跳动爱心代码 python非常炫酷的跳动爱心代码 python非常炫酷的跳动爱心代码 python非常炫酷的跳动爱心代码 python非常炫酷的跳动爱心代码
123pan_2.0.5
NOSQL-课程复习资料
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。
python爱心代码高级
开发语言:java 框架:springboot,vue JDK版本:JDK1.8 数据库:mysql5.7+(推荐5.7,8.0也可以) 数据库工具:Navicat11+ 开发软件:idea/eclipse(推荐idea)
ClaudiaIDE
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。
基于JavaScript+html+css开发的泊车系统+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用~ 基于JavaScript+html+css开发的泊车系统+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用~ 基于JavaScript+html+css开发的泊车系统+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用~ 基于JavaScript+html+css开发的泊车系统+源码,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用~
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。
1. 发送文件到OpenHarmony: hdc file send minicom /data hdc shell chmod +x /data/minicom hdc shell mkdir -p /data/terminfo/v/ hdc file send vt100 /data/terminfo/v/ 2. 进入串口之后,执行以下命令运行minicom setenforce 0 export TERMINFO=/data/terminfo export TERM=vt100 /data/minicom -D /dev/ttyS9 3. minicom的操作方式,跟在linux系统下一模一样。 备注:这个工具在hdc shell连接终端下使用不友好,只能看到进入的界面,其他的操作都看不到。
Optimizer-16.4
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。
Node.js,简称Node,是一个开源且跨平台的JavaScript运行时环境,它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立,旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎,可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型,这使得它非常适合处理大量并发连接,从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外,Node.js使用了模块化的架构,通过npm(Node package manager,Node包管理器),社区成员可以共享和复用代码,极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展,它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等,因此,开发者可以用JavaScript编写全栈应用程序,这一点大大提高了开发效率和便捷性。 在实践中,许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台,如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能,简化了开发流程,并且能更快地响应市场需求。