备份Oracle 10g时出现问题

发布于 2024-09-29 18:09:15 字数 538 浏览 7 评论 0原文

我刚刚开始工作,并发现了一个问题,可以说数据库当前没有得到正确备份。我们使用 Oracle 本机备份实用程序每 6 小时进行一次备份,但一家公司还向我们出售了一种流程,他们表示他们实际上可以通过简单地获取文件系统副本来对我们的数据库执行“热”备份我们的数据库文件,当我们需要恢复时,我们只需关闭 Oracle,然后复制已复制的文件,重新启动 Oracle,世界就会再次完整。挑战在于我们还没有让它发挥作用。我需要花更多时间查看 Oracle 提供的消息,但我的主要问题是,“是否可能”在 Oracle 仍在运行时获取 Oracle 文件的副本,并在以后使用这些文件来恢复数据库?我知道如果数据库关闭然后创建副本,它就可以工作,但这是我第一次听说可以在数据库运行时创建副本(文件系统)。任何指导将不胜感激。这是我们收到的错误。

ORA-00314: log 3 of thread 1, expected sequence# 1939 doesn't match 1944
ORA-00312: online log 3 thread 1: 'E:\ORACLE\ORADATA\ITMS\REDO03.LOG'

I've just started a job and have identified an issue in which the database isn't currently being backed up properly so to speak. We are doing one back up every 6 hours that uses the Oracle native backup utility, but we were also sold a process by a company in which they stated that they could in essence perform "warm" backups of our database by simply taking file system copies of our database files and when we needed to restore we'd simply shut down Oracle and then copy over the files that had been copied, restart Oracle and the world would be whole again. The challenge is the fact that we have not gotten this to work just yet. I need to spend some more time reviewing the message that Oracle is giving, but my primary question is, "Is it possible" to take copies of Oracle files while Oracle is still running and to use those files at a later date to restore the database? I know that it works if the database is shut down, and then copies are made, but this is the first that I've heard that a copy (file system) can be made while the database is running. Any guidance would be greatly appreciated. Here is the error that we are getting.

ORA-00314: log 3 of thread 1, expected sequence# 1939 doesn't match 1944
ORA-00312: online log 3 thread 1: 'E:\ORACLE\ORADATA\ITMS\REDO03.LOG'

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

归属感 2024-10-06 18:09:15

是的,这是可能的,但您必须先将所有表空间置于备份模式,然后再将其取出(例如ALTER TABLESPACE x BEGIN BACKUPALTER TABLESPACE x END BACKUP ;您需要检查语法并确保它适合您的情况!)。过于简单化,这告诉 Oracle 不要写入任何数据文件,因此它们都保持一致的状态。

否则,您遇到的两个主要问题是,在复制单个文件时会更新它们,因此单个文件可能会被损坏;更明显的是,不同的文件有不同的内部时间戳和序列,因此 Oracle 不允许使用它们。

如果您正在使用您购买的流程,那么它应该已经处理了所有这些问题。听起来备份没问题,但您还没有进行恢复。

我已经有一段时间没有参与从热备份的恢复了,所以其他人需要提供实际错误的详细信息。我的解读是,您尝试使用恢复的数据文件打开,但使用后来的实时重做日志。恢复时,我认为您必须使用自备份以来生成的重做日志来RECOVER数据库;或者或者,如果您尝试恢复到该时间点,则可以使用 RESETLOGS 指令打开数据,并丢失稍后出现的所有重做日志中的所有更改。但确实需要比这更明智的建议......

Yes, it is possible, but you have to put all the tablespaces into backup mode first and take them out afterwards (e.g. ALTER TABLESPACE x BEGIN BACKUP and ALTER TABLESPACE x END BACKUP; you'll need to check the syntax and make sure it's appropriate for your situation!). Oversimplifying hugely, this tells Oracle not to write to any of the data files, so they're all kept in a consistent state.

The two main problems you get otherwise are that individual files are updated while you're copying them so a single file can be corrupted; and more visibly that different files have different internal timestamps and sequences so Oracle won't allow them to be used.

