BitMap or Partition

Hello gurus

I want to know if I screwed up in my interveiew :-). I think I did.

I was asked this case you have an employee table with 100 million lines with field of sex in it to have 50% MAN and 50% of GIRLS (i.e. 50 million each). Currently, there are no indexes and partitions. the user issues a SELECT statement * OF THE KIND WHERE the EMPLOYEES = "MALE" and find it slow. Who would be the first best option for best prformance? BITMAP image index the gender OR the gender column list partition column (assuming that there is no other request on this table)?

I originally ported to the Bitmap indexes, but changed his mind to score because in this case oracle knows where the data is located and access directly the partition, but in the case of index bitmap, oracle still has to do a scan to find which lines have MALE having the bit 1.

A I screw up :-)?

Thank you

Sunny

Hello

It is a very good. And your response (partition) was good. Any index, bitmap or no, will never be a good idea to get 50 million lines. A comprehensive analysis of a partition that has all of the lines that we need is the best: read you each block only once, all lines in the block are the ones you are interested in, and read you them with diluvium readings.

The case concerned the myth this bitmap index is good for poor selective columns. But it is false. And the access of the index is good only for good selectivity. The point with the bitmap index, is that you can combine them, then you can have the index bitmap on all columns, and they are effective if you combine enough columns to get good selectivity.

Kind regards

Franck.

Tags: Database

Similar Questions

Local Bitmap Index confusion
Hello
I use Oracle 10.2.0.3.0 on Solaris 5.10.

I have a range based to 60 partitions partition table. It is a fact table. I load the data for 60 days in this table. I created a partition for each day, and the partition key is the column date. I've created the table with the partition, but does not create the local bitmap index on the partition keys $vdate, because as far as I know oracle makes the local bitmap index unusable before insert you and then to rebuild it after the charge. Is this fair?

So the best strategy is first load the data in the partition, and then create a local on this partition, is bitmap index - this exact?

For example, in the future, some lines get inserted into an existing partition where the local bitmap index is present, then I should still once rebuild the index on that partition, as in the case of insertion Oracle would have it turned off?

In this table, it has a vactivity column that is a foreign key to a dimension. Several queries use this column here where clause. I also want to create an index of bitmap on this column? On this not partitioned key column, the local bitmap index should be created. Is this fair?

Please also suggest as which is faster, a local bitmap index rebuild after making it unusable, or the deletion and recreation it?

Thank you and best regards
If you insert only a few lines, you don't need to score the unusable bitmap index partition. The insert will not fail.

However, if you perform a bulk insert several lines, it would be desirable mark it unusable and rebuild after insertion.

You can certainly create an index on the column of the FK.

Hemant K Collette

change the bitmap index
Hello
I have a table with defined as above and bitmap index partitions.
I am trying to edit bitmap index gives me the following error:

change the index BITMAP INDEX_NAME local unusable;

Error from the 1 in the command line:
change the unusable BITMAP INDEX_NAME local index
Error report:
SQL error: ORA-00940: invalid ALTER command

Is there anyway I can make unusable index bitmap and make it reusable again once my platelets are made.

Any suggestion is welcome.
Thank you
J
The current syntax is
```
ALTER INDEX  indexname UNUSABLE;  -- for the whole index
```
or
```
ALTER INDEX indexname MODIFY PARTITION partitionname UNUSABLE ;  -- for a specific partition
```

Can I create an index on a partitioned table bitmap?
Can I create an index on a partitioned table bitmap?
Yes, you can. But an index on a partitioned table bitmap must be a local index.
Image bitmap index on non partitioned tables cannot be partitioned.

Index BITMAP Advisor Advisor access SQL on the Partition key
I ran SQL and SQL Access Advisor as below he recommends index bitmap on p_key... Given that the cust table is partitioned on the p_key, does make sense to create indexes on p_key?

Not sure if SQL Access Advisor look just in ' where clause conditions/predicates "and the cardinality of such columns and not look at whether the table is partitioned or not. T it?

Is it wise to create BITMAP indexes on the partition key? If so what scenario would be beneficial?
```
SELECT * FROM cust
WHERE 
    'T' = 'T' AND 
    part_key IN 
    (   2, 3, 4 )) AND 
    (   p_key, act_key) IN ( select p_key, act_key from account where act_type = 'PENDING' and p_key in (2,3,4) )
```
user4529833 wrote:
Jonathan, I have exactly one value per partition for the partition key. However, most SQLs use 'IN' as predicate of partitioning pruning so overall stats are always used and they are always a bit bland compared to the partition level stats. Then this led SQL Access advisor recommendations?

