我有一个支持单个应用程序的数据库服务器。 令人遗憾的是，这个盒子的大部分configuration都是由供应商严格控制的。 所以如果我们改变了事情，他们可能会停止支持。
显然他们的一个脚本已经停止运行了，因为自从6月15日以来，我们已经积累了大量名称为以下格式的文件：ARCxxxxx_xxxxxxxxxx.001它们基本都在25MB以下。 这些文件是什么？ 内容是二进制的，一旦写入，看起来不会改变（查看这个服务器的备份以及增量中的内容）。 我可以删除它们吗？ 根据与我们的工作周相比所产生的数字，它们似乎是某种交易logging？
供应商支持还没有到来，刚刚告诉我“不应该发生，脚本应该处理它们”。 但他们不会告诉我哪个脚本。 我没有在事件日志中获得错误日志logging。 有没有一个oracle日志，可以告诉我哪个脚本失败，所以我可以看看，如果我能弄清楚为什么？
服务器：Windows 2003 Oracle：10.2.0.3.0
ARC *文件几乎可以肯定归档重做日志。 您不应该删除它们，因为它们是某些types的恢复操作所需的。 另外，如果您正在使用RMAN进行备份，那么如果自上次备份以来无法find完整系列的日志，RMAN可能会失败。
请注意，如果磁盘满了这些日志，Oracle将停止运行。 如果磁盘开始变满，您可能需要将这些日志移动到另一台服务器以释放空间。
RMAN备份脚本可以configuration为在备份后删除这些文件。 数据库备份后，旧式备份过程也将删除这些文件。
我会开始考虑备份是如何完成的，看看有没有什么东西在写日志。 不幸的是，logging备份程序非常依赖于写备份脚本的人，所以我们不能真正帮助你。
你应该检查一般的Oracle更改日志是否有可疑的东西。
你有使用SQLPLUS访问数据库吗？
如果是这样，请连接到数据库并运行以下命令它将显示Oracleconfiguration其放置跟踪文件的位置。
SQL> show parameter background_dump_dest NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ background_dump_dest string D:\oracle\admin\MyDataBase\bdump 在这个目录中应该有一个名为'alert_DATABASENAME.log'的文件如果你没有SQLPLUS访问数据库，只要在机器上search'alert _ *。log'
这个文件应该是第一个find任何Oracle古怪的地方。
你可能不得不殴打供应商一段时间才能得到这个固定的。 公司什么时候才会知道在他们的产品中“embedded”Oracle是一个坏主意？
他们（很可能）是归档重做日志。 如果需要恢复，可能需要它们。
它们不会被Oracle自动删除。 通常，您的备份过程（如RMAN）将从默认位置将其备份并删除。
这个数据库是如何备份的？ 如果你不知道，我会问供应商。 这可能是一个迹象表明，备份过程中可能导致数据易受攻击。