[[질문]] index btree 관련 및 시스템 관련 질문

안녕하세요..
제가 상품검색을 하려고 oracle text의 catsearch을 사용하려고 합니다.
오라클 버전은 : 10gr2 (10.2.0.2)
os 는
Linux price 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 10:11:19 EST 2007 i686 i686 i386 GNU/Linux
SQL> begin
2 ctx_ddl.create_index_set('tproduct_iset');
3 ctx_ddl.add_index('tproduct_iset','PRICE');
5 end;
6 /
SQL> CREATE INDEX ctx_tproduct ON tproduct(PRODUCT_NAME) INDEXTYPE IS CTXSYS.CTXCAT PARAMETERS ('index set tproduct_iset');
위와 같이 가격과 상품명에 대해서 인덱스를 주었습니다.
데이터건수는 1500만건정도 입니다.
인덱스 생성시간은 1시간 30분정도 소요됩니다.
질문 1. 인덱스를 생성을 하면은 dr$ctx_tproduct$r, dr$ctx_tproduct$x, dr$ctx_tproduct01 이렇게 생성이 되는데 여기서 인덱스 b*tree level이 3이로 생성이 됩니다.
제가 알기로는 인덱스 레벨이 4이상이 되면은 인덱스 리빌드를 해야 하는거로 알고 있는데
인덱스를 재생성을 했는데도 1로 되는게 아니고 3으로 생성이 될까요?
온라인 리빌드도 안되고 리빌드 시간도 만만치 않아서요..
상품명에 대해서 인덱스를 생성을 해서 텍스트라서 레벨이 높은건가요?

인덱스 레벨은 인덱스 높이 아닌가요;;;;;
루트노드 -> 브랜치 노드 -> 리프노드
이렇게 되어 기본적으로 3레벨이 구성되는것 같은데요;;;
레벨1이라는건 없을것 같은데요...
오라클 포럼인데...날짜가 이상하게 찍히네요;;;
글 수정:
nicekijun

Similar Messages

Which is better of MANY_TO_ONE and ONE_TO_MANY

I am trying je.
A little confuse is , that suppose A has one_to_many relation to B, then B can have many_to_one relation to A. And both solution is acceptable to my application. Which should I choose?

