Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

73

积分

0

好友

3

主题
1#
发表于 2012-6-26 23:27:15 | 查看: 9829| 回复: 9
1.问题描述:线上库有个一含有2亿多条记录的数据,现在是通过DELETE FROM TBSEARCH_CHARTS_PRODUCT_RANKIN WHERE PRDATETIME <= TO_DATE('2012-05-31','yyyy-mm-dd') AND ROWNUM<=10000 来删除数据。但是保留最近的数据,并且每晚用脚本插入新的数据,所以不考虑truncate。
问题就出来了,undo表空间全部耗尽了。这个该如何处理。
2.有人说应该对于那条delete采用了并行处理,所以导致undo中active居高不下,我从哪个视图或表能证明这一点。
3.我问了开发人员,是没删除1万条就commit一次。
数据库版本为10.2.0.4
SQL> show parameter undo;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                             integer     900
undo_tablespace                          string      UNDOTBS1

SQL> select status,sum(bytes)/1024/1024  from dba_undo_extents group by status;
STATUS    SUM(BYTES)/1024/1024
--------- --------------------
UNEXPIRED               1.4375
EXPIRED                  4.875
ACTIVE                98297.25

SQL> select usn,xacts,status,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks
   from v$rollstat order by rssize;  2  
       USN      XACTS STATUS          RSSIZE/1024/1024/1024 HWMSIZE/1024/1024/1024    SHRINKS
---------- ---------- --------------- --------------------- ---------------------- ----------
         1          0 ONLINE                     .000114441             .666130066       4477
        13          0 ONLINE                     .000114441             .427055359        123
        12          0 ONLINE                     .000114441             .318107605        132
         2          0 ONLINE                     .000114441               3.969841       4823
         3          0 ONLINE                     .000114441             3.97557831       8460
         4          0 ONLINE                     .000114441             .249137878        684
         5          0 ONLINE                     .000114441             3.97374725       6966
         6          0 ONLINE                     .000114441             3.98044586       7644
         7          0 ONLINE                     .000114441             3.96159363       7523
         9          0 ONLINE                     .000114441             3.97277069       9448
        10          0 ONLINE                     .000114441             3.95519257      18476
        11          0 ONLINE                     .000114441             3.99375916      24368
        14          0 ONLINE                     .000175476             .991073608        323
         0          0 ONLINE                     .000358582             .000358582          0
         8          1 FULL                       3.99327087             3.99995422       7426

急,请赐教啊。明天在线等。
10#
发表于 2012-6-28 23:01:30

回复 8# 的帖子

maclean:
在您提到的第二个方法中,我去http://www.oracledatabase12g.com ... E4%B8%8Edelete.html 看了,并留了疑问,现在把疑问放到这里,请给解释下。
获取rowid分块的SQL脚本中,select * from cnt;这个cnt是个什么??

回复 只看该作者 道具 举报

9#
发表于 2012-6-27 15:34:33

谢谢大家了

嗯,谢谢大家了

回复 只看该作者 道具 举报

8#
发表于 2012-6-27 10:13:53
DELETE FROM TBSEARCH_CHARTS_PRODUCT_RANKIN WHERE PRDATETIME< SYSDATE-8   

显然这句是 批量 删除 , 而不是你说的一条条 删除


对于非分区表 的数据大规模删除:

1.  使用在线重定义    online
2. 利用rowid  划分分区删除        
利用rowid分块实现非分区表的并行update与delete http://www.oracledatabase12g.com ... E4%B8%8Edelete.html           online

3.  仅使用游标 串行rowid删除             online

回复 只看该作者 道具 举报

7#
发表于 2012-6-27 10:02:28
按时间分区,过期的直接turncate 掉 。。省的delele

回复 只看该作者 道具 举报

6#
发表于 2012-6-27 09:37:42

回复 5# 的帖子

那现在目前是不是只能建议开发把那两个语句先停掉吧。如果停掉,但是业务上有需要把将近2亿条数据清掉,只保留最近2周数据,有没有什么办法,来满足这个需求呢。

回复 只看该作者 道具 举报

5#
发表于 2012-6-27 09:20:17
系统中存在 大的DML 操作如下
  1. ############## Details on Long Run Queries ##############


  2. SQL ID        SQL Text                                                                         Last Load                              Elapsed Days
  3. ------------- -------------------------------------------------------------------------------- -------------------------------------- ------------
  4. 58qn43n42h1kk DELETE FROM TBSEARCH_CHARTS_PRODUCT_RANKIN WHERE PRDATETIME< SYSDATE-8           2012-06-24/00:39:49                         6502973
  5. 1dk2zft00hzh6 DELETE FROM TBSEARCH_CHARTS_PRODUCT_RANKIN WHERE PRDATETIME <= TO_DATE('2012-05- 2012-06-22/05:45:08                         5014468
  6. 9bys29hdjymn5 SELECT SUPCATID,SUPCATNAME FROM SUPERMARKET_CAT WHERE LENGTH(SUPCATID)=3         2012-06-26/09:13:59                             198
  7. cdnakywn4yry4 SELECT "A1"."ID","A1"."AREAID","A1"."PUBDATE","A1"."HOUR","A1"."INFORMATION_CNT" 2012-06-26/23:59:00                           16128
  8. 8szmwam7fysa3 insert into wri$_adv_objspace_trend_data select timepoint,  space_usage, space_a 2012-06-26/22:00:08                            7118
  9. agcn4w73kz7js INSERT INTO TBSEARCH__HIS_P (PRKEYWORD,PRPRODUCTCLASS,PRAREACLASS,PRTRADE,PRINFO 2012-06-23/23:15:55   
复制代码
注意以上2个 DELETE FROM TBSEARCH_CHARTS_PRODUCT_RANKIN  语句 消耗了大量undo

回复 只看该作者 道具 举报

4#
发表于 2012-6-27 09:17:41

回复 2# 的帖子

我把undo的诊断结果上传到论坛了。帮忙看看^_^

回复 只看该作者 道具 举报

3#
发表于 2012-6-27 09:15:23

上传undo的诊断结果

上传undo的诊断结果

Undo_Diag.out.txt

1.45 MB, 下载次数: 1201

回复 只看该作者 道具 举报

2#
发表于 2012-6-27 08:32:10
请运行 http://www.oracledatabase12g.com ... nostic-scripts.html 中提供的脚本 ,并上传运行结果

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 23:50 , Processed in 0.055605 second(s), 25 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569