Similar Questions

• Index BITMAP and NOT NULL

  Hi all
  Is it possible to use the Index BITMAP for a NOT NULL condition?
  
  
  >
  
  CREATE a BITMAP of INDEX x_ix FOR tab (x);
  
  SELECT *.
  TAB
  WHERE x IS NOT NULL
  
  >
  
  Thank you!

  user3646231 wrote:
  You say that :) to hope

  Here it is:

  Your test is a good effort - but it needs a little more.

  Your question is "is it possible...". «, not "If Oracle always...» »

  Your demonstration showed an example where the choice of plan Oracle has surprised you (and me). Now, you need run the query with index indicator (because if the indexed access path is legal, must be taken an indexed correctly suggested path).

  I just ran a similar test (1 line of 100,000), with the following results:

  SQL> select * from table(dbms_xplan.display_cursor);
  
  PLAN_TABLE_OUTPUT
  ------------------------------------------------------------------------------
  SQL_ID  52q6gxkscvg9v, child number 0
  -------------------------------------
   select /*+ index(t1(n1)) */ * from t1 where n1 is not null
  
  Plan hash value: 2828957992
  
  ----------------------------------------------------------------------
  | Id  | Operation                    | Name  | Rows  | Bytes | Cost  |
  ----------------------------------------------------------------------
  |   0 | SELECT STATEMENT             |       |       |       |  1859 |
  |   1 |  TABLE ACCESS BY INDEX ROWID | T1    |     1 |   118 |  1859 |
  |   2 |   BITMAP CONVERSION TO ROWIDS|       |       |       |       |
  |*  3 |    BITMAP INDEX FULL SCAN    | T1_N1 |       |       |       |
  ----------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     3 - filter("N1" IS NOT NULL)
  

  You will notice that the cost of the query is unreasonable - and without the suspicion my test showed Oracle taking the full analysis at a much lower cost.
  If your test has actually demonstrated a bug in the costing, explaining why Oracle does not automatically take a path that seems reasonable.

  The above output comes from 11.2.0.3, but I had the same thing with 11.1.0.7

  Concerning
  Jonathan Lewis
  http://jonathanlewis.WordPress.com
  Author: core Oracle

• Question index bitmap

  Guys,
  
  I have a general question about the bitmap index. I develop a data model for a new system.
  
  I have a table that will get close to 20,000 files per year. There are 4 broad categories, and each row in this table is covered by one of these 4 categories. I'll use the category several times field to search all the records in the system.
  
  Don't you think that a Bitmap index on the category column will be a great help? A comment I received from my internal staff member is that: Bitmap can be an overkill for this kind of small table
  
  All comments or suggestions would be a great help...
  
  -Raj

  Hello

  I see no points you must have an index on that column bitmap if you encounter one single index bitmap for this table. Other columns are also a good candidate for the bitmap index?

  For such a small record 20,000 per year (assuming that the size of each line is normal) and with four distinct values, I doubt that you will get no gain performance between full table scan and bitmap.

  Even with 20,000 lines and four distinct values and are filled at the same time that you create a tree index b top as the grouping factor is very low. Still, he would not give a lot of benefits.

  And if most of the research is run on this table, I see it as a good candidate to keep bool in the buffer cache.

  Concerning
  Anurag

• Which switch to index for the index bitmap in Oracle Standard Edition

  Hello
  
  I have to move from Oracle Enterprise edition to standard edition (oracle11g). As standard edition does not support bitmap indexes. But the current database which is an Enterprise edition a bitmap index a column-based date or varchar2 or column in a table. The tables have approximately 60000000 records. I would like to know what index go for bitmap index.
  
  
  Kind regards
  Vaibhav
  
  Published by: Vaibhav on November 7, 2011 05:35

  The BTree index certainly can and are frequently used when values are not unique (e.g. are duplicated).

  uniqueness isn't the issue. The relative number of distinct values (relative to the total number of lines) is important. An advantage of BitMap index BTree indexes, it's that BTree indexes can be composite - made up of multiple columns.

  You can read the documentation on the index.

  http://download.Oracle.com/docs/CD/E11882_01/server.112/e25789/indexiot.htm#CBBECABB

  http://download.Oracle.com/docs/CD/E11882_01/server.112/e25494/indexes.htm#i1007132

  Hemant K Collette