Hello Jie,
This is a very good question, since we do not describe in the documentation how to choose between MANY_TO_ONE and ONE_TO_MANY. As you point out, it can be done either way when a related entity is used.
For example, here is how MANY_TO_ONE can be used:
@Entity
class Person {
@PrimaryKey(sequence="ID")
long id;
@SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Employer.class)
long employerId;
String name;
@Entity
class Employer {
@PrimaryKey(sequence="ID")
long id;
String description;
}Of course we will need primary indexes for both entities:
PrimaryIndex<Long,Person> personById = ...;
PrimaryIndex<Long,Employer> employerById = ...;To get the employer of a person, we simply pass the employerId to the primary index:
Person person = ...;
Employer employer = employerById.get(person.employerId);To get the employees for a given employer, we get a sub-index for the employerId secondary key:
long anEmployerId = ...;
SecondaryIndex<Long,Long,Person> personByEmployerId = ...;
EntityIndex<Long,Person> employees = personByEmployerId.subIndex(anEmployerId);
EntityCursor<Person> cursor = employees.entities();
try {
for (Person employee : cursor) {
// do something with employee
} finally {
cursor.close();
}And here is how ONE_TO_MANY can be used to provide the same functionality:
@Entity
class Person {
@PrimaryKey(sequence="ID")
long id;
String name;
@Entity
class Employer {
@PrimaryKey(sequence="ID")
long id;
@SecondaryKey(relate=ONE_TO_MANY, relatedEntity=Person.class)
Set<Long> employeeIds;
String description;
}To get the employer of a person, we simply pass the person id to the employer's secondary index:
Person person = ...;
SecondaryIndex<Long,Long,Employer> employerByEmployeeIds = ...;
Employer employer = employerByEmployeeIds.get(person.id);The primary difference is that with MANY_TO_ONE the collection of employee IDs is maintained by the secondary index, while with ONE_TO_MANY the collection of employee IDs is embedded in the Employer entity.
Therefore to get the employees for a given employer with ONE_TO_MANY, we get the Employer object from the employerById primary index and then get each person in the employeeIds set:
long anEmployerId = ...;
SecondaryIndex<Long,Long,Person> personByEmployerId = ...;
Employer employer = employerById.get(anEmployerId);
for (long employeeId : employer.employeeIds) {
Person employee = personById.get(employeeId);
// do something with employee
}There is a major difference in terms of performance and scalability. With ONE_TO_MANY, if the number of employees for a single employer is very large, then the Employer record will be large because the list of employee IDs is embedded in the Employer object. This means that it will be more expensive to load the employer, for example, if all you want is the employer description field. The list of employee IDs will always be loaded whenever you access an employer.
On the other hand, with MANY_TO_ONE, the set of employers is stored in the sub-index. The sub-index is a Btree. It is very scalable and can easily support large numbers of employees per employer, even millions. And when simply loading the Employer record, the set of employeeIds for that employer will not be loaded. The Employer record will be very small.
There are four factors in deciding whether to use MANY_TO_ONE or ONE_TO_MANY.
(1) As shown above, it is slightly easier to use ONE_TO_MANY, because you don't need to use a sub-index as you must do with MANY_TO_ONE.
(2) MANY_TO_ONE will scale to larger number of entities per relationship, since a sub-index Btree is used to store the related entities.
(3) With MANY_TO_ONE, the entity object will not grow to a large size as many related entities are added. Smaller records are always better for performance and resource consumption.
In general, I advise using MANY_TO_ONE because it does not have the potential performance problems of ONE_TO_MANY (items 2 and 3 above).
But if you know that the number of related entities per relationship will be small, then either technique works well, and you should choose whichever you prefer. You may find that ONE_TO_MANY is slightly easier to use (item 1 above). Or you may choose one technique over the other because you prefer to maintain the relationship via the Person.employerId field or the Employer.employeeIds set.
There is one additional factor. If you have a secondary key where there is no related entity, just related keys, then you have no choice. There is only one entity, and you choose the relationship type accordingly.
For example, a Person may have many email addresses, and you may choose not to have an EmailAddress entity. The email addresses are simply secondary keys, not the key of another related entity. If a user can only have one email address, you would use ONE_TO_ONE. If the user can have multiple email addresses, you would use ONE_TO_MANY as shown below.
@Entity
class Person {
@PrimaryKey(sequence="ID")
long id;
@SecondaryKey(relate=ONE_TO_MANY)
Set<String> emailAddresses;
String name;
}A gender (male or female) secondary key is an example of a MANY_TO_ONE relationship where no related entity is involved:
@Entity
class Person {
@PrimaryKey(sequence="ID")
long id;
@SecondaryKey(relate=MANY_TO_ONE)
char gender; // M or F
String name;
}In this last example, there is no choice about whether to use ONE_TO_MANY or MANY_TO_ONE because there is only one entity involved. So this last rule is:
(4) If there is no related entity, then because there is only one entity involved the relationship type is determined by the cardinality (number) of entities and keys in each relationship.
Mark

Line item...Card H

hi guys,
while creating infocube dimensions...I found some things I didnot understand...
1.Line Item Dim
2.Card H Dim
what are they and where do we use them in real time....
thanks and rgds
Surekha

Hi
Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
○ When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
this can be created when you are creating dimension in infocube.
select dimension tab in infocube declarationselect creategive 1. description for thatin the same line you find a check box called line itemcheck that-then select assign tabinclude charactertics for that dimension--activate it.
Cardinality High
When you select high cardinality for a dimension (usually when dimension table is >20% the size of the fact table), the system depending on the database, will create a different type of index (btrees instead of bitmap), which enhances selection from these structures by queries.
On your second query, on compression, the requests will be visible in the manage screen, but will not be visible in the cube and data will be compressed/summarised/aggregated). So it will not be possible to delete data from the cube based on request selection.
Please find an link for SAP Help
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Many thanks
kiran

Corporate Online Training For Oracle DBA @ Suninfosysinc Software Solutions

SUN INFOSYS SOFTWARE SOLUTIONS
Sun Infosys is a leading software solutions provider based out of Highland Park , New Jersey and serving clients across North America . Sun Infosys' dedicated information technology professionals are committed to meeting your company's information technology needs. Our allegiance to this goal and our high quality service guarantees our client's success.
Sun Infosys empowers the exchange, execution and integration of software consultancy projects with a strong edge for human resource management. By building strategic alliances with world-class companies, Sun Infosys serves a plethora of multinational businesses.
ORACLE 10g DBA COURSE CONTENTS
●     Introduction
●     Course Objectives
●     Suggested Schedule
●     Lesson Objectives
●     Oracle Products and Services
●     Oracle Database g: Stands for Grid
●     Oracle Database Architecture
●     Database Structures
●     Oracle Memory Structures
●     Process Structures
●     Oracle Instance Management
●     Server Process and Database Buffer Cache
●     Physical Database Structure
●     Tablespaces and Data Files
●     SYSTEM and SYSAUX Tablespaces
●     Segments, Extents, and Blocks
●     Logical and Physical Database Structures
●     Course Examples: The HR Schema
●     Database Architecture: Summary of Structural Components
●     Installing the Oracle Database Software
●     Tasks of an Oracle Database Administrator
●     Tools Used to Administer an Oracle Database
●     Installation: System Requirements
●     Checking the System Requirements
●     Optimal Flexible Architecture (OFA)
●     Using Optimal Flexible Architecture
●     Setting Environment Variables
●     Oracle Universal Installer (OUI)
●     Installing the Oracle Software
●     Database Configuration Options
●     Executing Configuration Scripts
●     Completing Your Installation
●     Advanced Installation Options
●     Installation Option: Silent Mode
●     Practice Overview: Installing the Oracle Software
●     Creating an Oracle Database
●     Planning the Database
●     Databases: Examples
●     Database Configuration Assistant (DBCA)
●     Using the DBCA to Create a Database
●     Password Management
●     Creating a Database Design Template
●     Using the DBCA to Delete a Database
●     Summary
●     Practice Overview: Using the DBCA
●     Managing the Oracle Instance
●     Management Framework
●     Starting and Stopping Database Control
●     Oracle Enterprise Manager
●     Accessing Oracle Enterprise Manager Database Home Page
●     Using SQL*Plus and iSQL*Plus to Access Your Database
●     Using iSQL*Plus
●     Setting Up iSQL*Plus for SYSDBA and SYSOPER Access
●     Using SQL*Plus
●     Calling SQL*Plus from a Shell Script
●     Calling a SQL Script from SQL*Plus
●     Initialization Parameter Files
●     Simplified Initialization Parameters
●     Database Startup and Shutdown
●     Starting Up an Oracle Database Instance
●     Starting Up an Oracle Database Instance: NOMOUNT
●     Starting Up an Oracle Database Instance: MOUNT
●     Starting Up an Oracle Database Instance: OPEN
●     Shutting Down an Oracle Database Instance
●     Shutdown Modes
●     SHUTDOWN Options
●     Using SQL*Plus to Start Up and Shut Down
●     Viewing the Alert Log
●     Viewing the Alert History
●     Dynamic Performance Views
●     Dynamic Performance Views: Usage Examples
●     Dynamic Performance Views: Considerations
●     Summary
●     Practice Overview: Managing the Oracle Instance
●     Managing Database Storage Structures
●     Storage Structures
●     How Table Data Is Stored
●     Anatomy of a Database Block
●     Tablespaces and Data Files
●     Oracle Managed Files (OMF)
●     Space Management in Tablespaces
●     Exploring the Storage Structure
●     Creating a New Tablespace
●     Storage for Locally Managed Tablespaces
●     Tablespaces in the Preconfigured Database
●     Altering a Tablespace
●     Actions with Tablespaces
●     Dropping Tablespaces
●     Viewing Tablespace Information
●     Gathering Storage Information
●     Viewing Tablespace Contents
●     Enlarging the Database
●     What Is Automatic Storage Management?
●     ASM: Key Features and Benefits
●     ASM: Concepts
●     Summary
●     Practice Overview: Managing Database Storage Structures
●     Administering User Security
●     Database User Accounts
●     Predefined Accounts: SYS and SYSTEM
●     Creating a User
●     Authenticating Users
●     Administrator Authentication
●     Unlocking a User Account and Resetting the Password
●     Privileges
●     System Privileges
●     Object Privileges
●     Revoking System Privileges with ADMIN OPTION
●     Revoking Object Privileges with GRANT OPTION
●     Benefits of Roles
●     Assigning Privileges to Roles and Roles to Users
●     Predefined Roles
●     Creating a Role
●     Secure Roles
●     Assigning Roles to Users
●     Profiles and Users
●     Implementing Password Security Features
●     Creating a Password Profile
●     Supplied Password Verification Function: VERIFY_FUNCTION
●     Viewing and Modifying Initialization Parameters
●     Managing Schema Objects
●     What Is a Schema?
●     Accessing Schema Objects
●     Naming Database Objects
●     Specifying Data Types in Tables
●     Creating and Modifying Tables
●     Understanding Data Integrity
●     Defining Constraints
●     Constraint Violations
●     Constraint States
●     Constraint Checking
●     Creating Constraints with SQL: Examples
●     Viewing the Columns in a Table
●     Viewing the Contents of a Table
●     Actions with Tables
●     Dropping a Table
●     Truncating a Table
●     Indexes
●     Types of Indexes
●     BTree Index
●     Bitmap Indexes
●     Index Options
●     Creating Indexes
●     What Is a View?
●     Creating Views
●     Sequences
●     Creating a Sequence
●     Using a Sequence
●     Temporary Tables
●     Temporary Tables: Considerations
●     Data Dictionary: Overview
●     Data Dictionary Views
●     Data Dictionary: Usage Examples
●     Summary
●     Practice Overview: Administering Schema Objects
Managing Data and Concurrency
●     Performance Management
●     Performance Monitoring
●     Performance Monitoring: Top Sessions
●     Performance Monitoring: Top Services
●     SQL Tuning Advisor: Overview
●     SQL Tuning Advisor Options and Recommendations
●     Using the SQL Tuning Advisor
●     Using the SQL Tuning Advisor: Example
●     SQL Tuning Advisor: SQL Statistics
●     SQL Tuning Advisor: Identifying Duplicate SQL
●     Using the SQL Access Advisor
●     Managing Memory Components
●     Enabling Automatic Shared Memory Management (ASMM)
●     Manually Setting Shared Memory Management
●     Using the Memory Advisor
●     Dynamic Performance Statistics
●     Troubleshooting and Tuning Views
●     Invalid and Unusable Objects
●     Summary
●     Practice Overview: Monitoring and Improving Performance
●     Backup and Recovery Concepts
●     Part of Your Job
●     Categories of Failures
●     Statement Failure
●     User Process Failure
●     Network Failure
●     User Error
●     Instance Failure
●     Background Processes and Recovery: Checkpoint (CKPT)
●     Background Processes and Recovery: Redo Log Files and LogWriter
●     Background Processes and Recovery: Archiver (ARCn)
●     Instance Recovery
●     Phases of Instance Recovery
●     Tuning Instance Recovery
●     Using the MTTR Advisor
●     Media Failure
●     Configuring for Recoverability
●     Control Files
●     Redo Log Files
●     Multiplexing the Redo Log
●     Archive Log Files
●     Archive Log File: Naming and Destinations
●     ARCHIVELOG Mode
●     Summary
Practice Overview: Configuring for Recoverability
○     Performing Database Backups
○     Backup Solutions: Overview
○     Oracle Secure Backup
○     User Managed Backup
○     Terminology
○     Recovery Manager (RMAN)
○     Configuring Backup Settings
Sun Infosys Software Solutions Offering Courses:
     Oracle 10g / 11g DBA
     SQL , PL/SQL
     Linux Administration
     Oracle OCA DBA
     Unix/Linux + Shell Scripting
Phone: +001-732-675-7911 (U.S.A)
E-mail : [email protected]
Website: www.suninfosysinc.com

I'll remember that company name to ensure that I neither use it nor recommend it.
John.

Diff b/w btree and bitmap index ?

What is the difference between btree and bitmap index ?
which one to used and when.
how they are differ from each other.

you'd love to see
http://www.oracle.com/technology/pub/articles/sharma_indexes.html

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

BIT MAP & BTREE INDEX

Hi Friends,
How to create the bitmap index? Pls given the syntax
When should we create the Btree index?
Given one example btree index
regs
renga

Hi Vinas,
generally bitmap is not good for data on which u are making dml operations. Since there are lock issues and index size issues.
1) lock issues bitmap index has different structre than b-tree one. There are flag, lock byte, value, start rowid, end rowid and bitmap in your index entry. So when you change one bitmap you have to lock all rows in your row id's range. In btree you lock just one row.
2) when you update index u mark one entry as deleted and create new one with new value. When you look on structure described in point 1) you get know that index entry could be quite big (generally bigger than index entry for btree index). So this is the way how your bitmap index can growth.
Both these points are really dangerous from the point of view of performance and it's reason why it's not good idea use bitmap index on columns with dml activity.
Jakub.

