当前位置：theitroad>database 如何重新复制损坏的物理备用数据库？

database 如何重新复制损坏的物理备用数据库？

声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow 原文地址: http://stackoverflow.com/questions/8135393/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示：将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间：2020-09-08 08:22:41 　来源:igfitidea点击:

How do you re-duplicate a broken physical standby database?

databaseoracleoracle11gstandby

提问by Crazy Bytes

first some data: we are using Oracle 11g databases. A primary database running on a dedicated server and a physical standby database on a separate dedicated server. We use the DataGuard feature to automatically replicate the primary database to the physical standby database in real time. The primary database is also backeed up through RMAN.

首先是一些数据：我们使用的是 Oracle 11g 数据库。在专用服务器上运行的主数据库和在单独专用服务器上的物理备用数据库。我们使用DataGuard 特性将主库实时自动复制到物理备库。主数据库也通过 RMAN 进行备份。

currently I am unable to cope a problem with our physical standby database. Somehow the transfer of the archive logs from the primary database to the physical standyby database has stopped, what it makes worse some of the archive logs already got deleted from some of our employees, now I can't issue a recovery by performing the following statement:

目前我无法处理物理备用数据库的问题。不知何故，存档日志从主数据库到物理备用数据库的传输已经停止，更糟糕的是一些存档日志已经从我们的一些员工那里被删除，现在我无法通过执行以下语句来进行恢复：

RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILE;

since the required archive logs are gone.

因为所需的存档日志已经消失。

So my thought was to re-duplicate the physical standby database. I shutdown the physical standby database and restarted it with STARTUP NOMOUNT. Then logged onto the server hosting the primary database and started a RMAN-session with:

所以我的想法是重新复制物理备用数据库。我关闭了物理备用数据库并使用 STARTUP NOMOUNT 重新启动它。然后登录到托管主数据库的服务器并使用以下命令启动 RMAN 会话：

RMAN target / auxiliary sys@PRIMARY_DB_DG
   RMAN> sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
   RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER
         NOFILENAMECHECK;

but shortly after altering the the physical standby database to MOUNT status the process crashes due to either

但是在将物理备用数据库更改为 MOUNT 状态后不久，由于任一原因，进程崩溃

  1. RMAN-04006: error from auxiliary database: ORA-12537: TNS:connection closed,

  2. RMAN-03009: failure of switch command on clone_default channel at 11/15/2011 11:13:58 ORA-03113: end-of-file on communication channel or

  3. RMAN-06136: ORACLE error from auxiliary database: ORA-03113: end-of-file on communication channel

  1. RMAN-04006：来自辅助数据库的错误：ORA-12537：TNS：连接已关闭，

  2. RMAN-03009：11/15/2011 11:13:58 在 clone_default 通道上的 switch 命令失败 ORA-03113：通信通道上的文件结束或

  3. RMAN-06136：来自辅助数据库的 ORACLE 错误：ORA-03113：通信通道上的文件结束

I have googled around for solutions, but only found guides to setup a physical standby database from scratch. So anybody knows howe to fix the physical database without setting it up completely new?

我已经搜索了解决方案，但只找到了从头开始设置物理备用数据库的指南。所以有人知道如何修复物理数据库而不用全新的设置吗？

Greetings, CB

问候，CB

采纳答案by Niall Litchfield

I'd look in the alert.log at the standby site to see what the errors were around the time of the failure of the rman session.

我会查看备用站点的 alert.log 以查看在 rman 会话失败时出现的错误。

In addition you won't necessarily have to do a full reinstantiation - you can apply incremental backups to a standby database to bring it up to date. See for example http://jarneil.wordpress.com/2008/06/03/applying-an-incremental-backup-to-a-physical-standby/

此外，您不必进行完全重新实例化——您可以将增量备份应用到备用数据库以使其保持最新状态。参见例如http://jarneil.wordpress.com/2008/06/03/applying-an-incremental-backup-to-a-physical-standby/

Niall

尼尔

回答by Crazy Bytes

Here is my solution that worked for me:

