一.现象 数据库突然断掉,无法响应,. 二.分析 查看日志发现错误如下(日志路径:D:\app\Administrator\diag\rdbms\orcl\orcl\trace\alert_hrpdev.log): Mon Jan 15 13:16:00 2018 Thread 1 cannot allocate new log, sequence 8 Checkpoint not complete Current log# 1 seq# 7 mem# 0: D:\APP\ADMINISTRAT

简介 ORA-10458: standby database requires recovery ORA-01196: 文件 1 由于介质恢复会话失败而不一致 ORA-01110: 数据文件 1: 'XXXXXXXXXXXXXXXXXX\XXXXX1.DBF' 一个项目做了Oracle主从数据库同步,通过Dataguard实现,从库服务器宕机,再开机的时候,从库无法启动,报"ORA-01196: 文件 1 由于介质恢复会话失败而不一致"这个错误,具体日志信息如下: ORA-10458:

系统:redhat 6.6 oracle版本: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production 问题描述:宕机后,使用 sqlplus   登陆发现: Oracle ORA-01033: ORACLE initialization or shutdown in progress 即,数据库未正常打开. 问题排查: 由于非正常关机,数据库需要恢复.遂Bd一下: https://www.cnblogs.co

回滚环境: 1.源库版本: Grid Infrastructure:11.2.0.3.15 Database:11.2.0.3.15 2.目标库版本: Grid Infrastructure:11.2.0.3.13 Database:11.2.0.3.13   执行步骤: 1.备份源库(root & grid & oracle) 在待回滚的节点执行备份,以防止回滚失败后导致软件故障. a.备份 ASM 实例参数文件(grid) 以 / as sysasm 身份进入 sqlplus 环境,执

升级环境: 1.源库版本: Grid Infrastructure:11.2.0.3.13 Database:11.2.0.3.13 2.目标库版本: Grid Infrastructure:11.2.0.3.15 Database:11.2.0.3.15   执行步骤: 1.备份源库(root & grid & oracle,每个节点) 在待升级的节点执行备份,以防止升级失败后导致软件故障. a.备份 ASM 实例参数文件(grid) 以 / as sysasm 身份进入 sqlplus

首先按照网友说的shutdown immediately,结果hang了半个小时也么反应. 然后检查日志,全盘搜索.trc,发现 (D:\app\oracle\diag\rdbms\cms1u\cms1u\trace) 进过分析,怀疑是由于归档已满导致数据库宕机,从而shutdown 无法生效. 再次google,手动删除了 归档文件 ,保留了最后一天的目录,文件位置: D:\app\oracle\flash_recovery_area\cms1u\ARCHIVELOG 再次百度 需要RMAN

案例环境 操作系统 :Oracle Linux Server release 5.7 64bit 虚拟机 硬件配置 : 物理机型号为DELL R720 资源配置 :RAM 8G Intel(R) Xeon(R) CPU E5-2690 8核 案例描述 早晨发现桂林那边一台Linux服务器(虚拟机)网络无法ping通,于是联系那边的系统管理员通过Lync共享桌面给我,通过他的电脑VMware vSphere Client登录后,发现在控制台亦无响应.无法登录.无法操作,输入操作无响应.也就是说系统

今天遇到一起ORACLE数据库宕机案例,下面是对这起数据库宕机案例的原因进行分析.解读.分析过程中顺便记录一下这个案例的前因后果,攒点经验值,培养一下分析.解决问题的能力. 案例环境:   操作系统 :Oracle Linux Server release 5.7 64 bit 数据库版本:Oracle Database 10g Release 10.2.0.4.0 - 64bit Production 案例分析: 收到告警去检查数据库时,发现实例已经宕机.检查告警日志,发现下面错误信息: OR

ASMB的BUG(ORA-04030 kfmditer)导致数据库宕机 现象: 客户的一个重要生产系统RAC的一个实例宕机,查看alert日志: Fri Jun 21 17:05:52 2013 Errors in file /opt/app/diag/rdbms/jyj/jyj1/trace/jyj1_asmb_11391.trc (incident=31397): ORA-04030: out of process memory when trying to allocate 592 byt

最近一段时间,OSChina 网站在早上 8 点出头的时候很容易因为数据库连接池爆满而导致网站宕机.表现的情况是数据库处理大量的查询,堆积大量并发连接,导致无法再连接到数据库,执行一个简单的查询速度也非常慢,数据库机器的 CPU 很高. 但事实上早上 8 点并非 OSC 网站的高峰期,高峰期的时候都不会挂,为什么偏偏在这么一个没多少人访问的时间点宕机呢? 找了很久没发现系统在 8 点这个时间点有什么特殊的任务要做,对数据库也做了一些调整,包括 “ MySQL Can’t Create Threa

