ARCHIVELOG 的后果
负责我们服务器备份的人员在整个备份场景中使我们的数据库（一个大型数据库）离线超过 6 个小时。
我与他们交谈，询问我们是否可以将其分解为更小、更频繁的备份任务，即一次备份每个模式，甚至在不同时间备份一组表。
他们的答案是，如果我们决定转向归档日志，这是可能的，这会产生性能影响。
我对此非常不熟悉，就像对备份方法一样不熟悉。
你们会推荐哪些其他选项来以更有效的方式备份我的架构，或者至少不那么耗费停机时间？
谢谢！
f.
The guys responsible for the backup of our servers get our database (a large one) offline for over 6h for the whole backup scene.
I spoke to them asking if we could break that down to smaller and more frequent backup tasks, i.e. backing up each schema at time, or even sets of tables in different times.
Their answer was it was sort of possible if we decided to turn the ARCHIVELOG, which, would have performance consequences.
I'm quite unfamiliar with that just as much as with ways of doing backup.
Which other options would you guys recommend for backing up my schemas in a more efficient, or at least, not so down-time intensive way?
thanks!
f.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的数据库禁用了 ARCHIVELOG，则在发生硬件故障时您将丢失数据（可能是自上次备份以来输入的所有数据）。如果这是可以接受的，那么您可以禁用 ARCHIVELOG。
在生产实例上，通常要求不丢失数据（这将是 DBA 的主要目标）。在这种情况下，关于性能的争论毫无意义，您将打开 ARCHIVELOG，因为这是一个要求。然后你可以进行热备份，如果你使用RMAN，它们并不比冷备份更复杂，它们也不会刷新数据库缓存（提高性能）。您可以使用 RMAN 进行增量备份（而不是完整冷备份），该备份仅记录自上次备份以来的更改。
此外，通过足够的 IO（添加更多磁盘），您可以设置数据库，以便归档日志的写入不会明显影响性能。
if your database has its ARCHIVELOG disabled, you will lose data in case of a hardware failure (potentially all data entered since the last backup). If this is acceptable, then you can disable ARCHIVELOG.
On production instances it is common to have the requirement to NOT lose data (this would be the primary goal of a DBA). In that case the argument about performance is moot, you will turn ARCHIVELOG on because it is a requirement. Then you can have hot backups, they are not more complex than cold backups if you use RMAN, they also won't flush the database cache (improving performance). You can use RMAN to make incremental backups (instead of FULL cold backup) that will only log changes since the last backup.
Furthermore, with enough IO (add more disks), you can setup the database so that the writing of the archive logs doesn't impact performance noticeably.