备库查询导致的ORA-01110错误及修复

   最近帮助业务部门解决了一个技术问题,因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来,当我看到他们提供的语句,在备库做了简单的数据评估之后,发现数据量比想象的要多,大概有200万条左右的数据,而业务部门手头有一个excel文件,需要和这些数据做一些比对,当然停了下筛选逻辑还蛮复杂,最开始建议他们数据量太大,使用excel还是可能出问题,但是业务部门认为应该没有太大的问题,他们会有excel中的公式等来处理,想想也有道理,就提供给了他们一个近40M的文件。
   等到快中午的时候,业务部门找到我说,两个excel文件做比对,电脑完全卡住了,还是想问问我看看有没有好的办法,从我的角度来看,这些操作用sql语句完全可以胜任,而且数据量更大都不是问题。简单了解了需求之后,和开发的同学确认了业务逻辑,就开始准备环境了,当然思路还是比较常规的,用外部表来实现。
    首先通过excel来得到需要的几列数据,生成csv文件或者文本文件均可。然后在目标数据库服务端创建外部表来读取这些文本数据,同时和相关的表做集合运算,比如Minus,intersect之类的操作,即可得到最终的结果。
    说起来容易,在实际操作中碰到了一个比较有意思的问题。
在备库中准备做这类的大查询,结果抛出了一个错误。创建的外部表为jeanron.temp_tab
select t1.cash,t1.TEST_TRANSACTION_ID ,t2.trade_no,t2.cash from TEST_NEW.TEST_detail t1,jeanron.temp_tab t2 where req_time >= to_date('2016-03-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') and req_time < to_date('2016-04-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') and status <> '1'  and pay_way_channel_code in ('44','45','46','15','16','17','18','19','91','93','94','146','147','148','149','150','151','159')
*
ERROR at line 1:
ORA-00376: file 21 cannot be read at this time
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
看问题提示无法读取21号文件,根据错误可以基本判断出来应该是文件在offline状态。
查看数据文件的状态,可以看到21号文件TEST_new_index04.dbf 目前是在RECOVER状态。

jeanron@TEST> select file_name,status,online_status from dba_data_files;
FILE_NAME                                             STATUS    ONLINE_
-------------------------------------------------------- --------- -------
/U01/app/oracle/oradata/TEST/TEST_new_data01.dbf         AVAILABLE ONLINE
/U01/app/oracle/oradata/TEST/system01.dbf                AVAILABLE SYSTEM
...
/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf        AVAILABLE RECOVER
这个问题看起来比较奇怪,查看主库中的数据文件状态,都已经是online,说明在过去的某一个时间出现过一个相关的小问题。
对于这类问题,一个比较快捷的解决方法就是从主库生成备库控制文件,然后启动数据库到Mount阶段即可。
但是这一次还是出了差错,把生成的备库控制文件拷贝到备库替换之后,重启数据库,dg broker报了下面的错误。
DGMGRL> show configuration;
Configuration
  Name:                TEST
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Fast-Start Failover: DISABLED
  Databases:
    TEST   - Primary database
    sTEST4 - Physical standby database
    sTEST2 - Physical standby database

