前段时间做了一下zfs做pg的增量恢复测试,mark一下. 服务器信息: 主机:192.168.173.43 备机:192.168.173.41 主备使用流复制搭建,在备机上面进行了zfs快照备份. 做zfs快照备份: 备机: 1.在2016-04-02 15:43:34对存放pg数据的zfs dataset zp1/data01进行快照备份.…

--RMAN备份介质的移动与再恢复测试 ---------------------------------------------------------2013/09/21   由于目前生产环境中没有集中的备份条件,所以备份要考虑到可以移动再恢复性.这里要测试的就是,RMAN全部备份的介质,我关注是否可以定期的移动到其他存储介质中,到要恢复的时候再拿过来.   1. 备份现有数据库和控制文件. RMAN> backup database include current controlfile;…

--RMAN恢复测试实战   RMAN> list backup;   using target database control file instead of recovery catalog   List of Backup Sets ===================     BS Key  Type LV Size       Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------…

日常的数据备份及恢复测试,是DBA工作重中之重的事情,所以要做好备份及测试,日常的备份常见有mysqldump+binlog备份.xtrabackup+binlog备份,无论那一种,几乎都少不了对binlog的备份,说明了binlog在数据恢复中的重要性,下面做个小测试,是工作中不少运维或者新人DBA容易犯的错. 创建一个测试表tb1: <test>(root@localhost) [xuanzhi]> show create table tb1\G ******************…

Mongodb5节点异地两中心故障转移恢复测试案例 架构方式:5节点,主中心(2数据1仲裁),备中心(1数据1仲裁) 1基本情况 操作系统:Red Hat Enterprise Linux Server release 6.3 (Santiago) Mongodb版本:db version v3.6.3 Mongodb架构: Ip,端口规划 "hosts" : [##数据节点 "10.15.7.114:28001",#主中心 "10.15.7.114:28…

数据库版本:Oracle 12.2.0.1 本篇为<执行PDB的PITR恢复失败的说明 (文档 ID 2435452.1)>的证明篇,通过当前控制文件,无法在PDB级别进行PITR(Point In Time Recovery)恢复出被DROP的表空间,因为当前控制文件没有记录该表空间(数据文件),必须想办法对控制文件下手,但是控制文件是CDB共享的,意味着将要影响所有数据库.具体是否要通过恢复控制文件副本(或手工重建),根据实际情况自行决定. 官方给出的意见是用目录库进行恢复.在不动控制文件…

Oracle 12.1版本中,UNDO表空间仅存在CDB级别(共享UNDO),来自于AskScuti博客园. Oracle 12.2版本开始,UNDO表空间同时可以存在每个PDB级别(本地UNDO). 问题表现前提:在12.2.0.1 多租户环境.备份后删除表空间并进行PDB PITR恢复.PDB采用本地UNDO(LOCAL_UNDO_ENABLED=TRUE) MOS 文档 ID 2435452.1 (建议使用 Catalog) 目录 1. 问题现象 2. 原因 3. 方案 1. 问题现象 在…

本次测试目的是从生产数据库导出rman备份然后在测试数据库恢复 1,拷贝备份至相应目录 2,进入rman rman target \ 3,关闭数据库 shutdown 4,以nomount模式启动数据库 startup nomount 5,恢复控制文件 restore controlfile from ' /home/oracle/rman_backup/cf_c-1383295282-20171102-00'; 6,挂载数据库 alter database mount; 7,设置catalog…

前提:如果namenode没有做HA,那么至少应该启用secondarynamenode,以便namenode宕机之后手动恢复数据 实验环境:3个节点(cenos 6.10) 测试前数据: 1.为了确保数据尽可能恢复,手动checkpoint一下 [root@hadoop1 dfs]# hdfs secondarynamenode -checkpoint force /************************************************************ STA…

(一)问题背景 最近在生产环境中,开发人员误操作,使用truncate将oracle数据库某个表的数据全部删除了,在删除之后,开发人员发现自己闯祸了,于是联系值班的DBA进行紧急数据恢复. 经过分析,表被truncate后,使用一般的闪回表.闪回查询.闪回事物等方法,是不可能将数据找回来的,可以使用闪回数据库.闪回数据归档的方法来进行恢复,但是通常在生产环境中,都不会开启这2个特性,所以剩下的只有使用RMAN进行数据恢复了. 对于使用RMAN进行数据恢复,可以在生产环境上直接进行,也可以恢复到其…