Binary and btree index

hi all,
i want to know the exact difference between binary and btree index and how it is useful in searching

And if you want to know how btree indexes are implemented in Oracle then you can look at [url http://gplivna.blogspot.com/2007/03/where-bad-performance-starts-my.html]my blog post containing quite many urls pointing to resources about btree indexes, bitmap indexes etc etc by such authors like Jonathan Lewis, Julian Dyke, Tim Gorman, Richard Foote.
Gints Plivna
http://www.gplivna.eu

BTree Index File

Can someone tell me what the index file of a BTree would look like as i need to program one and have no idea what the file would look like. Thanks in advance for your post.
bnid

You need to know hte exact format. Knowing generally what the format would look like might be good background knoledge but unless you have the exact format you will not be able to decode it.

Difference between btree index and bitmap index

i knw btree is the default index.but what's are the other difference present.

21 characters and 10 seconds at google:
http://www.akadia.com/services/ora_bitmapped_index.html
http://www.oracle.com/technology/pub/articles/sharma_indexes.html
http://www.dba-oracle.com/art_9i_indexing.htm
Dim

Can I select the data of the indexes?

Hi everybody,
Oracle storages indexes in index type segments as I know.
Is it possible to see the data of these index segments like a table or view?
So I would like to see not only the structue of it with:
select * from dba_segments SG where SG.segment_name = ’index_name’
I think something like this:
For example if I have a table named Table1.
(please don’t see the format of the rowid):
Rowid....field1
1_1.......AA
1_2.......AB
1_3.......BB
and I have an index on field1 named ndx_t1_f1.
Create index ndx_t1_f1 on Table1(field1);
I would like to see something like this
(if it is a simple Btree index like the ndx_t1_f1):
Select * from some_schema.???ndx_t1_f1???
Rowid..........ParentRowid..........ValuePrefix..........SolutionRowid
2_1
2_11............2_1.......................A
2_12............2_1.......................B
2_111..........2_11.....................AA......................1_1
2_112..........2_11.....................AB......................1_2
2_121..........2_12.....................BB......................1_3
And if i run:
select field1 from table1 where filed1 like 'B%'
oracle can use ndx_t1_f1 index like this:
2_1 -> 2_12 -> 2_121 -> BB
Yes, I know, there are some promlems with this imagine, but is it possible, or is it a silly question?
Thanx: lados.

Hi,
You asked: „Why do you want to do that?”
Well, I have a table T with fields F1, F2, F3 ...
If I run:
select F2, T.* from T where F1=12345;
the result is one record and the value of F2 is ‘A’.
But if I run:
select F2, F1 from T where F1=12345;
the result is one record and the value of F2 is ‘B’.
And this is the same record. Oppps!!!!!
I think the cause of the problem is the next:
I have an index on F1, F2 named ndx_T_F1_F2
In the second case: oracle uses only the index blocks and no table blocks, because all asked data exists in the index blocks.
In the first case: oracle uses the table blocks too, because I asked all field.
And I think there is a corrupted data on the index.
I created a new index on (F1,F2,F3), and I suggest to use this.
select /*+index(T, ndx_T_F1_F2_F3)*/ T.F2 from T where F1=12345;
the result is one record and the value of F2 is ‘A’.
But what is strange, oracle didn’t realise this inconsistent situation.
(It could be an earlier crash, I don’t know, I’m new at this workplace)
I think, the problem can solve with recreating the index ndx_T_F1_F2.
But it’s a very special situation for me, and I would like to see the corrupted data concretly with my eyes.
I think, that
Select * from some_schema.???ndx_t1_f1???
would I see like a view, but it would based on procedures and not tables.
It would be enough to me, because I only could see the data in the index.
But it is impossible as you wrote, isn’t it?
Thanx: lados.

Rebuild Index VS Drop and Rebuild?

Hey all,
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation) for specific indexes that get massive updates. The old process has proved to be able to fix and maintain reports performance.
In this process we rebuild specific indexes using the below command:
Alter index index_name rebuild online;
This command takes around 10 min for selected indexes.
Testing the below took 2 min for 6 or 7 indexes.
Drop Index Index_Name;
Create Index Index_Name on Table_name (Col1, col, ..);
I know that indexes might not be used, and the application performance would be degraded with stale or non-existent stats. But our production and all our test DBs have procedures that daily gather stats on them.
I tested the below script to make sure that execution plan does not change:
SELECT ProductID, ProductName, MfrID FROM PRODUCT WHERE MFRID = 'Mfr1';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 37 | 3737 | 13 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| PRODUCT | 37 | 3737 | 13 (0)|
| 2 | INDEX RANGE SCAN | PRODUCT_X1 | 37 | | 3 (0)|
dropping PRODUCT_X1 and recreating it only changed the cost to 12.
Gathering the stats again took the cost to 14.
No performance issues were faced and index was still used.
My question is: Is there any oracle recommendation that requires rebuilding the index instead of dropping and recreating it?
Is there any side effect to my approach that I did not consider?
Thank you