• Index Bitmap and MV in Standard edition

  Salvation of DBA
  
  I have an enterprise edition 10.2.0.3 database which can be transformed into 11.2.0.3 EE. There many Materialized view with activated query rewrite. If I downgrade to the standard edition, what will be the impact? I know the rewrite of the query is a feature of EA and not SE and SEO. It is also the index Bitmap in the database which I think must be re-created as the normal b-tree index.
  
  I know that bitmap is not a feautre of the SE. One advantage that I see that updates will be faster if there is a normal index as DML are slow, if there is a Bitmap index.
  
  What will be the impact on the performance of the database if there is standard edition which does not rewrite of the query and the characteristics of Bitmap?
  
  Thank you
  
  DBA is the hero behind the screen, while developers are heroes on the screen.

  user13368428 wrote:
  I went through this table before posting my first post. I don't know there are a lot of tables in my EE database that contains bitmap indexes. In the past, I turned on the control over some of them, and they have been used. Also, I have seen queries that are rewritten to use the MV table instead of the base of fact tables.

  Yes. Really, I need to test in decommissioning and annexing the request to it. But I wanted to know if anyone has experienced this. What were their experiences do not use Bitmap indexes, function index and Query rewrite.

  Your response was very useful.

  Thank you.

  The Oracle Server Standard edition supports function based indexes (I think since version 8.1.5). Bitmap indexes are not supported and treat B * index of tree as the index of the bitmap to bitmap join operations are also not supported. You can partially determine the impact of not having the second option by editing a hidden at the session level setting (obvious caveat on masked editing settings apply here):

  ALTER SESSION SET "_B_TREE_BITMAP_PLANS" = FALSE;
  

  I'm fairly certain that the Standard Edition supports materialized views - automatic query simply not rewrite for possibly enjoy this feature based on cost.

  There may be a few other surprises, here is part 1 of 4 that explores the potentially unexpected differences between Standard Edition and Enterprise Edition (the differences are version and OPTIMIZER_FEATURES_ENABLED load):
  http://hoopercharles.WordPress.com/2010/11/21/different-performance-from-Standard-Edition-and-Enterprise-Edition-1/

  Good luck to you with the project.

  Charles Hooper
  http://hoopercharles.WordPress.com/
  IT Manager/Oracle DBA
  K & M-making Machine, Inc.

• 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."

• B - Tree and explanation Index Bitmap

  Hi gurus

  I am trying to absorb the notion of bitmap index and b-tree, but unable to grasp the concept, so far, I have learned the following:

  Index B-Tree

  Use in the OLTP environment

  It is customary for these types of columns where you have more unique value or we can say that high cardinality

  It occupies less storage

  Using the corresponding model and ranges

  By default, Oracle uses tree indexing

  Bitmap index

  Use in home environment/OLAP data items

  It is customary for these types of columns where repeated values exist or we can say that low cardinality, example are male and female

  It seems that these points of difference between the two indexes. I really appreciate if someone give me more explanation on these subjects.

  Thanks in advance

  Concerning

  Muzz

  I am trying to absorb the concept index bitmap and tree but unable to grasp the concept,

  Then the FIRST place to look is the Oracle documentation; specifically the chapter "Index and Index-Organized Tables" chapter of the Concepts doc.

  http://docs.Oracle.com/CD/E25054_01/server.1111/e25789/indexiot.htm

  3 indices and Index of Tables

  This chapter deals with indices, which are schema objects that can speed up access to the lines of the table and organized index of tables, which are tables stored in an index structure.

  This chapter contains the following sections:

  • Overview of index
  • Overview of the Tables organized by Index

  This chapter has a lot of basic information on ALL the various types of indexes.

  so far, I've learned the following:

  Where, exactly, 'have you' who? Most of it is wrong, incomplete or distorted.

  Index B-Tree

  Use in the OLTP environment

  Index B-Tree, by default, are used in all environments.

  It is customary for these types of columns where you have more unique value or we can say that high cardinality

  They can be used for a cardinality. True - a unique column index is most commonly used for high-cardinality columns. But Oracle may also use an index column, simple or composite, when the data being sought is ENTIRELY contained in one or more indexes, low cardinality.

  It occupies less storage

  Maybe, maybe not. It is based on the column being indexed, the size of the key values and the cardinality of the key values. For your example "Male and female" there will be only THREE index entries: male, female and null. And each entry is simply a list of ranges of ROWID. This index can be orders of magnitude smaller than the equivalent B-Tree index.

  Using the corresponding model and ranges

  For the most part correct - although the range queries can be used with the bitmap index which is not a common use.

  By default, Oracle uses tree indexing

  Fix.

  Bitmap index

  Use in home environment/OLAP data items

  Especially correct - DML on tables with the bitmap index can cause severe performance and throughput problems. The distinction is therefore between environments with medium/high DML on a table compared to the weak or nonexistent DML on a table.

  So rather than a distinction between environments (OLAP and warehouse) the distinction is no longer between the TABLES (high/medium DML versus LOW/NO DML). There is nothing wrong at all with the help of the index of the bitmap in an OLAP environment - but these indices should be limited to the tables with low, or no, DML.

  It is customary for these types of columns where repeated values exist or we can say that low cardinality, example are male and female

  Yes and no.

  Yes - a bitmap index is not really appropriate, if there is NO repeat value.

  No - part II (low cardinality). The attribute MAJOR missing from what you have posted is that bitmap indexes are ALMOST always used in conjunction with others (usually a bitmap) index.

  If one, or more, high cardinality bitmap index can be used VERY effectively together to identify a set of rows to a query.

  See my multiple responses in this thread

  https://community.oracle.com/message/10219613?

  One of my answers presents, in detail, just how many attributes can be combined using several bitmap on both high columns index and low cardinality.

  In a later response, I provide the actual sample code and display the execution plan indicating how Oracle just that.

  SQL> set serveroutput on
