recovery

“时间线”（Timeline）是PG一个很有特色的概念，在备份恢复方面的文档里面时有出现。但针对这个概念的详细解释却很少，也让人不太好理解，我们在此仔细解析一下。 时间线的引入 为了理解引入时间线的背景，我们来分析一下，如果没有时间线，会有什么问题？先举个将数据库恢复到以前时间点的例子。假设在一个数据库的运行过程 中，DBA在周三12:00AM删掉了一个关键的表，但是直到周五中午才发现这个问题。这个时候DBA拿出最初的数据库备份，加上存在归档目录的日志文 件，将数据库恢复到周三11:00AM的时间点，这样就能正常启动和运行。但是，DBA后来意识到这样恢复是不对的，想恢复到周四8:00AM的数据，这 时会发现无法做到：因为在数据库不断运行中，会产生与旧的WAL文件重名的文件，这些文件进入归档目录时，会覆盖原来的旧日志，导致恢复数据库需要的 WAL文件丢失。为了避免这种情况，需要区分原始数据库历史生成的WAL文件和完成恢复之后继续运行产生的（重名的）新WAL文件。整个过程如图1所示： 为了解决这个问题，PostgreSQL引入了时间线的概念。每当归档文件恢复完成后，创建一个新的时间线用来区别新生成的WAL记录。WAL文件名由时间线和日志序号组成，源码实现如下： #define XLogFileName(fname, tli, log, seg) \ snprintf(fname,

环境： pg版本：PostgreSQL 9.4.4 on x86_64 系统版本：CentOS release 6.6 linux内核版本：2.6.32-504.8.1.el6.x86_64 今天测试standby延时复制时，在standby节点配置了recovery_min_apply_delay参数，刚开始设置的是5min，但重启完standby节点后，连接数据库直接报：psql: FATAL: the database system is starting up 错误，我一开始以为是节点中的backup标签有问题，之前曾经碰到过这个报错，是由backup的标签引起的，当时是删掉该标签就可以了，然后查看错误日志，错误日志中没有和backup标签有关的报错信息。怀疑是recovery_min_apply_delay参数的问题，将recovery_min_apply_delay从recovery.conf中去掉，重启，可以连接，重新调整recovery_min_apply_delay值得大小为5s，也可以连接，然后再设为5min，发现仍然报psql: FATAL: the database system is starting up错误，查阅官方文档，没有这方面的说明。 下面是测试内容: 1、将recovery_min_apply_delay参数设为5s： recovery_min

USE [ master ] ALTER DATABASE 数据库名 SET RECOVERY SIMPLE WITH NO_WAIT ALTER DATABASE 数据库名 SET RECOVERY SIMPLE --简单模式 USE 数据库名 DBCC SHRINKFILE ( N '数据库名_log' , 2 , TRUNCATEONLY ) --设置压缩后的日志大小为2M，可以自行指定 USE [ master ] ALTER DATABASE 数据库名 SET RECOVERY FULL WITH NO_WAIT ALTER DATABASE 数据库名 SET RECOVERY FULL --还原为完全模式 来源： https://blog.csdn.net/u011045266/article/details/99309340

windows2008上的数据库版本为11.2.0.4.0，数据库打开为mount状态。报错如下： SQL> startup ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 779080 bytes Variable Size 535043256 bytes Database Buffers 1073741824 bytes Redo Buffers 1048576 bytes Database mounted. ORA-01113: file 1 needs media recovery ORA-01110: data file 1: 'c:\app\administrator\oradata\orcl\system01.dbf' 解决方法： SQL> RECOVER DATAFILE 'c:\app\administrator\oradata\orcl\system01.dbf' Media recovery complete. SQL> recover tablespace system; Media recovery complete. SQL> RECOVER DATABASE; Media recovery complete. SQL> ALTER

使用_allow_resetlogs_corruption打开无归档日志rman备份库 rman还原恢复操作 --还原数据库 RMAN> restore database; --恢复数据库 RMAN> recover database; Starting recover at 2012-03-08 21:20:45 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=65 device type=DISK starting media recovery RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 03/08/2012 21:20:47

一、实验说明： 本文转载于Luocs的丢失控制文件恢复实验记录--1，此处属于转载+模拟。 操作系统：rhel 5.4 x32 数据库：oracle 11g r2 二、实验操作： ----备份当前控制文件---- 1 RMAN > backup current controlfile; 2 3 Starting backup at 10 - JAN - 13 4 using target database control file instead of recovery catalog 5 allocated channel: ORA_DISK_1 6 channel ORA_DISK_1: SID = 17 device type = DISK 7 channel ORA_DISK_1: starting full datafile backup set 8 channel ORA_DISK_1: specifying datafile(s) in backup set 9 including current control file in backup set 10 channel ORA_DISK_1: starting piece 1 at 10 - JAN - 13 11 channel ORA_DISK_1: finished piece 1 at 10 - JAN -

一、实验说明： 本文转载于Luocs的丢失控制文件恢复实验记录--2，此处属于转载+模拟。 操作系统：rhel 5.4 x32 数据库：oracle 11g r2 二、实验操作： ----重新备份一个当前控制文件,这里也可以使用backup current controlfile---- 1 RMAN > backup as copy current controlfile; 2 3 Starting backup at 10 - JAN - 13 4 allocated channel: ORA_DISK_1 5 channel ORA_DISK_1: SID = 42 device type = DISK 6 channel ORA_DISK_1: starting datafile copy 7 copying current control file 8 output file name =/ u01 / app / oracle / flash_recovery_area / YFT / controlfile / o1_mf_TAG20130110T132142_8gwmz7rd_.ctl tag = TAG20130110T132142 RECID = 2 STAMP = 804345704 9 channel ORA_DISK_1: datafile copy

This is a follow up question to a previously answered post: Is there a command line utility for validating SQLite databases in Linux? If a database is producing the following error: $ sqlite3 mydata.db "PRAGMA integrity_check" Error: database disk image is malformed Is there any cleanup processing that can be done to recover the database to a usable state? Even at the potential loss of some corrupt records? Thanks If there were any automatic method, SQLite would already be able to do it. Sometimes, the corruption is only or mostly in indexes, in which case it would be possible to get some or