If you're using a process you've bought in then it should already be taking care of all that though. It sounds the backup is OK and it's the restore that you haven't got working.

I haven't been involved in a restore from a hot backup for some time so someone else will need to give the detail on the actual error. My read of it is that you've tried to open with the restored data files but the later live redo logs. When restoring I think you either have to RECOVER the database using the redo logs generated since the backup was taken; or if you're trying to restore to that point in time then you can open the data with the RESETLOGS directive and lose all the changes from all the redo logs that came later. But really take more informed advice than this...

半世蒼涼 2024-10-06 18:09:15

据我所知,有两种方法可以从正在运行的 Oracle 实例中“复制”数据文件。

  • 数据文件被复制为
    表空间 当表空间位于
    “开始备份”模式。
  • 您正在使用高端日记本
    文件系统,例如 Veritas,可以
    快照和跟踪块
    文件系统上的更改,而
    复制正在进行。

As far as I know, there are two ways that you can "copy" datafiles from a running Oracle instance.

  • The datafiles are copied for a
    tablespace when the tablespace is in
    "BEGIN BACKUP" mode.
  • You are using a high-end journalling
    filesystem such as Veritas that can
    snapshot and track block
    changes on the filesystem while the
    copy is taking place.
少女净妖师 2024-10-06 18:09:15

这是可能的。您必须处于 ARCHIVELOG 模式。

一个示例脚本将用于手动:

Alter tablespace USERS begin backup;
host cp -p /u02/oradata/PROD/users01.dbf /u03/backup/PROD/
host cp -p /u02/oradata/PROD/users02.dbf /u03/backup/PROD/
Alter tablespace USERS end backup;

但是,我建议仅使用 RMAN。 RMAN 非常强大,免费提供,并且可以进行热备份和冷备份。它将克隆到另一个实例、克隆为一个时间点、恢复到某个时间点等。任何手动备份过程都应该迁移到使用 RMAN。

如果您想在打开时备份整个数据库(我更喜欢使用 Oracle 和 DBA,这样您就可以避免在脚本中使用密码,但是 ymmv):

$ ORAENV_ASK=NO
$ ORACLE_SID=PROD
$ . oraenv
$ rman target=/

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Oct 28 14:23:29 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: PROD (DBID=x)

RMAN> backup as compressed backupset database plus archivelog;

...

Backup Complete.

It is possible. You must must be in ARCHIVELOG mode.

An example script would be for manual:

Alter tablespace USERS begin backup;
host cp -p /u02/oradata/PROD/users01.dbf /u03/backup/PROD/
host cp -p /u02/oradata/PROD/users02.dbf /u03/backup/PROD/
Alter tablespace USERS end backup;

However, I would recommend just using RMAN. RMAN is QUITE ROBUST, included free, and will do the hot backup, as well as cold. It will clone to another instance, clone as a point in time, recover to a certain point in time, etc. Any manual backup procedure should be migrated to using the RMAN.

If you wanted to backup the entire database while it is open (I prefer as Oracle with DBA so you can avoid passwords in scripts, but ymmv):

$ ORAENV_ASK=NO
$ ORACLE_SID=PROD
$ . oraenv
$ rman target=/

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Oct 28 14:23:29 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: PROD (DBID=x)

RMAN> backup as compressed backupset database plus archivelog;

...

Backup Complete.
疯到世界奔溃 2024-10-06 18:09:15

我已经使用在 Amazon EC2 上运行的非任务关键型数据库有效地完成了此任务。我的备份策略是定期拍摄 EBS 卷的快照。为了恢复备份,我从快照创建一个新的 EBS 卷,使用它启动实例,然后运行RECOVER DATABASE

当然,这会丢失拍摄快照时正在进行的所有事务。

I've effectively done this with a non-mission-critical database running on Amazon EC2. My backup strategy is to periodically take a snapshot of the EBS volume. To restore a backup, I create a new EBS volume from the snapshot, start up the instance using it, then run RECOVER DATABASE.

This loses any transactions that were in-flight at the time when the snapshot was taken, of course.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文