首页 文章

Oracle从分区表中获取数据时出现问题

提问于
浏览
1

在一项新工作中,我必须弄清楚一些数据库报告脚本是如何工作的 . 有一张 table 给我带来了一些麻烦 . 我在现有脚本中看到它是一个分区表 . 我的问题是,我在这个表上运行的任何查询都返回“没有选择行” .

以下是我在此表中调查的一些细节:

Table size estimate

SQL> select sum(bytes)/1024/1024 Megabytes from dba_segments where segment_name = 'PPREC';

MEGABYTES
----------
45.625

Partitions

日期范围共有730个分区 .

SQL> select min(PARTITION_NAME),max(PARTITION_NAME) from dba_segments where segment_name = 'PPREC';

MIN(PARTITION_NAME)            MAX(PARTITION_NAME)
------------------------------ ------------------------------
PART20110201                   PART20130130

它们中分配了几个表空间和分区

SQL> select tablespace_name, count(partition_name) from dba_segments where segment_name = 'PPREC' group by tablespace_name;

TABLESPACE_NAME                COUNT(PARTITION_NAME)
------------------------------ ---------------------
REC_DATA_01                                       281
REC_DATA_02                                        48
REC_DATA_03                                        70
REC_DATA_04                                        26
REC_DATA_05                                        44
REC_DATA_06                                        51
REC_DATA_07                                        13
REC_DATA_08                                        48
REC_DATA_09                                        32
REC_DATA_10                                        52
REC_DATA_11                                        35
REC_DATA_12                                        30

附加查询:

SQL> select * from dba_segments where segment_name='PPREC' and partition_name='PART20120912';

OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE    TABLESPACE_NAME HEADER_FILE HEADER_BLOCK BYTES BLOCKS EXTENTS 
----- ------------ -------------- --------------- --------------- ----------- ------------ ----- ------ -------
HIST  PPREC        PART20120912   TABLE PARTITION REC_DATA_01              13       475315 65536      8       1

INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_POOL
-------------- ----------- ----------- ----------- ------------ --------- --------------- ------------ -----------
  65536                              1  2147483645                                                 13    DEFAULT

Tabespace usage

这是一个空间摘要(dba_tablespaces,dba_data_files,dba_segments,dba_free_space的复合)

TABLESPACE_NAME                TOTAL_MEGABYTES USED_MEGABYTES FREE_MEGABYTES
------------------------------ --------------- -------------- --------------
REC_01_INDX                              30,700            250         30,449
REC_02_INDX                               7,745              7          7,737
REC_03_INDX                              22,692             15         22,677
REC_04_INDX                              15,768             10         15,758
REC_05_INDX                              25,884             16         25,868
REC_06_INDX                              27,992             16         27,975
REC_07_INDX                              17,600             10         17,590
REC_08_INDX                              18,864             11         18,853
REC_09_INDX                              19,700             12         19,687
REC_10_INDX                              28,716             16         28,699
REC_DATA_01                             102,718            561        102,156
REC_DATA_02                              24,544          3,140         21,403
REC_DATA_03                              72,710              4         72,704
REC_DATA_04                              29,191              2         29,188
REC_DATA_05                              42,696              3         42,692
REC_DATA_06                              52,780            323         52,456
REC_DATA_07                              16,536              1         16,534
REC_DATA_08                              49,247              3         49,243
REC_DATA_09                              30,848              2         30,845
REC_DATA_10                              49,620              3         49,616
REC_DATA_11                              40,616              2         40,613
REC_DATA_12                             184,922        123,435         61,486

表空间用法似乎确认此表不为空,实际上它的最后一个表空间(REC_DATA_12)似乎非常繁忙 .

Existing scripts

令我感到困惑的是,有一些PL / SQL存储过程似乎在该表上工作并从中获取数据 . 这种存储过程的一个例子如下:

procedure FIRST_REC as
vpartition varchar2(12);
begin
select 'PART'||To_char(sysdate,'YYYYMMDD') INTO vpartition FROM DUAL;

execute immediate
'MERGE INTO FIRST_REC_temp a
 USING (SELECT bno, min(trdate) mintr,max(trdate) maxtr
        FROM PPREC PARTITION ('||vpartition||') WHERE route_id IS NOT NULL AND trunc(trdate) <= trunc(sysdate-1)
        GROUP BY bno) b
    ON (a.bno=b.bno)
    when matched then
    update set a.last_tr = b.maxtr
    when not matched then
    insert (a.bno,a.last_tr,a.first_tr)
    values (b.bno,b.maxtr,b.mintr)';
    commit;

但是,如果我尝试在表上手动使用相同的语法,这是我得到的:

SQL> select count(*) from PPREC PARTITION (PART20120912);

  COUNT(*)
----------
         0

我尝试了几个随机分区,我总是得到相同的0计数 .

Summary - 我看到一个似乎包含数据的表(使用的空间,表空间,数据文件) - 表被分区(在2013年1月底结束的730天期间每天一个分区) - 脚本从该表中提取数据不知何故

Question - 我使用PARTITION的查询都返回给我"no rows selected" . 我究竟做错了什么?我怎样才能知道如何从该表中提取数据?

1 回答

  • 1

    我想其他一些进程可能正在删除数据,但如果没有访问您的网站,那么这里的任何人都无法判断是否可能 .

    我在你的帖子中没有看到你提到了分区DATE列的名称,但根据你发布的SQL,我假设它是TRDATE - 如果这不正确,请在下面的语句中将TRDATE更改为分区列 .

    也就是说,尝试一下:

    SELECT COUNT(*)
      FROM PPREC
      WHERE TRDATE >= TO_DATE('01-SEP-2012 00:00:00', 'DD-MON-YYYY HH24:MI:SS')
    

    这假设您应该从9月开始在此表中包含数据 . 如果您找到数据,那很好 . 如果你不这样做 - 好吧,Back In The Day(当男人是男人,女人是女人,电脑是水冷的:-)我们对IBM大型机的内存有一点说法:

    1.  If you can see it,   and it's there,     it's Real.
    2.  If you can't see it, but it's there,     it's Protected.
    3.  If you can see it,   but it's not there, it's Virtual.
    4.  If you can't see it, and it's not there, it's GONE!
    

    :-)

    对于遇到性能问题的情况,应保留PARTITION子句的使用(注意:不允许猜测是什么或不会出现性能问题 . 直到您遇到性能问题 . 多年来我've found that software spends a lot of execution time in the darndest places :-), and the usual fixes (adding indexes, deleting unnecessary data, human sacrifice, etc) haven' t工作 . 基本上,正常编写查询并信任数据库以使其正确 . (在一般情况下 - 始终编写最简单的代码 - 并做最简单的事情 - 这可能有效 . 99%的时间它将是这使得您可以将优化时间花在不太百分之一的简单不够好的情况下 - 而且您编写或设计的大部分软件都很简单易懂 .

    分享和享受 .

相关问题