SQL> set autotrace on explain
SQL> select rowid from star_fact where
  2   (state = 'CA') or (state = 'CO')
  3  and (age = 'young') and (marital_status = 'divorced')
  4  and (((summer_sport = 'baseball') and (softdrink = 'pepsi'))
  5  or ((summer_sport = 'golf') and (beer = 'coors')));


  Read the full thread.

• How to include the total number of table one fact in another fact table to calculate the percentage

  I have a fact table in the grain of each document created in any organization, say the 1st table of facts. I have another table of facts (2nd fact table) seen those documents which are considered by different commentators. grain of this second fact table is so each review, even if I document in both IDs the fact table.

  Now, I want to calculate the percentage return documents reviewed. For this I need to divide count separate from the document of performance by the total performance document. Now this document of total performance can be obtained from the 1st table of facts, but I don't get how to bring this indictment in the 2nd table of facts to show the percentage.

  Please let me know if there is no ambiguity in my question, because I'm a starter in OBIEE.

  Thank you very much.

  then you can set new logical column with two columns of fact in the formula

• OBIEE - multiple fact Tables

  Hello

  I have a case.

  I have three tables:

  1 XX_PERIODS_D

  2 XX_ORDERS_F

  3 XX_SHIPMENTS_F

  XX_PERIODS_D a column PERIOD_CODE

  XX_ORDERS_F a column PERIOD_CODE

  XX_SHIPMENTS_F a column PERIOD_CODE

  XX_PERIODS_D.PERIOD_CODE joined with XX_ORDERS_F.PERIOD_CODE

  XX_PERIODS_D.PERIOD_CODE joined with XX_SHIPMENTS_F.PERIOD_CODE

  RPD is OK

  Analysis Log Queries return results that are OK

  Analysis shows the results are bad for XX_SHIPMENTS_F tbal

  

  Hello

  I fixed my self,

  I created only once the fact table by the application using as start logic diagram and it's corrected now.

  Thanks @.

• Help! Logical physical Table table - imported as fact table

  I am trying to create a logical table. When I drag the alias of the physical layer in the MDB, logic is created with the sign #. I think that it indicates as a fact table. I can't create a logical dimension of this table. How can I make the table come in a logic instead of a fact?

  Thank you for your help.

  1 > drag the physical Table in MDB. It will create a logical fact table in MDB Test for example.

  2 > duplicate this logical fact table. Another fact logical Test #1 table will be created.

  3 > select Test / Test No. 1 logical tables, and then right-click and select model for Business diagram.

  4 > create a new logical join between the Test and the Test #1 in MDB. Make sure that this Test: Test #1 cardinality is 1:M.

  5 > This will make the Test as a logical dimension table. Double-click the logical size Test table, go to the tab key and create a primary key.

• How to create a logical fact table in a layer MDB?

  Hello
  
  I have 3 Dimension table - 2 are in a schema and the last is another schema. Using this 3 dimension tables, I need to create a logical fact table.
  So, my question is if we can create this table made by joining these 3 dimension table that are 2 different schema s?
  
  Thank you

  Hi Kuldip,
  Business is never a problem.

  Presentation layer is used to group similar business lines tables.
  It's just for users to understand or requirrment.

  You can use different domain tables to create a report. However the MDB and the physical joins is given in the tables to the RPD. It is compulsory to join tables in MDB layer and the physical layer to be used in the analysis.

  Hope that clarifies.

  A course if you think perticular table is used in the object anaother are, so you must add this table to the domain of the RPD. (Which makes sense)

  Mark if it is correct,

  Bachelot

