我有一个支持单个应用程序的数据库服务器。遗憾的是，该服务器的大部分配置都由供应商严格控制。因此，如果我们做出更改，他们可能会停止支持。
显然他们的一个脚本已经停止运行，因为自 6 月 15 日以来，我们已经积累了大量文件，其名称格式如下：ARCxxxx_xxxxxxxxxx.001 它们基本上都不超过 25MB。这些文件是什么？内容是二进制的，它们似乎一旦写入就不会改变（查看此服务器的备份和增量中的内容）。我可以删除它们吗？根据与我们的工作周相比生成的数字，它们似乎是某种事务日志？
供应商支持人员没有提供任何帮助，只是告诉我“不应该发生这种情况，脚本应该可以处理这些问题。”但他们没有告诉我是哪个脚本。事件日志中没有错误记录。是否有 Oracle 日志可以告诉我哪个脚本失败了，以便我可以查看是否能找出原因？
服务器：Windows 2003 Oracle：10.2.0.3.0
答案1
ARC* 文件几乎肯定是存档重做日志。您不应删除它们，因为它们对于某些类型的恢复操作是必需的。此外，如果您使用 RMAN 进行备份，如果 RMAN 无法找到自上次备份以来的完整日志系列，则很可能会失败。
请注意，如果磁盘被这些日志填满，Oracle 将停止运行。如果磁盘开始变满，您可能需要将这些日志移动到另一台服务器以释放空间。
可以配置 RMAN 备份脚本以在备份后删除这些文件。旧式备份过程也会在数据库备份后删除这些文件。
我会开始研究备份是如何进行的，看看是否有任何东西在写入日志。遗憾的是，备份过程的日志记录非常依赖于编写备份脚本的人，因此我们无法真正为您提供太多帮助。
不过，您应该检查常规 Oracle 更改日志是否存在任何可疑内容。
您可以使用 SQLPLUS 访问数据库吗？
如果是这样，请连接到数据库并运行以下命令它将向您显示 Oracle 配置放置其跟踪文件的位置。
SQL> show parameter background_dump_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest string D:\oracle\admin\MyDataBase\bdump
此目录中应该有一个名为“alert_DATABASENAME.log”的文件，如果您没有 SQLPLUS 访问数据库的权限，只需在机器上搜索“alert_*.log”
此文件应该是查找任何 Oracle 异常的第一个地方。
不过，你可能得花点时间批评一下供应商才能解决这个问题。什么时候公司才能明白“嵌入” Oracle 到他们的产品中是个坏主意？
答案2
它们（最有可能）是存档重做日志。如果需要恢复，可能需要它们。
Oracle 不会自动删除它们。通常，您的备份过程（如 RMAN）会从其默认位置备份它们并删除它们。
这个数据库是如何备份的？如果你不知道，我会问供应商。这可能表明备份过程出了问题，可能会使你的数据处于危险之中。