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

CPU 利用率高的排查方法 看看该机器的连接数是不是比其他机器多,监听的端口数:netstat -anlp | wc -l Kafka-0.8的停止和启动 启动: cd /usr/local/kafka-0.8.0-release/ && nohup ./bin/kafka-server-start.sh config/server.properties & 停止: ps ax | grep -i 'kafka.Kafka' | grep -v grep | awk '{print

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

今天想起了很久没用的oracle库,用plsql尝试连接,发现报超时错误,以为是偶然,多次尝试连接,发现还是超时,于是登录到系统中,查看数据库情况,发现正常查询和修改添加,感觉不是数据库问题,查看监听 lsnrctl status后,监听不动了,只显示 LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 02-JAN-2018 16:52:45 Copyright (c) 1991, 2005, Oracle.  All rights re

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

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

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

案例环境 操作系统 :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登录后,发现在控制台亦无响应.无法登录.无法操作,输入操作无响应.也就是说系统

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

修复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 --指

2019年3月3日凌晨,微博炸锅,有网友反映说阿里云疑似出现宕机,华北很多互联网公司受到暴击伤害,APP.网站全部瘫痪,我自己的朋友圈和微信群里也有好友反馈,刚刚从被窝被叫起来去修Bug,结果发现服务器登不上去了...... 凌晨2点37分,阿里云官方回应称:华北2地域可用区C部分ECS服务器等实例出现IO HANG,经紧急排查处理后逐步恢复,此外将根据协议尽快赔偿.并已经全面排查其他地域及可用区,未发现此类情况. IO HANG 那么问题来了,IO HANG是个什么鬼?简单的说,就是服务器磁盘

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

个人博客:https://blog.sharedata.info/ Elasticsearch 突然宕机,每次重启都只生成错误日志报错信息:## There is insufficient memory for the Java Runtime Environment to continue.# Native memory allocation (mmap) failed to map 10039525376 bytes for committing reserved memory.# Poss

科来 做流量分析,同时也做了一些安全分析(偏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

KubeEdge v0.2发布 KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目,旨在依托K8S的容器编排和调度能力,实现云边协同.计算下沉.海量设备的平滑接入. KubeEdge脱胎于华为云IEF服务,是第一个具备在生产环境部署能力的边缘计算领域开源项目.前几天K8S IOT/Edge工作组发布了关于边缘计算的白皮书,并将KubeEdge作为K8S在IOT/Edge场景下的参考架构. KubeEdge架构上包含两部分,分别是云端和边缘侧.云端负责应用和配置的下发

Region Server宕机总述 HBase一个很大的特色是扩展性极其友好,可以通过简单地加机器实现集群规模的线性扩展,而且机器的配置并不需要太好,通过大量廉价机器代替价格昂贵的高性能机器.但也正因为廉价机器,由于网络硬盘等各方面的原因,机器宕机的概率就会相对比较大.RegionServer作为HBase集群中实际的执行节点,不可避免地也会出现宕机. 宕机并不十分可怕,因为不会丢数据.HBase集群中一台RegionServer宕机(实指RegionServer进程挂掉,下文同)并不会导致已经