记一次sql执行卡死的问题

这几天一直在进行aix环境下10.2.0.1数据库升级为10.2.0.5的实验

但是在跑数据库脚本的时候总是跑到某一步数据库就没反应了,然后检查数据库等待事件一直显示为空闲等待

日志中报错

Errors in file /u01/app/oracle/admin/test/bdump/test_arc1_23310.trc:

ORA-16038: log 3 sequence# 90 cannot be archived

ORA-19809: limit exceeded for recovery files

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:19:29 CDT 2015

ARCH: Archival stopped, error occurred. Will continue retrying

Sun May 31 20:19:29 CDT 2015

ORACLE Instance test - Archival Error

Sun May 31 20:19:29 CDT 2015

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:19:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc0_26602.trc:

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:24:07 CDT 2015

Shutting down instance (immediate)

Sun May 31 20:24:07 CDT 2015

Shutting down instance: further logons disabled

Sun May 31 20:24:07 CDT 2015

Stopping background process CJQ0

Sun May 31 20:24:07 CDT 2015

Stopping background process MMNL

Sun May 31 20:24:09 CDT 2015

Stopping background process MMON

License high water mark = 2

Sun May 31 20:24:10 CDT 2015

Job queue slave processes stopped

Sun May 31 20:24:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc1_23310.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.

Sun May 31 20:24:29 CDT 2015

************************************************************************

You have following choices to free up space from flash recovery area:

1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,

then consider changing RMAN ARCHIVELOG DELETION POLICY.

2. Back up files to tertiary device such as tape using RMAN

BACKUP RECOVERY AREA command.

3. Add disk space and increase db_recovery_file_dest_size parameter to

reflect the new space.

4. Delete unnecessary files using RMAN DELETE command. If an operating

system command was used to delete files, then use RMAN CROSSCHECK and

DELETE EXPIRED commands.

************************************************************************

ARCH: Archival stopped, error occurred. Will continue retrying

Sun May 31 20:24:29 CDT 2015

ORACLE Instance test - Archival Error

Sun May 31 20:24:29 CDT 2015

ORA-16038: log 3 sequence# 90 cannot be archived

ORA-19809: limit exceeded for recovery files

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:24:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc1_23310.trc:

ORA-16038: log 3 sequence# 90 cannot be archived

ORA-19809: limit exceeded for recovery files

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:25:29 CDT 2015

ARCH: Archival stopped, error occurred. Will continue retrying

Sun May 31 20:25:29 CDT 2015

ORACLE Instance test - Archival Error

Sun May 31 20:25:29 CDT 2015

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:25:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc0_26602.trc:

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:29:09 CDT 2015

Active call for process 23850 user ‘oracle‘ program ‘[email protected] (TNS V1-V3)‘

System State dumped to trace file /u01/app/oracle/admin/test/udump/test_ora_18216.trc

SHUTDOWN: waiting for active calls to complete.

Sun May 31 20:30:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc1_23310.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% us

Sun May 31 20:30:29 CDT 2015

************************************************************************

You have following choices to free up space from flash recovery area:

1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,

then consider changing RMAN ARCHIVELOG DELETION POLICY.

2. Back up files to tertiary device such as tape using RMAN

BACKUP RECOVERY AREA command.

3. Add disk space and increase db_recovery_file_dest_size parameter to

reflect the new space.

4. Delete unnecessary files using RMAN DELETE command. If an operating

system command was used to delete files, then use RMAN CROSSCHECK and

DELETE EXPIRED commands.

************************************************************************

ARCH: Archival stopped, error occurred. Will continue retrying

Sun May 31 20:30:29 CDT 2015

ORACLE Instance test - Archival Error

Sun May 31 20:30:29 CDT 2015

ORA-16038: log 3 sequence# 90 cannot be archived

ORA-19809: limit exceeded for recovery files

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:30:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc1_23310.trc:

ORA-16038: log 3 sequence# 90 cannot be archived

ORA-19809: limit exceeded for recovery files

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:31:29 CDT 2015

ARCH: Archival stopped, error occurred. Will continue retrying

Sun May 31 20:31:29 CDT 2015

