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

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

最近做某数据库恢复演练,数据库版本是10.2.0.4,恢复控制文件一直报错,报错如下,经过反复折腾,原来恢复机上oracle用户不是oracle导致(我的是oraclev4),查看源库oracle用户gid为dba,最终在恢复机上新建oracle用户(gid=oinstall groups=dba)或oraclev4不变(gid=dba groups=oinstall)均可顺利恢复.以下是nbu官网说明: https://www.veritas.com/support/zh_CN/article

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

一.目的 在做SQL Server数据库维护的时候,当上司要求我们把几十G的数据文件搬动到其它服务器,并且要求最小宕机时间的时候,我们有没什么方案可以做到这些要求呢? 在这里我们假设这两台机器并不是在一个机房上,这样看起来我们的解决方案才更有意义,如果你那么好运这两台机器在同一个局域网,那么恭喜你,你可以多很多的方案可以做到. 二.分析与设计思路 其实我们假设的环境有两个特点:第一个是数据库文件比较大:第二个就是我们的传送文件的速度可能会比较慢.也许这传送速度我们是没有办法了,但是我们可以就从文

控制文件中的SCN 数据文件头的SCN 数据块中的SCN 日志文件头中的SCN 事务SCN 内存中的SCN 一 控制文件中的SCN 1.1 数据库SCN 数据库SCN表示最近一次全量checkpoint操作时的SCN SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------        1744125 dump控制文件语法 alter session set events 'imm

1.首先需要安装好oracle数据库,本机适用plsql连接数据库正常,记录下数据库名称 2.安装cx_oracle模块 pip install cx_Oracle 3.python中引入模块 import cx_Oracle as cx 4.测试 conn = cx.connect('sys/password@localhost/orcl')    cursor = conn.cursor ()  cursor.execute ("select * from dual")  row

一.连接oracle数据库 一.windows环境 oracle windows客户端下载地址:http://www.oracle.com/technetwork/topics/winx64soft-089540.html 1.首先需要安装好oracle数据库,本机适用plsql连接数据库正常,记录下数据库名称 oracle连接工具下载地址:https://www.allroundautomations.com/bodyplsqldevreg.html 2.安装cx_oracle模块 pip i

四月份我们公司负责的电票系统上线了,这个系统上线比客户方其他系统上线还特殊,是二期改造项目,旧系统数据还要整合抽取到新系统中继续使用,而且该系统不是增量型方式开发上线的,而且全部开发完后全国上线的,这样开发压力大,测试人员压力也很大,由于环境问题以及在接近上线前客户方还在做需求变更,导致上线后出现了不少缺陷问题,两周后大部分问题还好都得以解决.而在上线前由于多种原因,我们性能测试人员根据项目调研提供的典型交易进行测试发现了不少问题,但是由于开发人员还在忙于需求变更等开发工作,对我们发现的性能问题

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

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

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

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

数据库版本:11.2.0.4 RAC环境 操作系统版本:Asianux Server release 7.3 数据库报错分析 接到业务消息,应用无法访问,开发人员查看日志后发现无法连接数据库. 查看数据库进程,发现无数据库进程存在,命令如下: ps -ef | grep smon 查看数据库alert日志,报错信息如下: PMON (ospid: 248987): terminating the instance due to error 484 Wed Feb 15 08:53:54 2023

环境: A机:RHEL5.5 + Oracle 10.2.0.4 B机:RHEL5.5 需求: A机10.2.0.4数据库,在B机升级到11.2.0.4,应用最新PSU补丁程序. 目录: 一. 确认是否可以直接升级 二. B机安装11g软件,打好PSU补丁 三. B机环境变量检查 四. B机创建需要的目录 五. A机原库升级前检查 5.1 从B机上传utlu112i.sql脚本到A机 5.2 A机执行utlu112i.sql进行升级前检查 5.3 根据检查结果调整A机数据库 六. A机备份原库

由于阿里云经典网络迁移到专用网络,一不小心没有先预备方案调整网段, 导致实例无法以内网IP形式访问数据库,被迫进行数据库停机后网络网段调整,导致宕机了几个小时...被客户各种投诉爆了.. 基于这次数据库恢复血泪史, 特整理解决办法, 让日后同学避免再犯. 数据库master库重启后, 确保能正常提供服务.由于生产上BI系统使用的是slave从库做数据查询, 从库的数据库已经落后了master好几天, 查看从库状态: mysql> show slave status\G; 显示 Slave_IO_

[问题现象] 服务器在运行过程中,因人为意外导致电源被拔,服务器宕机,mysql重启不成功,报错如下 根据提示,输入systemctl status mysql.service和journalctl -xe查看日志,经过一番百度谷歌折腾也是无果.(很多时候,不能因为突发事件就“病急乱投医”) 最后在mysql 的日志处看到了报错日志 如果centos是通过yum安装的mysql,那么日志一般在/var/log/mysql.log 查看到日志 2018-11-29T08:39:18.977374Z

1,如果是本机的oracle数据库,ip就为127.0.0.1,数据库名看tnsname.ora文件 LISTENER_ORCL =  (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) ORACLR_CONNECTION_DATA =  (DESCRIPTION =    (ADDRESS_LIST =      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))    )    (

因为要更新数据库加个表,远程桌面又无法连接...所以就远程到另外一台电脑,然后用navicat通过内网修改目标数据库. 一直用着navicat操作数据库,所以很速度的弄好然后新建连接进入数据库. 然而意外就发生了,Cannot create oci environment !!!什么鬼??? 用了这么久第一次碰到这个问题,各种百度发现是oci.dll文件版本不对,然后就是更换oci文件 因为远程的是Oracle 11g所以选择下面那个文件夹内的oci.dll文件,更新后成功. 在百度上也是翻了好