Current status for "TEST":
Warning: ORA-16607: one or more databases have failed
查看alert日志,报出了ORA-01110的错误。
RFS[1]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2016_04_12/o1_mf_1_8158_cjs8mqfp_.arc'
Tue Apr 12 15:24:33 2016
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  NODELAY
Tue Apr 12 15:24:33 2016
Attempt to start background Managed Standby Recovery process (TEST)
MRP0 started with pid=23, OS id=10683
Tue Apr 12 15:24:33 2016
MRP0: Background Managed Standby Recovery process started (TEST)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1110
Tue Apr 12 15:24:38 2016
Errors in file /U01/app/oracle/admin/TEST/bdump/TEST_mrp0_10683.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Tue Apr 12 15:24:38 2016
Errors in file /U01/app/oracle/admin/TEST/bdump/TEST_mrp0_10683.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Tue Apr 12 15:24:38 2016
MRP0: Background Media Recovery process shutdown (TEST)
根据错误可以看出应该是文件校验的时候有问题,creation SCN校验出现了问题。
而这个时候查看dg broker中的verbose明细信息,显示这个备库目前的状态为:
Current status for "sTEST2":
Error: ORA-16766: Redo Apply unexpectedly offline
对于这个问题,要想修复SCN的部分,有一个策略就是BBED,但是线上库,而且考虑这种风险,与其BBED修改,我更愿意保险一些重建备库。
不过重建备库是最后的方案,我来看看有没有其它的方案。
这个数据文件通过查看明细信息发现已经处于这种状态很久了,也就意味着这部分信息在控制文件中已经无法保留,数据文件的SCN还是很早之前,比如半年前的SCN情况。这个时候如果尝试做recover肯定是不现实的,归档保留也不会那么久。不过因为是备库,所以这个问题还好办一些,那就是从主库还原恢复即可。
这个数据文件大概有5G左右,目前使用率在60%,rman备库数据文件大概有3G左右。
所以拷贝数据文件的备份集到备库之后,使用catalog start with的方式进行还原。
RMAN> catalog start with '/U01/app/oracle/temp';
using target database control file instead of recovery catalog
searching for all files that match the pattern /U01/app/oracle/temp
List of Files Unknown to the Database
=====================================
File Name: /U01/app/oracle/temp/full_1804_908984436_1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /U01/app/oracle/temp/full_1804_908984436_1
RMAN> restore datafile 21;
Starting restore at 12-APR-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2976 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00021 to /U01/app/oracle/oradata/TEST/TEST_new_index04.dbf
channel ORA_DISK_1: reading from backup piece /U01/app/oracle/temp/full_1804_908984436_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/U01/app/oracle/temp/full_1804_908984436_1 tag=TAG20160412T154036
channel ORA_DISK_1: restore complete, elapsed time: 00:00:36
Finished restore at 12-APR-16

这个时候不用重启备库,数据文件的SCN就自然推进到了新的值,再次查看数据文件的状态就变为了ONLINE.
通过这个案例可以看出,对于数据文件的操作还是需要非常谨慎,对于数据文件的状态监控也应该是运维监控的一个重要参考。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
一、在创建表的时候加上主键的例子: create table stu( id number(5)primary key, name varchar2(20) ); 以上是一种主键约束。简单了解下。约束表中id列中的数据,要求不为空且不能重复。   二、修改表结构常用的3种操作: 1.在一个表中加入一个新的列 语法格式: alter table 表名 add ( 列名 数据类型 [default 默认值] [, 列名…]) 如果加一列不够,可以逗号之后再加一列。 【注意】alter 是DDL语句,一旦改动就
1 安装环境 在 Primary 库上安装数据库软件,并建监听和实例,在 Standby 库上安装数据库软件,并建监听,但不建实例。   Primary 库 Standby 库 操作系统 CentOS release 6.4  64 位 CentOS release 6.4  64 位 IP / 主机名 192. 183.3. 17/nn 192.183.3.145/kk 数据库软件版本 oracle 11.2.0.1.0 oracle 11.2.0.1.0 ORACLE_HOME / home/orac
安装了MySQL,在安装的过程中有些问题让我很注意,在安装的过程中我将步骤截了图,希望对有需要的人有所帮助,我的数据库是5.5.28这个版本的。以下是我的安装步骤: 在数据库行列,mysql的表现也是非常出色,现在与大家分享一下Mysql 5.5安装图解教程,供大家参考下 1.首先单击MySQL5.5.28的安装文件,出现该数据库的安装向导界面,单击“next”继续安装,如图所示: 2、在打开的窗口中,选择接受安装协议,单击“next”继续安装,如图所示: 3、在出现选择安装类型的窗口中,有“typica
丰富的函数可以简化用户的操作,让操作更加灵活,此外,由于函数的执行速度非常快,还可以提高MySQL的处理速度。 前面介绍到的Select语句及其条件表达式,Insert、Update和Delete语句及其条件表达式都可以使用这些函数。 MySQL函数包括数学函数、字符串函数、日期和时间函数、条件判断函数、徐彤信息函数、加密函数、格式化函数等。下面将详细介绍这些函数的使用方法。 1、数学函数 数学函数主要用于处理数字,包括整型、浮点型等。 2、字符串函数 字符串函数主要用于处理表中的字符串。 (1)假设利用
1.索引组织表:     在InnoDB存储引擎中,表都是按照主键顺序组织存放的,这种存储方式的表称为索引组织表,在innodb存储引擎表中,每张表都有主键,如果创建的时候没有显式定义主键,则InnoDB会按照如下方式选择或者创建主键:  1). 首先判断表中是否有非空的唯一索引,如果有,则该列就为主键。  2).   如果不符合上述条件,则innodb会自动创建一个6字节大小的指针  如果表中有多个非空唯一索引时,InnoDB将选择建表时第一个定义的非空唯一索引为主键,通过_rowid可以显示表的主键,