为了迎接春节假期后的访问高峰,我们今天对 docker swarm 集群进行了变更操作,购买了1台阿里云4核8G的服务器作为 worker 节点,由原来的  3 manager nodes + 2 worker nodes 变为  3 manager nodes + 3 worker nodes . 晚上,我们对已经持续运行一段的5个节点逐一进行重启操作,重启方式如下: 1)docker node update --availability drain 让节点下线2)阿里云控制台重启服务器3)d

情景再现: 在修复hadoop集群某一个datanode无法启动的问题时,搜到有一个答案说要删除hdfs-site.xml中dfs.data.dir属性所配置的目录,再重新单独启动该datanode即可: 问题就出在这个误删除上,当时是在namenode的hadoop/hdfs/目录下,然后就执行了一个可怕的命令 rm -rf data rm -rf name #存储namenode永久性元数据目录 当时还不知道删除这个的可怕,以为只是误删除了普通数据而已,然后再转到datanode下再次执行删

修复ogg source端意外宕机造成的数据不同步 分类: Oracle2016-04-28 11:50:40原文地址:修复ogg source端意外宕机造成的数据不同步 作者:十字螺丝钉 ogg source端意外宕机后(13:00宕机),引起ogg不能同步(source和target端数据不同步). 处理办法如下: 一.source端 1.extract服务:extract服务状态为:abended 解决办法:alter extract extract_name ETROLLOVER --指

一.mysql group replication 生来就要面对两个问题: 一.主节点宕机如何恢复. 二.多数节点离线的情况下.余下节点如何继续承载业务. 在这里我们只讨论第一个问题.也就是说当主结点宕机之后.我们怎么把它从新加入到高可用集群中去.这个问题又可以细分成 两种情况: 1.温和打击:主结点的数据还在.宕机期间集群中的其它结点的binlog日志也都还在 这种情况下重新启动mysql group replication 就可修复问题. 2.毁灭打击:主结点的数据都没有了 这种情况下要从其

一.初始化数据库11张quartz表:qrtz_*   先从官网下载好quartz2.3.0包:http://www.quartz-scheduler.org/downloads/ 解压后进入目录:quartz-2.3.0-SNAPSHOT\src\org\quartz\impl\jdbcjobstore 得到22种数据库的11张qrtz_*表的初始化SQL,这里列举几个经典的数据库文件:tables_oracle.sql.tables_mysql_innodb.sql.tables_sqlSe

调用最简单的JNI没有出错,但是涉及到OCI时就会异常退出,分析后基本确定是OCI 11g中的signal所致,参考ora-24550 signo=6 signo=11解决. 但是这个相同的so库直接被其它c++应用调用就一直正常,但是java通过jni调用就会挂掉,而且很有规律.如果是单个线程循环调用,则一直运行稳定,没有任何异常.但是一旦多个线程去调用(无论是串行(加了synchronized放并发).还是并行),都会发生SEGFAULT,而且通常在运行6-7次后发生.所以问题肯定在于对于J

3 月 24 日晚间大约 23 点左右,新浪云 SAE 一处核心机柜掉电,导致 SAE 平台下大量应用无法正常访问,并在 10 小时后才陆续修复.这次事故暴露 SAE 的哪些缺陷?SAE 运维人员又是做何感想? SAE官微虽然在第一时间发布了宕机公告,在稍后宣布抢修并赔偿所有用户,不过之后就没动静了,连续一晚上的主站无法访问,国内节点和日本节点无法访问,这不是一个成熟的云服务商所发生的...最起码让二级域名或者主站跳转到备用服务器给个公告 阿喂 我的私人博客.两个微信公众和一个易信公众都罢工了.

Vertica集群单节点宕机恢复方法 第一种方法: 直接通过admintools -> 5 Restart Vertica on Host 第二种方法: 若第一种方法无法恢复,则清空宕机节点的catalog 和 data目录 比如 v_testdb_node0001_catalog/ v_testdb_node0001_data/ 然后从其他节点拷贝catalog目录下的vertica.conf,然后恢复.

Vertica节点宕机处理一例: 查询数据库版本和各节点状态 常规方式启动宕机节点失败 进一步查看宕机节点的详细日志 定位问题并解决 1. 查询数据库版本和各节点状态 dbadmin=> select version(); version ------------------------------------ Vertica Analytic Database v6.1.3-7 (1 row) dbadmin=> select node_name, node_id, node_state,

我们生产服务器都部署在VMware ESXi 5.5平台上,最近大半年的时间,偶尔就会出现操作系统为Windows Servre 2012的服务器出现没有任何响应(unresponsive)的情况,出现问题的时候,服务器有下面一些现象: 1: 应用程序无法访问SQL Server数据库,使用Microsoft SQL Server Management Sutdio去测试连接数据库,也会返回连接错误. 2: 网络有时候能Ping通,有时候是Ping不通的情况. 3: 远程连接无法访问服务器,从V