书上摘抄 ---深入浅出mysql 448页  grant reload on *.* to 'backup'@'localhost' identified by '123456'; grant reload,lock tables on *.* to 'backup'@'localhost' identified by '123456'; grant reload,lock tables,replication client on *.* to 'backup'@'localhost' ide

本文主要描述Oracle备库日志与主库日志之间有gap,切主库这部分gap的归档日志已经删除或丢失,如何在不重建备库的情况下,恢复备库. 欢迎转载,请注明作者.出处. 作者:张正 blog:http://space.itpub.net/26355921  QQ:176036317 如有疑问,欢迎联系. 在dataguard环境中,由于主库archivelog丢失,且尚未同步到standby,问如何在避免 重建standby的情况下来将standby恢复成功的. 下面是我的测试过程,供参考! —-

数据从主库恢复到备库:打开备库发现出现异常 SQL> alter database open; alter database open * ERROR at line 1: ORA-10458: standby database requires recovery ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/u01/app/oradata/orcl/syst

1.先查找备库控制文件路径 先在备库上找出控制文件的路径,通过和主库一样,不过为了以防万一,还是check为好. SQL>  select name from v$controlfile; NAME -------------------------------------------------------------------------------- /Oracle/app/oracle/oradata/powerdes/control01.ctl /oracle/app/oracle/

环境: OS: CentOS 6.5 X64 DB: oracle 10.2.0.5 故障:之前由于错误激活备库主写导致主备日志同步,重建备库 1.关闭备库,删除数据文件及控制文件,redo文件 rm -rf *.log rm -rf *.ctl rm -rf *.dbf 2.主库备库 channel ORA_DISK_1: starting piece 1 at 13-SEP-14 RMAN-00571: ============================================

数据库版本: test=# select version(); version ---------------------------------------------------------------------------------------------------------------------- KingbaseES V008R006C005B0041 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复 环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境 主库: SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database; DBID NAME LOG_MODE OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE

非常抱歉!今天 12:03-12:52 ,由于数据库连接数异常突增超过1万,达到了阿里云RDS的最大连接数限制,影响了全站的正常访问.由此给您带来麻烦,请您谅解. 在发现数据库连接数突增的问题后,我们一开始怀疑可能是我们的某些应用中产生太多ADO.NET连接引起的,但是对嫌疑的应用们进行重启后,连接数依然高居不下. 后来,我们回想起去年9月份遇到的一次数据库问题,当时很多数据库查询超时,IOPS突增达到RDS的最大限制.开始我们也是从应用层面下手,但怎么也解决不了,后来实在没办法,试了试主备库切

客户有套data guard环境,主库在阿里云上,备库在本地机房,现在想定期做备份,但是因为一些原因,备份阿里云上的主库实现会有些问题,所以只能备份本地的备库.目前需求就是测试备库的备份文件是否可以进行恢复,当误删除等操作之后,能否通过备份找回数据.以下为具体的测试: 1. 在data guard的备库进行完整+归档的备份 RMAN> run { > allocate channel t1 type disk; > allocate channel t2 type disk; >

​ 案例说明: 此案例是在KingbaseES V8R6集群环境下,当主库磁盘空间不足时,执行sys_rman备份,将集群的备库节点作为repo主机,执行备份,并将备份存储在备库的磁盘空间. 集群架构状态: [kingbase@node102 bin]$ ./repmgr cluster show ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string ----+-----

oracle 利用flashback将备库激活为read wirte(10g 及上) 环境: OS: CENTOS 6.5 X64 DB: ORACLE 10.2.0.5 主库操作: SQL> alter system switch logfile; System altered. SQL> 备库操作 取消归档应用 SQL> alter database recover managed standby database cancel; Database altered. SQL>

  演练包括被动切换和主动切换两部分.被动切换是主库宕机,主动切换是人工手动触发.   演练步骤大致如下:       1 先停掉主库,模拟主库宕机     2 mha将vip切到备库,备库变成主库,应用可以正常读写数据库     3 重新启动宕机的原主库     4 在原主库上建立同步关系(根据宕机时,日志记录的binlog的文件名和偏移量,恢复从这里开始)     5 mha手动切换主库,还原到最初状态,应用可以正常读写数据库     6 演练结束     演练过程问题总结:   1 mha

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致MRP进程自动断开,处理方式. 1.问题环境模拟 1)正常情况下的dg 主库创建数据文件,备库接受日志,自动创建表空间及数据文件. RFS[49]: Selected log 4 for thread 1 sequence 115 dbid 699220720 branch 994543603 Fri Feb 22 23:20:36 2019 Media Recovery Log /u01/app/oracle/

