1

新しい仕事で、いくつかのデータベース レポート スクリプトがどのように機能しているかを把握する必要があります。私にいくつかの問題を与えているテーブルが 1 つあります。既存のスクリプトで、それが分割されたテーブルであることがわかります。私の問題は、このテーブルで実行したクエリが「行が選択されていません」と返すことです。

この表での調査の詳細を次に示します。

テーブルサイズの見積もり

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

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

パーティション

日付範囲には合計 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

テーブルスペースの使用

スペースの概要は次のとおりです (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) はかなりビジーなようです。

既存のスクリプト

私が困惑しているのは、そのテーブルで動作し、そこからデータを取得するように見える 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 カウントになります。

概要 - データ (使用されているスペース、テーブルスペース、データ ファイル) を含むと思われるテーブルが表示されます - テーブルが分割されています (2013 年 1 月末までの 730 日間、1 日あたり 1 つのパーティション) - スクリプトがそのテーブルからデータを抽出しています何とかして

質問 - PARTITION を使用したクエリですべて「行が選択されていません」と返されます。私は何を間違っていますか?このテーブルからデータを抽出する方法を見つけるにはどうすればよいですか?

4

1 に答える 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 月からのデータがあることを前提としています。データが見つかった場合は、すばらしいことです。そうでない場合は、バック・イン・ザ・デイ (男性が男性で、女性が女性で、コンピューターが水冷式だった時代 :-) 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 句の使用は、パフォーマンスの問題が発生している状況のために予約する必要があります (注: 何がパフォーマンスの問題であるかどうかについて推測することは許可されていません。パフォーマンスの問題が発生するまでは、何年にもわたって、私はソフトウェアが最も危険な場所で多くの実行時間を費やしていることを発見しました:-)、通常の修正 (インデックスの追加、不要なデータの削除、人的犠牲など) は機能しませんでした。基本的に、クエリを通常どおりに記述し、データベースを信頼して正しく取得します。(一般的な場合 -常に最も単純なコードを書き、最も単純なことを実行してください。99% 以上の確率で問題ありません。これにより、単純では不十分な 1% 未満のケースに最適化の時間を費やすことができます。また、作成または設計するソフトウェアのほとんどは、単純で理解しやすいものになります)。

共有してお楽しみください。

于 2012-09-12T11:40:21.113 に答える