在一项新工作中,我必须弄清楚一些数据库报告脚本是如何工作的 . 有一张 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 回答
我想其他一些进程可能正在删除数据,但如果没有访问您的网站,那么这里的任何人都无法判断是否可能 .
我在你的帖子中没有看到你提到了分区DATE列的名称,但根据你发布的SQL,我假设它是TRDATE - 如果这不正确,请在下面的语句中将TRDATE更改为分区列 .
也就是说,尝试一下:
这假设您应该从9月开始在此表中包含数据 . 如果您找到数据,那很好 . 如果你不这样做 - 好吧,Back In The Day(当男人是男人,女人是女人,电脑是水冷的:-)我们对IBM大型机的内存有一点说法:
:-)
对于遇到性能问题的情况,应保留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%的时间它将是这使得您可以将优化时间花在不太百分之一的简单不够好的情况下 - 而且您编写或设计的大部分软件都很简单易懂 .
分享和享受 .