VC客户端无法登陆都是REDO日志惹的祸

环境:VSPHERE5.5+独立oracle 11G数据库

现象:打开vcenter服务器控制台,输入密码后卡在欢迎界面无响应,客户端也无法正常登陆。

正常重启也不行。由于VC所在虚机为独立磁盘无法做快照,不能备当时状态。

查看所在WINDOWS系统日志发现硬件可能有问题。

这是偏移量,并不能代表硬件有问题,怀疑VC连接的数据库有问题,逐登陆排查。
1、登陆11.15.146.2

首先查看数据库进程,正常。

2、查看数据库的告警日志,发现一个问题。

这个实际上是个比较常见的错误。通常来说是因为在日志被写满时会切换日志组,这个时候会触发一次checkpoint,DBWR会把内存中的脏块往数据文件中写,只要没写结束就不会释放这个日志组。如果归档模式被开启的话,还会伴随着ARCH写归档的过程。如果redo log产生的过快,当CPK或归档还没完成,LGWR已经把其余的日志组写满,又要往当前的日志组里面写redolog的时候,这个时候就会发生冲突,数据库就会被挂起。并且一直会往alert.log中写类似上面的错误信息。

分析原因:
服务器有三个日志组g1、g2、g3.当g1写完时,要往g2上写,这时候g1要进行归档,还要进行checkpoint。然后另外两个日志组继续写。当g2和g3都写完之后,又要往g1上写,但是问题来了,g1还没有完成归档和checkpoint操作。所以这时就会报警。
解决方法:
多加几个日志组,并且每个日志组空间大一点,这样就可以延缓时间,会留给g1充分的时间来完成归档和checkpoint任务。就不会有报错。

操作步骤:

首先查看下数据库的日志组状态

查看在线日志组:SQL> select * from v$log;

查看日志组中的成员:SQL> select * from v$logfile;

查看日志组的具体状态:SQL> select group#,sequence#,bytes,members,status from v$log;

GROUP# SEQUENCE#      BYTES    MEMBERS   STATUS

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

1     28825   52428800          1     INACTIVE

2     28826   52428800          1     INACTIVE

3     28827   52428800          1       CURRENT

日志只有50M太小

扩充下日志组大小

SQL> alter database add logfile group 4 (‘/u01/app/oracle/oradata/pvdb/redo04.log‘)size 500M;

Database altered.

SQL> alter database add logfile group 5(‘/u01/app/oracle/oradata/pvdb/redo05.log‘) size 500M;

Database altered.

SQL> alter database add logfile group 6 (‘/u01/app/oracle/oradata/pvdb/redo06.log‘)size 500M;

Database altered.

切换日志组

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

注意:alter system switch logfile 和alter system archive log current这两个切换的区别。

alter system switch logfile 是不等待归档完成就switch logfile。如果database尚未开启archive log mode。那用这个切换是毋庸置疑了。另外,也是对单实例database和RAC模式下当前实例执行日志切换。

而alter system archive log current则需要等待归档完成才switch logfile。会对其中所有实例执行日志切换。

整体上说来,在自动归档的库里,两个命令的所产生的结果几乎一样。有区别的是alter system archive log current所用的时间会比alter system switch logfile 的长。

 删除日志组

SQL> alter database drop logfile group1;

Database altered.

SQL> alter database drop logfile group2;

Database altered.

SQL> alter database drop logfile group3;

Database altered.

注意删除日志组及日志组成员:

原则:删除前必须遵守如下原则,每个实例必须至少有两个日志组;当一个组处于ACTIVE或者CURRENT的状态时不可删除;删除日志组的操作只对数据库进行更改,操作系统的文件尚未删除;当删除时适用DROP LOGFILE GROUP N语句时,此时GROUP N内的所有成员都将被删除。

ALTER DATABASE DROP LOGFILE GROUP N;

删除日志成员的原则:当你删除一个是该组中最后一个成员的时候,你不能删除此成员;当组的转台处于current的状态时,不能删除组成员;在归档模式下,必须得归档之后才能删除;删除日志组成员的操作只对数据库进行更改,操作系统的文件尚未删除。

删除日志组后再删除相应日志文件,例如redo01.log

SQL> !rm  /u01/app/oracle/oradata/pvdb/redo01.log

SQL> alter system switch logfile;

System altered.

SQL> selectgroup#,sequence#,bytes,members,status from v$log;

GROUP#  SEQUENCE#      BYTES   MEMBERS    STATUS

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

4      28828  524288000          1     INACTIVE

5      28829  524288000          1     ACTIVE

6      28830  524288000          1     CURRENT

最后切完日志组后,观察新建的REDO日志组已被应用,数据库正常,数据库日志再无报警,问题解决。

时间: 2024-10-13 02:05:30

VC客户端无法登陆都是REDO日志惹的祸的相关文章

VMware虚拟机采用桥接方式不能上网——都是共享神盾惹的祸!