Yes, the Counselor also recommended to create Bitmap indexes on act_type... Given this does make sense to have the Bitmap index on the partition key?

I'll post the execution plan as soon as I have access to the system...

The fact that statistics are "a little stale" was not much of a difference.

The fact that Oracle has probably used statistics at the level of the tables is likely to be the underlying issue. Is the partitioned table list or you have rigged it with partitioning range: If you faked list partitioning using partitioning of the range which MAY have contributed to the issue (but it's an assumption that I have not tested).

Unofficially, the optimizer has said something like:

+ "There are 25 possible values for pkey, there are 4 possible values for act_type, there seems to be 100 different combinations - so your query will pick up X lines. 80% of these lines will be packed in Y blocks and 20% of them will be scattered through the Z blocks if we have two bitmap index, and we will have to do sequential reading of the db file SSS. If we do an analysis through the affected partitions, we do MMM db file scattered reads. What are those cheaper. » +

You know how false it's - if you know that you need not the pkey index. You also know what is the efficiency of the column act_type is in the identification of data, so you can decide whether or not an index on act_key may be useful.

Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK

"The premature temptation to theories of shape on the lack of data is the scourge of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "the Valley of fear."

Cannot install windows after reset of the partition

I've literally been sitting to my macbook for the last 10 hours trying to get my bootcamp at work, however after tons of things difficult and research I found online I'm always at a loss. Initially, I had installed windows 7 a few weeks ago for the second time (after that yosemite deleted my previous one during the upgrade) and everything was fine. Then, I took the decision to uninstall my windows because I really wanted to expand the size of my partition, then backed up all my files and used bootcamp to delete windows and re partitioning my hard drive to a single volume. However after this, and then following the same exact steps as before (running bootcamp and sharing in a larger space) once the restarts my laptop that it comes up with the message "No boot device - insert boot disk and press any key" instead start windows automatically load (as it did before). I've repeated several times in the hope that it would work once however I can't help but feel that there is a problem with my hard drive and when I try to check my hard drive (not the 'Macintosh HD' a top one) sometimes - (I say sometimes because it does not say this error when you try to check) said this :

Audit score card for "APPLE HDD HTS547 * A9E384 Media.

Checking prerequisites

Checking the list of partition

Looking for an EFI system partition

Checking the size of the EFI system partition

The EFI system partition file system check

Check the contents of the folder on the EFI system partition

Problems were found with the partition plan that may prevent startup

Error: A disk with a mount point is required.

and yet when I performed the same task again 2 minutes later he says:

Audit score card for "APPLE HDD HTS547 * A9E384 Media.

Checking prerequisites

Checking the list of partition

Looking for an EFI system partition

Checking the size of the EFI system partition

The EFI system partition file system check

Check the contents of the folder on the EFI system partition

Audit of all areas of charger data HFS partition

Audit of the partitions to boot

Checking boot partition disk0s4

Check the file system.

HFS volume logged more control.

Check the overflow file extensions.

Check the file catalog.

Checking multiple files linked.

Check the catalog hierarchy.

Check the extended attribute file.

Checking volume bitmap.

Check the volume information.

The volume Recovery HD seems to be OK.

File system check exit code is 0.

Verification of the physical Volume of basic storage partitions

The partition plan seems to be OK

(and just for the record more when I check macintosh hd, fine):

Check the volume "Macintosh HD"

Check the file system.

Using the live mode.

Perform direct verification.

HFS volume logged more control.

Check the overflow file extensions.

Check the file catalog.

Checking multiple files linked.

Check the catalog hierarchy.

Check the extended attribute file.

Checking volume bitmap.

Check the volume information.

The volume Macintosh HD appears to be OK.

File system check exit code is 0.

I'm really not good when it comes to such things, so this information can be totally irrelevant, sorry! I had originally check my volumes a recovery when yosemite initially deleted to repartition my hard drive and reinstall windows. I really don't know what to do, any help would be appreciated. I have no knowledge in this subject what so ever but I feel that my hard drive is damaged somewhere (even if yosemite still works perfectly and all my files appear to be intact) or for some reason my boot loaders do not work...

I can provide more information if necessary, but quite frankly, I have no idea what I'm doing.

Thank you for taking the time to read this if you have!

1. do you use a USB key to install Windows?

2 can you post the output of the following OSX Terminal commands?

diskutil list

Cs diskutil list

sudo TPG - vv - r see the/dev/disk0

sudo fdisk/dev/disk0

The "sudo" commands will prompt to enter your password, and there do not appear to come back. You can also see caution against improper use 'sudo' and the potential loss of data due to an "abuse" of the order.

Rebuild partition/subpartition in parallel

Hello
I'm on 11 GR 2.
I have a composite partitioned table.
I have the index local bitmap created with the parallel clause. no degree specified and left to "DEFAULT".
I made the unusable index for some of the subparts.
Now, I want to rebuild the local indexes on the server.
alter index < index_name > < partition name > rebuild subpartition;
Given that these indices were initially created with parallel clause, do I need to explicitly specify the parallel clause for them to be rebuilt at the same time?
EDIT:
I've tested this and it seems that I have to specify the parallel clause explicitly for the index to rebuild at the same time. Without the parallel clause, the index used only a thread to do the work.
Mark as answer and closed.

Responded. We need to explicitly specify

Possible to move data in a partitioned into another tablespace table without indexes becoming UNUSABLE?

Hello
We use oracle 11.2.0.3 and know that if move us data into partitions to a different tablespace indexes get marked as UNUSABLE.
It is the range of composite date hash partitioned table.
As a result, to rebuild the global and local bitmap index.
Is it possible to transfer data to one another without the index tablespace becomes UNUSABLE?
Thank you

Hello

If you want to update the index (so that it becomes invalid) while you perform the move partition, you can use the index update clause.

Details are mentioned in the Oracle documentation. Glue one of the page here for quick reference.

Maintenance of Partitions

Note: It has an impact on the duration of this sql statement which may increase or decrease depending on the amount of data to move.

Concerning

Anurag

User_sub_partitions data dictionary not updated after you rename the partition but user_tab_partitions is

Hello
Using oracle 11.2.0.3
Date range poartitioned 1 partition for each month and 4 separate secondary partitions for each month.
and executed suite
ALTER table retailer_transaction rename partition SYS_P64937 tablespace PART_201505;
ALTER table move subpartition SYS_SUBP64933 tablespace RTRN_PART_201505 retailer_transaction;
ALTER table move subpartition SYS_SUBP64934 tablespace RTRN_PART_201505 retailer_transaction;
ALTER table move subpartition SYS_SUBP64935 tablespace RTRN_PART_201505 retailer_transaction;
ALTER table move subpartition SYS_SUBP64936 tablespace RTRN_PART_201505 retailer_transaction;
ALTER table retailer_transaction change the default attributes for the partition PART201505 tablespace RTRN_PART_201505;
Check user_tab_partitions and now to see nom_partition like PART_201505 but when check user_tab_subpartitions
a still 4 secondary partitions with a score of SYS_P64937 name
Why is this and how do you ensure user_sub_partitions corresponds to user_tab_partitions?
Thank you

user5716448 wrote:

Thanks for the reply.

Œuvres by renaming the index partition as suggested.

However, one last problem to try to rebuild the local bitmap index that is marked as UNUSABLE for the affected partition is ORA-14287 cannot rebuild a partition of a composite range partitioned index.

ALTER index RTRN_SAS_IDX PART_201505 rebuild partition;

How we can rebuild the local bitmap index to ensure it can be used - would not want to delete the local bitmap index and rebuild?

Thank you

[oracle@localhost ~] $14287 oerr ora

14287, 00000, "can not REBUILD a partition of a Composite range partitioned index.

* Cause: The user attempted to rebuild a partition of a Composite range partitioned index

which is illegal

* Action: REBUILD the index partition, a subpartition at a time

Move the data from the partitions again tablespace - direct table filled by ETL

Hello
We have a large composite table date-range/hash partitioned table (using time partitioning 11.2.0.3 range)
1 partition for each month and each such partition 4 under separate partitions.
We want to move some data from most significant storage but also direct table and inserted in all the days as part of the data warehouse and large table want to ensure
operations below result in errors in the data loading procedure
Suppose also should not take long to run lines 40 million or more each month.
Select *.
Of user_tab_partitions
Where table_name = 'CUSTOMER_TRANSACTION '.
And nom_partition like 'SYS % '.
1. (1) Alter table retailer_transaction and rename partition < nom_partition > CUST_PART_ < YYYYMM >
1. (2) tablespace create dedicated for the month of the affected partition
1. ((3) alter table retailer_transaction move tablespace subpartition < sys... > < partition_tablespace > created in 2) above
ALTER table retailer_transaction change the default attributes for the partition < CUST_PART < YYYYMM > < tablespace in 2 above > tablespace)
4 global index which would eventually rebuild afterwards due to the transition if movement makes no valid.
Several local bitmap indexes that belong to partitions.
Thoughts?
Thank you

