SQL> alter tablespace yhqt read only; SQL> alter tablespace yhqt read write;
在数据的备份恢复中，基本都在使用rman来做了，但是从数据库的内部原理来说，对于介质恢复，其实还是做两件事，restore和recover. restore是一个类似物理文件的复制，而recover则在数据库后台根据scn做相关的数据恢复。 在归档模式下，一般有下面四种场景可以做完全恢复，当然前提还是在有备份的情况下。 我们可以不依赖rman来手工完成备份恢复的这些过程。因为手工的过程其实也不复杂。 手工备份恢复，那么备份就是热备了。如果连归档没开，就会报出下面的错误。 SQL> alter tables
SYSTEM表空间是Oracle数据库最重要的一个表空间,存放了一些DDL语言产生的信息以及PL/SQL包、视图、函数、过程等,称之为数据字典,
Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:
最近几天发现库里有坏块了，环境是11gR2, linux平台的64位的库。以下是我的修复办法，基于dbms_repair做的在线修复，也可以基于备份rman来修复，archivelog,noarchive log可能修复的方式有所不同。 -->首先从alert.log里面发现如下的错误。 DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident) ORA-01110: data file 8: '/dbTS2/oracle/TES
继昨天发生san存储切换导致io等待异常高的问题后，晚上客户对测试环境的数据库进行了远程启动，因为库比较多，监控process都起来了。客户就发邮件通知测试组继续测试。 结果早上测试反馈有一个库怎么都等不了。 他们提供的日志如下： sqlplus test3c/xxxx@testdb SQL*Plus: Release 11.2.0.2.0 Production on Sat Jun 21 12:59:36 2014 Copyright (c) 1982, 2010, Oracle. All rights
前面文章提到，这周末帮一个客户测试报错场景： 客户通过duplicate生产备库的方式创建cascade备库。 发现每次都会遇到两个文件报错，ORA-17628: Oracle error 19505错误，且每一次跑，报错文件不一样。 现在想帮客户验证，这属于是正常现象还是bug。
如果数据库只有很少的数据块被破坏，那么块介质恢复（Block Media Recovery，BMR）是较好的块恢复方法。BMR只能用于恢复物理损坏（Physical Corruptions），在数据文件联机时即可恢复相关坏块。BMR主要使用BLOCKRECOVER命令进行恢复坏块，该命令有以下三种使用方式：
对于物理损坏的数据块，我们可以通过RMAN块介质恢复(BLOCK MEDIA RECOVERY)功能来完成受损块的恢复，而不需要恢复整个数据库或所有文件来修复这些少量受损的数据块。恢复整个数据库或数据文件那不是大炮用来打蚊子，有点不值得！但前提条件是你得有一个可用的RMAN备份存在，因此，无论何时备份就是一切。本文演示了产生坏块即使用RMAN实现坏块恢复的全过程。
最近帮助业务部门解决了一个技术问题，因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来，当我看到他们提供的语句，在备 库做了简单的数据评估之后，发现数据量比想象的要多，大概有200万条左右的数据，而业务部门手头有一个excel文件，需要和这些数据做一些比对，当然 停了下筛选逻辑还蛮复杂，最开始建议他们数据量太大，使用excel还是可能出问题，但是业务部门认为应该没有太大的问题，他们会有excel中的公式等 来处理，想想也有道理，就提供给了他们一个近40M的文件。 等到快中
在 Oracle 归档模式下直接 rm data.dbf 数据文件并重启数据库还有救吗？为何会有这样的问题，要追溯到上周一位朋友咨询的事情，他那里一个 Oracle 单机的环境因为表空间不足了，需要扩容表空间，则通过添加表空间数据文件的命令加入了一个数据文件，执行成功后呢便可以继续写入数据了。
工作中碰到问题当然是见怪不怪了，而处理这些问题也是我们的价值所在。 今天处理了几个看起来比较有意思的小问题，当然究其原因，要不是不规范，要不就是基本功不够扎实。 问题1：奇怪的ORA-00600报错，常规的原因 对于ORA-00600的错误，其实自己也碰到过很多次了，绝大多数的情况下，这个错误还是能够反映出来一些不规范的现象。 比如今天得到了一个DDL语句，执行的时候有卡顿，然后直接抛出了ORA-00600的错误。 SQL> CREATE USER "KA_SYS" IDENTIFIED BY VAL
听说过还原(restore)数据库，表空间及数据库文件，使用归档日志恢复(recover)数据库，表空间，数据库文件。咦，还有还原归档日志这一说法呢？没错，可能我们忽略了还原归档日志这一个过程，原因是还原归档日志通常情况下是oracle在recover时自动完成的。大多数情况下我们是先还原数据库，恢复数据库，打开数据库。实际上在恢复数据库之前有一个动作，那就是还原归档日志，也就是将日志文件还原到缺省的归档位置，如果我们在备份归档日志时使用了delete [all] input子句的话。本文对此给出了单独还原归档日志以及恢复归档日志的示例以及restore archivelog的一些用法，仅仅是为了更好来的理解还原与恢复的过程，因为大多数情形下,数据文件被还原到缺省路径。如果是还原到非缺省路径，那就需要手动restore archivelog。
普通数据文件指：非system表空间、undo_tablespace表空间、临时表空间和只读表空间的数据文件。它们损坏导致用户数据不能访问，不会导致db自身异常、实例崩溃、数据库不恢复就无法启动的情况。
某项目扩展表空间后增加了一个数据文件，出现数据库无法连接的情况，项目人员联系主机硬件厂家，对方发了几个图片说空间不足了，项目人员于是说按照对方说法在主机删除了对应数据文件，这次更无法启动数据库了，，，，，真是无知者无畏，对方敢让删数据文件，项目人员也赶删，实在是无语至极！
最近在使用swingbench的时候碰到了ORA-01157故障，下面是其具体描述与解决。
在ACOUG的年终大会上，我分享了一个主题，列举了使用Oracle 12c多租户的过程中可能遇到的各种坑，当你使用一个新产品或者新特性时，如果你不了解，就可能是使用中，陷入其中。 首先我们已经知道，Oracle 12c的多租户特性，允许在一个容器数据库中，创建多个PDB，这些PDB彼此隔离和独立，但是依赖CDB而存在。 问题一：PDB丢失一个文件数据库会如何？ 现在请大家思考一个问题：如果某个PDB中，因为意外而丢失了一个数据文件，那么数据库会怎样？ 目前我们涉及的版本包括：12.1.0.1.0 ，12.1
之前在生产中遇到同样报错，用户在客户端查询表中数据，报如下错误： Errors in file /oratrace/xxx/diag/rdbms/xxx/xxx2/trace/xxx2_dbw0_8454382.trc: ORA-01157: cannot identify/lock data file 366 - see DBWR trace file ORA-01110: data file 366: '/dev/rrpt001vg05'
墨墨导读：一套Oracle RAC环境运行在HW超融合环境中，由于硬件问题导致数据库crash，期间出现了不少数据坏块，本文详述整个恢复过程，希望对大家有帮助。
SQL> select status from v$instance; STATUS ------------ MOUNTED SQL> ALTER DATABASE OPEN; ALTER DATABASE OPEN * ERROR at line 1: ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
今天在做一些演示的时候，在虚拟机上装了两套数据库软件，10g和11g的。还是在演示普通数据文件迁移的时候还是碰到了一些意料之外的问题，从当时的情况来看感觉还是比较诡异的，所以马上切换到另外一套环境去试验就没有任何问题了。对于这个问题事后进行了分析，发现还是一些简单常规的错误，自己还是对一些细节没有掌握好， 本来对于普通数据文件的迁移流程是很简单的，在数据库open状态就可以迁移， 基本步骤如下： alter tablespace xxxx offline; cp datafiles alter ta
环境：RHEL 6.4 + Oracle 11.2.0.4 背景：备份恢复的测试库在一次不完全恢复后，没有来及做有效的全备，又一次数据库故障导致数据库无法正常open。 只能离线部分数据文件打开数据库，其中包含undo表空间数据文件。 适用场景：无有效备份，可以丢失数据，删除回滚段状态为NEEDS RECOVERY的undo表空间。
最近的数据导入(IMP)时碰到了ORA-01187 ORA-01110 错误，由于这个数据库是使用热备恢复过来的，且恢复也是成功的，因为数据库能够成功open，那到底是哪里有遗漏呢？如你有类似的问题，不妨往下看。
在启动数据库的时候,open阶段总是可能出现各种各样的问题， 比如让人胆战心惊的错误。 ORA-01113: file 1 needs media recovery 自己留意了一下，其实还是有蛮多的场景会出现这个问题，有些细节可能没有注意到就会出现这个问题， 比如我们重建控制文件的时候。 在重建控制文件之前做了shutdown abort的操作。 SQL> shutdown abort ORACLE instance shut down. SQL> startup nomount ORACLE in
今天计划把一个测试环境升级到12c，为了练练手，先在备库上来做。数据库版本是11.2.0.3.0，计划升级到12.1.0.2.0。 为了不影响原有的测试主库，我在备库上做了Failover，两个命令下去就立刻生效了。 SQL> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY SQL>alter database recover managed standby database finish force;
SYSAUX表空间是在10g之后引入的一个新的表空间，主要用于减轻对SYSTEM表空间的压力而作为SYSTEM表空间的辅助表空间。
环境：RHEL 5.4 + Oracle 11.2.0.3 背景：数据库没有备份，数据库文件被误操作rm，此时数据库尚未关闭，也就是对应句柄存在，如何快速恢复？
一 系统环境： 1、操作系统：oracle Linux 5.6 2、数据库： Oracle 11g 二 Oracle 重做日志的作用: [模拟介质恢复] 1. 关闭数据库归档模式： [oracle@test ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 6 23:49:30 2017 Copyright (c) 1982, 2009, Oracle. All rights reserved. SQL>
墨墨导读：某客户单位数据库出现异常，大致现象是：数据库状态是open的，但是其中一个数据文件无法访问，本文分享排查原因与解决问题的整个过程。
案例：Standby RAC遭遇ORA-1157,1111,1110导致实例crash处理 环境：RHEL 6.5 + Oracle RAC 11.2.0.4 + Dataguard 今天在实验环境的Pirmary RAC主库上做了一个增加表空间的操作，结果Standby RAC启动同步后直接crash，具体报错如下：
灾备库通过源库的全备archive文件做完全库恢复后，拿到源库的archive日志在灾备库执行recovery恢复时报错：
有的时候由于备库空间不足，在主库添加了数据文件后，导致备库数据文件的缺失，可能很久之后才发现，但是由于归档的缺失等其它原因而导致备库不能正常应用Redo日志。还有其它情况可能导致备库的数据文件不能正常ONLINE，在这种情况下，可以在主库上利用CONVERT命令备份一个数据文件然后拷贝到备库即可。若是备库归档文件比较全，则可以直接在备库创建数据文件后应用Redo日志即可，而不需要从主库拷贝数据文件。
今天碰到一个有些奇怪的问题，但是奇怪的现象背后都是有本质的因果。 下午在做一个环境的检查时，发现备库是在mount阶段，这可是一个11gR2的库，没有ADG实在是太浪费了，对于这种情况感觉太不应该了。 所以尝试启动至open阶段，发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊。 使用dg broker设置为READ-ONLY,备库的数据库日志如下： Standby Database: stestdb3, Enabled Phys
最近测试环境需要做一些变更，把测试环境切分成两套环境，存储空间也需要压缩压缩和整理。 unix组的人已经开始做空间划分了，然后我们需要在此基础上重建一套环境。 有些数据文件使用空间不大，所以准备压缩一下。 用了下面的sql语句，结果跑了十几秒中就抛了下面的错误。 SQL> set linesize 200 SQL> col name for a40 SQL> col resizecmd for a80 SQL> select a.file#,a.name,a.bytes/1024/1024 CurrentM
移动数据文件/home/oracle/cjctbs02.dbf到/u01/app/oracle11/oradata/chendb/cjctbs02.dbf
环境：OEL 5.7 + Oracle 10.2.0.5 背景：在Oracle的运维过程中，时常会遇到一些场景是需要重建控制文件才可以解决的。本文的场景可以通过复制控制文件到新路径，运行一段时间后，再用老的控制文件启动数据库重现。
--====================== -- 只读表空间的备份与恢复 --====================== 一、只读表空间的特性 使用只读表空间避免对静态数据的频繁备份 当使用alter tablespace tbs read only时,数据文件会执行检查点进程(将所有脏缓冲区的内容写至磁盘)， 当前的SCN号会被标注,同时存储了SCN的数据文件头部被冻结.控制文件内也会记录该数据文件的冻结信息。 可以清除只读表空间的对象 二、只读表空间的备份 一般情况下，只读表空间只需要进行一次备份，即当表空间状态发生改变时应立即进行备份 可以使用OS系统cp命令来备份或RMAN进行备份只读表空间 使用RMAN时建议启用备份优化选项 RMAN> CONFIGURE BACKUP OPTIMIZATION ON; 只读表空间不支持热备 SQL> alter tablespace tbs1 begin backup; alter tablespace tbs1 begin backup * ERROR at line 1: ORA-01642: begin backup not needed for read only tablespace 'TBS1' 三、只读表空间的还原与恢复 还原与恢复只读表空间的问题在于控制文件如何控制只读表空间，分为下列三种情况： --------- --------------- ---------------- ------------------------------------- case backup 1 crash status recovery --------- --------------- ---------------- ------------------------------------- case 1 Read-Only Read-Only 将备份的只读表空间复制到目的地(Restore) case 2 Read-Only Read-Write 先Restore backup1,后recover(applied log ) case 3 Read-Write Read-only 先Restore backup1,后recover(applied log ) 只读表空间恢复时需要考虑的问题 重建一个控制文件时 重命名数据文件时 使用一个备份的控制文件时 下面对表空间tbs1置为只读后对比前后生成的重建控制文件的脚本
SQL> create tablespace test_data 2 logging 3 datafile '/opt/oracle/oradata/bisal/test_data_01.dbf' 4 size 10M 5 autoextend on 6 next 10m maxsize 2000m 7 extent management local; Tablespace created.
在上周五的时候，本来一个例行巡检，想扩充一些表空间，结果弄巧成拙，因为一个drop datafile的操作直接导致了一主两备的两个备库MRP直接抛出了ORA-600错误。 在尝试了一些方法和查看了MOS之后，除了重建备库，暂时还没有找到其它相对更快捷的方法。 因为是10.2.0.4.0的环境，为了先修复问题，自己先使用rman在主库做了备份，然后在备库直接做duplicate操作还原恢复。先搭好了一个备库，另外一个备库则先留下来，观察一下，看看有没有其它的方法，如果还是没有找到，就继续重新搭建备库。 结果在
背景：这里提到的常规恢复指的是数据库有完备可用的RMAN物理备份。 实验环境：RHEL6.4 + Oracle 11.2.0.4 DG primary.
对于只读表空间，只需要在第一备份时进行备份，在以后的备份中不需要再对备份过的只读表空间进行备份。
在Oracle中，Redo日志文件包含所有的数据库变化历史记录，例如所有的DML变化（INSERT、UPDATE、DELETE和SELECT FOR UPDATE）和所有DDL语句造成的数据字典对象的更改及递归语句的更改等，所以redo文件可以最大限度地保证数据的一致性与安全性。万一数据库出现故障可以启用数据恢复。但是redo日志被误删了怎么办呢？本文通过一个案例来了解一下redo日志被误删，强制开库遭遇ORA-16433，供大家参考。
因为最近需要做一个测试，就顺手搭建了一套简单的dg环境。不过碰到了一些小问题。 数据库环境是11gR2，备库是开在open状态，配置了dg broker,一切都很快完成了。备库状态为"READ ONLY WITH APPLY"当然这是期望之中ADG的状态。 然后在主库需要做一些配置，准备创建几个表空间 先创建了一个表空间 create tablespace testdata datafile '/DATA/app/oracle/oradata/test04/testdata01.dbf' size 100
今天创建了一些表空间，准备做data guard来看看效果。 为了方便起见，我用gridcontrol来做，主库也开了Omf,省去了好多步骤。 一路点下来，就等gc的那个状态变成对号了，结果装了近20分钟，alert日志开始报错。 ******************** WARNING *************************** The errors during Server autobackup are not fatal, as it is attempted after sucess
作者简介 胡中豪 云和恩墨西区交付工程师，多年一线 DBA 经验，曾服务于运营商、电网、政府行业、银行等行业客户；擅长数据库故障处理、性能优化、实施升级 本文由恩墨大讲堂147期线上分享整理而成。课程
本文阐述了Oracle ADG备库SYSAUX数据文件坏块恢复处理（ORA-00600,ORA-10567,ORA-10564,ORA-01110,ORA-10561）的思路、步骤、解决方案。
客户的一套开发环境，大概了解到的背景是清理空间时redo被运维人员当作log误删除，一线同事先接手处理，过程中遇到问题升级到我这里继续分析。 接手后，数据库处于mount状态，之前恢复过程中已经做过resetlogs的操作，也设置了"_allow_resetlogs_corruption"隐藏参数为true，目前直接开库会提示需要恢复，重新进行resetlogs时报错ORA-600 [2662]，起初看到这个错误心中略有些放松，根据经验，推下SCN就好了：
这是一次来自生产实践的真实案例，某客户核心生产库由于进行新老存储替换变更操作后，Oracle RAC 两个节点均无法打开，数据库遭遇严重故障。
Total System Global Area 914358272 bytes Fixed Size 2088184 bytes Variable Size 528483080 bytes Database Buffers 377487360 bytes Redo Buffers 6299648 bytes Database mounted. ORA-01157: cannot identify/lock data file 8 – see DBWR trace file ORA-01110: data file 8: ‘/var/opt/gssyneeadb/gssy_neeadb.dbf’
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