宿主机是XP,双网卡,一个连接互联网,另一个连接内部生产网,通过来回拔插网线,来切换不同的网络(不允许同时连接两个网络).连接互联网的网卡是Realtek RTL8169,IP是192.168.1.88,通过宽带路由器上网.在VMware Workstation8上建了两个虚拟机,一个是XP,一个Linux.虚拟机采用nat或Host-Only+共享Internet连接时,都能上网,但采用桥接方式确不能上网.测试结果如下表(如不能完全显示,请下载附件后直接打开): Vmware网络 宿主机 虚拟

360家用摄像头无辜中枪,都是销量第一惹的祸

人民刚刚想念完周鸿祎,我们的"红衣教主"就出离愤怒了.当然,他不是因为人民想念他而愤怒,只是因为这两天,有人抹黑他家的360智能摄像机而表示愤慨. 8月7日下午3时23分,360公司董事长兼CEO周鸿祎转发了一条自家360智能摄像机官微的声明,并用了如下评论:"为什么不能好好做产品,在背后下黑脚有意思吗?而且还是毫无根据胡编乱造的,想对这些人说一句,下三滥的手段没用,把自己产品做好了比什么都强!" 到底是怎么回事呢?在这条<关于"网上篡改媒体文章抹黑

[cocos2d-x][apk打包][Fatal signal 11][andriod]Eclipse编译Fatal signal 11报错-都是字符赋值惹的祸

流程重现: 使用coco2d-x制作了一个2048,在xcode模拟器运行以及在pad上真机调试都是没有问题的,但是在使用eclipse调试打包android能够运行,但是进入游戏之后会在随机的地方闪退,debug模式报错为: 10-20 11:48:36.413: A/libc(17408): Fatal signal 11 (SIGSEGV) at 0x68d7b0b8 (code=2), thread 17426 (Thread-7958) 在网上查到关于这个问题的n中说法,包括andro

【恢复】Redo日志文件丢失的恢复

第一章 Redo文件丢失的恢复 1.1  online redolog file 丢失 联机Redo日志是Oracle数据库中比较核心的文件,当Redo日志文件异常之后,数据库就无法正常启动,而且有丢失据的风险,强烈建议在条件允许的情况下,对Redo日志进行多路镜像.需要注意的是,RMAN不能备份联机Redo日志文件.所以,联机Redo日志一旦出现故障,则只能进行清除日志了.清除日志文件即表明可以重用该文件. 1.1.1  数据库归档/非归档模式下inactive redo异常ORA-00316

【恢复,1】 redo 日志恢复的各种情况

Recovering After the Loss of Online Redo Log Files If a media failure has affected the online redo logs of a database, then the appropriate recovery procedure depends on the following considerations: The configuration of the online redo log: mirrored

使用LogMiner分析oracle的redo日志和归档

Oracle LogMiner 是Oracle公司从产品8i以后提供的一个实际非常有用的分析工具,使用该工具可以轻松获得Oracle 在线/归档日志文件中的具体内容,特别是该工具可以分析出所有对于数据库操作的DML和DDL语句.该工具特别适用于调试.审计或者回退某个特定的事务. LogMiner分析工具实际上是由一组PL/SQL包和一些动态视图(Oracle8i内置包的一部分)组成,它作为Oracle数据库的一部分来发布是8i产品提供的一个完全免费的工具.但该工具和其他Oracle内建工具相比使

MySQL中redo日志

重做日志用来实现事务的持久性,即ACID中的D,由两部分组成: 一是内存中的重做日志缓冲(redo log buffer)  易丢失 二是重做日志文件(redo log file) 持久的 InnoDB是事务的存储引擎,其通过Force Log at Commit 机制实现事务的持久性,即当事务提交commit时,必须先将事务的所有日志写入到重做日志文件进行持久化,待事务COMMIT操作完成才算完成,这里的日志指重做日志,在InnoDB存储引擎中,由两部分组成,即redo log 和undo L

Redo日志

当向存储系统写一个数据元素时,通常是先写入主存或者缓冲,然后再写入磁盘,如果系统在写入磁盘的时候,系统发生故障,当系统恢复后,需要再次从磁盘中读取此数据元素的时候,并不知道此时磁盘上所保存的数据元素是正确的还是错误的,Redo日志是一种应对此种故障的比较常用的故障恢复策略.为了确保一个数据元素的完整性,还需要借助事务这一概念,对于更新数据一个元素的redo日志,我们将其描述为"在一个事物T中写入数据元素A的新值x",使用元组<T, A, x>表示. 一个事务的数据元素的更新

理解数据库中的undo日志、redo日志、检查点

理解数据库中的undo日志.redo日志.检查点 2014-6-18 原文:https://www.letiantian.me/2014-06-18-db-undo-redo-checkpoint/ 数据库存放数据的文件,本文称其为data file.数据库的内容在内存里是有缓存的,这里命名为db buffer.某次操作,我们取了数据库某表格中的数据,这个数据会在内存中缓存一些时间.对这个数据的修改在开始时候也只是修改在内存中的内容.当db buffer已满或者遇到其他的情况,这些数据会写入da