精华内容
下载资源
问答
  • oracle数据库宕机原因之一,三个redo.log日志误删导致。 三个redo.log日志被删,数据库无法启动。 解决步骤: 1、sqlplus /nolog 无日志登录 2、conn /as sysdba 进入到sql命令下 3、startup mount ; ...
    oracle数据库宕机原因之一,三个redo.log日志误删导致。
    
             三个redo.log日志被删,数据库无法启动。
             解决步骤:
             1、sqlplus /nolog
                  无日志登录
             2、conn /as sysdba
                   进入到sql命令下
             3、startup mount ;
                  启动数据库到挂载模式下
             4、alter  database  open ;
                  尝试打开数据库,注意报错信息。
                  一般会报错如下(为英文)。
                  ora-00313:无法打开日志组1(线程1)的成员
                  ora-00312:联机日志1线程1:‘../REDO01.LOG’。
                  可以确定是REDO01.LOG日志被误删了,导致缺失。 
             3、select group#,sequence#,archived,status from v$log;
                   查看重组日志组成员和个数状态信息。
             4、alter database clear logfile group 1;
                   清除任务组1的日志文件
             5、alter database open
                   再次尝试打开数据库
                   依旧报错。
                    ora-00313:无法打开日志组2(线程1 )的成员                ora-00312:联机日志1线程1:‘../REDO0 2.LOG ’。
                  可以确定是REDO02.LOG日志也被误删了,导致缺失。
             6、  alter database clear logfile group 2;
                   清除任务组2的日志文件
             7、  alter database open
                   再次尝试打开数据库
                   依旧报错。
                    ora-00313:无法打开日志组3(线程1 )的成员
                    ora-00312:联机日志3线程1:‘../REDO0 3.LOG ’。
                   可以确定是REDO03.LOG日志也被误删了,导致缺失。
             8、  alter database clear logfile group 3;
                    清除任务组3的日志文件。但此时报错!
                   ora-01624:日志3需要恢复
                   ora-00312:联机日志3线程1:‘../REDO03.LOG’。
                   这是因为日志3正是当前数据库使用的重做日志,无法直接清除。
             9、recover database until cancel;
                   恢复数据库
            10、auto
                     第一选择自动,通过归档日志恢复。
                     但若没开启归档日志,则会报错。
                     ora-00308:不能打开archive.log日志
                     ora-27037:无法获取文件状态
            11、recover database until cancel;
                     二次尝试恢复数据库
            12、cancel
                    这次选择cancel
            13、alter databse open;
                    再次打开数据库,一般都会成功,但仍有数据库会失败(我解决时就是后者,失败了) 
                    失败,请继续执行步骤14。
            14、alter database open resetlogs;
                     ora-01194:文件1需要更多的恢复。
                     ora-01110:data file '../undo01.dbf'
            15、shutdown immediate;
                      先关闭数据库。
            16、在pfile加入隐藏参数
                       *_allow_resetlogs_corruption=TRUE
            17、startup mount pfile='../xxx.ora';
                       启动到mount下
            18、alter databse open ;
                      再次尝试打开,失败!
                      ora-00600: [13013] [5001] [267]
                      这意味着警告日志也有报错。
            19、show parameter undo;
                      查看重做表空间
            20、drop system undotbs01 including contents and datafiles
                      尝试删除undo表空间。
                      失败,提示需要打开数据库才能删除。
            21、shutdown immediate
                       关闭数据库
            22、新建一个pfile1文件,将其中的undo_management=Manual
                      将自动管理重做关闭
            23、startup mount  pfile='../pfile1';
                       启动到挂载模式
            24、alter database open;
                       打开数据库。
            25、show parameter undo;
                       再次查看undo表空间
            26、create UNDO tablespace UNDOTBS datafile '../undotbs01.dbf' size 5120m;
                       创建新的undo表空间
            27、drop tablespce undotbs1 including contents and datafiles;
                       删除旧的undo表空间
            28、alter system set undo_tablespace='UNDOTBS'
                      将undo参数配置改为新的UNDOTBS
            29、shutdown immediate;
                      关闭数据库
            30、startup;
                      重启解决!
    展开全文
  • 应用无法访问,报错无法获取数据库连接,应用宕机数据库报错同期有报错,超过最大连接及异常被kill。 Mon Nov 23 00:06:23 2020 ORA-00020: maximum number of processes (4000) exceeded ORA-20 errors...

    如何完整处理一个故障,聊聊我的思路。
    技术人人都可以磨炼,但处理问题的思路和角度各有不同,希望这篇文章可以抛砖引玉。

    以一个例子为切入点



    一、故障现象

    • 应用无法访问,报错无法获取数据库连接,应用宕机。

    • 数据库报错同期有报错,超过最大连接及异常被kill。

    Mon Nov 23 00:06:23 2020
    ORA-00020: maximum number of processes (4000) exceeded
    ORA-20 errors will not be written to the alert log forthe next minute. Please look at trace files to see all the ORA-20 errors.
    Mon Nov 23 00:06:54 2020
    ........
    Current time = 520601892, process death time = 520541771 interval = 60000 Called from location UNKNOWN:UNKNOWN
    Attempting to kill process 0x0xa394305a8 with OS pid = 16729OSD kill succeeded for process 0xa394305a8
    Instance Critical Process (pid: 9, ospid: 16729, DBRM) died unexpectedly
    PMON (ospid: 16372): terminating the instance due to error 56710



    二、故障说明

    • 通过宕机前DB 监控agent 采集的实例运行数据,定位异常开始具

      体时间,从关键指标的趋势变化和历史监控数据,关联到OS 的内

      存瓶颈,结合数据库和操作系统的监控数据,判断出故障链:应用

      宕机是因为获取不到数据库连接(数据库宕机),数据库宕机是因

      为OS 内存耗尽,OS 内存耗尽是因为应用发起了大量连接,应用

      大量连接创建,是因为应用的连接复用出现异常。

       

    • 这是数据库实例监控数据,OS 监控数据二者结合在一起,用实际

      监控数据来验证我们的推断,排除掉其它干扰因素,定位数据库

      宕机的根本原因,帮助其他同事快速修复。



    三、故障原因


    先总结一下DB端排查的原因:

    • 应用端创建大量的连接,数据库OS 内存逐渐耗尽并出现swap 使用,最终整个os 系统hang 住,数据库DBRM 进程检测到Heavy swapping observed 异常,最终数据库被异常终止。

    • (说明:应用发起新的数据库连接创建时,数据库服务器需要分配相应端口,打开对应的文件句柄,创建相应的OS 进程,分配相应的OS 内存(大约每个8MB 左右),随着应用连接数的增加,OS 内存逐渐耗尽并出现swap 使用)

     

    四、疑问点排查及分析思路


    1、故障时段数据库有多少连接?瞬间过来的连接还是均匀建立的连接?


    监控数据显示至少有3700 个连接(实际上如果包括创建中的,已经超过4000 了),从sess指标来,连接是在8 分钟内均匀建立的, 而且分布在8 台机器上。
    DB agent 监控数据:

     

     

     

    2、什么时间点开始有异常?


    从数据库的监控数据看,11 月22 号23 点55 分以前,sess 连接数指标稳定在468 左右,从55 分开始,下降到127 左右,57 分开始又逐渐上升,58 分以后,数据库端连接数明显超过了之前的468,可以认为异常大概开始于22 号23:58 分。
    DB agent 监控数据:



    3、什么时候数据库无法连接?


    一直到23 号0 点05 分,alert 日志出现达到最大连接数报错,数据库监控也无法连接进行数据采集,数据库监控数据停留在这个时间点。


     

     

     

     

    4、数据库OS 主机性能指标数据有没有异常?


    通过OS 采集到的监控数据,OS 层面出现了内存使用异常,可以看到mem_used 内存使用,随着23:55 的连接下降,出现内存释放(14635MB),随着57 分应用重启,连接数增加,内存使用开始增加,到23 号0 点01 分时,内存使用就和重启之前差不多了,后面随着时间的推移,OS 内存逐渐耗尽。


    DB agent 监控数据(OS 指标):


    5、OS 内存耗尽,是什么原因? 


    从数据库监控采集的数据分析,随之数据库连接数的增加,os 的内存使用也同步增加,连接数增加。
    DB agent 监控的连接数:

    • 2020-11-22 23:54 连接数468

    • 2020-11-22 23:58:08 连接数539

    • 2020-11-22 23:59:01 连接数1107

    • 2020-11-22 23:59:54 连接数1498

    • 2020-11-23 00:01:51 连接数2629

    • 2020-11-23 00:03:54 连接数3396


    从上面的连接数增量和os 内存的增量来算,每个连接os 分配了8MB 内存

    SQL> select trunc((78426853376-47416942592)/1024/1024/3300) from dual;TRUNC((78426853376-47416942592
    
    ------------------------------8


    DB agent 监控数据(OS 指标):

     

     

     


    从02 分之后,内存使用逐渐增加,swap 使用也随之增加,直到15 分左右,os 的内存被完全使用完,随后swap 使用快速增加。


     

     

     


    6、OS 内存耗尽,有没有大的SQL 查询?
    DB agent 监控数据(图形化展示):


     

     

     

    22 号23 的监控数据显示,指标变化最大的是数据库的cget 逻辑读和SQL 执行次数,从趋势图上,可以判断应为sql 执行次数增加导致了数据库的cget 逻辑读的增加;大查询,高消耗IO 等相应指标没有明显突变。


    7、故障时段的SQL 执行次数异常是什么语句?


    DB agent 监控数据(SQL 运行数据):
    从采集的SQL 监控数据,按执行次数排序查询,集中在3 个sql 上:

     

     

     


    具体的sql文本我就不贴了。

    8、故障时段,有没有行锁或者死锁?


    如上监控图,没有明显的行锁或死锁,排查这个可能


    9、为什么会有大量连接创建?

    从23 点57 分到00:05,8 分钟左右时间,一共创建了8018 个数据库连接,但数据库端记录的sess 指标是3700 左右,排除掉正在创建的连接,推测有大量的连接创建后,又被应用连接池主动释放了,而这些频繁创建和释放的连接,一个可能是在执行高频但非常快的SQL(下面有列出来),也有可能是连接池代码,或者应用代码问题。
    经最终确认,应用端的连接复用出现问题,又是程序的锅

     

    聚焦技术与人文,分享干货,共同成长!

    更多内容请关注“数据与人”

    展开全文
  • oracle 数据库突然宕机 解决办法

    千次阅读 2017-08-03 20:26:12
    Oracle数据库突然宕机 查看日志发现(E:\app\Administrator\diag\rdbms\orcl\orcl\trace\alert_orcl.log) 日志中报错 Thread 1 cannot allocate new log, sequence 287072 Checkpoint not complete 参照...

    Oracle数据库突然宕机

    查看日志发现(E:\app\Administrator\diag\rdbms\orcl\orcl\trace\alert_orcl.log)

    日志中报错

    Thread 1 cannot allocate new log, sequence 287072
    Checkpoint not complete


    参照:http://blog.csdn.net/huaishu/article/details/16886111



    select group#,sequence#,bytes,members,status from v$log;


    alter database add logfile group 4 ('E:\APP\ADMINISTRATOR\ORADATA\ORCL\redo04.log') size 200M;   
    alter database add logfile group 5 ('E:\APP\ADMINISTRATOR\ORADATA\ORCL\redo05.log') size 200M;
    alter database add logfile group 6 ('E:\APP\ADMINISTRATOR\ORADATA\ORCL\redo06.log') size 200M;

    alter system switch logfile;
    alter database drop logfile group 1;
    展开全文
  • su 切换用户带来的疑惑这是一个客户的案例,客户的一台oracle数据库服务器突然宕机了,由于在线业务的需要,客户没有考虑太多直接重启了服务器,系统重新启动倒是没有出现问题,可是接下来,当客户切换到oracle用户...

    su 切换用户带来的疑惑

    这是一个客户的案例,客户的一台oracle数据库服务器突然宕机了,由于在线业务的需要,客户没有考虑太多直接重启了服务器,系统重新启动倒是没有出现问题,可是接下来,当客户切换到oracle用户下启动数据库时,怎么都无法进行su切换,于是问题出现了。

    (1)案例现象

    在root用户下,su切换到一个普通用户oracle下,却发生了如下错误:

    20200422000923158748536340722.jpeg

    于是,尝试直接通过oracle用户登录系统,发现此时的oracle用户也无法登录了,出现与上面同样的错误。

    2、解决思路

    从上面错误提示可知是权限出现了问题,那么可以从权限入手进行排查,基本思路如下:

    用户目录/home/oracle权限问题;

    su程序执行权限问题;

    程序依赖的共享权限问题;

    selinux问题导致;

    系统根空间问题。

    3、排查问题

    根据上面的思路,我们进行逐一检查,考虑到su在切换到oracle用户时会读取oracle目录下的环境变量配置文件,因此,首先检查/home/oralce目录的权限是否存在问题,

    [root@loaclhost home]# ls -al/home|grep oracle

    drwx---- 4 oralce  oinstall 4096 01-31 10:45 oracle

    从输出可知,/home/oracle目录的属主是oracle用户,oracle用户对这个目录有“rwx”权限,因此,oracle用户目录的权限设置是正确的,可以排除掉这个问题了。

    接着检查su执行权限问题:

    [root@loaclhost home]# 11 /bin/su

    -rwsr-xr-x 1 root root 24120 2007-11-30 /bin/su

    可见su命令执行权限也没有问题,这个也排除了。

    继续检查su依赖的共享库权限,使用ldd命令检查su命令依赖的共享库文件,如下图

    201906201561041205152798.png

    根据上面的操作,依次检查su命令依赖的每个库文件的权限,发现也都是正常的,因此,共享库的问题也排除了。

    根据上面的思路,绩效检查SELinux的设置。

    201906201561041324495886.png

    由输出可知,SELinux处于关闭状态,这个原因也排除了。

    到这来为止,问题变得朴素迷离,到底是哪里出现问题了呢?作为Linux运维,例行检查系统根分区状态是非常必要的,那么首先检查一个根分区的磁盘空间大小,发现剩余空间还有很多,空间问题也排除了。既然报的错误是权限有问题,那么只要以权限为线索,不偏离这个核心没错,于是继续尝试检查/home目录下各个用户的权限,如下图。

    201906201561041395758775.png

    从输出看每个用户的目录权限,都是“rwx----”,即“700”,完全没有问题,可是我发现我错了,我的目光一直在用户对应的目录上,而忽略了其他输出信息,而问题藏在我没有关注的信息中。在这个命令输出的前两行中,行权限对应的目录是“.”,代表当前目录,也是/home目录,权限为“rwxr-xr-x”,第二行权限对应的目录是“..”,也是根目录,权限却为“rw-rw-rw-”,即“666”,此时,问题终于查找到了,原来是根目录权限问题。

    4、解决问题

    知道了问题产生的原因,解决问题非常简单,执行如下命令:

    [root@localhost~]#chmod 755 /

    然后可顺利执行su切换命令。

    总结:

    这个问题主要是由于根目录没有执行权限,而Linux下所有的操作都是在根目录下进行的,进而导致/home/oralce目录没有执行权限。其实根目录权限的丢失对于系统中运行的每个用户存在同样的影响。因此,在权限出现问题时,一定要注意根目录的权限。

    展开全文
  • 笔者在之前的项目中,发现服务部署上去之后,过了很大概几天,数据库宕机了,当时以为可能只是一次偶然异常,并没有在意,于是重启数据库就行了。但是之后,发现过了一段时间数据库又宕机了。于是重视起来,决定排查...
  • 一个安静的下午,测试环境中一台装有ORACLE数据库的AIX小机因意外断电而导致其上的oracle数据库宕机了。由于是测试环境,安排了一个工程师过去解决了,具体是这样解决的:首先重启了小机服务器,启动完后,发现...
  • 当前的问题Oracle日前发布了两个公告在其官网上,简单描述为对应的数据库都需要打上对应的最小补丁,否则在2019年6月的时候可能会导致大范围宕机的情况。SCN是System Change Number的缩写,是在某个时间点定义数据库...
  • 今天去一个朋友公司,正好碰到他们的生产线宕机,问了一下原因,原来是数据库过于复杂,一点点人为操作的失误,就造成了灾难性的后果。老板大发雷霆,谴责数据部门,问他们为什么用这么糟糕的数据库,为什么不用...
  • ORACLE数据库11g减少宕机

    千次阅读 2008-09-14 16:14:00
    今天去一个朋友公司,正好碰到他们的生产线宕机,问了一下原因,原来是数据库过于复杂,一点点人为操作的失误,就造成了灾难性的后果。老板大发雷霆,谴责数据部门,问他们为什么用这么糟糕的数据库,为什么不用...
  • OA数据库宕机处理

    2021-09-27 14:44:50
    登陆到数据库服务器 windows:直接进入cmd之下下边命令 linux: 需要切换到oracle账号执行下边命令 rman target / RMAN> crosscheck archivelog all; RMAN> delete expired archivelog all; RMAN>...
  • 1. 发现数据库宕机,(ps -ef | grep smon )首先考虑是不是RAC,是否影响正常的生成环境。确定大概修复时间。 如果是RAC,那么到到另一台数据库上输入操作命令。查找静态参数文件进行启动。2.在本地宕机的数据库系统...
  • 生产环境oracle 忽然宕机 查看运行日志 发现归档空间占满 了解到之前开启过DataGuard异地备份 目前已经不再需要此功能 解决方法是关闭归档模式、关闭闪回功能解决过程如下 1.查看归档模式是否打开 SQL>...
  • 根据Bethune智能诊断平台对于中国Oracle数据库用户使用现状分析报告,我们发现,实例异常宕机的相关错误总结如下:(图为2016年非完全统计结果,仅供参考)从以上结果看出,I/O类报错和异常宕机相关性最⾼,...
  • orcle数据库宕机问题

    2019-11-09 08:00:36
    1.原因: ST+PJ大于设置的Xmax的最大值导致 2.处理方式 设置Xmax的值从536M提升至正常值2G左右

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,447
精华内容 8,178
关键字:

oracle数据库宕机