这是我的解决方案，对我有用：

  1. Shutdown the physical standby database

    SQL> shutdown immediate;

  2. (Optional, safer in case of failure) Backup all datafiles (*.dbf), redologs, archive logs, online logs, flashback logs and control files that are used by the shut down instance.

  3. Delete all datafiles (*.dbf), redologs, archive logs, online logs, flashback logs and control files in their referenced locations, but make sure to keep the directories.

  4. Start up your physical standyby database with NOMOUNT-Option

    SQL> startup nomount;

  5. Now switch to your primary database environment.

  6. Start your rman on you primary envoronment:

    $> rman target / auxiliary sys@Dataguard_instance

    Dataguard_instance must be substituted with your DataGuard instance name. After connect make sure your connected target database is your primary database

    connected to target database: PRIM_DB (DBID=4135917300)
auxiliary database Password:
connected to auxiliary database: PRIM_DB (not mounted)

    Note that your physical standby database is listed as not mounted primary database. If you see the same information as in target database, chances are that you are connected twice to your primary database. In that case we would create a 100% copy and not a physical standby database. So make sure you are using the right DataGuard instance.

  7. So before we start we force a log switch:

    RMAN> sql 'alter system archive log current';

  8. Now we are going to start the full replication of our physical standby database

    RMAN> duplicate target database for standby from active database dorecover  nofilenamecheck;

  9. Now rman will perform a duplication of your physical standby database. Depending on your datafile size, this can take from a few hours to open end (I needed about 4 hours during night when the primary database was idle for about 1,5T of files) .

  10. After rman is finished you can exit rman.

  11. Reconnect to your physical standby database and shut it down:

    SQL> shutdown immediate;

  12. If you use flashback option (else continnue with step 13):

    SQL> startup mount;
SQL> alter database flashback on;
SQL> alter database open;

  13. Restart physical standby:

    SQL> startup;

  14. Finished!

  1. 关闭物理备用数据库

    SQL> shutdown immediate;

  2. （可选，在发生故障时更安全）备份关闭实例使用的所有数据文件 (*.dbf)、重做日志、存档日志、在线日志、闪回日志和控制文件。

  3. 删除引用位置中的所有数据文件 (*.dbf)、重做日志、存档日志、在线日志、闪回日志和控制文件，但请确保保留这些目录。

  4. 使用 NOMOUNT-Option 启动您的物理备用数据库

    SQL> startup nomount;

  5. 现在切换到您的主数据库环境。

  6. 在您的主要环境中启动您的 rman：

    $> rman target / auxiliary sys@Dataguard_instance

    Dataguard_instance 必须替换为您的 DataGuard 实例名称。连接后确保您连接的目标数据库是您的主数据库

    connected to target database: PRIM_DB (DBID=4135917300)
auxiliary database Password:
connected to auxiliary database: PRIM_DB (not mounted)

    请注意，您的物理备用数据库被列为未安装的主数据库。如果您看到与目标数据库中相同的信息，则您可能两次连接到主数据库。在这种情况下，我们将创建 100% 副本而不是物理备用数据库。因此，请确保您使用的是正确的 DataGuard 实例。

  7. 所以在我们开始之前，我们强制进行日志切换：

    RMAN> sql 'alter system archive log current';

  8. 现在我们将开始我们的物理备用数据库的完整复制

    RMAN> duplicate target database for standby from active database dorecover  nofilenamecheck;

  9. 现在 rman 将执行物理备用数据库的复制。根据您的数据文件大小，这可能需要几个小时才能打开（当主数据库空闲大约 1.5T 的文件时，我在夜间需要大约 4 小时）。

  10. rman 完成后，您可以退出 rman。

  11. 重新连接到物理备用数据库并将其关闭：

    SQL> shutdown immediate;

  12. 如果您使用闪回选项（否则继续步骤 13）：

    SQL> startup mount;
SQL> alter database flashback on;
SQL> alter database open;

  13. 重启物理备机：

    SQL> startup;

  14. 完成的！

Hope that helps you to in case of need.

希望能在需要的时候帮到你。

回答by RMAN Express

Do you have Oracle Enterprise Manager Grid Control setup? Data Guard setup is point and click. Easiest way I have seen to setup a physical or logical standby database.

您是否安装了 Oracle Enterprise Manager Grid Control？Data Guard 设置是点击。我见过的设置物理或逻辑备用数据库的最简单方法。

相关推荐

database 如何从数据库中填充 h:selectOneMenu 的选项？

database 如何从数据库中填充 h:selectOneMenu 的选项？

database 如何从 MongoDB 文档中完全删除字段？

database 如何从 MongoDB 文档中完全删除字段？

database 何时在数据库上使用 LDAP？

database 何时在数据库上使用 LDAP？

database 如何停止 redis-server？

database 如何停止 redis-server？

相关推荐
最近更新
标签