Should both indexes be bitmap when joining or neither?

I have a table with several hundred K rows (expected to be in the millions in a matter of months, estimated 200M in a few years) with one particular smallint column that's an FK to a reference table. In the reference table it's the PK and there are only about 500 values and it is expected to grow very slowly, if at all. The large table is loaded daily in a batch process after which a stats refresh can be issued, so updates while users query is not a concern.
Am I correct in assuming the ratio of 500 to million+ makes a good low cardinality candidate for a bitmap index? The goal is equal between saving space and improving performance. Most queries join the reference table because a very small subset (or just one) of the possible values in the reference table are needed, not all of them.
If the index's purpose is to support joining to the reference table, does the PK index on the ref table need to also be bitmap type to make the most of the bitmap structure?
Thanks for any help!

>
I have a table with several hundred K rows (expected to be in the millions in a matter of months, estimated 200M in a few years) with one particular smallint column that's an FK to a reference table. In the reference table it's the PK and there are only about 500 values and it is expected to grow very slowly, if at all. The large table is loaded daily in a batch process after which a stats refresh can be issued, so updates while users query is not a concern.
Am I correct in assuming the ratio of 500 to million+ makes a good low cardinality candidate for a bitmap index? The goal is equal between saving space and improving performance. Most queries join the reference table because a very small subset (or just one) of the possible values in the reference table are needed, not all of them.
If the index's purpose is to support joining to the reference table, does the PK index on the ref table need to also be bitmap type to make the most of the bitmap structure?
>
Your use case would not be appropriate for a bitmap index.
Bitmap indexes provide benefits when used in combination with other bitmap indexes on the same table. For those use cases Oraclel can manipulate the bitmap indexes against either other ((A AND B) OR (C AND D)) very efficiently to identify the rows of interest.
You should not create either of the join indexes as a bitmap index.
See the Data Warehousing Guide for information on bitmap indexes and how/when to use them
http://docs.oracle.com/cd/B28359_01/server.111/b28313/indexes.htm
>
Bitmap indexes are most effective for queries that contain multiple conditions in the WHERE clause. Rows that satisfy some, but not all, conditions are filtered out before the table itself is accessed. This improves response time, often dramatically. If you are unsure of which indexes to create, the SQL Access Advisor can generate recommendations on what to create. As the bitmaps from bitmap indexes can be combined quickly, it is usually best to use single-column bitmap indexes.

Similar Messages

Authenticated binding: Should be asking for password when joining OD?

Hello,
I have enabled "Authenticated Binding" under OD-Policies-Binding.
When I join a computer from Accounts to OD, should the OD be asked for password? It just presents the dialog for autoconfigure services and it just binds, without any credentials.
Is it how it suppose to work?
Regards
Kostas

So after unlocking the lock, entering your password, and clicking on Login Options, the checkbox for autologin is greyed out? Did you try clicking the toggle box anyway? Does that bring up a blank dropdown menu? Did you click on the little triangle?

How to prevent Oracle from using an index when joining two tables ...

How to prevent Oracle from using an index when joining two tables to get an inline view which is used in an update statement?
O.K. I think I have to explain what I mean:
When joining two tables which have many entries sometimes it es better not to use an index on the column used as join criteria.
I have two tables: table A and table B.
Table A has 4.000.000 entries and table B has 700.000 entries.
I have a join of both tables with a numeric column as join criteria.
There is an index on this column in table A.
So I instead of
where (A.col = B.col)I want to use
where (A.col+0 = B.col)in order to prevent Oracle from using the index.
When I use the join in a select statement it works.
But when I use the join as inline view in an update statement I get the error ORA-01779.
When I remove the "+0" the update statement works. (The column col is unique in table B).
Any ideas why this happens?
Thank you very much in advance for any help.
Regards Hartmut

I think you should post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your query resp. update statement. Please use the \[code\] and \[code\] tags to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Usually if you're using the CBO (cost based optimizer) and have reasonable statistics gathered on the database objects used the optimizer should be able to determine if it is better to use the existing index or not.
Things look different if you don't have statistics, you have outdated/wrong statistics or deliberately still use the RBO (rule based optimizer). In this case you would have to use other means to prevent the index usage, the most obvious would be the already mentioned NO_INDEX or FULL hint.
But I strongly recommend to check in first place why the optimizer apparently seems to choose an inappropriate index access path.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Which index I should create Btree or Bitmap index?