本篇文档学习,DG备库,实时应用如何判断,MR进程,及MRP应用归档,三种情况的查询及验证 1.取消MRP进程 备库查询进程状态select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby;PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS--------- -------- ---------- ------------ ---------- -

DG备库无法接受主库归档日志之密码文件 实验目的:还原某个客户案例,客户审计需要,对主库sys用户进行锁定,一小时后对sys用户进行解锁后,发现备库无法接受主库的归档日志 本篇文章,测试sys用户与DG备库接受归档有什么关系? 1. 实验环境: 类别 主库 备库 软件版本 11.2.0.4.0 11.2.0.4.0 是否RAC 否 否 Db_name ENMO Db_unique_name ENMO dage Service_name ENMO dage Listener.ora 192.168

概述: 一.环境      主库:       ip地址:192.168.122.203       oracle根目录:/data/db/oracle       SID:qyq       数据文件路径/data/db/oracle/oradata/qyq       归档文件路径:/data/db/oracle/archive'      备库:       ip地址:192.168.122.204       oracle根目录:/data/app/oracle       SID:qy

一.安装与备份 1. 下载安装XtraBackup$wget http://www.percona.com/redir/downloads/XtraBackup/LATEST/binary/tarball/percona-xtrabackup-2.2.5-5027-Linux-x86_64.tar.gz$tar xf percona-xtrabackup-2.2.5-5027-Linux-x86_64.tar.gz#cd percona-xtrabackup-2.2.5-Linux-x86_64

1.使用快照先决条件:主备库开启闪回功能 2.把备库转为快照库 DGMGRL> convert database satest to SNAPSHOT STANDBY; Converting database "satest" to a Snapshot Standby database, please wait... Database "satest" converted successfully 3.把快照库转回物理备库 DGMGRL> conver

在实际运营环境中,我们经常碰到类似这样的需求,譬如想不影响现网业务评估DB补丁在现网环境中运行的时间,或者是想在做DB切换前想连接Standby DB做实际业务运行的测试,如果在9i版本的时候,想做到这样,在不搭建新测试环境的前提下,可以将Standby DB激活后进行测试,但是激活后的Standby DB将不能再用于容灾,必须重建Standby DB.在10g以及11g之后,可以利用新特性很好的解决这个问题,激活的Standby DB可以闪回到激活前的状态,继续参与容灾,而不需要重建. 下面简

故障描述: 主库异常下线,需要将备库强制启动为主库,切断日志时提示需要介质恢复,执行介质恢复后,再激活日志即可进行切换 1.  执行alter database recover managed standby database finish force; 发现需要恢复介质 2.  确认归档日志目录中是否存在最近的日志 检查发现该目录中只有最开始建立时的3个日志,没有1月22日调整时的日志,检查发现是因为计划任务中有删除归档日志这个任务导致,至少说明后面的日志都已应用 3.  确认归档日志文件是否

问题现象 在使用shutdown abort停DataGuard备库后.备库不能open,报ORA-01196错误. 详细例如以下: 发现一备库不能应用日志.查看备库日志没发现报错.怀疑是备库应用日志服务停止,于是尝试重新启动备库. 可能由于备库是读业务比較繁忙,在shutdown immediate关闭备库时等时间过长,于是使用了shutdown abort命令: 但后面在启动备库时发生报错,造成数据文件损坏,控制文件和数据文件的scn号不一致. --启动备库时报错 SQL> startup