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

Similar Messages

  • Do partition scans take longer than a full table scan on an unpartitioned table?

    Hello there,
    I have a range-partitioned table PART_TABLE which has 10 Million records and 10 partitions having 1 million records each. Partition is done based on a Column named ID which is a sequence from 1 to 10 million.
    I created another table P2_BKP (doing a select * from part_table) which has the same dataset as that of PART_TABLE except that this table is not partitioned.
    Now, I run a same query on both the tables to retrieve a range of data. Precisely I am trying to read only the data present in 5 partitions of the partitioned tables which theoretically requires less reads than when done on unpartitioned tables.
    Yet, the query seems to take extra time on partitioned table than when run on unpartitioned table.Any specific reason why is this the case?
    Below is the query I am trying to run on both the tables and their corresponding Explain Plans.
    QUERY A
    =========
    select * from P2_BKP where id<5000000;
    | Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |                                                                                                                                                                                                                                
    |   0 | SELECT STATEMENT  |        |  6573K|   720M| 12152   (2)| 00:02:26 |                                                                                                                                                                                                                                
    |*  1 |  TABLE ACCESS FULL| P2_BKP |  6573K|   720M| 12152   (2)| 00:02:26 |                                                                                                                                                                                                                                
    QUERY B
    ========
    select * from part_table where id<5000000;
    | Id  | Operation                | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |                                                                                                                                                                                                     
    |   0 | SELECT STATEMENT         |            |  3983K|   436M| 22181  (73)| 00:04:27 |       |       |                                                                                                                                                                                                     
    |   1 |  PARTITION RANGE ITERATOR|            |  3983K|   436M| 22181  (73)| 00:04:27 |     1 |     5 |                                                                                                                                                                                                     
    |*  2 |   TABLE ACCESS FULL      | PART_TABLE |  3983K|   436M| 22181  (73)| 00:04:27 |     1 |     5 |                                                                                                                                                                                                     

    at the risk of bringing unnecessary confusion into the discussion: I think there is a situation in 11g in which a Full Table Scan on a non partitioned table can be faster than the FTS on a corresponding partitioned table: if the size of the non partitioned table reaches a certain threshold (I think it's: blocks > _small_table_threshold * 5) the runtime engine may decide to use a serial direct path read to access the data. If the single partitions don't pass the threshold the engine will use the conventional path.
    Here is a small example for my assertion:
    -- I create a simple partitioned table
    -- and a corresponding non-partitioned table
    -- with 1M rows
    drop table tab_part;
    create table tab_part (
        col_part number
      , padding varchar2(100)
    partition by list (col_part)
        partition P00 values (0)
      , partition P01 values (1)
      , partition P02 values (2)
      , partition P03 values (3)
      , partition P04 values (4)
      , partition P05 values (5)
      , partition P06 values (6)
      , partition P07 values (7)
      , partition P08 values (8)
      , partition P09 values (9)
    insert into tab_part
    select mod(rownum, 10)
         , lpad('*', 100, '*')
      from dual
    connect by level <= 1000000;
    exec dbms_stats.gather_table_stats(user, 'tab_part')
    drop table tab_nopart;
    create table tab_nopart
    as
    select *
      from tab_part;
    exec dbms_stats.gather_table_stats(user, 'tab_nopart')
    -- my _small_table_threshold is 1777 and the partitions
    -- have a size of ca. 1600 blocks while the non-partitioned table
    -- contains 15360 blocks
    -- I have to flush the buffer cache since
    -- the direct path access is only used
    -- if there are few blocks already in the cache
    alter system flush buffer_cache;
    -- the execution plans are not really exciting
    | Id  | Operation           | Name     | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |          |     1 |  8089   (0)| 00:00:41 |       |       |
    |   1 |  SORT AGGREGATE     |          |     1 |            |          |       |       |
    |   2 |   PARTITION LIST ALL|          |  1000K|  8089   (0)| 00:00:41 |     1 |    10 |
    |   3 |    TABLE ACCESS FULL| TAB_PART |  1000K|  8089   (0)| 00:00:41 |     1 |    10 |
    | Id  | Operation          | Name       | Rows  | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |            |     1 |  7659   (0)| 00:00:39 |
    |   1 |  SORT AGGREGATE    |            |     1 |            |          |
    |   2 |   TABLE ACCESS FULL| TAB_NOPART |  1000K|  7659   (0)| 00:00:39 |
    But on my PC the FTS on the non-partitioned table is faster than the FTS on the partitions (1sec to 3 sec.) and v$sesstat shows the reason for this difference:
    -- non partitioned table
    NAME                                               DIFF
    table scan rows gotten                          1000000
    file io wait time                                 15313
    session logical reads                             15156
    physical reads                                    15153
    consistent gets direct                            15152
    physical reads direct                             15152
    DB time                                              95
    -- partitioned table
    NAME                                               DIFF
    file io wait time                               2746493
    table scan rows gotten                          1000000
    session logical reads                             15558
    physical reads                                    15518
    physical reads cache prefetch                     15202
    DB time                                             295
    (maybe my choose of counters is questionable)
    So it's possible to get slower access for an FTS on a partitioned table under special conditions.
    Regards
    Martin

  • Importing partitioned table data into non-partitioned table

    Hi Friends,
    SOURCE SERVER
    OS:Linux
    Database Version:10.2.0.2.0
    i have exported one partition of my partitioned table like below..
    expdp system/manager DIRECTORY=DIR4 DUMPFILE=mapping.dmp LOGFILE=mapping_exp.log TABLES=MAPPING.MAPPING:DATASET_NAPTARGET SERVER
    OS:Linux
    Database Version:10.2.0.4.0
    Now when i am importing into another server i am getting below error
    Import: Release 10.2.0.4.0 - 64bit Production on Tuesday, 17 January, 2012 11:22:32
    Copyright (c) 2003, 2007, Oracle.  All rights reserved.
    Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Master table "MAPPING"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
    Starting "MAPPING"."SYS_IMPORT_FULL_01":  MAPPING/******** DIRECTORY=DIR3 DUMPFILE=mapping.dmp LOGFILE=mapping_imp.log TABLE_EXISTS_ACTION=APPEND
    Processing object type TABLE_EXPORT/TABLE/TABLE
    ORA-39083: Object type TABLE failed to create with error:
    ORA-00959: tablespace 'MAPPING_ABC' does not exist
    Failing sql is:
    CREATE TABLE "MAPPING"."MAPPING" ("SAP_ID" NUMBER(38,0) NOT NULL ENABLE, "TG_ID" NUMBER(38,0) NOT NULL ENABLE, "TT_ID" NUMBER(38,0) NOT NULL ENABLE, "PARENT_CT_ID" NUMBER(38,0), "MAPPINGTIME" TIMESTAMP (6) WITH TIME ZONE NOT NULL ENABLE, "CLASS" NUMBER(38,0) NOT NULL ENABLE, "TYPE" NUMBER(38,0) NOT NULL ENABLE, "ID" NUMBER(38,0) NOT NULL ENABLE, "UREID"
    Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
    Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type OBJECT_GRANT:"MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
    ORA-39112: Dependent object type INDEX:"MAPPING"."IDX_TG_ID" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."PK_MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."IDX_UREID" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."IDX_V2" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."IDX_PARENT_CT" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
    ORA-39112: Dependent object type CONSTRAINT:"MAPPING"."CKC_SMAPPING_MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type CONSTRAINT:"MAPPING"."PK_MAPPING_ITM" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_TG_ID" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."PK_MAPPING" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_UREID" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_V2" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_PARENT_CT" creation failed
    Processing object type TABLE_EXPORT/TABLE/COMMENT
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type COMMENT skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
    ORA-39112: Dependent object type REF_CONSTRAINT:"MAPPING"."FK_MAPPING_MAPPING" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type REF_CONSTRAINT:"MAPPING"."FK_MAPPING_CT" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type REF_CONSTRAINT:"MAPPING"."FK_TG" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type REF_CONSTRAINT:"MAPPING"."FK_TT" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Processing object type TABLE_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
    ORA-39112: Dependent object type INDEX:"MAPPING"."X_PART" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."X_TIME_T" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."X_DAY" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    ORA-39112: Dependent object type INDEX:"MAPPING"."X_BTMP" skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_AND_BITMAP/INDEX_STATISTICS
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_TG_ID" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_V2_T" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."PK_MAPPING" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_PARENT_CT" creation failed
    ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"MAPPING"."IDX_UREID" creation failed
    Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
    ORA-39112: Dependent object type TABLE_STATISTICS skipped, base object type TABLE:"MAPPING"."MAPPING" creation failed
    Job "MAPPING"."SYS_IMPORT_FULL_01" completed with 52 error(s) at 11:22:39Please help..!!
    Regards
    Umesh Gupta

    yes, i have tried that option as well.
    but when i write one tablespace name in REMAP_TABLESPACE clause, it gives error for second one.. n if i include 1st and 2nd tablespace it will give error for 3rd one..
    one option, what i know write all tablespace name in REMAP_TABLESPACE, but that too lengthy process..is there any other way possible????
    Regards
    UmeshAFAIK the option you have is what i recommend you ... through it is lengthy :-(
    Wait for some EXPERT and GURU's review on this issue .........
    Good luck ....
    --neeraj                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Set table level degree for partitioned table

    Hi all,
    Usually, we set degree 2 or 4 to big tables. In this case, CBO will choose parallel select for these tables if possible.
    Let assume one case that is table1 joins table2. non-partitioned Table1 has 20m rows and has degree 2. partitioned table2 has 50m rows and has no parallel degree.
    When I checked the execution plan, CBO uses parallel execution and uses PX BLOCK ITERATOR on table1 as expected. But I don't know whether table2 is selected in parallel, too.
    I mean I am not sure whether CBO launches slave processes against table2 or just select table2 as a whole.
    And with your tuning or architecture experiences, do you think whehther we should set degree for a partitioned table as the partitioned table can be parallelized based on partitions?
    best regards,
    Leon

    user12064076 wrote:
    And with your tuning or architecture experiences, do you think whether we should set degree for a partitioned table as the partitioned table can be parallelized based on partitions?What version of Oracle?
    A site I worked at recently preferred not to hard-code the degree but to let Oracle choose it at runtime; they felt it offered better allocation of system load than hard-coding the values. They were on 10g release 2.

  • Tuning an insert sql that inserts a million rows doing a full table scan

    Hi Experts,
    I am on Oracle 11.2.0.3 on Linux. I have a sql that inserts data in a history/archive table from a main application table based on date. The application table has 3 million rows in it. and all rows that are older then 6 months should go into a history/archive table. this was recently decided and we have 1 million rows that satisfy this criteria. This insert into archive table is taking about 3 minutes. The explain plan shows a full table scan on the main table - which is the right thing as we are pulling out 1 million rows from main table into history table.
    My question is that, is there a way I can make this sql go faster?
    Here is the query plan (I changed the table names etc.)
       INSERT INTO EMP_ARCH
       SELECT *
    FROM EMP M
    where HIRE_date < (sysdate - :v_num_days);
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        2      0.00       0.00          0          0          0           0
    Execute      2     96.22     165.59      92266     147180    8529323     1441230
    Fetch        0      0.00       0.00          0          0          0           0
    total        4     96.22     165.59      92266     147180    8529323     1441230
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: FIRST_ROWS
    Parsing user id: 166
    Rows     Row Source Operation
    1441401   TABLE ACCESS FULL EMP (cr=52900 pr=52885 pw=0 time=21189581 us)
    I heard that there is a way to use opt_param hint to increase the multiblock read count but didn't seem to work for me....I will be thankful for suggestions on this. also can collections and changing this to pl/sql make it faster?
    Thanks,
    OrauserN

    Also I wish experts share their insight on how we make full table scan go faster (apart from parallel suggestion I mean).
    Please make up your mind about what question you actually want help with.
    First you said you want help making the INSERT query go faster but the rest of your replies, including the above statement, imply that you are obsessed with making full table scans go faster.
    You also said:
    our management would like us to come forth with the best way to do it
    But when people make suggestions you make replies about you and your abilities:
    I do not have the liberty to do the "alter session enable parallel dml".  I have to work within this constraings
    Does 'management' want the best way to do whichever question you are asking?
    Or is is just YOU that want the best way (whatever you mean by best) based on some unknown set of constraints?
    As SB already said, you clearly do NOT have an actual problem since you have already completed the task of inserting the data, several times in fact. So the time it takes to do it is irrevelant.
    There is no universal agreement on what the word 'best' means for any given use case and you haven't given us your definition either. So how would we know what might be 'best'?
    So until you provide the COMPLETE list of constraints you are just wasting our time asking for suggestions that you refute with a comment about some 'constraint' you have.
    You also haven't provided ANY information that indicates that it is the full table scan that is the root of the problem. It is far more likely to be the INSERT into the table and a simple use of NOLOGGING with an APPEND hint might be all that is needed.
    IMHO the 'best' way would be to partition both the source and target tables and just use EXCHANGE PARTITION to move the data. That operation would only take a millisecond or two.
    But, let me guess, that would not conform to one of your 'unknown' constraints would it?

  • Query is doing full table scan

    Hi All,
    The below query is doing full table scan. So many threads from application trigger this query and doing full table scan. Can you please tell me how to improve the performance of this query?
    Env is 11.2.0.3 RAC (4 node). Unique index on VZ_ID, LOGGED_IN. The table row count is 2,501,103.
    Query is :-
    select ccagentsta0_.LOGGED_IN as LOGGED1_404_, ccagentsta0_.VZ_ID as VZ2_404_, ccagentsta0_.ACTIVE as ACTIVE404_, ccagentsta0_.AGENT_STATE as AGENT4_404_,
    ccagentsta0_.APPLICATION_CODE as APPLICAT5_404_, ccagentsta0_.CREATED_ON as CREATED6_404_, ccagentsta0_.CURRENT_ORDER as CURRENT7_404_,
    ccagentsta0_.CURRENT_TASK as CURRENT8_404_, ccagentsta0_.HELM_ID as HELM9_404_, ccagentsta0_.LAST_UPDATED as LAST10_404_, ccagentsta0_.LOCATION as LOCATION404_,
    ccagentsta0_.LOGGED_OUT as LOGGED12_404_, ccagentsta0_.SUPERVISOR_VZID as SUPERVISOR13_404_, ccagentsta0_.VENDOR_NAME as VENDOR14_404_
    from AGENT_STATE ccagentsta0_ where ccagentsta0_.VZ_ID='v790531'  and ccagentsta0_.ACTIVE='Y';
    Table Scan                                                       AGENT_STATE                                                2.366666667
    Table Scan                                                       AGENT_STATE                                                0.3666666667
    Table Scan                                                       AGENT_STATE                                                1.633333333
    Table Scan                                                       AGENT_STATE                                                       0.75
    Table Scan                                                       AGENT_STATE                                                1.866666667
    Table Scan                                                       AGENT_STATE                                                2.533333333
    Table Scan                                                       AGENT_STATE                                                0.5333333333
    Table Scan                                                       AGENT_STATE                                                       1.95
    Table Scan                                                       AGENT_STATE                                                        0.8
    Table Scan                                                       AGENT_STATE                                                0.2833333333
    Table Scan                                                       AGENT_STATE                                                1.983333333
    Table Scan                                                       AGENT_STATE                                                        2.5
    Table Scan                                                       AGENT_STATE                                                1.866666667
    Table Scan                                                       AGENT_STATE                                                1.883333333
    Table Scan                                                       AGENT_STATE                                                        0.9
    Table Scan                                                       AGENT_STATE                                                2.366666667
    But the explain plan shows the query is taking the index
    Explain plan output:-
    PLAN_TABLE_OUTPUT
    Plan hash value: 1946142815
    | Id  | Operation                   | Name            | Rows  | Bytes | Cost (%C
    PU)| Time     |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT            |                 |     1 |   106 |   244
    (0)| 00:00:03 |
    |*  1 |  TABLE ACCESS BY INDEX ROWID| AGENT_STATE     |     1 |   106 |   244
    (0)| 00:00:03 |
    |*  2 |   INDEX RANGE SCAN          | AGENT_STATE_IDX |   229 |       |     4
    (0)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       1 - filter("CCAGENTSTA0_"."ACTIVE"='Y')
       2 - access("CCAGENTSTA0_"."VZ_ID"='v790531')
    The values (VZ_ID) i have given are dummy values picked from the table. I dont get the actual values since the query is coming with bind variables. Please let me know your suggestion on this.
    Thanks,
    Mani

    Hi,
    But I am not getting what is the issue..its a simple select query and index is there on one of the leading columns (VZ_ID --- PK). Explain plan says its using its using Index and it only select fraction of rows from the table. Then why it is doing FTS. For Optimizer, why its like a query doing FTS.
    The rule-based optimizer would have  picked the plan with the index. The cost-based optimizer, however, is picking the plan with the lowest cost. Apparently, the lowest cost plan is the one with the full table scan. And the optimizer isn't necessarily wrong about this.
    Reading data from a table via index probes is only efficient when selecting a relatively small percentage of rows. For larger percentages, a full table scan is generally better.
    Consider a simple example: a query that selects from a table with biographies for all people on the planet. Suppose you are interested in all people from a certain country.
    select * from all_people where country='Vatican'
    would only return only 800 rows (as Vatican is an extremely small country with population of just 800 people). For this case, obviously, using an index would be very efficient.
    Now if we run this query:
    select * from all_people where contry = 'India',
    we'd be getting over a billion of rows. For this case, a full table scan would be several thousand times faster.
    Now consider the third case:
    select * from all_people where country = :b1
    What plan should the optimizer choose? The value of :b1 bind variable is generally not known during the parse time, it will be passed by the user when the query is already parsed, during run-time.
    In this case, one of two scenarios takes place: either the optimizer relies on some built-in default selectivities (basically, it takes a wild guess), or the optimizer postpones taking the final decision until the
    first time the query is run, 'peeks' the value of the bind, and optimizes the query for this case.
    In means, that if the first time the query is parsed, it was called with :b1 = 'India', a plan with a full table scan will be generated and cached for subsequent usage. And until the cursor is aged out of library cache
    or invalidated for some reason, this will be the plan for this query.
    If the first time it was called with :b1='Vatican', then an index-based plan will be picked.
    Either way, bind peeking only gives good results if the subsequent usage of the query is the same kind as the first usage. I.e. in the first case it will be efficient, if the query would always be run for countries with big popultions.
    And in the second case, if it's always run for countries with small populations.
    This mechanism is called 'bind peeking' and it's one of the most common causes of performance problems. In 11g, there are more sophisticated mechanisms, such a cardinality feedback, but they don't always work as expected.
    This mechanism is the most likely explanation for your issue. However, without proper diagnostic information we cannot be 100% sure.
    Best regards,
      Nikolay

  • Update doing full table scan and taking long time

    Hi All,
    I am running an update statement which is doing a full table scan.
    UPDATE Database.TABLE AS T
    SET COMMENTS = CAST(CAST(COALESCE(T.COMMENTS,0) AS INTEGER) + 1 AS
    CHARACTER)
    WHERE T.TRACKINGPOINT = 'NDEL'
    AND T.REFERENCENUMBER =
    SUBSTRING(Root.XML.EE_EAI_MESSAGE.ReferenceNumber || '
    ' FROM 1 FOR 32);
    Any advice.
    Regards,
    Umair

    Mustafa,
    No Developer is writing it in his program.
    Regards,
    Umair

  • Order by column  has index which results in full table scan

    I have a query on table A which has index for column B.In the query i am using order by column B .In explain plan it shows that the full table scan is performed for table A without picking up the index for B .How can i ensure that index is picked up in the explain plan.Please help its urgent.
    Pandu

    Please help its urgent.Contact Oracle Support in that case.
    By making that remark you have just made Blushadow go out to lunch (again) now.... ;)
    Depending on your query a full scan could be 100% appropriate here.
    But since you didn't post your DB_version, optimizer settings, execution plan etc. there's not much more to say, really, besides:
    "Full scans aren't always evil".
    See:
    [When your query takes too long...|http://forums.oracle.com/forums/thread.jspa?messageID=3299435]
    [How to post a SQLstatement Tuning Request|http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0]

  • Avoid Full table scan

    Hi,
    My Query generation needs to be fine tuned. There are several queries generated that force full table scans of large tables. My question over here is whether functions and decodes need to be removed so that the queries take full advantage of the indexes on the table? I have used decode, Sum, case functions. So does it forces a full table scan of item price table (> 200 million records) as many times I have used these functions?
    How can I optimized it in more better way?

    How to see execution plan? Is it like explain plan you are saying? Can you please brief me on same.
    My query is
    Select S_ACCT_INFO.CUST_ACCT_NAM as CUST_ACCT_NAM,
           S_SLS_CRMEM_ITEM.CUST_ACCT_ID as CUST_ACCT_ID,
           S_SLS_CRMEM_ITEM.CUST_CNTRC_ID as CUST_CNTRC_ID,
           S_MCK_ITEM.GNRC_ID as GNRC_ID,
           S_MCK_ITEM.GNRC_NAM as GNRC_NAM,
           S_MCK_ITEM.SELL_DSCR_TXT as SELL_DSCR_TXT,
           S_MCK_ITEM.ITEM_STAT_CD_DSPSTN as ITEM_STAT_CD_DSPSTN,
           S_MCK_ITEM.RETL_LBL_CNT as RETL_LBL_CNT,
           S_MCK_ITEM.LBL_NAM as LBL_NAM,
           S_MCK_ITEM.MFG_SIZ_QTY as MFG_SIZ_QTY,
           S_SLS_CRMEM_ITEM.EM_ITEM_NUM as EM_ITEM_NUM,
           S_MCK_ITEM.NDC_NUM as NDC_NUM,
           S_MCK_ITEM.SPLR_ITEM_SEQ_NUM as SPLR_ITEM_SEQ_NUM,
           S_MCK_ITEM.SPLR_ACCT_NAM as SPLR_ACCT_NAM,
           S_MCK_ITEM.SPLR_ACCT_ID as SPLR_ACCT_ID,
           S_MCK_ITEM.UPC_NUM as UPC_NUM,
           S_IW_CNTRC_LEAD.CNTRC_LEAD_NAM as CNTRC_LEAD_NAM,
           DECODE(S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID, NULL, 'N', 'Y') CNTRC_IND_HIST,
           S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID as CNTRC_LEAD_TP_ID,
           S_SLS_CRMEM_ITEM.SLS_DOC_NUM as SLS_DOC_NUM,
           SUM(S_SLS_CRMEM_ITEM.SLS_AMT) INV_EXT_PRC_3,
           S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT as SLS_PROC_WRK_DT,
           CASE
             WHEN S_SLS_CRMEM_ITEM.GRS_SLS_QTY <> 0 THEN
              ROUND(S_SLS_CRMEM_ITEM.GRS_SLS_AMT / S_SLS_CRMEM_ITEM.GRS_SLS_QTY,
                    2)
             ELSE
              0
           END INV_PRC_PKG_2,
           SUM(S_SLS_CRMEM_ITEM.SLS_QTY) NET_QTY_3,
           S_SLS_CRMEM_ITEM.CUST_PO_NUM as CUST_PO_NUM,
           CASE
             WHEN S_SLS_CRMEM_ITEM.CUST_OMIT_IND IN
                  ('L', 'U', 'R', 'F', 'A', 'X') THEN
              SUM(S_SLS_CRMEM_ITEM.ORDR_QTY - S_SLS_CRMEM_ITEM.GRS_SLS_QTY)
             ELSE
              0
           END QTY_OMTD_MUS_1,
           S_ACCT_INFO.NATL_SUB_GRP_CD as NATL_SUB_GRP_CD,
           S_ACCT_INFO.CUST_STOR_NUM as CUST_STOR_NUM,
           S_MCK_ITEM.PKG_SIZ as PKG_SIZ,
           SUM(S_SLS_CRMEM_ITEM.GRS_SLS_QTY) INV_QTY_1,
           SUM(S_SLS_CRMEM_ITEM.ORDR_QTY) ORDR_QTY_2,
           SUM(S_SLS_CRMEM_ITEM.ORDR_QTY - S_SLS_CRMEM_ITEM.GRS_SLS_QTY) QTY_OMTD_1,
           SUM(S_SLS_CRMEM_ITEM.GRS_RTN_QTY) RTRN_QTY_1
      from S_SLS_CRMEM_ITEM
      LEFT OUTER JOIN S_MCK_ACCT_ITEM_PRC ON (S_SLS_CRMEM_ITEM.CUST_ACCT_ID =
                                             S_MCK_ACCT_ITEM_PRC.CUST_ACCT_ID AND
                                             S_SLS_CRMEM_ITEM.EM_ITEM_NUM =
                                             S_MCK_ACCT_ITEM_PRC.ITEM_NUM)
      LEFT OUTER JOIN S_ACCT_CNTRC_LEAD_TYP ON (S_MCK_ACCT_ITEM_PRC.CUST_ACCT_ID =
                                               S_ACCT_CNTRC_LEAD_TYP.CUST_ACCT_ID AND
                                               S_MCK_ACCT_ITEM_PRC.CNTRC_LEAD_ID =
                                               S_ACCT_CNTRC_LEAD_TYP.CNTRC_LEAD_ID)
      LEFT OUTER JOIN S_IW_CNTRC_LEAD ON (S_MCK_ACCT_ITEM_PRC.CNTRC_LEAD_ID =
                                         S_IW_CNTRC_LEAD.CNTRC_LEAD_ID)
    INNER JOIN S_ACCT_INFO ON (S_SLS_CRMEM_ITEM.CUST_ACCT_ID =
                               S_ACCT_INFO.CUST_ACCT_ID)
      LEFT OUTER JOIN S_VA_CUST_CNTRC ON (S_SLS_CRMEM_ITEM.CUST_ACCT_ID =
                                         S_VA_CUST_CNTRC.CUST_ACCT_ID AND
                                         S_SLS_CRMEM_ITEM.EM_ITEM_NUM =
                                         S_VA_CUST_CNTRC.ITEM_NUM)
    INNER JOIN S_MCK_ITEM ON (S_SLS_CRMEM_ITEM.EM_ITEM_NUM =
                              S_MCK_ITEM.EM_ITEM_NUM)
    where ((((((((S_SLS_CRMEM_ITEM.CUST_ACCT_ID in ('110718') or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000001')) or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000002')) or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000003')) or
           (S_ACCT_INFO.NATL_GRP_CD = '0227' and
           S_ACCT_INFO.NATL_SUB_GRP_CD = '000005')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000001')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000002')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000003')) or
           (S_ACCT_INFO.CUST_CHN_ID = '227' and
           S_ACCT_INFO.CUST_RGN_NUM = '000005'))
       and S_MCK_ITEM.SPLR_ACCT_ID IN
           ('34227', '34232', '34233', '34228', '34229', '34230', '34231',
            '34235', '34236', '78063', '84230', '90014', '98014')
       and (S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT between
           to_date('04/01/2007', 'MM/DD/YYYY') and
           to_date('06/30/2007', 'MM/DD/YYYY'))
    GROUP BY S_ACCT_INFO.CUST_ACCT_NAM,
              S_SLS_CRMEM_ITEM.CUST_ACCT_ID,
              S_SLS_CRMEM_ITEM.CUST_CNTRC_ID,
              S_MCK_ITEM.GNRC_ID,
              S_MCK_ITEM.GNRC_NAM,
              S_MCK_ITEM.SELL_DSCR_TXT,
              S_MCK_ITEM.ITEM_STAT_CD_DSPSTN,
              S_MCK_ITEM.RETL_LBL_CNT,
              S_MCK_ITEM.LBL_NAM,
              S_MCK_ITEM.MFG_SIZ_QTY,
              S_SLS_CRMEM_ITEM.EM_ITEM_NUM,
              S_MCK_ITEM.NDC_NUM,
              S_MCK_ITEM.SPLR_ITEM_SEQ_NUM,
              S_MCK_ITEM.SPLR_ACCT_NAM,
              S_MCK_ITEM.SPLR_ACCT_ID,
              S_MCK_ITEM.UPC_NUM,
              S_IW_CNTRC_LEAD.CNTRC_LEAD_NAM,
              DECODE(S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID, NULL, 'N', 'Y'),
              S_SLS_CRMEM_ITEM.CNTRC_LEAD_TP_ID,
              S_SLS_CRMEM_ITEM.SLS_DOC_NUM,
              S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT,
              CASE
                WHEN S_SLS_CRMEM_ITEM.GRS_SLS_QTY <> 0 THEN
                 ROUND(S_SLS_CRMEM_ITEM.GRS_SLS_AMT /
                       S_SLS_CRMEM_ITEM.GRS_SLS_QTY,
                       2)
                ELSE
                 0
              END,
              S_SLS_CRMEM_ITEM.CUST_PO_NUM,
              S_SLS_CRMEM_ITEM.CUST_OMIT_IND,
              S_ACCT_INFO.NATL_SUB_GRP_CD,
              S_ACCT_INFO.CUST_STOR_NUM,
              S_MCK_ITEM.PKG_SIZ
    order by S_MCK_ITEM.NDC_NUM               asc,
              S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT asc,
              S_SLS_CRMEM_ITEM.SLS_PROC_WRK_DT asc

  • PARTITION TABLE 이란?

    제품 : ORACLE SERVER
    작성날짜 : 2004-08-13
    PARTITION TABLE 이란?
    =====================
    PURPOSE
    partition table에 대한 기본 개념입니다.
    SCOPE
    8~10g Standard Edition 에서는 Partitioning Option 은 지원하지 않습니다.
    Explanation
    ORACLE 8에서 제공하는 partition table 에 대해 알아보자.
    1. Partitioned Table이란?
    partitioning 이란 큰 object 를 작고 manage 가 가능하게 분리하는 것을 의미하며,
    table 이나 index 에서만 가능하고 cluster, snapshot 은 불가능하다.
    각 partition 은 별개의 segment 에 저장되어진다.
    Oracle8에서 table 은 기본이 되는 key value 에 의해 partition 으로 분리되어진다.
    각 partition은 독립적으로 운영된다.
    예를 들어 table partition 은 DML (insert, update, delete) 문에 의한
    transaction 을 다른 partition 에 영향을 주지 않고 복구가 가능하다.
    DBA_TAB_PARTITIONS 에 각 partition 의 storage 정보 등을 갖는다.
    2. 어떻게 partitioned Table을 생성하는가 ?
    partition key(s)와 개개의 partition 에 범위를 주어 생성한다.
    이 partition 이름은 주어질 수 있으며 만일 생략되면 ORACLE 이 SYS_Pn 으로
    generate 한다.
    예제 :
    emp partition 을 EMPNO column을 partition key 로 하여 생성해 보자.
    CREATE TABLE emp
    (EMPNO NUMBER(5),
    PARTITION BY RANGE(EMPNO)(
    partition emp_p1 VALUES LESS THAN (2000),
    partition emp_p2 VALUES LESS THAN (4000),
    partition emp_p3 VALUES LESS THAN (MAXVALUE));
    select * from emp partition (emp_p3);
    ACCT_NO PERSON SALES_AMOUNT WEEK_NO
    1000 abc 10 30
    insert into emp partition (emp_p3) values (7000, 'bcd', 10, 30);
    3. partition table 관련한 dictionary 정보
    . storage parameters
    --> DBA_TAB_PARTITIONS
    . partiton table 의 upper partition bound
    --> select high_value, partition_position from sys.dba_tab_partitions
    where table_name = 'SALES';
    4. Partitioned tables의 제약점은?
    a) Datatype 제약
    Partitioned table은 LONG 이나 LONG RAW datatype을 가질 수 없다.
    또한 LOB datatypes (BLOB, CLOB, NCLOB, or BFILE), object types을 가질 수
    없다. 이 LOB type 은 V8.1부터는 가능할 것으로 기대된다.
    b) Clusters 는 partition 될 수 없다.
    c) Bitmap 제한
    bitmap 은 local partitioned table 에서만 가능하고 global indexes 로는
    불가능하다.
    d) Physical 제한
    Partitioned table은 여러 개의 database에 걸쳐 있을 수 없다.
    오직 1 instance 에서만 가능하다.
    5. Local Prefixed와 Local Non-Prefixed index란?
    Local index란 partitioned table 의 index로 이는 오로지 한 partition 의
    row들을 나타내는 ROWID 를 갖는 index 이다.
    이는 주로 partition table 의 partition key 로 사용되어진다.
    이를 equi-partitioning 이라 한다.
    Prefixed index는 partition key 에 대응하는 leading index key(s) 이다.
    Non-Prefixed index 는 leading column 이 되는 partition key 를 포함하지 않는
    index key 이다.
    6. Global index란?
    global index 는 prefix 만 제공하며 non-prefix 는 제공하지 않는다.
    global Index 는 전체 table 의 ROWID 처럼 사용되어진다.
    7. partitions을 사용하는 방법?
    Partition-Extended Table Name을 사용한다.
    즉 "schema.table PARTITION part_name" 를 사용하는데 schema 는 schema owner
    이고 table은 base table 이름이며, PARTITION 은 써도 되고 안 써도 되는 용어이고,
    partition_name은 partition 의 name 이다.
    이 partition-extented table 이름은 다음 문장에서 사용되어진다.
    INSERT
    UPDATE
    DELETE
    LOCK TABLE
    SELECT
    Q) partition 에 insert 시:
    SQL> insert into sales partition (p8) values (7000, 'bcd', 10, 30);
    Q) partition을 delete시:
    SQL> delete from sales partition (p8);
    Q) partition을 update 시:
    SQL> update sales partition (p8) set sales_amount = 20;
    Q) partition을 select 시:
    SQL> select * from sales PARTITION (Q4);
    8. partition-extended table 이름의 제약?
    . remote schema object를 포함할 수 없다.
    partition-extended table name 은 dblink 를 포함할 수 없으며, dblink 를 통해
    table 로 변환 가능한 synonym 을 포함할 수 없다.
    만일 remote partition의 사용을 원할 때에는 remote site 에서
    partitioned-extended table 이름을 사용하여 view 를 생성할 수 있다.
    . partition-extended table 이름은 PL/SQL에서 사용되지 않는다.
    partition-extended table 이름을 사용한 SQL 문은 DBMS_SQL package 를 통해
    만일 사용하고자 한다면 view 를 사용하여야 한다.
    . 오로지 base table 만 허용된다.
    partition extension 은 base table 에만 허용되고 synonyms, views, 그외 schema
    에서는 허용되지 않는다.
    9. Export/Import 시 Table-Level 과 Partition-Level 의 차이점?
    테이블 단위의 export에서는 partitioned or non-partitioned table 전체가 index
    와 그 table 에 dependent 한 다른 모든 object 가 함께 export 된다.
    즉 partitioned table 의 모든 partition 이 export 된다. (이는 direct path
    export and conventional path export에 모두 적용.)
    또한 모든 export 모드 (full, user, table) 가 테이블 단위의 export 를 support
    한다.
    partition 단위의 export에서는 사용자가 테이블의 하나 또는 그 이상의 partition
    을 export 할 수 있다.
    Full database 단위나 user mode 는 partition-level의 export 를 support 하지
    않는다. 오직 table levle 만 가능하다.
    또한 incremental export (incremental,cumulative, and complete) 가 full
    database mode 에서만 가능하기 때문에 partition-level export는 incremental
    exports를 지원하지 못한다.
    Partition-level import는 export 되어진 non-partitioned table을 import 하지
    못한다. 그러나, table-level 의 import로 non-partitioned table 로부터
    partitioned table 이 import되어진다.
    즉 partition-level import 는 export 되어진 table 이 partitioned 되어 있고
    export file 에 있을 때에만 가능하다.
    export file 의 partition name 이 valid 하지 않는 경우 import 시 경고
    message 를 발생한다.
    모든 경우 partitioned data 는 import 시 선택적으로 가능하게 export 되어 진다.
    export 나 import 시 table name 을 지정 시는
    TABLES=schema_name : tables_name : partition_name 으로 사용한다.
    Partition 단위의 export 는 table 내의 특정 partition 을 한개 또는 그 이상을
    export 가능하게 한다.
    이 때 partition name 이 주어지지 않으면 table 전체가 사용된다.
    다음은 partiotion level 의 export 예제이다.
    exp system/manager FILE = export.dmp TABLES = (scott.b:px, scott.b:py,
    mary.c, d:qb)
    이 예제에서 scott.b 는 반드시 partitioned table이고 px ,py 는 2개의
    partition 이다.
    mary.c 는 partitioned 또는 non-partitioned table 이다. 그러나 d table 은
    반드시 partitioned table 이며 qb 는 그 partioion 중의 하나이다.
    만일 table-name이나 같은 table 의 partition-name이 중복 사용되어지면
    export 는 error 를 발생한다. 예를 들어 다음 partition-level의 export 명령어는
    table sc 와 partition px 가 중복 사용되어 error 를 발생한다.
    exp system/manager FILE = export.dmp TABLES = (sc, sc:px, sc)
    10. partiton table 또는 view를 어떻게 non-partitioned table로 변환시키는가?
    table 을 변환하기 위해 dummy table 을 생성하고,
    alter table EXCHANGE PARTITION 명령어를 통해 수행한다.
    이 명령어는 매우 빨리 data dictionary 를 update 시킨다.
    SPLIT PARTITION 은 매우 큰 partition table 이나 view 를 handling 하는 데
    유용하다.
    SQL:
    1. partition을 갖는 dummy_t table 을 생성
    2. alter table EXCHANGE partition T with dummy_T
    3. drop table T
    exp/imp:
    1. export the table
    2. drop the table .
    3. partiton 을 갖는 table 을 다시 생성
    4. table data 를 import 한다.
    11. table partition을 결합하는 법?
    export/import:
    partition-level 의 export, import 를 통해 가능하다.
    1. partition data 를 갖는 temporary table을 생성한다.
    2. drop the partition to be merged
    3. insert into table (select * from temporary table)
    4. drop temp.
    그러나, table partition 을 분할하는 방법은 export, import 를 통해 불가능하다.
    Example
    Reference Document
    ------------------

    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

  • 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

  • Issue with updating partitioned table

    Hi,
    Anyone seen this bug with updating partitioned tables.
    Its very esoteric - its occurs when we update a partitioned table using a join to a temp table (not non-temp table) when the join has multiple joins and you're updating the partitoned column that isn't the first column in the primary key and the table contains a bit field. We've tried changing just one of these features and the bug disappears.
    We've tested this on 15.5 and 15.7 SP122 and the error occurs in both of them.
    Here's the test case - it does the same operation of a partitioned table and a non-partitioned table, but the partitioned table shows and error of "Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'".
    I'd be interested if anyone has seen this and has a version of Sybase without the issue.
    Unfortunately when it happens on a replicated table - it takes down rep server.
    CREATE TABLE #table1
        (   PK          char(8) null,
            FileDate        date,
            changed         bit
    CREATE TABLE partitioned  (
      PK         char(8) NOT NULL,
      ValidFrom     date DEFAULT current_date() NOT NULL,
      ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
    LOCK DATAROWS
      PARTITION BY RANGE (ValidTo)
      ( p2014 VALUES <= ('20141231') ON [default],
      p2015 VALUES <= ('20151231') ON [default],
      pMAX VALUES <= (MAX) ON [default]
    CREATE UNIQUE CLUSTERED INDEX pk
      ON partitioned(PK, ValidFrom, ValidTo)
      LOCAL INDEX
    CREATE TABLE unpartitioned  (
      PK         char(8) NOT NULL,
      ValidFrom     date DEFAULT current_date() NOT NULL,
      ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
    LOCK DATAROWS
    CREATE UNIQUE CLUSTERED INDEX pk
      ON unpartitioned(PK, ValidFrom, ValidTo)
    insert partitioned
    select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    insert unpartitioned
    select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    insert #table1
    select "ET00jPzh", "Jan 15 2015", 1
    union all
    select "ET00jPzh", "Jan 15 2015", 1
    go
    update partitioned
    set    ValidTo = dateadd(dd,-1,FileDate)
    from   #table1 t
    inner  join partitioned p on (p.PK = t.PK)
    where  p.ValidTo = '99991231'
    and    t.changed = 1
    go
    update unpartitioned
    set    ValidTo = dateadd(dd,-1,FileDate)
    from   #table1 t
    inner  join unpartitioned u on (u.PK = t.PK)
    where  u.ValidTo = '99991231'
    and    t.changed = 1
    go
    drop table #table1
    go
    drop table partitioned
    drop table unpartitioned
    go

    wrt to replication - it is a bit unclear as not enough information has been stated to point out what happened.  I also am not sure that your DBA's are accurately telling you what happened - and may have made the problem worse by not knowing themselves what to do - e.g. 'losing' the log points to fact that someone doesn't know what they should.   You can *always* disable the replication secondary truncation point and resync a standby system, so claims about 'losing' the log are a bit strange to be making. 
    wrt to ASE versions, I suspect if there are any differences, it may have to do with endian-ness and not the version of ASE itself.   There may be other factors.....but I would suggest the best thing would be to open a separate message/case on it.
    Adaptive Server Enterprise/15.7/EBF 23010 SMP SP130 /P/X64/Windows Server/ase157sp13x/3819/64-bit/OPT/Fri Aug 22 22:28:21 2014:
    -- testing with tinyint
    1> use demo_db
    1>
    2> CREATE TABLE #table1
    3>     (   PK          char(8) null,
    4>         FileDate        date,
    5> --        changed         bit
    6>  changed tinyint
    7>     )
    8>
    9> CREATE TABLE partitioned  (
    10>   PK         char(8) NOT NULL,
    11>   ValidFrom     date DEFAULT current_date() NOT NULL,
    12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
    13>   )
    14>
    15> LOCK DATAROWS
    16>   PARTITION BY RANGE (ValidTo)
    17>   ( p2014 VALUES <= ('20141231') ON [default],
    18>   p2015 VALUES <= ('20151231') ON [default],
    19>   pMAX VALUES <= (MAX) ON [default]
    20>         )
    21>
    22> CREATE UNIQUE CLUSTERED INDEX pk
    23>   ON partitioned(PK, ValidFrom, ValidTo)
    24>   LOCAL INDEX
    25>
    26> CREATE TABLE unpartitioned  (
    27>   PK         char(8) NOT NULL,
    28>   ValidFrom     date DEFAULT current_date() NOT NULL,
    29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
    30>   )
    31> LOCK DATAROWS
    32>
    33> CREATE UNIQUE CLUSTERED INDEX pk
    34>   ON unpartitioned(PK, ValidFrom, ValidTo)
    35>
    36> insert partitioned
    37> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    38>
    39> insert unpartitioned
    40> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    41>
    42> insert #table1
    43> select "ET00jPzh", "Jan 15 2015", 1
    44> union all
    45> select "ET00jPzh", "Jan 15 2015", 1
    (1 row affected)
    (1 row affected)
    (2 rows affected)
    1>
    2> update partitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join partitioned p on (p.PK = t.PK)
    6> where  p.ValidTo = '99991231'
    7> and    t.changed = 1
    Msg 2601, Level 14, State 6:
    Server 'PHILLY_ASE', Line 2:
    Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
    Command has been aborted.
    (0 rows affected)
    1>
    2> update unpartitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join unpartitioned u on (u.PK = t.PK)
    6> where  u.ValidTo = '99991231'
    7> and    t.changed = 1
    (1 row affected)
    1>
    2> drop table #table1
    1>
    2> drop table partitioned
    3> drop table unpartitioned
    -- duplicating with 'int'
    1> use demo_db
    1>
    2> CREATE TABLE #table1
    3>     (   PK          char(8) null,
    4>         FileDate        date,
    5> --        changed         bit
    6>  changed int
    7>     )
    8>
    9> CREATE TABLE partitioned  (
    10>   PK         char(8) NOT NULL,
    11>   ValidFrom     date DEFAULT current_date() NOT NULL,
    12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
    13>   )
    14>
    15> LOCK DATAROWS
    16>   PARTITION BY RANGE (ValidTo)
    17>   ( p2014 VALUES <= ('20141231') ON [default],
    18>   p2015 VALUES <= ('20151231') ON [default],
    19>   pMAX VALUES <= (MAX) ON [default]
    20>         )
    21>
    22> CREATE UNIQUE CLUSTERED INDEX pk
    23>   ON partitioned(PK, ValidFrom, ValidTo)
    24>   LOCAL INDEX
    25>
    26> CREATE TABLE unpartitioned  (
    27>   PK         char(8) NOT NULL,
    28>   ValidFrom     date DEFAULT current_date() NOT NULL,
    29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
    30>   )
    31> LOCK DATAROWS
    32>
    33> CREATE UNIQUE CLUSTERED INDEX pk
    34>   ON unpartitioned(PK, ValidFrom, ValidTo)
    35>
    36> insert partitioned
    37> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    38>
    39> insert unpartitioned
    40> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    41>
    42> insert #table1
    43> select "ET00jPzh", "Jan 15 2015", 1
    44> union all
    45> select "ET00jPzh", "Jan 15 2015", 1
    (1 row affected)
    (1 row affected)
    (2 rows affected)
    1>
    2> update partitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join partitioned p on (p.PK = t.PK)
    6> where  p.ValidTo = '99991231'
    7> and    t.changed = 1
    Msg 2601, Level 14, State 6:
    Server 'PHILLY_ASE', Line 2:
    Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
    Command has been aborted.
    (0 rows affected)
    1>
    2> update unpartitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join unpartitioned u on (u.PK = t.PK)
    6> where  u.ValidTo = '99991231'
    7> and    t.changed = 1
    (1 row affected)
    1>
    2> drop table #table1
    1>
    2> drop table partitioned
    3> drop table unpartitioned

  • How   to  find  global  index  in partition table

    Hi guys ,
    need one help
    How to find global index on partition table
    How to find local index on partition table
    Need query
    Thanks in advance
    Edited by: nav on Feb 17, 2012 6:51 AM

    nav wrote:
    Hi Solomon,
    so I have to identify partition & index are created or not,
    also I have check the status of index ( both global and local)So what's the problem? Table/index partition is an object, so you can query DBA_OBJECTS:
    SELECT  SUBOBJECT_NAME,
            CREATED
      FROM  DBA_OBJECTS
      WHERE OWNER = partitioned-table-owner
        AND OBJECT_NAME = partitioned-table-name
        AND CREATED >= TRUNC(SYSDATE)
    /This will give you partitions created today. So if you run this right after your job (I hope your job doen't run too close to midnight), you'll get table partition name your job created. Same logic can be applied to indexes.
    SY.

  • Auto stats gathering for partitioned table

    Hi,
    We are in 10gR2 in sun solaris. We are using auto stats gathering for our DB. Here is my question,
    i know oracle gather statistics of the table, if the table changes more than 10%. How this work out for partitioned table? If the partition table changes more than 10% will last partition analyzed or the full table. We have partitioned based on insertion date.
    Appreciate your responds.
    Regards,
    Satheesh Shanmugam
    http://borndba.com

    I hope it will be only current partition which has teh stale statistics will be gathered the stastics instead of full table.
    Anil Malkai

  • [SOLVED] The best way to recover a Partition Table. (LVM)

    I just did something really stupid I accidently had a typo in gdisk and changed the wrong hard drive partition table.
    So before I do something really stupid I post here.
    The hard drive is still mounted and I luckily have the output of the former partition table, this is it:
    fdisk -l /dev/sdb
    Festplatte /dev/sdb: 2,7 TiB, 3000558944256 Bytes, 732558336 Sektoren
    Einheiten: Sektoren von 1 * 4096 = 4096 Bytes
    Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes
    E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
    Festplattenbezeichnungstyp: dos
    Festplattenbezeichner: 0x00028375
    Device Boot Start End Sectors Size Id Type
    /dev/sdb1 256 366211193 366210938 1,4T 83 Linux
    /dev/sdb2 366211194 732558335 366347142 1,4T 83 Linux
    The partition table was a LVM partition table.
    This is the current one:
    gdisk -l /dev/sdb
    GPT fdisk (gdisk) version 0.8.10
    Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/sdb: 732558336 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): DA7956E1-B120-4F78-925A-B5DDE14E7C9C
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732558330
    Partitions will be aligned on 256-sector boundaries
    Total free space is 250 sectors (1000.0 KiB)
    Number Start (sector) End (sector) Size Code Name
    1 256 131327 512.0 MiB EF00 EFI
    2 131328 13238527 50.0 GiB 8E00 Arch
    3 13238528 732558330 2.7 TiB 8300 EXT
    I really hope someone can help me with that, I'm currently a total nerve wrack.
    If its a more or less impossible task (well or there is no guarantee that it works) I will buy a new Drive tomorow to save the currently still mounted files.
    Thank You!
    [EDIT]
    Forget about copying the file system isn't really accessible, I can open a few folders but everything in there are 0byte files
    Last edited by theblackdog (2015-03-10 14:16:59)

    So because no one gave me a answer so far (ok it's already pretty late and I was a bit imatient) I took the leap of faith and used fdisk to recreate the partition sheme,  so far everything seems to work.
    There is only one thing that would interest me, as far as I know a GPT partition table is bigger than a dos partition table, how big is the risk that data got corrupted because of the bigger table?
    I will mark the thread as solved after that.

Maybe you are looking for

  • Satellite A300D-15B - Upgrade from Windows 7 32bit to 64bit?

    I've added an extra 4GB of memory to my Satellite A300D-15B (PSAKCE). When I try to run the Windows 7 64bit upgrade it fails with a blue screen. Is it possible to upgrade this model to 64 bit Windows 7?

  • Error while viewing the SC via BBP_MON_SC

    Hello, BBP_MON_SC(check status) takes me to the initial screen where in I enter the SC number. I get the initial screen with header data. But clicking on for item details button 'item overview' gives me the following error.. System Error: SC not in T

  • High Resolution Display for MBP 13"?

    Hope Apple is listening from this board ... Am I the only one who want the powerful MBP 13" w/ fine high-res display of MBA 13"?

  • Credit card decline

    I'm from the Philippines, I've using apple for almost 2 years now. My problem just occurred just a week ago. I have been able to purchase apple apps in the apps store successfully for quite some time now. But, my issue lately is that I'm having probl

  • [CRASH] Win7 64bit + X-Fi Titanium BSOD OPENAL

    i'm just sick about blue screen window with the xfi titanium. When Creative will release proper driver for WIN Seven 64bit's here is the log: Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION The computer has rebooted from a bugcheck. The bugcheck was: 0x0000