• How to remove the fact Table

  Hi all
  
  If I have to restart my fact table on the same day, more than once a day, and he had already stored in it, I want to remove these lines and reload the fact with the current date. I want to create a procedure and include it in the package, the process must check the current_timestamp and if the lines with the date and if there is then it should delete it. Please let me know how I can do this. I am running SQL Server - 2008.
  
  Thanks for your time and your help.

  You should have to date in your primary key (ex: in a varchar as YYYYMMDD format).

  Then you have 2 ways to implement:

  create an ODI procedure that will remove all data where this date = today. Perform this procedure before your interface.
  * or change your IKM: Add a step that will erase the data in the target table if date = today.

• the combination of more than two fact tables

  Hello
  
  I have read many texts on combining made tables but I have not yet find answer to my question.
  
  I have four fact tables I would combine into one. This is something simple, but is anyway it to avoid joins when you query the fact that one?
  
  So I'm waisting my time or is this possible?

  Hello

  I think it's possible. I have not yet tried in my environment, but how about you create several LTS for these facts. I mean you can create several LTS (according to your requests of course however) for each of your facts and some combinations of these.

  So, every time there is that one table of facts to be questioned, BI Server can intelligently pick the correct LTS but don't need to make an unnecessary join between the huge facts.

  I hope this helps.

  Thank you
  Diakité

• Two filters in two dimensions without constraining the fact table

  Hi all
  
  does anyone know how to avoid the factual constraint when you create a report with two filters on different dimensions?
  
  I have a fact table big with more than 10 million lines. In the starmodel is the customer of the dimension and the products. I create a filter on the customer atrribute 'Status' and set to 'active '. Now I add the "Product Type" column of the dimension 'Product' in the filter section. When I want to choose a value OBIEE executes a select statement in the fact table. So I have to wait very long to select a value. Is it possible to say OBIEE only to select the dimension table without joining the fact table?
  
  Thank you much in advance.
  
  Kind regards
  Stefan

  Use is implied.

  Create a table of facts of the DUMMY and make also implied made for this dimension column. It will solve the problem.
  http://obiee11gqna.blogspot.com/2011/01/implicit-fact-column-in-OBIEE.html

  Published by: MK on January 17, 2012 07:08

  Published by: MK on January 17, 2012 07:08

• Limit the rows of the fact Table by using a table Dim - 10 g

  Hello
  
  I'm having some trouble trying to restrict the result to a fact table using a Dim picture (assume that the example below).
  
  -----DIM A-------------------------------FACT B--------------
  ID-Code - Id_Date - Id_Dim - value
  1---ABCD---01-01-2011---1---10
  2---XYZ---02-01-2011---2---20
  3---RST---03-01-2011---1---30
  ----------------------------------04-01-2011-------3------------40
  
  I want to show only the rows where Dim.Code = 'ABCD '. I know on the MDB, I choose the LTS of the fact table and on the content tab, on where clause insert: Dim.Id = 1, but I don't want to be limited by Dim.Id, I want to limit by Dim.Code and who cannot do this way.
  
  What I did on the LTS of the fact table, on the tab general got the fact Table on the mapped tables and I added the table Dim doing a join internal between the fact Table and the Table Dim. This way when I go to the content tab, I can do: Dim.Code = "ABCD" because the tables are attached now.
  
  Is it bad to do? Is there a better way to solve this problem?
  
  Before ask you I can't do it directly on the table of the Sun because this chart Dim is used in other Tables of facts. Creates an alias for the Table Dim and limit there the way forward?
  
  I hope that I was clear, thank you

  The way you do it is correct. If you have only one or two measures, then you could also do it using logical columns with the filter function.

  table of facts, for example:
  value = (unfiltered, do not show in the layer close)
  Value of ABCD = (filter (value using dim code = "ABCD"))

  Then you can expand this without having to create a table of facts for each variation:
  value = (unfiltered, do not show in the layer close)
  Value of ABCD = (filter (value using dim code = "ABCD"))
  Value of XYZ = (filter (value using dim code = "XYZ"))
  First value = (filter (value using dim code = "RST"))

  etc. Contrary to the statements of case, it pushes the return filter logic to the database (you get a where clause clause). Kind regards

  Robert