数据库报错 ORA

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库报错 ORA相关的知识,希望对你有一定的参考价值。

Thu Feb 25 06:00:10 2010Thread 1 advanced to log sequence 3518 Current log# 1 seq# 3518 mem# 0: /oradata/jtgmis/redo/redo01.logThu Feb 25 11:35:56 2010Thread 1 advanced to log sequence 3519 Current log# 2 seq# 3519 mem# 0: /oradata/jtgmis/redo/redo02.logThu Feb 25 13:10:07 2010ORA-1652: unable to extend temp segment by 256 in tablespace JTGTEMPSPACE Thu Feb 25 13:10:07 2010Errors in file /oracle/admin/jtgmis/udump/jtgmis_ora_2629802.trc:ORA-07445: 出现异常错误: 核心转储 [] [] [] [] [] []ORA-33272: 无法打开分析工作空间 ExpTemp。ORA-01652: 无法通过 256 (在表空间 JTGTEMPSPACE 中) 扩展 temp 段

参考技术A 1. ORA-1652, 无法扩展表空间, 即表空间满了
1.1 一般表空间出现这种错要增加数据文件或者手工扩展数据文件
1.2 TEMP表空间为系统表空间, 用于临时排序等, 检查下如果太小(比如<1G),建议增加, 具体比例可参考页面文件与内存的大小关系
1.3 如果TEMP表空间大小也足够, 比如服务器4G内存,TEMP表空间已经设置了8G
还报这种错, 不排除有比较垃圾的SQL, 少写了条件, 在数据量少的时候发现不了错误, 但一但数据量大了后, 将占用大量资源, 可以通过PERFSTAT跟踪分析一下
2. ORA-07445 错误, 检查派生的TRACE文件: jtgmis_ora_2629802.trc
参考技术B unable to extend temp segment by 256 in tablespace JTGTEMPSPACE

表空间满了,检查一下?

oracle数据库报错ORA-27300 ORA-27301等错误

oracle数据库日志报错ORA-27300 ORA-27301 ORA-27302 ORA-27157处理记录:

1、事件的原因排查

应用连接数据库失败,先连接数据库服务器,启动数据库服务恢复应用业务,然后排查数据库crush原因:
1)查看messages日志是否有与Oracle用户相关的出错信息

# cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core)
# cat /var/log/messages |grep failed

2)查看用户邮件日志是否有与Oracle用户相关的出错信息

# tail -n 200 /var/mail/oracle

3)检查跟踪日志文件

SQL> select value from v$diag_info where name =‘Diag Trace‘;
VALUE
--------------------------------
/app/oracle/diag/rdbms/crm/crm/trace

$ cat /app/oracle/diag/rdbms/crm/crm/trace/alert_crm.log |grep ORA-
$ cat /app/oracle/diag/rdbms/crm/crm/trace/alert_crm.log |grep err
$ cat /app/oracle/diag/rdbms/crm/crm/trace/alert_crm.log |grep fail 

SQL> select name,value from v$diag_info;
NAME              VALUE
--------------------------------
Diag Enabled    TRUE
ADR Base    /app/oracle/
ADR Home    /app/oracle/diag/rdbms/crm/crm
Diag Trace  /app/oracle/diag/rdbms/crm/crm/trace
Diag Alert  /app/oracle/diag/rdbms/crm/crm/alert
Diag Incident   /app/oracle/diag/rdbms/crm/crm/incident
Diag Cdump  /app/oracle/diag/rdbms/crm/crm/cdump
Health Monitor  /app/oracle/diag/rdbms/crm/crm/hm
Default Trace File  /app/oracle/diag/rdbms/crm/crm/trace/crm_ora_10974.trc
Active Problem Count    1
Active Incident Count   1

查看log.xml搜索问题出现时间点

$ less /app/oracle/diag/rdbms/crm/crm/alert/log.xml
Errors in file /app/oracle/diag/rdbms/crm/crm/trace/crm_dbw2_80900.trc:
ORA-27157: OS post/wait facility removed
ORA-27300: OS system dependent operation:semop failed with status: 43
ORA-27301: OS failure message: Identifier removed
ORA-27302: failure occurred at: sskgpwwait1
Errors in file /app/oracle/diag/rdbms/crm/crm/trace/crm_dbw3_80902.trc:
ORA-27157: OS post/wait facility removed
ORA-27300: OS system dependent operation:semop failed with status: 43
ORA-27301: OS failure message: Identifier removed
ORA-27302: failure occurred at: sskgpwwait1

2、事件的解决处理

This could be due to some outside user or application removing the semaphores/shared memory. 
To monitor the semaphore/shared memory state we can use the following methods:

Setup a cronjob to run every 5-10min and dump the output of ‘ipcs‘ and ‘ps - ef‘ to a file with a timestamp. 
Rotate your logs every 4-7 days to build a history. 
Then if the problem re-occurs, we can at least try to make sure ‘ipcrm‘ wasn‘t the culprit and get some general information of the state of the IPC resources plus the processes running.

You can also consult with your sysadmin to check if there is any OS level auditing that can be turned on to audit the usage of commands like ‘ipcrm‘ which can remove shared memory segments /semaphore sets.

Note: This issue can happen on different platform, but in case you encounter the issue in RHEL7.2, then please also check below RHEL7.2 specific information.

In  RHEL7.2 operating system setting RemoveIPC=YES crashes the database.The default value for RemoveIPC in RHEL7.2 is YES.

         Workaround :

      1) Set RemoveIPC=no in /etc/systemd/logind.conf if it is not in that file

      2) Reboot the server or restart systemd-logind as follows:
       # systemctl daemon-reload
       # systemctl restart systemd-logind

Centos7.2有个特性,默认该配置是为yes

技术图片

# vim /etc/systemd/logind.conf
RemoveIPC=no
# systemctl daemon-reload
# systemctl restart systemd-logind

以上是关于数据库报错 ORA的主要内容,如果未能解决你的问题,请参考以下文章

SQL中,使用NVL函数,报错:ora-01722:无效数字

数据库报错 ORA

数据泵导出报错ORA-31693 ORA-02354 ORA-01466

导入数据报错:ORA-39083、ORA-02195

Oracle 数据库 IMPDP 导入报错, ORA-39083 ORA-04052 ORA-12154 求解决方案

oracle数据库sys用户登录报错ora-00119,ora-00132后问题分析及解决