Select with no conditions taking long time, too many blocks, pctused?

Question

select * from at_journal;is taking 15 seconds, which is absurd. I have similar situations with other log tables in this system.
(selecting with rownum < 5 and with first_rows hint still takes 15 seconds)
Suspicious parameters:
PCT_FREE 1
PCT_USED 99
(Some other log tables have PCT_FREE 5, PCTUSED 90)
The tables have frequent inserts, once every day all records older than 90 days get deleted.
After computing statistics:
Blocks: 42,304 (seems absurdly high)
Size: 663 Mb
NUM_ROWS: 505,966
After copying data without compression to new table:
Blocks: 3,785
Size: 60 Mb
NUM_ROWS: 505,966
The select on the new table is instantaneous.
On a side note, in general is compression for a table with frequent deletes OK? It seems OK to me.
Storage parameters of table creation script:
PCTUSED    99
PCTFREE    1
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            FREELISTS        1
            FREELIST GROUPS  1
            BUFFER_POOL      DEFAULT
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
NOMONITORING;I imagine that most blocks for the table are empty. In my mind pctused of 99 means most of the block space should be full. I have read several explanations of PCTUSED/pctfree including oracle documentation and it seems pctused of 99 means the block should be 99% full.
Much thanks,
goo

Answer 1

goo wrote:
I imagine that most blocks for the table are empty. In my mind pctused of 99 means most of the block space should be full. I have read several explanations of PCTUSED/pctfree including oracle documentation and it seems pctused of 99 means the block should be 99% full.Hello, you don't give your database version, but if you were using Automatic Segment Space Management you would not need to worry about the PCTUSED setting, and it could be that you already are:
  1  select tablespace_name, segment_space_management
  2 from dba_TABLESPACES
TABLESPACE_NAME                SEGMEN
SYSTEM                         MANUAL
SYSAUX                         AUTO
UNDOTBS1                       MANUAL
TEMP                           MANUAL
USERS                          AUTO
EXAMPLE                        AUTOAnd if you are already using ASSM, then the PCTUSED is not an issue (PCTFREE still applies, but it's not an issue in your case).
goo wrote:
On a side note, in general is compression for a table with frequent deletes OK? It seems OK to me.Frequent DELETEs could be an issue because they will not reset the High Watermark, though there will not be a performance penalty because of the compression for DELETEs (the record only needs to be located for a DELETE, not decompressed). Your PCTUSED, however, is high enough so that any newly deleted record slots should be quickly reused, but... it depends on how those new records are being INSERTed. If, as Daniel says, the HWM is being effectively bypassed (Direct Path INSERTs, etc.), then the table will grow in size every day, but the volume of records effectively stays just about the same.
Have a look at how the new records are being added to that table, if it's a:
INSERT /*+ APPEND */ INTO tableA
SELECT...Then the HWM is being advanced, and the newly vacated slots from the DELETEd records are not being reused. So the table will continually grow, for roughly the same amount of data, and there'll be a proportionately longer data retrieval time.