Charlov wrote:
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation)Nice. Not only have you defined and located index fragmentation but have also measured the rate at which it occurs.
Could you please share your definition of index fragmentation, how you detect it, and how you measure the rate of change of this fragmentation.
I am curious about all this since it can be repeatedly shown that Oracle btree indexes are never fragmented.
http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth-ii.pdf
The old process has proved to be able to fix and maintain reports performance.Great so you have traces and run time statistics from before and after the rebuild that highlight this mysterious fragmentation and show how the fragmentation caused the report to be slow, details what effects the rebuild had that caused the reports to perform better.
Please share them as these would be an interesting discussion point since no one has been able to show previously how an index rebuild caused a report to run faster or even show the fragmentation that caused it to be slow in the first place.
I mean it would be a pity if the report was just slow because of an inefficient plan and compressing an index or two that probably shouldn't be used in teh first place appears to temporarily speed it up. Could you imagine rebuilding indexes every week, because some developer put the wrong hint in a query? That would be pretty funny.

Index, Hints, etc

All,
I was wondering whether you could please help out on the following points:
(a) In the query below, what might be the suitable (and why?) indexes to be built?
=======================================
SELECT CONTRACT_PAY_GROUPS.CPG_AMOUNT_CY_AP,
CONTRACT_PAY_GROUPS.CPG_AMOUNT_EU_AP,
CONTRACT_PAY_GROUPS.CPG_TOTAL_ELIGIBLE_AREA
FROM CONTRACT JOIN CONTRACT_PAY_GROUPS ON CONTRACT.AC_SEQ = CONTRACT_PAY_GROUPS.CPG_CON_SEQ
WHERE CONTRACT.AC_START_YEAR = 2005
AND CONTRACT.AC_APPLICANT_NUMBER = '50614'
AND CONTRACT_PAY_GROUPS.CPG_SCHEME = 'Ε'
AND CONTRACT.AC_STATUS <> 2
=======================================
(b) Can the query below be (re-)written in any better way, in terms of performance (that is, which ---type of--- indexes and/or hints might be important to be created)?
=======================================
SELECT LYALLPLOTS.CP_END_YEAR
FROM (SELECT TYPLOTS.CP_PE_PLOT_ID FROM (SELECT CP_PE_PLOT_ID,
CP_PE_PT_SEQ,
AC_APPLICANT_NUMBER,
AC_START_YEAR,
AC_END_YEAR,
AC_STATUS,
AC_TYPE
FROM CONTRACT JOIN CONTRACT_PLOT ON CONTRACT.AC_SEQ = CONTRACT_PLOT.CP_CON_SEQ
JOIN APPLICATIONS ON CONTRACT.AC_APPL_SEQ = APPLICATIONS.APPL_SEQ
WHERE APPLICATIONS.APPL_YEAR = 2005
AND CP_PE_PT_SEQ IS NOT NULL ) TYPLOTS JOIN
(SELECT PT_SEQ, PT_PLOT_ID, PT_FROM_APPL_NUM, PT_TO_APPL_NUM FROM PLOTS_TRANSFER) TRPLOTS
ON TYPLOTS.CP_PE_PT_SEQ = TRPLOTS.PT_SEQ) TYTRANSFERS
JOIN (SELECT CP_PE_PLOT_ID, AC_APPLICANT_NUMBER, CONTRACT_PLOT.CP_END_YEAR FROM CONTRACT_PLOT JOIN CONTRACT
ON CONTRACT_PLOT.CP_CON_SEQ = CONTRACT.AC_SEQ
WHERE CONTRACT.AC_START_YEAR = 2004) LYALLPLOTS ON TYTRANSFERS.CP_PE_PLOT_ID = LYALLPLOTS.CP_PE_PLOT_ID
WHERE TYTRANSFERS.CP_PE_PLOT_ID = '5101-53/16--143'
GROUP BY LYALLPLOTS.CP_END_YEAR;
=======================================
(c) In general, could you please provide any insight on which types of indexes and/or hints (UNNEST, HASH_AJ, etc) might be needed in the case we are joining tables?
Any clue/support will be greatly appreciated. Thank you,
-Pericles Antoniades.

