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

问题背景 机房意外断电后Oracle主服务器启动失败,Oracle备机接管 为了安全,管理员对于数据库做expdp的逻辑备份.但备份时发现AttributeInstance表备份失败,提示ORA-01555.对该表执行Create AS Select进行备份时,同样报此错误. 处理过程 一.DB运维人员定位到是因为有几条数据的LOB字段(ObjValue)出现坏块造成的. 二.定位到有问题的几条数据后,可以按类别采用如下处理: 1. 运行中的实例,结合业务实际情况,可以考虑终止实例,重新提交审批

回滚环境: 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

系统: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

一.现象 数据库突然断掉,无法响应,. 二.分析 查看日志发现错误如下(日志路径: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

案例环境 操作系统 :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

昨晚通宵生产压测,终于算是将生产服务宕机的原因定位到了,心累.这篇博客,算作一个复盘和记录吧... 先来看看Redis的缓存淘汰算法思维导图: 说明:当实际占用的内存超过Redis配置的maxmemory时,Redis就会根据用户选择淘汰策略清除被选中的key. 业务场景:用户通过微信入口来访问一个页面: 测试场景:通过多线程模拟定量的并发来访问页面服务: 涉及架构:springsession+Redis集群,容器部署: 问题描述:固定并发数压测10分钟,压测开始后半小时,Redis连接数激增,

修复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.毁灭打击:主结点的数据都没有了 这种情况下要从其

科来 做流量分析,同时也做了一些安全分析(偏APT)——参考其官网:http://www.colasoft.com.cn/cases-and-application/network-security-analysis.php 安全防御的能力取决于安全感知能力 随着互联网的飞速发展,IT基础架构.移动互联网等技术的发展和变化,外部网络安全状况日趋严峻,传统安全防御技术手段和思路面临着诸多挑战.攻击数量越来越多,攻击方式越来越复杂,安全防御容易被绕过:具有针对性的高级攻击(如0-Day攻击.APT攻

一.初始化数据库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

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

早上突然收到dnspod的宕机通知(好久没收到了,有点手足无措). 服务器在上午10:40时达到85%.uptime显示cpu利用率达到35.不宕才怪. 按照之前的经验,应该是触发一个特别耗CPU的处理,把php-cgi重启就能立马恢复,之后再查看日志. 重启后立刻ok. 查看日志,调出那一时刻的日志一条一条的过,重点放在反应时间上.正常的处理时间应该在1秒内,发现很多在几十秒以上的日志,慢慢回溯,发现了最开始异常的记录,是多个提交comment的日志. 发现一连串的来自同一IP的高频率的浏览文