I have table with columns c1,c2,c3
I want to create index on column c1
which index I should create Btree or Bitmap index
the column contain 50% unique values and 50% duplicate values
If Btree why?
If Bitmap Why?
I know that
Btree is used when there more unique values (high cardinality)
Bitmap is used when there less unique values (low cardinality)

read this -
Deadlocks with Bitmap Indexes
Bitmap indexes were designed to be used solely within data warehouses, i.e. where the vast majority of the database activity is reading data,
and there's very little (or no) data modification, except for batch processes which occasionally re-populate the warehouse.
Each "row" in the bitmap index contains references to potentially many different rowids, in contrast to a B*-tree index which references a single rowid.
It should be obvious, therefore, that, since the transactional mechanism is the same for all database operations, that any DML on a table which impacts the bitmap index may end up locking (or attempting to lock) many different "rows" within the index.
This is the key concept with deadlocks in bitmap indexes, you're not being deadlocked on the underlying table, but on the index blocks. Courtesy - http://www.oratechinfo.co.uk/deadlocks.html
hope u got it now...

Poor query performance when joining CONTAINS to another table

We just recently began evaluating Oracle Text for a search solution. We need to be able to search a table that can have over 20+ million rows. Each user may only have visibility to a tiny fraction of those rows. The goal is to have a single Oracle Text index that represents all of the searchable columns in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending order by score. What we're seeing is that query performance from TOAD is extremely fast when we write a simple CONTAINS query against the Oracle Text indexed table. However, when we attempt to first reduce the rows the CONTAINS query needs to search by using a WITH we find that the query performance degrades significantly.
For example, we can find all the records a user has access to from our base table by the following query:
SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID;
This query can execute in <100 ms. In the working example, this query returns around 1200 rows of the primary key duns_loc.
Our search query looks like this:
SELECT score(1), d.*
FROM duns d
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
The :search value in this example will be 'highway'. The query can return 246k rows in around 2 seconds.
2 seconds is good, but we should be able to have a much faster response if the search query did not have to search the entire table, right? Since each user can only "view" records they are assigned to we reckon that if the search operation only had to scan a tiny tiny percent of the TEXT index we should see faster (and more relevant) results. If we now write the following query:
WITH subset
AS
(SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID
SELECT score(1), d.*
FROM duns d
JOIN subset s
ON d.duns_loc = s.duns_loc
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
For reasons we have not been able to identify this query actually takes longer to execute than the sum of the durations of the contributing parts. This query takes over 6 seconds to run. We nor our DBA can seem to figure out why this query performs worse than a wide open search. The wide open search is not ideal as the query would end up returning records to the user they don't have access to view.
Has anyone ever ran into something like this? Any suggestions on what to look at or where to go? If anyone would like more information to help in diagnosis than let me know and i'll be happy to produce it here.
Thanks!!

Sometimes it can be good to separate the tables into separate sub-query factoring (with) clauses or inline views in the from clause or an in clause as a where condition. Although there are some differences, using a sub-query factoring (with) clause is similar to using an inline view in the from clause. However, you should avoid duplication. You should not have the same table in two different places, as in your original query. You should have indexes on any columns that the tables are joined on, your statistics should be current, and your domain index should have regular synchronization, optimization, and periodically rebuild or drop and recreate to keep it performing with maximum efficiency. The following demonstration uses a composite domain index (cdi) with filter by, as suggested by Roger, then shows the explained plans for your original query, and various others. Your original query has nested loops. All of the others have the same plan without the nested loops. You could also add index hints.
SCOTT@orcl_11gR2> -- tables:
SCOTT@orcl_11gR2> CREATE TABLE duns
2    (duns_loc NUMBER,
3      text_key VARCHAR2 (30))
4 /
Table created.
SCOTT@orcl_11gR2> CREATE TABLE primary_contact
2    (duns_loc NUMBER,
3      emp_id       NUMBER)
4 /
Table created.
SCOTT@orcl_11gR2> -- data:
SCOTT@orcl_11gR2> INSERT INTO duns VALUES (1, 'highway')
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO duns
2 SELECT object_id, object_name
3 FROM   all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact
2 SELECT object_id, namespace
3 FROM   all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> -- indexes:
SCOTT@orcl_11gR2> CREATE INDEX duns_duns_loc_idx
2 ON duns (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> CREATE INDEX primary_contact_duns_loc_idx
2 ON primary_contact (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> -- composite domain index (cdi) with filter by clause
SCOTT@orcl_11gR2> -- as suggested by Roger:
SCOTT@orcl_11gR2> CREATE INDEX duns_text_key_idx
2 ON duns (text_key)
3 INDEXTYPE IS CTXSYS.CONTEXT
4 FILTER BY duns_loc
5 /
Index created.
SCOTT@orcl_11gR2> -- gather statistics:
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- variables:
SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
SCOTT@orcl_11gR2> EXEC :employeeid := 1
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
SCOTT@orcl_11gR2> EXEC :search := 'highway'
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- original query:
SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
SCOTT@orcl_11gR2> WITH
2    subset AS
3       (SELECT d.duns_loc
4        FROM      duns d
5        JOIN      primary_contact pc
6        ON      d.duns_loc = pc.duns_loc
7        AND      pc.emp_id = :employeeID)
8 SELECT score(1), d.*
9 FROM   duns d
10 JOIN   subset s
11 ON     d.duns_loc = s.duns_loc
12 WHERE CONTAINS (TEXT_KEY, :search,1) > 0
13 ORDER BY score(1) DESC
14 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 4228563783
| Id | Operation                      | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                   |     2 |    84 |   121   (4)| 00:00:02 |
|   1 | SORT ORDER BY                 |                   |     2 |    84 |   121   (4)| 00:00:02 |
|* 2 |   HASH JOIN                    |                   |     2 |    84 |   120   (3)| 00:00:02 |
|   3 |    NESTED LOOPS                |                   |    38 | 1292 |    50   (2)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 5 |      DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | DUNS_DUNS_LOC_IDX |     1 |     5 |     1   (0)| 00:00:01 |
|* 7 |    TABLE ACCESS FULL           | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("D"."DUNS_LOC"="PC"."DUNS_LOC")
   5 - access("CTXSYS"."CONTAINS"("D"."TEXT_KEY",:SEARCH,1)>0)
   6 - access("D"."DUNS_LOC"="D"."DUNS_LOC")
   7 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- queries with better plans (no nested loops):
SCOTT@orcl_11gR2> -- subquery factoring (with) clauses:
SCOTT@orcl_11gR2> WITH
2    subset1 AS
3       (SELECT pc.duns_loc
4        FROM      primary_contact pc
5        WHERE pc.emp_id = :employeeID),
6    subset2 AS
7       (SELECT score(1), d.*
8        FROM      duns d
9        WHERE CONTAINS (TEXT_KEY, :search,1) > 0)
10 SELECT subset2.*
11 FROM   subset1, subset2
12 WHERE subset1.duns_loc = subset2.duns_loc
13 ORDER BY score(1) DESC
14 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- inline views (sub-queries in the from clause):
SCOTT@orcl_11gR2> SELECT subset2.*
2 FROM   (SELECT pc.duns_loc
3           FROM   primary_contact pc
4           WHERE pc.emp_id = :employeeID) subset1,
5          (SELECT score(1), d.*
6           FROM   duns d
7           WHERE CONTAINS (TEXT_KEY, :search,1) > 0) subset2
8 WHERE subset1.duns_loc = subset2.duns_loc
9 ORDER BY score(1) DESC
10 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- ansi join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns
3 JOIN   primary_contact
4 ON     duns.duns_loc = primary_contact.duns_loc
5 WHERE CONTAINS (duns.text_key, :search, 1) > 0
6 AND    primary_contact.emp_id = :employeeid
7 ORDER BY SCORE(1) DESC
8 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- old join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns, primary_contact
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND    duns.duns_loc = primary_contact.duns_loc
5 AND    primary_contact.emp_id = :employeeid
6 ORDER BY SCORE(1) DESC
7 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- in clause:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND    duns.duns_loc IN
5          (SELECT primary_contact.duns_loc
6           FROM   primary_contact
7           WHERE primary_contact.emp_id = :employeeid)
8 ORDER BY SCORE(1) DESC
9 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 3825821668
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN SEMI              |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2>

HT4623 I installed ios7 on my iPad 2 yesterday, this morning it wouldn't open the weather channel app. I thought maybe I should power it down. When I held down on the power button the screen went black and now it won't do anything. What do I do now?

I installed ios7 on my iPad 2 yesterday, this morning it wouldn't open the weather channel app. I thought maybe I should power it down. When I held down on the power button the screen went black and now it won't do anything. What do I do now?

Try a reset: Press and hold both Sleep/Wake and Home buttons until the Apple logo appears.

What indexes are created when we check dimension as line item.

What indexes are created when we check dimension as line item.
and also What indexes are created when we check dimension as high cardinality.
Where can i see that information in the system.
Answers are highly appreciated.
Regards
Kunal

Hi,
Line item means it does not have any dimension table.
High Cardinality means that the dimension is to have a large number of instances (that is, a high cardinality). Also, it is very important to indentify the line item dimension properly. E.g. Sales Order number, this will have the exact number of entries as the fact table entries. Hence, this can be created as a line item dimension. If you are not sure of high cardinality never select that. Activate this function when the dimension has is at least 10%- 20% the size of the fact table (in terms of the number of records). <b>In this case, B tree indices are created instead of bitmap indices.</b>. By default it is BITMAP but with high cardinality it is B-Tree indexing.
Hope this helps.
PB

I can't use Photobooth - when I open the app, I get the message: "Photo Booth couldn't save your photos - Photo Both encountered an error when trying to save your photos. You photos cannot be saved at this time."

I can't use Photobooth - when I open the app, I get the message: "Photo Booth couldn't save your photos - Photo Both encountered an error when trying to save your photos. You photos cannot be saved at this time."
i tried adding user macintosh hd/users/your_user/pictures/"photo booth" but still photo booth is not working and even images in photo booth cant be deleted they keep coming back

Back up all data.
This procedure will unlock all your user files (not system files) and reset their ownership and access-control lists to the default. If you've set special values for those attributes on any of your files, they will be reverted. In that case, either stop here, or be prepared to recreate the settings if necessary. Do so only after verifying that those settings didn't cause the problem. If none of this is meaningful to you, you don't need to worry about it.
I've tested these instructions only with the Safari web browser. If you use another browser, they may not work as described.
Step 1
If you have more than one user account, and the one in question is not an administrator account, then temporarily promote it to administrator status in the Users & Groups preference pane. To do that, unlock the preference pane using the credentials of an administrator, check the box markedAllow user to administer this computer, then reboot. You can demote the problem account back to standard status when this step has been completed.
Triple-click anywhere in the following line on this page to select it:
{ sudo chflags -R nouchg,nouappnd ~ $TMPDIR.. ; sudo chown -R $UID:staff ~ $_ ; sudo chmod -R u+rwX ~ $_ ; chmod -R -N ~ $_ ; } 2> /dev/null
Copy the selected text to the Clipboard by pressing the key combination command-C.
Launch the Terminal application in any of the following ways:
☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)
☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.
☞ Open LaunchPad. Click Utilities, then Terminal in the icon grid.
Paste into the Terminal window (command-V). I've tested these instructions only with the Safari web browser. If you use another browser, you may have to press the return key after pasting.
You'll be prompted for your login password. Nothing will be displayed when you type it. You may get a one-time warning to be careful. If you don’t have a login password, you’ll need to set one before you can run the command. If you see a message that your username "is not in the sudoers file," then you're not logged in as an administrator.
The command may take a few minutes to run, or perhaps longer if you have literally millions of files in your home folder. Wait for a new line ending in a dollar sign (“$”) to appear, then quit Terminal.
Step 2 (optional)
Take this step only if you have trouble with Step 1 or if it doesn't solve the problem.
Boot into Recovery. When the OS X Utilities screen appears, select
Utilities ▹ Terminal
from the menu bar. A Terminal window will open.
In the Terminal window, type this:
res
Press the tab key. The partial command you typed will automatically be completed to this:
resetpassword
Press return. A Reset Password window will open. You’re not going to reset a password.
Select your boot volume ("Macintosh HD," unless you gave it a different name) if not already selected.
Select your username from the menu labeled Select the user account if not already selected.
Under Reset Home Directory Permissions and ACLs, click the Reset button.
Select
 ▹ Restart
from the menu bar.

Should i use discriminator in InheritanceType.JOINED?

There are three InheritanceType, when i use InheritanceType.JOINED, should i define discriminator just like InheritanceType.SINGLETABLE?
I dont think i need discriminator anymore, but i saw books about EJB3, the examples use it.
Should i use discriminator in InheritanceType.JOINED?
Thanks

X-Post

Why should we overide hashCode method when we overide equals ?

Why should we overide hashCode method when we overide equals ?

java.lang.Swapnil wrote:
Why should we overide hashCode method when we overide equals ?For the purpose of hashing, you need to override both hashcode and equal method. It is because different objects(in most cases) have different hashcode.
Edited by: Hunky322 on 28.?ub.2009 16:21

Bad exec plan when joining tables using primary keys together w/ Contains

Hello all...this is something that confuzzles me....
When joining 2 tables, the exec plan shows that the domain index is first accessed, before checking if there is a record in the other table using a highly selective index.
create table users
(userid varchar2(20),
name varchar2(100),
resume clob
create table seeker
(seekerid varchar2(20),
userid varchar2(20),
jobid varchar2(20)
create index user_idx on users(userid)
create index job_resume_index on users(resume)
indextype is ctxsys.context
create unique index seeker_unik on seeker(seekerid)
create index seeker_index on seeker(jobid,userid)
then sample records where inserted, then the text index was sync'ed.
Query and Execution Plan:
select u.userid, u.name
from users u, seeker s
where s.jobid = 'HJOBP000000000218627'
and u.userid = s.userid
and contains(resume,'texas') > 1
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=72)
1 0 NESTED LOOPS (Cost=3 Card=1 Bytes=72)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'USERS' (Cost=2 Card=1
Bytes=30)
3 2 DOMAIN INDEX OF 'JOB_RESUME_INDEX' (Cost=0)
4 1 INDEX (RANGE SCAN) OF 'SEEKER_INDEX' (NON-UNIQUE) (Cost=
1 Card=1 Bytes=42)
The problem with execution plan is if the domain index returns huge number of records i.e. 40k rows, then it has to check each userid with the SEEKER table, and returns only 10 rows. I can add a hint to specify the use of the user_idx instead of the domain index to improve performance.
My question is how does the database determine when to use the domain index or to use other highly selective index with out the aid of a HINT. The trace file shows the use of "CTXSYS"."TEXTOPTSTATS".ODCIStatsIndexCost and "CTXSYS"."TEXTOPTSTATS".ODCIStatsFunctionCost. Are these used to compute and compare the cost of each index and decide on what index to used? If so, why does it return a lower cost for domain index when the btree index is more efficient? I have all statistics gathered for all tables and indexes (inc dr$ tables and its indexes)
Thanks,
jojo

Hi,
What I'm pasting here is actually from Ch9 of Expert PL/SQL. It shows what happens during a select with CONTAINS. It does not include a join with another table, or an additional column in the where clause. Hope it helps.
================================================
By default, the Extensible Query Optimizer is enabled. When enabled, the Extensible Query Optimizer can determine the I/O and CPU cost associated with the CONTAINS predicate, find the cost of each call to the CONTAINS() function, and determine the selectivity of the CONTAINS predicate.
To see this in action I ran the basic select earlier. Examining the SQL trace shows the steps.
Step 1 - Determine the I/O and CPU cost of the CONTAINS() function:
--Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsFunctionCost(
sys.ODCIFuncInfo('CTXSYS',
'CTX_CONTAINS',
'TEXTCONTAINS',
2),
cost,
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(
2, 'DOCUMENT_REPOSITORY', 'PLSQL',
'"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Step 2 Determine the selectivity of the CONTAINS predicate
-- Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsSelectivity(
sys.ODCIPREDINFO('CTXSYS',
'CTX_CONTAINS',
'TEXTCONTAINS',
32),
sel,
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(5, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(2, 'DOCUMENT_REPOSITORY', 'PLSQL',
"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
0,
NULL,
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Step 3: Determine the I/O and CPU cost of the CONTAINS predicate
-- Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsIndexCost(
sys.ODCIINDEXINFO('PLSQL',
'EXPERT_IDX',
sys.ODCICOLINFOLIST(
sys.ODCICOLINFO('PLSQL', 'DOCUMENT_REPOSITORY',
'"DOCUMENT"', 'BFILE', NULL, NULL)),
NULL,
0,
0),
50.00000000,
cost,
sys.ODCIQUERYINFO(
2,
sys.ODCIOBJECTLIST(sys.ODCIOBJECT('SCORE', 'CTXSYS'))),
sys.ODCIPREDINFO('CTXSYS', 'CONTAINS', NULL, 0),
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(5, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(2, 'DOCUMENT_REPOSITORY', 'PLSQL',
'"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
1,
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Note: The 50.00000000 in this last call is the selectivity retrieved from step 2.
Only after these three steps complete does the query actually get executed:
-- Available online as part of contains_trace.doc
SELECT score(1), title
FROM document_repository
WHERE CONTAINS(document, 'constitution', 1) > 0
ORDER BY 1 DESC;
This is not the end of the processing though. To retrieve the records, the $I table (the index data table) is queried as follows:
-- Available online as part of contains_trace.doc
SELECT /*+ INDEX(i) */ TOKEN_FIRST,TOKEN_LAST,TOKEN_COUNT,ROWID
FROM "PLSQL"."DR$EXPERT_IDX$I" i
WHERE TOKEN_TEXT = 'CONSTITUTION'
AND TOKEN_TYPE = 0
ORDER BY TOKEN_TEXT, TOKEN_TYPE, TOKEN_FIRST;
Note: The search term is UPPERCASE when querying against the DR$EXPERT_IDX$I table because all of the tokens are stored in uppercase by default. The original SELECT was in lowercase. This automatic conversion to uppercase allows the Text index to provide case-insensitive searching.
This query returns the following result:
TOKEN_FIRST TOKEN_LAST TOKEN_COUNT ROWID
1 2 2 AAAN54AAEAAAOvEAAo
Finally, the $R table (the rowid table) is queried.
-- Available online as part of contains_trace.doc
SELECT data
FROM "PLSQL"."DR$EXPERT_IDX$R"
WHERE row_no = 0;
Only now do I see the results of my query:
SCORE(1) TITLE
55 United States Constitution
8 Bill of Rights
Keep in mind that modifications to the query, such as the addition of other columns in the where clause or the addition of operators, will result in a different trace.
===============================

Should I remove Lightroom 3 when installing Lightroom 5?

Should I remove Lightroom 3 when installing Lightroom 5?
Or should I remove Lightroom 3 before installing Lightroom 5?

it doesn't matter.
you can leave lr 3 and use both or you can remove lr3 and, if you remove lr 3, you can remove it before installing lr 5 (in which case you'll be prompted for lr3's serial number if your lr5 is an upgrade) or you can install it after (in which case you'll only be prompted for lr5's serial number).

What should be indexed?

Given the following queryplan:
<XQuery>
<FunctionDefinition name="{http://architecturaldatasystems.com}:makeMfgHeader">
<DOMConstructor type="element">
<Name>
<Sequence>
<AnyAtomicTypeConstructor value="mfg" typeuri="http://www.w3.org/2001/XMLSchema" typename="QName"/>
</Sequence>
</Name>
<Attributes>
<DOMConstructor type="attribute">
<Name>
<Sequence>
<AnyAtomicTypeConstructor value="img" typeuri="http://www.w3.org/2001/XMLSchema" typename="QName"/>
</Sequence>
</Name>
<Children>
<DbXmlNav>
<Variable name="m"/>
<DbXmlStep axis="attribute" name="img" nodeType="attribute">
<RQPlan>P(mfg.@img)</RQPlan>
</DbXmlStep>
<Function name="{http://www.w3.org/2005/xpath-functions}:string"/>
</DbXmlNav>
</Children>
</DOMConstructor>
<DOMConstructor type="attribute">
<Name>
<Sequence>
<AnyAtomicTypeConstructor value="mfgID" typeuri="http://www.w3.org/2001/XMLSchema" typename="QName"/>
</Sequence>
</Name>
<Children>
<DbXmlNav>
<Variable name="m"/>
<DbXmlStep axis="attribute" name="mfgID" nodeType="attribute">
<RQPlan>P(mfg.@mfgID)</RQPlan>
</DbXmlStep>
<Function name="{http://www.w3.org/2005/xpath-functions}:string"/>
</DbXmlNav>
</Children>
</DOMConstructor>
<DOMConstructor type="attribute">
<Name>
<Sequence>
<AnyAtomicTypeConstructor value="name" typeuri="http://www.w3.org/2001/XMLSchema" typename="QName"/>
</Sequence>
</Name>
<Children>
<DbXmlNav>
<Variable name="m"/>
<DbXmlStep axis="attribute" name="name" nodeType="attribute">
<RQPlan>P(mfg.@name)</RQPlan>
</DbXmlStep>
<Function name="{http://www.w3.org/2005/xpath-functions}:string"/>
</DbXmlNav>
</Children>
</DOMConstructor>
</Attributes>
</DOMConstructor>
</FunctionDefinition>
<DOMConstructor type="element">
<Name>
<Sequence>
<AnyAtomicTypeConstructor value="result" typeuri="http://www.w3.org/2001/XMLSchema" typename="QName"/>
</Sequence>
</Name>
<Children>
<FLWOR>
<ForBinding name="mfg">
<DbXmlNav>
<QueryPlanFunction result="collection" container="pmcatalog.dbxml">
<OQPlan>n(V(node-element-substring-string,keyword,substring,'windows'),V(node-element-substring-string,keyword,substring,'pella'))</OQPlan>
</QueryPlanFunction>
<DbXmlStep axis="child" name="pmcatalog" nodeType="element"/>
<DbXmlStep axis="child" name="manufacturer" nodeType="element"/>
<DbXmlStep axis="child" name="mfg" nodeType="element"/>
</DbXmlNav>
<Where>
<SomeFLWOR>
<ForBinding name="pmg">
<DocumentOrder>
<DbXmlNav>
<Variable name="mfg"/>
<DbXmlStep axis="child" name="pmdata" nodeType="element"/>
<DbXmlStep axis="child" name="pmgroup" nodeType="element"/>
</DbXmlNav>
</DocumentOrder>
</ForBinding>
<Operator name="and">
<DbXmlNav>
<Variable name="pmg"/>
<DbXmlContains join="child" name="keyword" nodeType="element">
<OQPlan>V(node-element-substring-string,keyword,substring,'windows')</OQPlan>
<Sequence>
<AnyAtomicTypeConstructor value="windows" typeuri="http://www.w3.org/2001/XMLSchema" typename="string"/>
</Sequence>
</DbXmlContains>
</DbXmlNav>
<DbXmlNav>
<Variable name="pmg"/>
<DbXmlContains join="child" name="keyword" nodeType="element">
<OQPlan>V(node-element-substring-string,keyword,substring,'pella')</OQPlan>
<Sequence>
<AnyAtomicTypeConstructor value="pella" typeuri="http://www.w3.org/2001/XMLSchema" typename="string"/>
</Sequence>
</DbXmlContains>
</DbXmlNav>
</Operator>
</SomeFLWOR>
</Where>
</ForBinding>
<UserFunction name="{http://architecturaldatasystems.com}:makeMfgHeader">
<Binding name="{}:m">
<Variable name="mfg"/>
</Binding>
</UserFunction>
</FLWOR>
</Children>
</DOMConstructor>
</XQuery>
Is there any method to read this to determine what should be indexed?
currently I have :
Index: node-element-substring-string for node {}:keyword
Index: node-element-equality-string for node {}:name
I don't want to index that which does not need to be indexed :)
I can provide the xsd file if needed -

Walt,
There isn't enough information here. What is the query itself, and what behavior are you seeing? The indexes you have are definitely getting used but something else may be causing slowness if that's what you see.
Regards,
George

[svn:osmf:] 14797: Decouple MetadataGroup from synthesizer API, MetadataGroup should only be linked in when a composite element is used.

Revision: 14797
Revision: 14797
Author:   [email protected]
Date:     2010-03-16 16:34:48 -0700 (Tue, 16 Mar 2010)
Log Message:
Decouple MetadataGroup from synthesizer API, MetadataGroup should only be linked in when a composite element is used.
Modified Paths:
    osmf/trunk/framework/OSMF/org/osmf/elements/compositeClasses/CompositeMetadata.as
    osmf/trunk/framework/OSMF/org/osmf/metadata/Metadata.as
    osmf/trunk/framework/OSMF/org/osmf/metadata/MetadataGroup.as
    osmf/trunk/framework/OSMF/org/osmf/metadata/MetadataSynthesizer.as
    osmf/trunk/framework/OSMF/org/osmf/metadata/NullMetadataSynthesizer.as
    osmf/trunk/framework/OSMFTest/org/osmf/elements/compositeClasses/TestCompositeMetadata.as
    osmf/trunk/framework/OSMFTest/org/osmf/metadata/TestMetadataGroup.as

The Morena 6.0 - Image Acquisition Framework for Java(tm) Platform from http://www.gnome.sk is a package which enables you to connect to your scanner or a camera in a very intuitive way.
If you just want to see how Morena works with your scanner or camera:
- java (1.2 or higher for Windows, 1.3 or higher for Mac OS X) has to be installed on your computer
- a scanner or camera has to be installed on your computer
- download the trial package from http://www.gnome.sk
- unzipp it
- go to the examples directory of the unzipped package
- in Windows: doubleclick the runExampleShow.bat
- in MacOS:
- open the Terminal window
- change the working directory to the examples
- run .sh file (type ExampleShow.sh or sh ExampleShow.sh)
This will pop up the Twain Source Selection user interface. There, all your scanners and cameras which do have a twain driver should be listed. (About 90% of scanners and cameras on the market do have a twain driver for Windows, only a few do have a twain driver for MacOS.) Select one of them. The user interface of the selected scanner (camera) will appear. Confirm the scanning (you can set the scanning parameters first). The scanned image will be displayed in a separate window. To end the application, close that window.
Running different examples, you can test scanning with hidden UI, saving the scanned image, using ADF, taking images at regular intervals (ExampleCamera) ...
To see how Morena works in applets, go to the online remote examples http://www.gnome.sk/Twain/remote/www/twain/server/php/remote.html
If there is any problem, do not hesitate to inquire about it at the technical support, email: [email protected] or join the online forum at www.gnome.sk
Erika Kupkova

Strange problem when joining two tables

Hi,
I have recently encountered a strange problem on an Oracle 11gR2 database which is optimized for Datawarehouse usage.
I am using two tables that have a relationship enforced by two fields of type NUMBER(10).
The problem is that when I am joining these two tables very often I get strange results and when I re-execute the query I get a different result. I saw in the explain plan that the Hash Join is used for joining these two tables.
select count(*)
from recharge_history rh, recharge_history_balance rhb
where rh.recharge_id = rhb.recharge_id
and rh.recharge_id2 = rhb.recharge_id2
and trunc(rh.recharge_date_time) between '30-Dec-2012' and '31-Dec-2012'
If I explicitly set the Join method to some other type through SQL Hints, or if I use to_number function when joining (even though the two fields used for join in both tables are of NUMBER(10) type), I get the correct result, like for example below:
select /*+ USE_MERGE (rh rhb) */
count(*)
from recharge_history rh, recharge_history_balance rhb
where rh.recharge_id = rhb.recharge_id
and rh.recharge_id2 = rhb.recharge_id2
and trunc(rh.recharge_date_time) between '30-Dec-2012' and '31-Dec-2012'
select
count(*)
from recharge_history rh, recharge_history_balance rhb
where to_number(rh.recharge_id) = t_number(rhb.recharge_id)
and to_number(rh.recharge_id2) = (to_number)rhb.recharge_id2)
and trunc(rh.recharge_date_time) between '30-Dec-2012' and '31-Dec-2012'
Thank you for your time.
Edrin

Hi, Edrin,
961841 wrote:
Hi,
I have recently encountered a strange problem on an Oracle 11gR2 database which is optimized for Datawarehouse usage.
I am using two tables that have a relationship enforced by two fields of type NUMBER(10).
The problem is that when I am joining these two tables very often I get strange results and when I re-execute the query I get a different result. I saw in the explain plan that the Hash Join is used for joining these two tables.
select count(*)
from recharge_history rh, recharge_history_balance rhb
where rh.recharge_id = rhb.recharge_id
and rh.recharge_id2 = rhb.recharge_id2
and trunc(rh.recharge_date_time) between '30-Dec-2012' and '31-Dec-2012'
Don't try to compare DATEs with VARCHAR2s, such as '30-Dec-2012'. The VARCHAR2 '31-Aug-2012' is between '30-Dec-2012' and '31-Dec-2012'; so are '31-Aug-2013' and '30-Mar-1999'.
That may not be your only problem, but it's still a problem.
If you're getting incosistent results, then it sounds like a bug. Start a service request with Oracle support.

Should both indexes be bitmap when joining or neither?

Similar Messages

Maybe you are looking for