我们有一个审计数据库（oracle），它保存部署在应用程序服务器上的服务（大约100个）执行的所有活动的监视器信息。您可能认为审计数据库非常庞大，因为服务处理的请求数量很大。此数据库上唯一的写入事务是实时编写审计信息的服务。
随着审计数据库的开始增长（每天超过一百万条记录），查询所需数据（例如select all errors occurred with service A for requests between start date and end date）很快变得几乎不可能。
为了解决这个问题，一些聪明的孩子＆＃34;决定设置批处理作业，将数据从数据库复制到另一个数据库（例如，audit_archives）并删除记录，以便在审计数据库中保留仅2天的审计数据。
这最初看起来很整洁，但每当批次＆＃34;进程运行时，将数据插入审计数据库的审计进程开始变得非常缓慢 - 有时候＆＃34;批处理＆＃34;由于数据库争用，进程也失败了。
设计此方案以更有效的方式执行上述归档的更好方法是什么，以便对审计流程和批处理产生最小的影响？
答案 0 :(得分：2)
您可能希望研究对基表进行分区。
创建一个镜像表（作为＆＃34;历史＆＃34;数据的目标）并在该表上创建相同的分区方案（最有可能是基于每个日期）。
然后你可以简单地交换＆＃34; old＆＃34;从一个表到另一个表的分区（使用ALTER TABLE the_table EXCHANGE partition）。应该只花几秒钟来“移动”＃34;分区。实际性能取决于定义的索引（本地，全局）。
这种技术通常用于反过来（准备将新数据输入到数据仓库环境中的报告表中），但应该适用于＆＃34;归档＆＃34;同样。
答案 1 :(得分：0)
我很轻松。
II队列