I agree in a good store of data, everything should be according to the best practices ETL or guideline. I guess it is a FACT table, because it's big enough. A method that I can share (followed in the real world big DW) is "ELP" IE Partition Exchange loading. You can find the basic architecture of the Internet.

The basic architecture is as

The source (in your case partitioned) Table--> (unpartitioned) intermediate Table--> Table possible target (partitioned)--> the cleaning activities (and overtime).

You can use any ETL tool for this (I won't mention any other reasons).

Later, you can delete the original table and use that new table as your FACT table, your application will be available all the time. There are drawbacks as most uses of double-spaced, other than normal ETL these work will take certain amount of resources so that other ALS etc. In addition, if you load a few current days during these activities you plan / program accordingly.

Your demo is also fine, but regular ETL may fail because you rename the partitions (some uses of ETL tool partition name, in case you ever ELP) also unusable global indexes can cause failure (you have local too?).

Partitioning strategy for the OBIEE query performance

I use partitioning for the first time and I'll have trouble determining if I partition my fact table in a way that will allow the partition size to work with queries generating OBIEE. I've set up a simple example using query I wrote to illustrate my problem. In this example, I have a star with a fact table schema and I join in two dimensions. My fact table is partitioned on JOB_ID and TIME_ID RANGE LIST and those are the keys that link the two dimensions that I use in this application.

Select sum (boxbase)
TEST_RESPONSE_COE_JOB_QTR a
Join DIM_STUDY C on A.job_id = C.job_id
Join DIM_TIME B on A.response_time_id = B.time_id
where C.job_name = "FY14 CSAT"
and B.fiscal_quarter_name = ' quarter 1';

What can I say, because the query is in fact done filtering on columns in the dimensions instead of they, the columns in the table, the size isn't actually is happening. I see actually slightly better performance of a non-partitioned table, even though I wrote this application specifically for partitioning strategy which is now in place.

If I run the next statement, it runs a lot faster and a plan to explain is very simple and it seems to me that it's size down to a partition of sub as I hoped. This isn't any query generated by OBIEE how will seem so.

Select sum (boxbase)
of TEST_RESPONSE_COE_JOB_QTR
where job_id = 101123480
and response_time_id < 20000000;

Any suggestions? I get some benefits from the exchange of partition by using this configuration, but if I'm going to sacrifice performance reports then that maybe isn't useful, or at the very least, I would need to get rid of my partitions void if they are not providing any benefit.

Here are the plans to explain that I got for two queries in my original post:
Operation
Name of the object
Lines
Bytes
Cost
Object node
In/Out
PStart
PStop
INSTRUCTION SELECT optimizer Mode = ALL_ROWS

1

20960

AGGREGATION OF TRI

1
13

VIEW
SYS. VW_ST_5BC3A99F
101 K
1 M
20960

NESTED LOOPS

101 K
3 M
20950

PARTITION LIST SUBQUERY

101 K
2 M
1281

KEY (SUBQUERY)
KEY (SUBQUERY)
RANGE OF PARTITION SUBQUERY

101 K
2 M
1281

KEY (SUBQUERY)
KEY (SUBQUERY)
CONVERSION OF BITMAP IN ROWID

101 K
2 M
1281

BITMAP AND

MERGE TO BITMAP IMAGE

KEY ITERATION BITMAP

BUFFER

INDEX SKIP SCAN
CISCO_SYSTEMS. DIM_STUDY_UK
1
17
1

BITMAP INDEX RANGE SCAN
CISCO_SYSTEMS. FACT_RESPONSE_JOB_ID_BMID_12

KEY
KEY
MERGE TO BITMAP IMAGE

KEY ITERATION BITMAP

BUFFER

VIEW
CISCO_SYSTEMS.index$ _join$ _052
546
8 K
9

HASH JOIN

INDEX RANGE SCAN
CISCO_SYSTEMS. DIM_TIME_QUARTER_IDX
546
8 K
2

INDEX FULL SCAN
CISCO_SYSTEMS. TIME_ID_PK
546
8 K
8

BITMAP INDEX RANGE SCAN
CISCO_SYSTEMS. FACT_RESPONSE_TIME_ID_BMIDX_11

KEY
KEY
TABLE ACCESS BY ROWID USER
CISCO_SYSTEMS. TEST_RESPONSE_COE_JOB_QTR
1
15
19679

ROWID
L LINE

Operation
Name of the object
Lines
Bytes
Cost
Object node
In/Out
PStart
PStop
INSTRUCTION SELECT optimizer Mode = ALL_ROWS

1

1641

AGGREGATION OF TRI

1
13

SIMPLE LIST OF PARTITION

198 K
2 M
1641

KEY
KEY
RANGE OF SINGLE PARTITION

198 K
2 M
1641

1
1
TABLE ACCESS FULL
CISCO_SYSTEMS. TEST_RESPONSE_COE_JOB_QTR
198 K
2 M
1641

36
36

It seems unreasonable to think that relying on our index in a table partitioned (or partitioned in a way only focused on the help of ETL) can actually work better than partitioning in a way that we could get some size dynamic, but never static pruning?

Yes - standard tables with indexes can often outperform partitioned tables. It all depends on types of queries and predicates to query which are typically used and the number of rows returned in general.

Size of the partition eliminates the partitions TOGETHER - regardless of the number of rows in the partition or table. An index, on the other hand, is prohibited if the query predicate needs a significant number of lines since Oracle can determine that the cost is lower simply use close readings and make a full scan.

A table with 1 million rows and a query predicate who wants 100 K of them probably will not use an index at all. But the same table with two partitions could easily have one of the partitions pruned by the "number of effective lines" only 500 k or less.

If you are partitioning for performance, you should test your critical queries to make sure partitioning/pruning is effective for them.

Select sum (boxbase)

TEST_RESPONSE_COE_JOB_QTR a

Join DIM_STUDY C on A.job_id = C.job_id

Join DIM_TIME B on A.response_time_id = B.time_id

where C.job_name = "FY14 CSAT"

and B.fiscal_quarter_name = ' quarter 1';

So, what is a typical value for 'A.response_time_id '? That represents a 'B.time_id '?

Because a way of providing explicit partition keys may be to use a range of 'response_time_id' of the FACT table rather than a value of 'fiscal_quarter_name' of the DIMENSION table.

If "1 quarter" could correspond to a range of dates from 01/01/YYYY ' at ' 03/31/yyyy '. "."

Also, you said that on the partitioning: JOB_ID and TIME_ID

But if your questions relate mainly to the DATES / TIMES, you might be better use the TIME_ID for PARTITIONS and JOB_ID, if necessary, for the subpartitioning.

Date range partitioning is one of the most common around.and serves both performance and ease of maintenance (delete/archive old data).

VMFS partition table corruption? Need help to retrieve data

My House ESXi 5.1 was installed on HP Microserver G7. Hypervisor on USB-flash, datastore on Adaptec 3405.
After some problems of power electro Microserver is will not start and I have chosen to build the new server on Microserver Gen8. I moved Adaptec and disks in the new box, installed new ESXi 5.5 U1 (HP image) on USB and after reboot did not store data :-(.
After some research, I found that ESXi is not see any partition table on this raid array:

partedUtil getptbl /vmfs/devices/disks/mpx.vmhba2:C0:T0:L0
unknown
728422 255 63 11702108160
BUT! I tried to start the server of linux liveCD with vmfs-tools 0.2.5 installed partition mounted with vmfs-fuse and able to see the data! But cannot copy all important vmdk (see below).
debugvmfs is also show me some useful information:
Volume Version: 14
Version: 54
Label: STORE
Mode: public
UUID: 4f2ac538-58c181cf-arms-441ea13ee615
Creation date: 2012-02-02 23:17:44
Block size: 1 MiB
Subblock size: 8 KiB
Size of header of the FDC: 64 KiB
County of FDC Bitmap: 64
and it's very strange
debugvmfs/dev/sda1 see the lvm.extent [0]
Device: / dev/sda1
UUID: 4f2ac4da-8de4b166-a-441ea13ee615 848
LUN: 0
Version: 5
Name:
Size: 459.99 GiB
NUM. Segments: 22319
First Segment: 0
Last Segment: 22318

because I don't know that I don't create scopes.

Also, there are two vmdk files on more than 256 GB data store and it cannot copy because of the limitation of vmdk-tools :-(.

I tried to do a magic (like this - partedUtil setptbl "/ vmfs/devices/disks/mpx.vmhba2:C0:T0:L0" GPT "1 2048 11702099429 AA31E02A400F11DB9590000C2911D1B8 0""), but without success;-(.)

All the suggestions, guys?

Finally!

Found that was an "Intel VT - d" enabled in the BIOS. After disable it everything is cool.

It looks like Adaptec 3405 working wrong with it. Will try to change it to P222.

Partitioned index
Using Oracle 11.2.0.3

We are evalauating partitiong stragetegies with a view to the realization of gains from perfomnace in reports in particular.

How effeicient are partitioned indexes in this by example anti-terrorism just partitioned index aan table is not partitioned.

One big fact to durrogate keys that have bitmpa indxese table which link to accentuate associated key dimensions.

Patitioning given bitmap index which links to the largest dimension and partitiong Kay dimesnion dimension laregts.

Reflections on partitioned indexes would be particularly useful.

Thank you
user5716448 wrote:
Using Oracle 11.2.0.3

We are evalauating partitiong stragetegies with a view to the realization of gains from perfomnace in reports in particular.

How effeicient are partitioned indexes in this by example anti-terrorism just partitioned index aan table is not partitioned.

One big fact to durrogate keys that have bitmpa indxese table which link to accentuate associated key dimensions.

Patitioning given bitmap index which links to the largest dimension and partitiong Kay dimesnion dimension laregts.

Reflections on partitioned indexes would be particularly useful.

Thank you

It is not possible to create a partitioned index bitmp on a non-partitioned table. Bitmap indexes can be local partitioned only.
--
John Watson
Oracle Certified Master s/n
http://skillbuilders.com

Btree vs bitmap image

Hello

I'm little surprised when creating index. I have a partition table with 10784102 files in them. one of its columns have distinct values 8558592 in them.
which is equal to 80% of the data in the table. This column cardinality is very high for btree indexes is good for this situation.
In addition, there no null values in the column as well. However, when I create a btree index
and make a simple index select does not scan. While when I create bitmap on this column indexes it scan index. Here is my test scenario

Btree index 
explain plan for 
select   SESS_SESSESSIONID  from REBE01S2_DG0 


SELECT * FROM table(dbms_xplan.display);

explain plan succeeded.
PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Plan hash value: 854853906                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                             
----------------------------------------------------------------------------------------------------------------------------------                                                                                                                                                                           
| Id  | Operation            | Name         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |                                                                                                                                                                           
----------------------------------------------------------------------------------------------------------------------------------                                                                                                                                                                           
|   0 | SELECT STATEMENT     |              |    10M|   287M|   103K  (1)| 00:24:07 |       |       |        |      |            |                                                                                                                                                                           
|   1 |  PX COORDINATOR      |              |       |       |            |          |       |       |        |      |            |                                                                                                                                                                           
|   2 |   PX SEND QC (RANDOM)| :TQ10000     |    10M|   287M|   103K  (1)| 00:24:07 |       |       |  Q1,00 | P->S | QC (RAND)  |                                                                                                                                                                           
|   3 |    PX BLOCK ITERATOR |              |    10M|   287M|   103K  (1)| 00:24:07 |     1 |    15 |  Q1,00 | PCWC |            |                                                                                                                                                                           
|   4 |     TABLE ACCESS FULL| REBE01S2_DG0 |    10M|   287M|   103K  (1)| 00:24:07 |     1 |    15 |  Q1,00 | PCWP |            |                                                                                                                                                                           
----------------------------------------------------------------------------------------------------------------------------------                                                                                                                                                                           

11 rows selected

*drop btree and create bitmap* 

PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Plan hash value: 1533847669                                                                                                                                                                                                                                                                                  
                                                                                                                                                                                                                                                                                                             
-----------------------------------------------------------------------------------------------------------------------------------------------------                                                                                                                                                        
| Id  | Operation                       | Name                 | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |                                                                                                                                                        
-----------------------------------------------------------------------------------------------------------------------------------------------------                                                                                                                                                        
|   0 | SELECT STATEMENT                |                      |    10M|   287M|  7170   (1)| 00:01:41 |       |       |        |      |            |                                                                                                                                                        
|   1 |  PX COORDINATOR                 |                      |       |       |            |          |       |       |        |      |            |                                                                                                                                                        
|   2 |   PX SEND QC (RANDOM)           | :TQ10000             |    10M|   287M|  7170   (1)| 00:01:41 |       |       |  Q1,00 | P->S | QC (RAND)  |                                                                                                                                                        
|   3 |    PX BLOCK ITERATOR            |                      |    10M|   287M|  7170   (1)| 00:01:41 |     1 |    15 |  Q1,00 | PCWC |            |                                                                                                                                                        
|   4 |     BITMAP CONVERSION TO ROWIDS |                      |    10M|   287M|  7170   (1)| 00:01:41 |       |       |  Q1,00 | PCWP |            |                                                                                                                                                        
|   5 |      BITMAP INDEX FAST FULL SCAN| MINDX_REBE01S2_DG0_0 |       |       |            |          |     1 |    15 |  Q1,00 | PCWP |            |                                                                                                                                                        
-----------------------------------------------------------------------------------------------------------------------------------------------------                                                                                                                                                        

12 rows selected

The two queries of different time taken bitmap, return in 8 seconds while the index btree take 2mints.
Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production
AMT for 64-bit Windows: Version 11.2.0.3.0 - Production
Table and index both partition local. Range

user10858330 wrote:
Hi Jonathan when I use strange terms of suspicion is explain. Pleas take a look

The first plan that you have demonstrated is exactly as planned during the sess_sesssessionid has not been declared as NOT NULL. However, I notice that you have modified the original request.

select   /*+ index_FFS(REBE01S2_DG0(SESS_SESSESSIONID)) */ distinct  SESS_SESSESSIONID  from REBE01S2_DG0
When I remove indication FFS it use another column index
MINDX_REBE01S2_DG0_3 please specify this

But in the previous post in response to Hemant, there no - this suggests that you are mixing up of your experiences.
And you certainly don't expect to guess what is happening with the other indexes when you don't have it yet we gave the definition of the index.

Because the column has not been declared NOT NULL, there wasn't any point in trying to the indicator. Instead you might (for the purpose of investigating a point) run your query with the predicate "sess_sessessionid is not null.

Concerning
Jonathan Lewis

A slower loading into partitioned table as the non partitioned table - why?
Hello

Using oracle 11.2.0.3.

Have a large fact table and do some comparative tests on the loading of large amounts of data histroical (several hundred GB) in fact range partitioned to date table.

Although I understand if use exhange partition loading may be faster to load a partitioned table, trying to figure out why a standard sql insert takes 3 x long to load a table partitioned compared to an identical table but not partitioned. Identical EVERYHING in terms of columsn and the sql that the insert and second partitioned sql execution to
ensure caching with no impact.

Local partitioned table a partitioned bitmap index as compared to the non-partitioned table that has standardnon-partioned bitmap indexes.

Any ideas/thoughts?

Thank you
One would expect that the queries that cannot no partition pruning may be slowed down, Yes.

An easy way to see this is to imagine that you have a partitioned local index b-tree and a query that needs to scan all partitions of the index to find a handful of lines that interest you (of course, this is not likely to be exactly what you see probably but we hope informative of the source of the problem). Let's say that each partition of the index has a height of 3, so for each partition, Oracle has read 3 blocks to reach the correct terminal node. So to analyze each of the N index partitions, you need block index 3 * N bed. If the index is not partitioned, perhaps the height of the index would go up to 4 or 5 If, in that case not partitioned, you must read 4 or 5 blocks. If you have hundreds or thousands of partitions, it can easily be hundreds of times more work to analyze all the index partitions individual he would to analyze one unpartitioned index.

Partitioning is not a magical option "go faster". It is a compromise - you optimize certain operations (such as those that can partition pruning) at the expense of operations that do not partition size.

Justin

INSTRUCTION SELECT optimizer Mode = ALL_ROWS		1		20960
AGGREGATION OF TRI		1	13

BitMap or Partition

Similar Questions

Maybe you are looking for