I'll echo sven's advice about not using hints unless you need to. I'm not telling you not to use hints. I am telling you to explore other solutions first, for the reasons sven mentioned.
An indexing strategy can be tricky to come up with. There are guidelines to follow (which follow), but also exceptions to those guidelines. Your own observations may differ from I'm going to describe. Also, I only glanced at your posting and possibly missed something. I'm going to describe btree indexes. Bitmap indexes work a bit differently.
Generally, indexes help do two things: get back small amounts of data quickly, and enforce uniqueness. Small amounts of data is sometimes considered to be between 15-20% of the rows in a table in 9i/10g; more than this and you might be better off with direct table access. Indexed lookups work well with nested loops joins (this is where the execution plan becomes useful) or direct table access, while other join methods (usually hash joins) may be more efficient when joining most of the rows from two tables.
What columns should you index? That's a matter of some debate. You can search OTN for other ideas. The best candidates for indexing are columns used in your WHERE clauses and/or those that make up a unique key. In your example
ON CONTRACT.AC_SEQ = CONTRACT_PAY_GROUPS.CPG_CON_SEQ WHERE CONTRACT.AC_START_YEAR = 2005 AND CONTRACT.AC_APPLICANT_NUMBER = '50614' AND CONTRACT_PAY_GROUPS.CPG_SCHEME = 'Ε' AND CONTRACT.AC_STATUS <> 2
I personally get the best results by listing the indexes in the order of most to last restrictive, but that's a matter of some debate.
I would consider putting indexes on contract.ac_seq, contract.ac_start_year contract.ac_applicant_number, and contrct.ac_status (composite), as well as contract_pay_groups.cpg_scheme and cpg_con_seq (composite). Then I would check to see if they were being used from an execution plan, ultimately using timings and run statistics from SQL*PLUS AUTOTRACE to decide if they were helping.

