Why elapsed time is high in Partitioned table ?

HI All,
I executed two cases, where I update a col of partition and non partitioned table, but the complete elapsed time is quite high in partition table. I am going to paste my findings on the board.
update test_partcodes set codetype = 'A'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          5          0           0
Execute      1     36.65      82.90      16982        367    3554469     3476353
Fetch        0      0.00       0.00          0          0          0           0
total        2     36.65      82.91      16982        372    3554469     3476353
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Join ACK                                4        0.00          0.00
  PX Deq: Parse Reply                             4        0.09          0.16
  PX Deq: Execute Reply                          61        0.07          0.18
  db file sequential read                     16982        0.57         41.57
  log file switch completion                     27        0.57          1.76
  PX Deq: Signal ACK                              5        0.10          0.10
  enqueue                                         2        0.00          0.00
  SQL*Net message to client                       2        0.00          0.00
  SQL*Net message from client                     2        8.12          8.13
  SQL*Net break/reset to client                   2        0.00          0.00
update test_partcode_partition set codetype = 'A'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1    105.34     182.91      13334    2637470    8409866     2899525
Fetch        0      0.00       0.00          0          0          0           0
total        2    105.34     182.91      13334    2637470    8409866     2899525
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  rdbms ipc reply                                 2        0.00          0.00
  enqueue                                         2        1.28          1.28
  PX Deq: Join ACK                                5        0.00          0.00
  PX Deq: Parse Reply                             4        0.26          0.31
  PX Deq: Execute Reply                        2464        0.17          1.50
  log buffer space                              163        0.28          2.27
  log file switch completion                     75        0.41          3.04
  db file sequential read                     13333        0.67         59.54
  PX Deq: Signal ACK                              8        0.10          0.32
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
Also, you can check explain plan
test_staging@CHRYSLER> explain plan for update test_partcodes set codetype = 'A' ;
Explained.
test_staging@CHRYSLER> @plan
PLAN_TABLE_OUTPUT
| Id  | Operation            |  Name           | Rows  | Bytes | Cost  |  TQ    |IN-OUT| PQ Distrib |
|   0 | UPDATE STATEMENT     |                 |  3476K|  6789K|   410 |        |      |            |
|   1 |  UPDATE              | TEST_PARTCODES  |       |       |       |        |      |            |
|   2 |   TABLE ACCESS FULL  | TEST_PARTCODES  |  3476K|  6789K|   410 | 37,00  | P->S | QC (RAND)  |
test_staging@CHRYSLER> explain plan for update test_partcode_partition set codetype = 'A' ;
Explained.
test_staging@CHRYSLER> @plan
PLAN_TABLE_OUTPUT
| Id  | Operation            |  Name                    | Rows  | Bytes | Cost  | Pstart| Pstop |  TQ    |IN-OUT| PQ Distrib |
|   0 | UPDATE STATEMENT     |                          |  1159K|  3397K|   342 |       |       |     | |            |
|   1 |  UPDATE              | TEST_PARTCODE_PARTITION  |       |       |       |       |       |     | |            |
|   2 |   PARTITION RANGE ALL|                          |       |       |       |     1 |    12 | 38,00  | PCWP |            |
|   3 |    TABLE ACCESS FULL | TEST_PARTCODE_PARTITION  |  1159K|  3397K|   342 |     1 |    12 | 38,00  | P->S | QC (RAND)  |
Note: cpu costing is offhare krishna
Alok

Sorry for incomplete info, Now I am pasting the DDL, which I used to create a Partition Table.
create table test_partcode_partition
Partition by range (codetype)
( PARTITION part_2 VALUES LESS THAN ('C'),
PARTITION part_3 VALUES LESS THAN ('E'),
PARTITION part_4 VALUES LESS THAN ('F'),
PARTITION part_5 VALUES LESS THAN ('L'),
PARTITION part_6 VALUES LESS THAN ('M'),
PARTITION part_7 VALUES LESS THAN ('O'),
PARTITION part_8 VALUES LESS THAN ('R'),
PARTITION part_9 VALUES LESS THAN ('T'),
PARTITION part_10 VALUES LESS THAN ('X'),
PARTITION part_11 VALUES LESS THAN ('Y'),
PARTITION part_12 VALUES LESS THAN ('Z'),
PARTITION PM VALUES LESS THAN (MAXVALUE))
nologging parallel
as
select * from mxm_partcodes ;
DB VERSION - 9.2.0.5.0
OS - WIn 2003 Server.
hare krishna
Alok

