科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道Oracle性能优化:drop table与db cache

Oracle性能优化:drop table与db cache

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

【IT168 技术文档】我们都知道drop table, truncate table时都会先做一次checkpoint,将被删除对象的脏块写入磁盘。次测试后,需要把测试产生的大量用户及其对象全部删除,删除用的是drop user username cascade。

来源:IT168网站 2009年12月9日

关键字:

  • 评论
  • 分享微博
  • 分享邮件

  【IT168 技术文档】我们都知道drop table, truncate table时都会先做一次checkpoint,将被删除对象的脏块写入磁盘。

  客户有一套系统,Oracle 9.2.0.8,需要做数据迁移,由于种种原因,采用的是逻辑迁移的方式。由于库比较大,超过了1.5T,而停机时间又有限,因此在正式迁移之前需要做大量的测试,测试的目的,一方面是看迁移流程上是否存在问题,另一方面是看迁移的时候,哪个地方会存在性能瓶颈,并进行优化,同时估算实施迁移时间。

  第一次测试后,需要把测试产生的大量用户及其对象全部删除,删除用的是drop user username cascade。不幸的是这种方式删除得相当地慢。一个9000多个表的用户,删除了1个半小时才删除了4000多个表。为什么这么慢?有没有办法提高速度?

  drop table既然要做checkpoint,那么在db cache非常大的情况下,这需要消耗的时间是比较长的。如果能够减少这个时间无疑将大幅提高速度。首先尝试做一次checkpoint,将buffer cache全部刷新出去:

  view plaincopy to clipboardprint?

  alter system checkpoint;

  alter session set events 'immediate trace name flush_cache level 1';

  alter system checkpoint;

  alter session set events 'immediate trace name flush_cache level 1';

  发现没什么效果。

  由于db_cache_size有50GB左右,db_keep_cache_size有6G左右。重新设置参数,将db_keep_cache_size设为0,将db_cache_size设为200M,重启一下数据库,重新执行删除用户的操作,操作很快完成。

  在另一次同样的过程中,采用同样的修改参数的方式,效果同样非常明显。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章