Issues with using XMLType indexes against a table with XMLType column

I am attempting to use an XMLIndex with a Structured Component and not having too much luck. Not much data in metalink nor is the documentation very helpful:
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10492/xdb_indexing.htm#BCGHGIGC
The table DDL is as follows:
CREATE TABLE ECI_SCHEMA.REV_ITEM_EARN_DTL_VIRTUAL(
REV_ITEM_EARN_DTL_ID_NBR NUMBER(16,0) NOT NULL,
UNIQ_MSG_ID_NBR VARCHAR2(50) NOT NULL,
REV_ITEM_BILL_DTL_ID_NBR NUMBER(16,0),
PLAN_RACN_NBR NUMBER(10,0) NOT NULL,
INV_DTL_IMG SYS.XMLType NOT NULL,
NON_INV_DTL_IMG BLOB NOT NULL,
PART_KEY_CD GENERATED ALWAYS AS (MOD(PLAN_RACN_NBR,5)) VIRTUAL,
LAST_UPDT_TMSTP TIMESTAMP(6) NOT NULL,
INV_ID_NBR NUMBER(16,0),
ITEM_STATUS_CD VARCHAR2(1) DEFAULT 'A' NOT NULL
LOB (NON_INV_DTL_IMG) STORE AS NON_IDI_LOB (CHUNK 8192 PCTVERSION 10 CACHE)
TABLESPACE ECI_DATA
PARTITION BY RANGE (PART_KEY_CD)
PARTITION RIED_DAY0_PART
VALUES LESS THAN (1)
TABLESPACE ECI_DATA
PARTITION RIED_DAY1_PART
VALUES LESS THAN (2)
TABLESPACE ECI_DATA
PARTITION RIED_DAY2_PART
VALUES LESS THAN (3)
TABLESPACE ECI_DATA
PARTITION RIED_DAY3_PART
VALUES LESS THAN (4)
TABLESPACE ECI_DATA
PARTITION RIED_MAXVAL_PART
VALUES LESS THAN (MAXVALUE)
TABLESPACE ECI_DATA
XMLTYPE COLUMN "INV_DTL_IMG" STORE AS OBJECT RELATIONAL
XMLSCHEMA "someXdbDocument.xsd"
ELEMENT "revenueInvoice"
According to the documentation, I should be able to create a structured XMLIndex on the XMLType column with the following syntax:
SQL> create index eci_schema.rev_item_earn_dtl_virt_xmlix on eci_schema.rev_item_earn_dtl_virtual
2 (INV_DTL_IMG)
3 INDEXTYPE IS XDB.XMLIndex
4 parameters ('PATH TABLE RIED_PATH_TABLE')
5 local;
When I do this, I get the following error:
create index eci_schema.rev_item_earn_dtl_virt_xmlix on eci_schema.rev_item_earn_dtl_virtual
ERROR at line 1:
ORA-29958: fatal error occurred in the execution of ODCIINDEXCREATE routine
ORA-30959: The indexed column is not stored in CLOB.
What am I doing wrong? Based on the Oracle documentation, I was under the impression that 11.2 XMLIndex would work with Object Relational storage. Is this not the case?

CREATE INDEX ECI_SCHEMA.REV_ITEM_EARN_DTL_IX7
       ON ECI_SCHEMA.REV_ITEM_EARN_DTL
                  extractValue(inv_dtl_img, '/revenueInvoice/service/transportation/mstrTrkngNbr')
TABLESPACE ECI_REV_ITEM_EARN_DTL_IX7_ITS
LOGGING
PARALLEL(DEGREE 8 INSTANCES 1)
LOCAL
/Elements that occur at most once in each document can be indexed using extractValue(). Despite the fact that the index appears to be a functional index, when we create the index we automatically re-write the create index into a normal btree index on the column that contains the value for the element identified by the xpath.
Eg in the case of a functional index based on extractValue, defined on XMLType using Object relational storage, with an xpath that identifies a node that occurs at most once in each document is not a functional index, it's re-written into a plain old vanilla btree index. You can actually check this by looking in the system tables
Eg
SQL> connect system/oracle
Connected.
SQL> select table_name, index_name from all_indexes where owner = 'OE' and table_name = 'PURCHASEORDER';
TABLE_NAME                     INDEX_NAME
PURCHASEORDER                  LINEITEM_TABLE_MEMBERS
PURCHASEORDER                  ACTION_TABLE_MEMBERS
PURCHASEORDER                  SYS_C0011037
SQL> alter session set current_schema = OE
2 /
Session altered.
SQL> create unique index PO_REF_INDEX on PURCHASEORDER (extractValue(object_value,'/PurchaseOrder/Reference'));
Index created.
SQL> set lines 250
SQL> select index_name, index_type from all_indexes where owner = 'OE' and table_name = 'PURCHASEORDER';
INDEX_NAME                     INDEX_TYPE
PO_REF_INDEX                   NORMAL
LINEITEM_TABLE_MEMBERS         NORMAL
ACTION_TABLE_MEMBERS           NORMAL
SYS_C0011037                   NORMAL
SQL> select * from dba_ind_expressions where table_name = 'PURCHASEORDER' and index_owner = 'OE'
2 /
no rows selectedFrom the above we can see that the index created on extractValue has been re-written in a plain old vanilla BTREE index, and there is no definition for it in dba_ind_expressions So assuming you were able to create the index and insert the data you should find that your index is not a functional index.
]

Creating a bit map index on a partitioned table

Dear friends,
I am trying to create a bitmap index on a partitioned table but am receiving the following ORA error. Can you please let me know on how to create a local bit map index as the message suggests?
ERROR at line 1:
ORA-25122: Only LOCAL bitmap indexes are permitted on partitioned tables
Trying to use the keyword local in front leads to wrong syntax.
Thanks in advance !!
Somnath

ORA-25122 Only LOCAL bitmap indexes are permitted on partitioned tables
Cause: An attempt was made to create a global bitmap index on a partitioned table.
Action: Create a local bitmap index instead
Example of a Local Index Creation
CREATE INDEX employees_local_idx ON employees (employee_id) LOCAL;
Example is about btree and I think it will work for bitmap also.

[[질문]] index btree 관련 및 시스템 관련 질문

Similar Messages

Maybe you are looking for