Similar Messages

  • Elapsed Time in my V$SQL

    Hi,
    Can someone answer this please?. I'm bit perplexed by the elapsed time in my v$sql
    UPDATE ods_router_tables SET last_data_received = :b1, last_data_received_dst = :b3 WHERE
    table_name = :b2 AND NVL(last_data_received,TO_DATE('01-JAN-1980','DD-MON-YYYY')) < :b1
    Executions: 2786327
    Disk reads: 0
    Buffer gets: 6023381
    Rows processed: 423713
    Optimizer cost: 1
    Sorts: 0
    CPU Time: 898500000
    Elapsed Time: 1.84467440681166E19
    This table is quite small, only 44 records and if i run the statement in Sql plus, it runs in a
    flash. But why this enormous Elapsed time in V$SQL. Is my conversion of this time to
    seconds/execution correct?
    Elapsed time in seconds/execution: 1.84467440681166E19/1000000/2786327=6620451 seconds!
    I guess there is something seriously wrong here. I'm running on a 4 CPU server. DB version is 9.2.
    I see similar figures in some of the innocent looking Insert statements as well.
    thanks in advance,
    Sunil

    ELAPSED_TIME in v$sql also includes all wait times for that sql. Is it possible that update is waiting for locks some time? See the following case.
    SQL> create table test2 as select * from dual;
    Table created.
    SQL> update test2 set dummy='A';
    1 row updated.From another session try to update the same row.
    SQL> update test2 set dummy='B';Wait for some time. Then rollback the first session.
    SQL> rollback;
    Rollback complete.Now look at v$sql.
    SQL> select sql_text,executions,elapsed_time from v$sql where sql_text like 'update%test2%';
    SQL_TEXT
    EXECUTIONS ELAPSED_TIME
    update test2 set dummy='B'
             1     29413712
    update test2 set dummy='A'
             1         2506The first update's elapsed time is very small. The second update's elapsed time is high because of the wait for the lock.

  • Why I cannot split a partition table whose partitions are in a tablespace?

    SQL> CREATE TABLE "GDRK"."LT2_701C_RANGE"
    2 ( "CHAR_CODE" VARCHAR2(40),
    3 "STAT_UNIT_CODE" VARCHAR2(20),
    4 "ORGN_TYPE_CODE" CHAR(1) NOT NULL ENABLE,
    5 "ORGN_CODE" VARCHAR2(26) NOT NULL ENABLE,
    6 "ORGN_NAME" VARCHAR2(60) NOT NULL ENABLE,
    7 "UUID" VARCHAR2(36) NOT NULL ENABLE,
    8 "CYC_CODE" VARCHAR2(2) NOT NULL ENABLE,
    9 "H10" VARCHAR2(2),
    10 "H11" VARCHAR2(3),
    11 "H12" VARCHAR2(1),
    12 "H13" VARCHAR2(1),
    13 "H14" VARCHAR2(1),
    14 "H15" VARCHAR2(1),
    15 "H16" VARCHAR2(1),
    16 "H17" VARCHAR2(1),
    17 "H18" VARCHAR2(1),
    18 "H19_01" VARCHAR2(3),
    19 "H19_02" VARCHAR2(1),
    20 "H2" VARCHAR2(1),
    21 "H20" VARCHAR2(4),
    22 "H3_01" VARCHAR2(2),
    23 "H3_02" VARCHAR2(2),
    24 "H4_01" VARCHAR2(1),
    25 "H4_02" VARCHAR2(1),
    26 "H5_01" VARCHAR2(1),
    27 "H5_02" VARCHAR2(1),
    28 "H6" VARCHAR2(1),
    29 "H7" VARCHAR2(1),
    30 "H8" VARCHAR2(1),
    31 "H9" VARCHAR2(4),
    32 "REG_NUM" NUMBER,
    33 "ERA_NUM" NUMBER,
    34 "POWER_1" FLOAT(126),
    35 "POWER_2" FLOAT(126)
    36 )
    37 PARALLEL
    38 partition by range(CHAR_CODE) --substr(c1,1,1)
    39 (
    40 partition p0 values less than ('10'),
    41 partition p1 values less than ('20'),
    42 partition p2 values less than ('50'),
    43 partition p5 values less than (maxvalue));
    Table created.
    SQL> set timi on
    SQL> insert /*+ append */ into LT2_701C_RANGE select * from LT2_701C;
    539398 rows created.
    Elapsed: 00:00:28.02
    SQL> commit;
    Commit complete.
    Elapsed: 00:00:00.06
    SQL> select count(*) from LT2_701C_RANGE partition(p0);
    COUNT(*)
    0
    Elapsed: 00:00:00.00
    SQL> c/p0/p5
    1* select count(*) from LT2_701C_RANGE partition(p5)
    SQL> /
    COUNT(*)
    0
    Elapsed: 00:00:00.02
    SQL> c/p5/p2
    1* select count(*) from LT2_701C_RANGE partition(p2)
    SQL> /
    COUNT(*)
    539398
    Elapsed: 00:00:01.15
    SQL> ALTER TABLE LT2_701C_RANGE SPLIT PARTITION p2 at ('4420')INTO (
    2 PARTITION p20,
    3 PARTITION p21);
    ALTER TABLE LT2_701C_RANGE SPLIT PARTITION p2 at ('4420')INTO (
    ERROR at line 1:
    ORA-01652: unable to extend temp segment by 128 in tablespace EPRAS
    Elapsed: 00:00:00.89

    SQL> drop table LT2_701c_RANGE;
    Table dropped.
    Elapsed: 00:00:00.58
    SQL> drop index idx_c_p2;
    drop index idx_c_p2
    ERROR at line 1:
    ORA-01418: specified index does not exist
    Elapsed: 00:00:00.00
    SQL> CREATE TABLE "GDRK"."LT2_701C_RANGE"
    2 ( "CHAR_CODE" VARCHAR2(40),
    3 "STAT_UNIT_CODE" VARCHAR2(20),
    4 "ORGN_TYPE_CODE" CHAR(1) NOT NULL ENABLE,
    5 "ORGN_CODE" VARCHAR2(26) NOT NULL ENABLE,
    6 "ORGN_NAME" VARCHAR2(60) NOT NULL ENABLE,
    7 "UUID" VARCHAR2(36) NOT NULL ENABLE,
    8 "CYC_CODE" VARCHAR2(2) NOT NULL ENABLE,
    9 "H10" VARCHAR2(2),
    10 "H11" VARCHAR2(3),
    11 "H12" VARCHAR2(1),
    12 "H13" VARCHAR2(1),
    13 "H14" VARCHAR2(1),
    14 "H15" VARCHAR2(1),
    15 "H16" VARCHAR2(1),
    16 "H17" VARCHAR2(1),
    17 "H18" VARCHAR2(1),
    18 "H19_01" VARCHAR2(3),
    19 "H19_02" VARCHAR2(1),
    20 "H2" VARCHAR2(1),
    21 "H20" VARCHAR2(4),
    22 "H3_01" VARCHAR2(2),
    23 "H3_02" VARCHAR2(2),
    24 "H4_01" VARCHAR2(1),
    25 "H4_02" VARCHAR2(1),
    26 "H5_01" VARCHAR2(1),
    27 "H5_02" VARCHAR2(1),
    28 "H6" VARCHAR2(1),
    29 "H7" VARCHAR2(1),
    30 "H8" VARCHAR2(1),
    31 "H9" VARCHAR2(4),
    32 "REG_NUM" NUMBER,
    33 "ERA_NUM" NUMBER,
    34 "POWER_1" FLOAT(126),
    35 "POWER_2" FLOAT(126)
    36 )
    37 PARALLEL
    38 partition by range(CHAR_CODE) --substr(c1,1,1)
    39 (
    40 partition p0 values less than ('4410'),
    41 partition p1 values less than ('4420'),
    42 partition p2 values less than ('4450'),
    43 partition p5 values less than (maxvalue));
    Table created.
    Elapsed: 00:00:00.22
    SQL> insert /*+ append */ into LT2_701C_RANGE select * from LT2_701C;
    insert /*+ append */ into LT2_701C_RANGE select * from LT2_701C
    ERROR at line 1:
    ORA-01688: unable to extend table GDRK.LT2_701C_RANGE partition P0 by 128 in
    tablespace EPRAS
    Elapsed: 00:00:06.20
    SQL> show parameter recy
    NAME TYPE VALUE
    buffer_pool_recycle string
    db_recycle_cache_size big integer 0
    recyclebin string OFF

  • Why does Disk Utility keep breaking my partition table?

    I have two drives in my Mac Mini - the original drive it came with, and a SSD drive.  I dual boot from the SSD drive and it is fine.  On my original drive, I still have the original Lion install, but I would like to add a NTFS partition for use by windows.  The problem is that every single time I have Disk Utility try to do something to it, like delete a partion, it breaks the partition table.  It does delete the partition, but then it goes and sets all the partition types to 07 (Microsoft BAsic) instead of AF (Apple HFS).  Then Disk utility will claim the disk is broken and can't mount the partitions anymore.  I have to go in with gdisk to set the partition type back to AF and it will start working again.  BTW, gdisk claims the partition table type is hybrid MBR, even though windows is not installed on it.  Diskutil thinks it is GUID.  I did create a partition on it from the windows side once if that means anything.
    Now what I want to do is resize the HFS partition, but I am deathly afraid that DU will break something that isn't as easy to fix.

    I repaired permissions because I reinstalled Epson drivers, and reinstalling Epson drivers has  given me a permissions problems in the past which was cured by running permission repair. As it is an easy prophylactic step to take, I did it again.
    It may not be needed, but that is not the issue, which is why, when the permissions are indicated as repaired, are they not.
    Other previous posts on this issue suggest that these indications of permissions not being repaired should be ignored, so the report made by Disk Utility is simply a programming error.
    Disk Utility needs some work if it is going to respond to usage by a typical average user this way.

  • Is my partition table corrupt? Why does Boot Camp hate me?

    Hi folks
    I have an iMac (27-inch, Mid 2010) (iMac11,3, with Boot ROM IM112.0057.B01).
    I replaced the internal SuperDrive with an SSD, which is now my primary boot device:
    iMac:/ michthom$ diskutil list
    /dev/disk0
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *250.1 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1
       2:                  Apple_HFS SSD                     248.1 GB   disk0s2
       3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
    iMac:/ michthom$ sudo gpt -r -vv show disk0
    Password:
    gpt show: disk0: mediasize=250059350016; sectorsize=512; blocks=488397168
    gpt show: disk0: PMBR at sector 0
    gpt show: disk0: Pri GPT at sector 1
    gpt show: disk0: Sec GPT at sector 488397167
          start       size  index  contents
              0          1         PMBR
              1          1         Pri GPT header
              2         32         Pri GPT table
             34          6       
             40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
         409640  484620800      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      485030440    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
      486299976    2097159       
      488397135         32         Sec GPT table
      488397167          1         Sec GPT header
    So far so good.
    I want to use the original internal HDD both to run Windows in Boot Camp mode, and to have a partition for my bulk data that doesn't need to be on the SSD.
    I reformatted the HDD as a single HFS+ partition, GUID partition table.
    I used BCA to create a Windows USB boot device from the Windows 8.1 media after following the hacking in this link.
    When the iMac restarted after creating the 250Gb Windows partition on the internal HDD, I got the "no boot device" screen.
    I restarted holding Option/Alt and booted from EFI Boot on the USB stick. Windows installer started, at least. Serial number accepted, on to picking a location.
    The installation balked when I tried to select the BOOTCAMP partition, with the warning that the disk was formatted as MBR - eh? Why?
    So, the current state of the internal HDD must be wrong somehow, but I don't see how to fix it (confidently) and would like someone to point me in the right direction (please!)
    iMac:/ michthom$ diskutil list
    /dev/disk1
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *1.0 TB     disk1
       1:                        EFI EFI                     209.7 MB   disk1s1
       2:                  Apple_HFS Internal                751.9 GB   disk1s2
       3:       Microsoft Basic Data BOOTCAMP                248.0 GB   disk1s3
    iMac:/ michthom$ sudo gpt -r -vv show disk1
    gpt show: disk1: mediasize=1000204886016; sectorsize=512; blocks=1953525168
    gpt show: disk1: Suspicious MBR at sector 0
    gpt show: disk1: Pri GPT at sector 1
    gpt show: disk1: Sec GPT at sector 1953525167
           start        size  index  contents
               0           1         MBR
               1           1         Pri GPT header
               2          32         Pri GPT table
              34           6        
              40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
          409640  1468478336      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      1468887976      263256        
      1469151232   484372480      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
      1953523712        1423        
      1953525135          32         Sec GPT table
      1953525167           1         Sec GPT header
    gdisk has this to say:
    iMac:/ michthom$ sudo gdisk /dev/disk1
    Password:
    GPT fdisk (gdisk) version 0.8.10
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Partition table scan:
      MBR: hybrid
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with hybrid MBR; using GPT.
    Command (? for help): x
    Expert command (? for help): o
    Disk size is 1953525168 sectors (931.5 GiB)
    MBR disk identifier: 0x4F5BB38B
    MBR partitions:
    Number  Boot  Start Sector   End Sector   Status      Code
       1                     1       409639   primary     0xEE
       2                409640   1468887975   primary     0xAF
       3            1469151232   1953523711   primary     0x0B
    Expert command (? for help): p
    Disk /dev/disk1: 1953525168 sectors, 931.5 GiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 3E1D7EF9-F86E-4552-8F40-BE9754C3C73F
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 1953525134
    Partitions will be aligned on 8-sector boundaries
    Total free space is 264685 sectors (129.2 MiB)
    Number  Start (sector)    End (sector)  Size       Code  Name
       1              40          409639   200.0 MiB   EF00  EFI System Partition
       2          409640      1468887975   700.2 GiB   AF00  Internal
       3      1469151232      1953523711   231.0 GiB   0700  BOOTCAMP
    Any help / pointers gratefully accepted!
    Mike

    Thanks to Loner T and some more reading, I think I'm now sorted out.
    I found that marking the first partition on the USB stick as Active made no difference - my only option was to boot from the "EFI boot" option at startup (when holding down the alt/option key).
    So to get the Windows installer to behave, I used gdisk to write a new protective MBR before rebooting to the USB stick, as shown below.
    With the protective MBR in place (rather than hybrid), the Windows installer was happy to reformat the chosen partition and the installation began.
    I'll try to report back once all is installed and working, but once again I owe my sanity to the generosity and patience of strangers!
    Mike
    bash-3.2# gdisk /dev/disk0
    GPT fdisk (gdisk) version 0.8.10
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Partition table scan:
      MBR: hybrid
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with hybrid MBR; using GPT.
    Command (? for help): x
    Expert command (? for help): o
    <snipped>
    Number  Boot  Start Sector  End Sector  Status      Code
      1                    1      409639  primary    0xEE
      2                409640  1468887975  primary    0xAF
      3            1469151232  1953523711  primary    0x0B
    Expert command (? for help): p
    <snipped>
    Number  Start (sector)    End (sector)  Size      Code  Name
      1              40          409639  200.0 MiB  EF00  EFI System Partition
      2          409640      1468887975  700.2 GiB  AF00  Internal
      3      1469151232      1953523711  231.0 GiB  0700  BOOTCAMP
    Expert command (? for help): v
    No problems found. 264685 free sectors (129.2 MiB) available in 3
    segments, the largest of which is 263256 (128.5 MiB) in size.
    Expert command (? for help): x
    <snipped>
    n create a new protective MBR
    <snipped>
    Expert command (? for help): n
    Expert command (? for help): w
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
    PARTITIONS!!
    Do you want to proceed? (Y/N): y
    OK; writing new GUID partition table (GPT) to /dev/disk0.
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Warning: The kernel may continue to use old or deleted partitions.
    You should reboot or remove the drive.
    The operation has completed successfully.
    bash-3.2# gdisk /dev/disk0
    GPT fdisk (gdisk) version 0.8.10
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with protective MBR; using GPT.
    Command (? for help): x
    Expert command (? for help): o
    Disk size is 1953525168 sectors (931.5 GiB)
    MBR disk identifier: 0x00000000
    MBR partitions:
    Number  Boot  Start Sector  End Sector  Status      Code
      1                    1  1953525167  primary    0xEE
    Expert command (? for help): p
    <snipped>
    Number  Start (sector)    End (sector)  Size      Code  Name
      1              40          409639  200.0 MiB  EF00  EFI System Partition
      2          409640      1468887975  700.2 GiB  AF00  Internal
      3      1469151232      1953523711  231.0 GiB  0700  BOOTCAMP

  • Partitioned table takes more time to load

    Hi,
    Recently I have been test loading a partition table (Datawarehouse fact table). However, I notice almost 2X to 2.5X jump in timing compared to the non-partitioned table.
    The partition is on the TIME Key on the basis of monthly range. Since this key is not entirely consistent (less than 1% cases) and can change sometimes, I have enabled row movement.
    Is there anything that you can do to improve timing when everything else remains same?
    Regards
    Prem

    Hi,
    When you load data into a partitioned table oracle has to check every record
    to decide in which partition store it.
    When you load data in a heap table oracle hasn't to check it. All records
    are saved in the same segment.
    You can save time when you load in partitioned tables using partition
    clause.
    Regards
    K.Rajkumar

  • Calculating elapsed time (in minutes) from a TIMESTAMP field in a table

    I have a table of events that contains a field, CREATION_DATE, that is defined as NOT NULL TIMESTAMP(6), and the value is normally in the format 'DD-MON-YYYY HH:MM:SS.FFFFFF xM'. I want to SELECT only those rows where the elapsed time between the CREATION_DATE and the local time (US/EASTERN) is greater than 15 minutes. And, I'd like the output to show the values for the elapsed time in days, hours, minutes, and seconds.
    Edited by: user12301147 on Dec 2, 2009 9:16 AM

    Hi,
    It looks like to have to adjust for time zones.
    I'm not sure what you mean by "2009-DEC-02 13:59:34.316, which is in actual time 2009-DEC-02 08:59:34.316." Aren't both actual times, just in different time zones? I'm also a lttle confused about the results: even if it's treating 6 hours 18 minutes as 0 hours 18 minutes, either way it's over 15 minutes.
    Convert either creation_date or SYSTIMESTAMP to the time zone of the other. (It looks like SYSTIMESTAMP is indeed Eastern Time, UTC - 5:00).
    Or, if they are always a fixed time apart, build that difference into the comparison. for example:
    WHERE SYSTIMESTAMP - creation_date > TO_DSINTERVAL ('-0 05:45:00')

  • DB Time much higher compared to (Elapsed time * CPU)

    11.2.0.2 on Linux x86 64-bit, Single Instance
    AWR shows
    CPUs : 16
    Cores : 8
    Sockets : 2
    Begin Snap: 10-Jan-12 01:00:17
    End Snap: 10-Jan-12 02:00:40
    Elapsed: 60.38 (mins)
    DB Time: 1,627.47 (mins)
    My understanding is that (Elapsed * CPUs) is an upper bound for DB Time. DB Time is much higher though (60.38 * 16 = 966.08).

    Databases are rarely single user systems.
    My understanding is that (Elapsed * CPUs) is an upper bound for DB TimeNo, this isn't correct. That's the maximum CPU time you have.
    DB_TIME gives you the amount of time spent by active sessions actively working or actively waiting.
    DB_TIME/ELAPSED_TIME gives you a figure of Average Active Sessions - i.e. on average you have 26 active sessions over this period.
    If you think about it, if you have a 60 minute report and you have 1 user actively working or actively waiting, your elapsed time would be 60 minutes, maximum cpu time on 16 cpus is 960 minutes your db time would be 60 minutes.
    Double the number of active users to 2, elapsed time still 60 minutes, max cpu time still 960 minutes, db time 120.
    Double the number of active users to 4, elapsed time still 60 minutes, max cpu time still 960 minutes, db time 240.
    Mulitply the number of active by 10 to 40, elapsed time still 60 minutes, max cpu time still 960 minutes, db time 2400.
    Of course, you're unlikely to have 40 users who are constantly active for 60 minutes, but you get the picture.
    Edited by: Dom Brooks on Jan 10, 2012 10:54 AM
    Reworded

  • Partition Table Query taking Too Much Time

    I have created partition table and Created local partition index on a column whose datatype is DATE.
    Now when I Query table and use index column in the where clause It is scaning all the table (Full scan) . The quey is :
    Select * From mytable
    where to_char(transaction_date, 'DD-MON-YY') = '01-Aug-07';
    I have to use to_char function not to_date due to Front end application problem.

    Before we go too far with this, if you manually query with TO_DATE on the variable instead of TO_CHAR on the column, does the query actually use the index?
    The TO_CHAR on the column will definitely stop Oracle from using any index on the column. If the query will use the index if you TO_DATE the variable, as I see it, you have three options. First, fix the application problem that won't let you use TO_DATE from the application. Second, change the application to call a function returning a ref cursor, get the date string as a parameter to the function, and do the TO_DATE in the function.
    Third, you could consider creating a function-based index on TO_CHAR(transaction_date, 'dd-Mon-yy'). This would be the least desirable option, particularly if you would also be selecting records based on a range of transaction_dates, since it loses a lot of information that the optimizer could use in devising an efficient query plan. It could also change your results for a range scan.
    John

  • Query Execution/Elapsed Time and Oracle Data Blocks

    Hi,
    I have created 3 tables with one column only. As an example Table 1 below:
    SQL> create table T1 ( x char(2000));
    So 3 tables are created in this way i.e. T1,T2 and T3.
    T1 = in the default database tablespace of 8k (11g v11.1.0.6.0 - Production) (O.S=Windows).
    T2 = I created in a Tablespace with Blocksize 16k.
    T3 = I created in a Tablespace with Blocksize 4k. In the same Instance.
    Each table has approx. 500 rows (So, table sizes are same in all the cases to test Query execution time ). As these 3 tables are created under different data block sizes so the ALLOCATED no. of data blocks are different in all cases.
    T1  =   8k  = 256 Blocks =  00:00:04.76 (query execution time/elapsed time)
    T2  = 16k=121 Blocks =  00:00:04.64
    T3 =   4k =  490 Blocks =  00:00:04.91
    Table Access is FULL i.e. I have used select * from table_name; in all 3 cases. No Index nothing.
    My Question is why query execution time is nearly the same in all 3 cases because Oracle has to read all the data blocks in each case to fetch the records and there is a much difference in the allocated no. of blocks ???
    In 4k block size example, Oracle has to read just 121 blocks and it's taking nearly the same time as it's taking to read 490 blocks???
    This is just 1 example of different data blocks. I have around 40 tables in each block size tablespace and the result are nearly the same. It's very strange for me because there is a much difference in the no. of allocated blocks but execution time is almost the same, only difference in milliseconds.
    I'll highly appreciate the expert opinions.
    Bundle of thanks in advance.
    Best Regards,

    Hi Chris,
    No I'm not using separate databases, it's 8k database with non-standard blocksizes of 16k and 4k.
    Actually I wanted to test the Elapsed time of these 3 tables, so for that I tried to create the same size
    tables.
    And how I equalize these is like I have created one column table with char(2000).
    555 MB is the figure I wanted to use for these 3 tables ( no special figure, just to make it bigger than the
    RAM used for my db at the db startup to be sure of not retrieving the records from cache).
    so row size with overhead is 2006 * 290,000 rows = 581740000(bytes) / 1024 = 568105KB / 1024 = 555MB.
    Through this math calculation I thought It will be the total table size. So I Created the same no. of rows in 3 blocksizes.
    If it's wrong then what a mes because I was calculating tables sizes in the same way from the last few months.
    Can you please explain a little how you found out the tables sizes in different block sizes.Though I understood how you
    calculated size in MB from these 3 block sizes
    T8K =97177 BLOCKS=759MB *( 97177*8 = 777416KB / 1024 = 759MB )*
    T16K=41639 BLOCKS=650MB
    BT4K=293656 BLOCKS=1147MB
    For me it's new to calculate the size of a table. Can you please tell me then how many rows I can create in each of
    these 3 tables to make them equal in MB to test for elapsed time.
    Then I'll again run my test and put the results here. Because If I've wrongly calculated table sizes then there is no need to talk about elapsed time. First I must equalize the table sizes properly.
    SQL> select sum(bytes)/1024/1024 "Size in MB" from dba_segments> 2 where segment_name = 'T16K';
    Size in MB
    655
    Is above SQL is correct to calculate the size or is it the correct alternative way to your method of calculating the size??
    I created the same table again with everything same and the result is :
    SQL> select num_rows,blocks from user_tables where table_name = 'T16K';NUM_ROWS BLOCKS
    290000 41703
    64 more blocks are allocated this time so may be that's y it's showing total size of 655 instead of 650.
    Thanks alot for your help.
    Best Regards,
    KAm
    Edited by: kam555 on Nov 20, 2009 5:57 PM

  • Partition Pruning on Interval Range Partitioned Table not happening when SYSDATE used in Where Clause

    We have tables that are interval range partitioned on a DATE column, with a partition for each day - all very standard and straight out of Oracle doc.
    A 3rd party application queries the tables to find number of rows based on date range that is on the column used for the partition key.
    This application uses date range specified relative to current date - i.e. for last two days would be "..startdate > SYSDATE -2 " - but partition pruning does not take place and the explain plan shows that every partition is included.
    By presenting the query using the date in a variable partition pruning does table place, and query obviously performs much better.
    DB is 11.2.0.3 on RHEL6, and default parameters set - i.e. nothing changed that would influence optimizer behavior to something unusual.
    I can't work out why this would be so. It very easy to reproduce with simple test case below.
    I'd be very interested to hear any thoughts on why it is this way and whether anything can be done to permit the partition pruning to work with a query including SYSDATE as it would be difficult to get the application code changed.
    Furthermore to make a case to change the code I would need an explanation of why querying using SYSDATE is not good practice, and I don't know of any such information.
    1) Create simple partitioned table
    CREATETABLE part_test
       (id                      NUMBER NOT NULL,
        starttime               DATE NOT NULL,
        CONSTRAINT pk_part_test PRIMARY KEY (id))
    PARTITION BY RANGE (starttime) INTERVAL (NUMTODSINTERVAL(1,'day')) (PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2013','DD-MM-YYYY')));
    2) Populate table 1million rows spread between 10 partitions
    BEGIN
        FOR i IN 1..1000000
        LOOP
            INSERT INTO part_test (id, starttime) VALUES (i, SYSDATE - DBMS_RANDOM.value(low => 1, high => 10));
        END LOOP;
    END;
    EXEC dbms_stats.gather_table_stats('SUPER_CONF','PART_TEST');
    3) Query the Table for data from last 2 days using SYSDATE in clause
    EXPLAIN PLAN FOR
    SELECT  count(*)
    FROM    part_test
    WHERE   starttime >= SYSDATE - 2;
    | Id  | Operation                 | Name      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT          |           |     1 |     8 |  7895  (1)| 00:00:01 |       |       |
    |   1 |  SORT AGGREGATE           |           |     1 |     8 |            |          |       |       |
    |   2 |   PARTITION RANGE ITERATOR|           |   111K|   867K|  7895   (1)| 00:00:01 |   KEY |1048575|
    |*  3 |    TABLE ACCESS FULL      | PART_TEST |   111K|   867K|  7895   (1)| 00:00:01 |   KEY |1048575|
    Predicate Information (identified by operation id):
       3 - filter("STARTTIME">=SYSDATE@!-2)
    4) Now do the same query but with SYSDATE - 2 presented as a literal value.
    This query returns the same answer but very different cost.
    EXPLAIN PLAN FOR
    SELECT count(*)
    FROM part_test
    WHERE starttime >= (to_date('23122013:0950','DDMMYYYY:HH24MI'))-2;
    | Id  | Operation                 | Name      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT          |           |     1 |     8 |   131  (0)| 00:00:01 |       |       |
    |   1 |  SORT AGGREGATE           |           |     1 |     8 |            |          |       |       |
    |   2 |   PARTITION RANGE ITERATOR|           |   111K|   867K|   131   (0)| 00:00:01 |   356 |1048575|
    |*  3 |    TABLE ACCESS FULL      | PART_TEST |   111K|   867K|   131   (0)| 00:00:01 |   356 |1048575|
    Predicate Information (identified by operation id):
       3 - filter("STARTTIME">=TO_DATE(' 2013-12-21 09:50:00', 'syyyy-mm-dd hh24:mi:ss'))
    thanks in anticipation
    Jim

    As Jonathan has already pointed out there are situations where the CBO knows that partition pruning will occur but is unable to identify those partitions at parse time. The CBO will then use a dynamic pruning which means determine the partitions to eliminate dynamically at run time. This is why you see the KEY information instead of a known partition number. This is to occur mainly when you compare a function to your partition key i.e. where partition_key = function. And SYSDATE is a function. For the other bizarre PSTOP number (1048575) see this blog
    http://hourim.wordpress.com/2013/11/08/interval-partitioning-and-pstop-in-execution-plan/
    Best regards
    Mohamed Houri

  • Cost in explain plan vs elapsed time

    hi gurus,
    i have two tables with identical data volume(same database/schema/tablespace) and the only difference between these two is, one partitioned on a date filed.
    statistics are up to date.
    same query is executed against both tables, no partition pruning involved.
    select ....... from non-partitioned
    execution plan cost=92
    elapsed time=117612
    select ... from partitioned
    execution plan cost=3606
    elapsed time=19559
    though plan cost of query against non-partitioned is quite less than partitioned, elapsed time in v$sqlarea is higher than partitioned.
    what could be the reason please?
    thanks,
    charles
    Edited by: user570138 on May 6, 2010 6:54 AM

    user570138 wrote:
    if elapsed time value is very volatile(with the difference in explain plan cost) , then how can i compare the performance of the query?Note that the same query with same execution plan and same data can provide different execution times - and due to a number of factors. The primary one being that the first time the query is executed, it performs physical I/O and loads the data into the buffer cache - where the same subsequent query finds this data via cheaper and faster logical I/O in the cache.
    in my case i want to compare the performance change before and after table partitioning.Then look at the actual utilisation cost of the query and not (variant) elapsed execution time. The most expensive operation on a db platform is typically I/O. The more I/O, the slower the execution time.
    I/O can be decreased in a number of ways. The usual approach in the database environment is to provide better or alternative data structures, in order to create more optimal I/O paths.
    So instead of using a hash table and separate PK b+tree index, using an index organised table. Instead of a single large table with indexes, a partitioned table with local indexes. Instead of joining plain tables, joining tables that have been clustered. Etc.
    In most cases, when done correctly, these physical data structure changes do not even impact the application layer. The SQL and code in this layer should be blissfully unaware of the physical structure changes done to improve performance.
    Likewise, changes in the logical layer (data model changes) can also improve performance. This of course does impact the application layer - and requires a proper design and implementation in the physical layer. Often proper data modeling is overlooked and flaws in it is attempted to be fixed by hacking the physical layer.
    my aim is to measure the query performance improvements, if any, by partitioning an existing tableWhy not measure current I/O before an operation, and then after the operation - and use the difference to determine the amount of I/O performed by that operation?
    This can be implemented in a start/stop watch fashion (instead of measuring time, measuring I/O) using the v$sesstat virtual performance view.

  • Unrecognized partition table for drive 80 error??

    Currently running leopard on a macbook pro.
    Formatted w bootcamp and running Windows Vista Ultimate.
    Installation went fine reformated drive to ntfs 45gigs.
    But when booting into windows I get this error message
    "unrecognized partition table for drive 80"
    Then the system boots into vista as normal but that error message is annoying.
    Tells me to fix bootmgr using fdisk. How do I do that?
    Thanks.

    I previously had Vista installed under the beta with Tiger and there was no issues at all regarding boot times or error messages. (Boot times being quite nippy considering)
    I did reformat the hard drive space partitioned in side Vista installation as NTFS. As I am only a switcher for a year or so I imagine there may be something I am missing but given the text when I try to boot into Vista, it looks to be the boot loader that is erroring and that looks the same as a GRUB loader failing.
    I just do not get why a BETA product would work fine, then after a fresh installation of the new Mac OSX 10.5 with the final version of boot camp I would receive errors like this.
    I have reclaimed the hard drive space and split the disk again but the same error persists. Previously I was showing off my Macbook to work mates showing how it handled Windows as well as the user friendly OSX. Now all I can show them is a 5 minute loading screen full of non booting Vista as they look at me like some kind of idiot. (Which depending on who you ask is possibly correct)

  • Query with non partition key in partitioning table

    i compare query select with non-partition key condition in table partition with 3, 4 and 6 partition.
    time execution for 3 partition faster then 4 partition, time execution for 4 partition faster than 6 partition.
    i know processing query select is selection all partition, but i don't know what make time execution different between 3, 4 and 6 partition??
    whether the transfer from one partition to another partition takes time?
    this example sql trace query select for 3,4 and 6 partition
    3 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.70       7.57      25291     1157583
    total        5.70       7.57      25291     1157583
    Parsing user id: 61  (SKENARIO1)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   PARTITION HASH (ALL) PARTITION: START=1 STOP=3
          0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
                   'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=34 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.46       8.03      25126     1157583
    total        5.46       8.03      25126     1157583
    Parsing user id: 62  (SKENARIO2)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   PARTITION HASH (ALL) PARTITION: START=1 STOP=4
          0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
                   'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=46 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.73       9.13      25190     1157583
    total        5.73       9.13      25190     1157583
    Parsing user id: 63  (SKENARIO3)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   PARTITION HASH (ALL) PARTITION: START=1 STOP=6
          0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
                   'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=6thanks
    best regards
    eko

    ekopur wrote:
    i compare query select with non-partition key condition in table partition with 3, 4 and 6 partition.
    time execution for 3 partition faster then 4 partition, time execution for 4 partition faster than 6 partition.
    i know processing query select is selection all partition, but i don't know what make time execution different between 3, 4 and 6 partition??
    whether the transfer from one partition to another partition takes time?
    this example sql trace query select for 3,4 and 6 partition
    3 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.70       7.57      25291     1157583
    total        5.70       7.57      25291     1157583
    Parsing user id: 61  (SKENARIO1)
    Rows     Execution Plan
    0  SELECT STATEMENT   MODE: ALL_ROWS
    0   PARTITION HASH (ALL) PARTITION: START=1 STOP=3
    0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
    'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=34 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.46       8.03      25126     1157583
    total        5.46       8.03      25126     1157583
    Parsing user id: 62  (SKENARIO2)
    Rows     Execution Plan
    0  SELECT STATEMENT   MODE: ALL_ROWS
    0   PARTITION HASH (ALL) PARTITION: START=1 STOP=4
    0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
    'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=46 partition
    SELECT *
    FROM
    EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
    call          cpu    elapsed       disk        rows
    Parse        0.00       0.00          0           0
    Execute      0.00       0.00          0           0
    Fetch        5.73       9.13      25190     1157583
    total        5.73       9.13      25190     1157583
    Parsing user id: 63  (SKENARIO3)
    Rows     Execution Plan
    0  SELECT STATEMENT   MODE: ALL_ROWS
    0   PARTITION HASH (ALL) PARTITION: START=1 STOP=6
    0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
    'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=6
    I'm assuming you recreated the table a couple of times with different numbers of hash partitions. (Tip: always use a power of two for the number of hash partitions - it keeps them all around the same size if you are using the feature on an appropriate data set.)
    There isn't really enough difference in time within the database to make any sensible comment about the difference in times. I note that you have also edited out the fetch count for the 1.1 million rows fetched, and have not captured (or perhaps just not printed) the wait times, so we don't know where you spent the time inside and outside the database.
    For all we can tell, the difference you are worried about might simply be network time on the fetch calls, and have nothing to do with the extract you've published.
    Regards
    Jonathan Lewis

  • Problem of full table scan on a partitioned table

    hi all
    There is a table called "si_sync_operation" that have 171040 number of rows.
    I partitioned that table into a new table called "si_sync_operation_par" with 7 partitoins.
    I issued the following statements
    SELECT * FROM si_sync_operation_par.
    SELECT * FROM si_sync_operation.
    The explain plan show that the cost of the first statement is 1626 and that of the second statments is 1810.
    The "cost" of full table scan on partitioned table is lower than the that of non-partitioned table.That's fine.
    But the "Bytes" of full table scan on partitioned table is 5761288680 and that of the non-partitioned table is 263743680.
    Why full table scan on partitioned table access more bytes than non-partitioned table?
    And how could a statment that access more bytes results a lower cost?
    Thank u very much

    As Hemant metioned bytes reported are approximate number of bytes. As far as Cost is concerned, according to Tom its just a number and we should not compare queries by their cost. (search asktom.oracle.com for more information)
    SQL> drop table non_part purge;
    Table dropped.
    SQL> drop table part purge;
    Table dropped.
    SQL>
    SQL> CREATE TABLE non_part
      2        (id  NUMBER(5),
      3         dt    DATE);
    Table created.
    SQL>
    SQL> CREATE TABLE part
      2        (id  NUMBER(5),
      3         dt    DATE)
      4         PARTITION BY RANGE(dt)
      5         (
      6         PARTITION part1_jan2008 VALUES LESS THAN(TO_DATE('01/02/2008','DD/MM/YYYY')),
      7         PARTITION part2_feb2008 VALUES LESS THAN(TO_DATE('01/03/2008','DD/MM/YYYY')),
      8         PARTITION part3_mar2008 VALUES LESS THAN(TO_DATE('01/04/2008','DD/MM/YYYY')),
      9         PARTITION part4_apr2008 VALUES LESS THAN(TO_DATE('01/05/2008','DD/MM/YYYY')),
    10         PARTITION part5_may2008 VALUES LESS THAN(TO_DATE('01/06/2008','DD/MM/YYYY'))
    11       );
    Table created.
    SQL>
    SQL>
    SQL> insert into non_part select rownum, trunc(sysdate) - rownum from dual connect by level <= 140;
    140 rows created.
    Execution Plan
    Plan hash value: 1731520519
    | Id  | Operation                     | Name | Rows  | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
    |   1 |  COUNT                        |      |       |            |          |
    |*  2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
    |   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter(LEVEL<=140)
    SQL>
    SQL> insert into part select * from non_part;
    140 rows created.
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT  |          |   140 |  3080 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  3080 |     3   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    SQL>
    SQL> commit;
    Commit complete.
    SQL>
    SQL> set line 10000
    SQL> set autotrace traceonly exp
    SQL> select * from non_part;
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |   140 |  3080 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  3080 |     3   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    SQL> select * from part;
    Execution Plan
    Plan hash value: 3392317243
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |   140 |  3080 |     9   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION RANGE ALL|      |   140 |  3080 |     9   (0)| 00:00:01 |     1 |     5 |
    |   2 |   TABLE ACCESS FULL | PART |   140 |  3080 |     9   (0)| 00:00:01 |     1 |     5 |
    Note
       - dynamic sampling used for this statement
    SQL>
    SQL> exec dbms_stats.gather_table_stats(user, 'non_part');
    PL/SQL procedure successfully completed.
    SQL> exec dbms_stats.gather_table_stats(user, 'part');
    PL/SQL procedure successfully completed.
    SQL>
    SQL>
    SQL> select * from non_part;
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |   140 |  1540 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  1540 |     3   (0)| 00:00:01 |
    SQL> select * from part;
    Execution Plan
    Plan hash value: 3392317243
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |   140 |  1540 |     9   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION RANGE ALL|      |   140 |  1540 |     9   (0)| 00:00:01 |     1 |     5 |
    |   2 |   TABLE ACCESS FULL | PART |   140 |  1540 |     9   (0)| 00:00:01 |     1 |     5 |
    SQL>After analyzing the tables, notice that the Bytes column has changed value

Maybe you are looking for