ORACLE Instance test - Archival Error

Sun May 31 20:31:29 CDT 2015

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:31:29 CDT 2015

Errors in file /u01/app/oracle/admin/test/bdump/test_arc0_26602.trc:

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

Sun May 31 20:33:47 CDT 2015

sculkget: failed to lock /u01/app/oracle/product/10.2.0/db_1/dbs/lkinsttest exclusive

sculkget: lock held by PID: 18216

Oracle Instance Startup operation failed. Another process may be attempting to startup or shutdown this Instance.

Failed to acquire instance startup/shutdown serialization primitive

Sun May 31 20:33:52 CDT 2015

Instance shutdown cancelled

Sun May 31 20:34:00 CDT 2015

Starting ORACLE instance (normal)

trace中报错

*** 2015-05-31 18:56:48.308 64950 kcrr.c

ARC0: Error 19809 Creating archive log file to ‘/u01/app/oracle/flash_recovery_area/TEST/archivelog/2015_05_31/o1_mf_1_90_%u_.arc‘

*** 2015-05-31 18:56:48.308 63059 kcrr.c

kcrrfail: dest:10 err:19809 force:0 blast:1

*** 2015-05-31 18:56:48.351 22402 kcrr.c

ORA-16038: log 3 sequence# 90 cannot be archived

ORA-19809: limit exceeded for recovery files

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 18:57:29.674

*** 2015-05-31 18:57:29.674 22402 kcrr.c

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 19:03:29.671

*** 2015-05-31 19:03:29.671 22402 kcrr.c

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 19:09:29.680

*** 2015-05-31 19:09:29.680 22402 kcrr.c

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 19:15:29.688

*** 2015-05-31 19:15:29.688 22402 kcrr.c

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 19:21:29.689

*** 2015-05-31 19:21:29.689 22402 kcrr.c

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 19:26:48.410

*** 2015-05-31 19:26:48.410 22402 kcrr.c

ORA-16014: log 3 sequence# 90 not archived, no available destinations

ORA-00312: online log 3 thread 1: ‘/u01/app/oracle/oradata/test/redo03.log‘

*** 2015-05-31 19:31:48.505

ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.

*** 2015-05-31 19:31:48.506

经查找资料确认为db_recover_file_dest_size,大小设置不够,导致日志归档失败,sql无法继续执行

修改参数

SQL> show parameter db_recovery

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

db_recovery_file_dest                string      /u01/app/oracle/flash_recovery

_area

db_recovery_file_dest_size           big integer 2G

SQL> alter system set db_recovery_file_dest_size=10G scope=both;

System altered.

修改成功

修改后sql重新执行,执行通过

时间: 2024-07-30 10:05:08

记一次sql执行卡死的问题的相关文章

in和exists的区别与SQL执行效率

in和exists的区别与SQL执行效率最近很多论坛又开始讨论in和exists的区别与SQL执行效率的问题,本文特整理一些in和exists的区别与SQL执行效率分析 SQL中in可以分为三类: 1.形如select * from t1 where f1 in ('a','b'),应该和以下两种比较效率 select * from t1 where f1='a' or f1='b' 或者 select * from t1 where f1 ='a' union all select * fro

SQL执行过程中的性能负载点

一.SQL执行过程 1.用户连接数据库,执行SQL语句: 2.先在内存进行内存读,找到了所需数据就直接交给用户工作空间: 3.内存读失败,也就说在内存中没找到支持SQL所需数据,就进行物理读,也就是到磁盘中查找: 4.找到的数据放到内存中,在内存进行数据过滤再放到会话工作空间. 5.假设会话工作空间需要暂存结果集进行排序,但空间不足的话,就会借用磁盘tmpdir,最后再将结果返回给用户. 注: 用户会话空间是内存中分配出来的一个工作空间,而innodb_buffer_pool是innodb存储引

RDIFramework.NET ━ .NET快速信息化系统开发框架 V3.2->新增记录SQL执行过程