NoSQL数据库介绍(6) - 2016-04-14 15:04:08

6 面向列的数据库      在本章中将研究第三类NoSQL数据存储:面向列的数据库。以列来替代行存储和处理数据的方法起源于分析和商业智能,在一个无共享的大规模并行处理(注:MPP)架构中的列存储可用于构建高性能应用。这一领域引人注目的产品是Sybase IQ和Vertica([ Nor09 ])。然而,在这一章中,面向列的存储类型被视为少一些纯粹性,也包括了整合面向列和行的数据存储。它们也被描述为“[稀疏的]、分布式的、持久的多维排序[映射]”(例如[ Int10 ])。面向列的存储的主要灵感是Goog
1. 基本查询 select [all | distinct] 字段或表达式列表 [from子句] [where子句] [group by子句] [having子句] [order by子句] [limit子句]; SELECT 8 + 5 ; # 8 + 5 , 8 5 是表达式 SELECT name, 8 5 , 8 + 5 ,id+class_id,NOW(),CONCAT( 'a' , 'b' , 'c' ) FROM stu; 1.1 all和 distinct 用于设定select出来的数据
通用设备管理信息系统数据库 设备表:id,名称,类别,型号,投运日期,购入日期,制造单位,数量,计量单位,使用部门,安装 地点,产品图片,技术数据,备注; 缺陷表:id, 设备id,缺陷描述,处理情况,处理人员; 事故表:id,设备id,事故描述,处理情况,处理人员; 维修类别表:id,类别名称,维修内容,周期(天) 设备类别表:id,类别名称; 部门表:id,部门名称; 设备状态表:id,状态名称 设备状态: 指定设备的状态,其状态数据有:上线、封存、闲置、报废、待修、备用 维修人员表:id,姓名,部门,

【案例】复制静止问题一则 - 2016-04-14 14:04:54

一背景   早上7点多接到一个数据库服务器空间报警,磁盘空间不足。登陆数据库查看,MySQL slave 大量延迟,有68G 的relay log。查看slave status 发现Relay_Log_Pos ,Exec_Master_Log_Pos  位点始终不变,当时的状态展示如下: 二 分析 根据slave 复制的原理可知  relay_log_pos 是指sql_thread 进程读取relay log文件的位点,exec_master_log_pos是sql_thread 执行relay log

mysql 5.7 linux环境下安装 - 2016-04-14 04:04:26

第一步:环境准备       1. CentOS 6.5 、mysql-5.7.10-linux-glibc2.5-x86_64.tar.gz  、jdk1.7      2. jdk安装    3. rpm -qa|grep -i mysql 如果安装可以卸载 第二步:创建用户和用户组        groupadd  mysql  添加用户组     useradd    -r -g mysql mysql 创建一个不用登陆的用户(useradd-s /sbin/nologin -g mysql my