有时我们需要记录整个系统运行的SQL以作分析,特别是在上线前这对我们做内部测试也非常有帮助,当然记录SQL的方法有很多,也可以使用三方的组件.3.2版本我们在框架底层新增了记录框架运行的所有SQl过程保存到用户指定的地方以便分析查看,只需要在配置文件把配置项"LogSQL"设置为True即可.框架会自动记录各常用数据库如:Oracle.SqlServer.MySQL等的操作情况. 一.Web记录Sql执行情况 1.在我们的Web项目中要记录SQL可以在Web的配置文件中设置LogSql

oracle   SQL执行过程

1.sql执行过程 1>解析(判断对象是否存在,是否有权限查询,语义解析,检查缓存中是否有相同的SQL等等) 2>优化(CBO确定优化模式,确定访问路径,联接顺序,过程中通过很多综合因素估算出各种方式的资源消耗,选择消耗最小为优) 3>生成QEP(Query Execution Plan:查询执行计划) 4>执行QEP,返回结果

SQL监控:mysql及mssql数据库SQL执行过程监控审计

最近生活有很大的一个变动,所以博客也搁置了很长一段时间没写,好像写博客已经成了习惯,搁置一段时间就有那么点危机感,心里总觉得不自在.所以从今天起还是要继续拾起墨笔(键盘),继续好好维护这个博客,写出心里最真实的想法,写出平时接触到的一些人和事以及一些新的技术.当然写博客也不是单纯的为了记录,也想通过博客来结交更多的朋友,今天在公司图书馆看到一句话大致说的是“在今天这个年代,已经很难等到三顾茅庐,诸葛亮也需要博客.微博和影响力”,在一年前就曾想过写一篇关于怎样通过博客来提高个人影响力的文章,我会尽

Oracle SQL执行计划基线总结(SQL Plan Baseline)

一.基础概念 Oracle 11g开始,提供了一种新的固定执行计划的方法,即SQL plan baseline,中文名SQL执行计划基线(简称基线),可以认为是OUTLINE(大纲)或者SQL PROFILE的改进版本,基本上它的主要作用可以归纳为如下两个: 1.稳定给定SQL语句的执行计划,防止执行环境或对象统计信息等等因子的改变对SQL语句的执行计划产生影响! 2.减少数据库中出现SQL语句性能退化的概率,理论上不允许一条语句切换到一个比已经执行过的执行计划慢很多的新的执行计划上! 注意:

【分享】小工具大智慧之Sql执行工具

工具概况 情况是这样的,以前我们公司有很多Sql用于完成一些很不起眼但又不得不完成的业务,出于方便就直接在Sql查询分析器里执行,按理说应该写一些专门的工具的,但是这些脚本很多,于是我就写了这样一个小工具,只要Sql可以解决的问题就能用到它了,那么它有什么优点呢 一.以前写好的Sql可以不用怎么更改,只需要将参数部分提取出来按照定好的规范改成一个模版即可,使用工具加载模版时,工具会自动将模块要求的参数提供给用户填写. 二.模版文件里可以配置好连接字符串,这样不用每次都连接数据库,也避免连接错误的

Mysql体系结构及sql执行过程总结

Mysql体系结构及sql执行过程总结 一.体系结构图 各模块说明: 1.Connectors:各应用程序与SQL的交互 2. Management Serveices & Utilities:系统管理和控制工具 3.Connection Pool:连接池 管理缓冲用户连接,线程处理等需要缓存的需求 4.SQL Interfaces:SQL接口 接受用户的SQL命令,并且返回用户需要查询的结果.例如select from就是调用SQL Interface 5.Parser:解析器 (1)将SQL

SQL执行过程

一般来说,数据库处理SQL都会经过三个过程:分析.执行.返回结果,比如COGNOS ReportNet通过拖放式完成表现层后,还是会自动生成SQL,然后将SQL传递到ORACLE进行处理. 1.分析 分析是处理SQL语句的第一步,它是SQL语句处理过程较为重要的一步,它又包含几个方面: (1)语法分析,oracel是采用数据库常用的自底向上的分析方法,包含检查语法规范,命名规范,它是处理SQL语句中最消耗时间且代价最高的步骤,主要表现在绑定变量和存储过程等方面: A.绑定变量:这也是为什么使用在