Information on HRP1000 and HRP1001 tables

Hello All,
Could someone please tell me where I can find more information on these tables (HRP1000 and HRP1001 tables) like what they are used for and some documentation? I searched the forums but I did not find much on documentation.
Thanks.
Mithun

Hi Mithun.
I would like to suggest a couple of references,
[SDN - Reference - Which are the best functions to use for reading infotype HRP1000|Which are the best functions to use for reading infotype HRP1000;
[SDN - Reference - HR ABAP - Organisational infotypes |Regarding HR ABAP;
[SDN - Reference - Organizational Model - HRP1000 and HRP1001 |Read the Org Model;
Hope that's usefull.
Good Luck & Regards.

Similar Messages

Question on data in tables HRP1000 and HRP1001

Hello,
we are in the process of putting in the SAP HR module. I have been asked by th Business analyst about entries already existing the HR OM space (HRP1000 and HRP1001).
I was not involved when this was being created. I am thinking that we are using org structures s for workflow notification purposes only.
would there be anything thing else that we would be using this for?
thanks

Hello Timothy,
there are a lot of applications from HR but also other components which use the tables HRP1000 and HRP1001. But there might be another source of the entries in the tables. All HR infotype tables are delivered as type C (customizing) tables. As a result sap delivers tons of garbage entries for these tables.
There is sap note 547031 which describes that the HR tables have to be excluded when doing a client copy with ustomizing so these garbage entries are not copied. I have seen several systems where this note has not been applied especially if the HR modules were not in focus when setting up the system. As far as I have experienced you can identify such entries as they have the value "SAP" in the UNAME field of the infotype.
Kind Regrads
Roman

Table HRP1000 and HRP1001

Hi,
what is the difference between table HRP1000 and HRP1001.
thank you.

Hi
HRP1000 - Object : Determines the existence of an organizational object.
Stores data that determines the short and long name
of an organizational object.
HRP1001-Relationship - Defines the Relationships between different objects.
For example, Org Unit to Org Unit, Position to Org
Unit, etc.
Refer this link for other HRP infotypes :
http://help.mybeacon.nc.gov/beaconhelp/Human_Resources/Org_Mgmt/Job_Aids/pdf_OM_Infotypes%20V2_050208.pdf

HRP1000 and HRP1001.

Hi Gurus-
Can anyone give some info on the tables HRP1000 and HRP1001 and important fields in them.
Thanks.
Ramesh.

hi Ramesh,
HRP1000 is the table having all the objects maintaines in SAP, objectrs like Position, Person, PA, PSA, Cost Center, Business Event. etc.
where as the table HRP1001 give the relation between the objects,
for eg: A person occupying which position, or belongs to what Org. unit.
of assigned to which cot cener.
i hope it serves ur purpose.
Regards,
Aman

HRP1000 and HRP1001 log changes

hi I am not able to see HRP1000 and HRP1001 log changes in CDHDR and CDPOS. The HR_IT1000 and HR_IT1001 are active in the system.

Hi,
the change documents can be activated after implementation of note 979104 and setting the related switch as described.
Best regards,
Malgorzata Herzog

Problem in join with hrp1000 and hrp1001???

Hi all, I am pasting code sAmpLE, i am having problem with join, without join the query is working. Help out.
IF per_no IS NOT INITIAL.
    SELECT objid sobid objid INTO TABLE lt_st_p1
      FROM hrp1001 WHERE otype EQ 'P' AND objid IN per_no
      AND plvar EQ lv_plan_version AND rsign EQ 'B' AND relat EQ '008' AND istat EQ '1'
       AND subty EQ 'B008' AND sclas EQ 'S'.
   LOOP AT lt_st_p1 INTO ls_st_p1_tem.
     ls_st_p1_tem-sobid1 = ls_st_p1_tem-pernr.
     MODIFY lt_st_p1 FROM ls_st_p1_tem TRANSPORTING sobid1.
   ENDLOOP.
    check lt_st_p1 is not INITIAL.
    SELECT h1objid h1sobid h0~stext INTO TABLE lt_st_p1_temp
      FROM hrp1001 AS h1 JOIN hrp1000 as h0 on ( h1objid eq h0objid and h1rsign eq h0otype )
      FOR ALL ENTRIES IN lt_st_p1
      WHERE h1otype EQ 'O' AND h1sobid = lt_st_p1-sobid
      AND h1plvar EQ lv_plan_version AND h1relat EQ '003'
      AND h1rsign EQ 'B' AND h1istat EQ '1' AND h1subty EQ 'B003' AND h1sclas EQ 'S'
I want to get the stext of the braNCH. THE lt_st_p1 is having the emp id and position. and i want to get branch , position and stext( of branch) in lt_st_p1_temp by the help of join. I am implementing this qauery, but is getting subrc 4, what is the problem in this , please rectifuy if any problem found ?

You may want to change:
check lt_st_p1 is not INITIAL.
to
check lt_st_p1[] is not INITIAL.
This depends on whether or not the internal table was defined with a header line.
Rob
Edited by: Rob Burbank on Jan 2, 2012 2:45 PM

Inconsitency between transaction PPPM and HRP1001 table

Hi,
I have a scenario where I distribute the data from my HR system to the xRPM system.
Problem as below.
I have 12 qualifications for a partner in the PPM transaction which are in the HR system. Now I check the table HRP1001 and it also shows 12 qualification in the table for this specific Business partner.
Now I delete all the qualification in the transaction PPM for this business partner. Now when I check the table HRP1001 for this business partner I am seeing 6 entries.
How is this possible to have the link between the BP and the Q after I have deleted them in the transaction PPPM. This is looking strange and I am not able to understand the way the system is behaving.
IS this as per the standard or am I missing out something here.
Need all your expert sugesstion here.
Regards,
Vijay V

Hi,
I have found the issue. The issue was with the key date with which I was viewing in the PPPM transaction. Once I set it to 1.1.1980 then it was deleting perfectly.
Closing this thread.
Regards,
Vijay V

Query infotype and RT table

Hi experts!!
Is possible to do queries and get information from Infotypes and RT table in the same time.
We would like to do a query with information from infotypes an RT table, we don't want do a query for the data from infotypes and another one to get data from de rt table (PC00_M99_CWTR).
How is possible to do this kind os queries?
Kind regards,
Julian

To check on how to use cl_hr_pay_access class, I would first try google and then the where used list button while reviewing said class in se24 tcode - example of use: RPCGR1K0
DATA: pay_access TYPE REF TO cl_hr_pay_access. "access of payroll result
CREATE OBJECT pay_access.
CALL METHOD pay_access->read_cluster_dir
 EXPORTING
 pernr = pernr
 IMPORTING
 cluster_dir = rgdir[]
 EXCEPTIONS
 OTHERS = 4.
CALL METHOD pay_access->read_pa_result
 EXPORTING
 pernr = p_pernr
 period = p_rgdir
 molga = '07'
 IMPORTING
 payroll_result = pay_result
 EXCEPTIONS
 no_authorization = 1
 read_error = 2
 country_version_not_available = 3
 OTHERS = 4.
 CALL METHOD pay_access->read_pe_result
 EXPORTING
 pernr = p_pernr
 period = p_rgdir
 molga = '07'
 IMPORTING
 payroll_result = pay_result_person
 EXCEPTIONS
 no_authorization = 1
 read_error = 2
 country_version_not_available = 3
 no_person_data = 4
 OTHERS = 5.
result will be held in pay_result_person->inter deep structure
RT is inter-rt
BT is inter-bt
Or you can use function PYXX_READ_PAYROLL_RESULT - again - google or where used in se37 tcode. standard use in RPCDCI00
* FORM GET_PAYRESULT *
* read the internationl part of the payroll result from sequential *
* number I_SEQNR. *
form get_payresult using i_seqnr like pc261-seqnr
 changing cs_payxx_result type pay99_international.
field-symbols: <payxx_result> type pay99_international.
call function 'PYXX_READ_PAYROLL_RESULT'
 exporting
 employeenumber = pernr-pernr
 sequencenumber = i_seqnr
 changing
 payroll_result = <pay_result>
 exceptions
 illegal_isocode_or_clusterid = 1
 error_generating_import = 2
 import_mismatch_error = 3
 subpool_dir_full = 4
 no_read_authority = 5
 no_record_found = 6
 versions_do_not_match = 7
 error_reading_archive = 8
 error_reading_relid = 9
 others = 10.
if sy-subrc <> 0.
 case sy-subrc.
 when 5.
 perform error using c_er_payauth i_seqnr space
 space space c_yes.
 when others.
 perform error using c_er_readpay i_seqnr sy-subrc
 space space c_yes.
 endcase.
endif.
assign component 'INTER' of structure <pay_result>
 to <payxx_result>.
cs_payxx_result = <payxx_result>.
endform. " GET_PAYRESULT
Good luck.

Which type of information can be hold by pool and cluster tables

hi experts tell me exactly which type of information hold by pooled and cluster tables
thanks in advance

Hi
I hope, you know that Rewarding with Points for the Useful answers is the SDN policy
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences,
program parameters or temporary data). Several pooled tables can be
combined to form a table pool. The table pool corresponds to a physical
table on the database in which all the records of the allocated pooled
tables are stored.
Cluster table
Cluster tables contain continuous text, for example documentation.
Several cluster tables can be combined to form a table cluster. Several
logical lines of different tables are combined to form a physical record
in this table category. This permits object-by-object storage or
object-by-object access. In order to combine tables in clusters, at
least part of the keys must agree. Several cluster tables are stored in
one corresponding table on the database.
Pool Tables (match codes, look up tables)
Should be accessed via primary key or
Should be buffered (SE11->Display Table->technical settings)
No secondary indexes
Select * is Ok because all columns retrieved anyway
Cluster Tables (BSEG,BSEC)
Should be accessed via primary key - very fast retrieval otherwise very slow
No secondary indexes
Select * is Ok because all columns retrieved anyway. Performing an operation on multiple rows is more efficient than single row operations. Therefore you still want to select into an internal table. If many rows are being selected into the internal table, you might still like to retrieve specific columns to cut down on the memory required.
Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported
Can not be buffered
Reward points for useful Answers
Regards
Anji

Apc asset, information about payments and debts to a vendor

Dear sap colleages
I need to know these information about an ASSET:
Purchased orders,
Items from purchase orders,
which of these items i've received, i've paid (also date), i've not paid ( amount of debt related to asset)
payments in advanced (date),
wich of these payments have been cleared (clearing date) and wich not,
who is the vendor,
other expenses (such as delivery)
the amount of taxes,
invoices related and NOT RELATED TO purchase order
payments without invoice
Which transactions do i need to follow?
or
Which document flow?
or
Which tables? Wich keys?
or
Is there a standard report that can give me such information?
Any documentation and/or code will be appreciated.
I need to program a report to integrate all these information.
Thanks and Kind Regards

Hi:
Regarding payments to vendors,refer to FBL1N - Display/Change Line Items .
Select the company code and then open items radio button and today date.It will show what are payments still to be paid to the vendor.If you select cleared items, it will show the payments paid to the vendor.If you select all items radio button, it will show all paid and unpaid payments to the vendor.
Check this report whether it fills your requirment.
When the user posts the business transaction, he has to input all the details, otherwise some of the information may be missing.
Please let me know if you need more information.
Assign points if useful.
Regards
Sridhar M

Relation b/w PRPS and RPSCO tables

Hi PS Experts,
What is the Relation b/w PRPS and RPSCO tables
PRPS : WBS (Work Breakdown Structure) Element Master Data
RPSCO : Project info database: Costs, revenues, finances
Thanks in Advance,
Regards,
sudharsan.

Hello Sasikanth Thank u for ur information,
and i need some more information, am working on abap, now i got a requirement in PS,
i want 2 calculate the values like Planned Revenue, Planned Cost, Actuall Rev, Actuall Cost, Actuall Billing, Revenue Taken, Cost Taken, BNS and SNB.
based on i/p parameters: Company Code, Fiscal year and month.
pls let me know how to calculate the above values, its very urgent for me.
Thanks in advance,
sudharsan.

Drop and recreate table in stored procedure

Hi all
When creating tables using Transact-SQL scripts, I have always preferred to drop the table if it exists and then create it explicitly using CREATE TABLE. For two reasons:
1) It does not matter if it is the first time the SP is run ie. if I create the table manually in the first instance and just use TRUNCATE TABLE it could fail if the table is deleted
2) I have control over the data types of the table fields
Just recently though I discovered the error that can occur when dropping and creating a table in the same batch (see link below)
Microsoft Website
This causes me a problem when dropping and creating tables in stored procedures, as I understand that a stored procedure is in itself a single batch?
Can I avoid this error in a stored procedure whilst continuing to drop and create tables? Or should I be taking a different approach?
Coding best practice advice would be greatly appreciated.
Thank you

Thanks Ronen
Please see my second post immediately before your reply.
Given that I need to store the data output in a physical table for use in QlikView, would you suggest truncating the table each time the SP runs? And then having a script that handles both dropping and creating the physical table, and also creating
the SP?
>> QlikView
QlikView is an Israeli company, right?
In any case I am not familiar with QlikView's application, therefore I can only give you general information, based on assumptions regarding the application, and facts regarding the SQL Server.
>> for use in QlikView
I assume that external application use specific database structure (table
structure) and it is change only in rare situations (for example CMS interface might change the tables if and when a module s update/install). In this case there is no need to drop the table and recreate it and TRUNCATE is the solution.
>> would you suggest truncating the table each time the SP runs
I am sorry but i cant recommend on TRUNCATE a table each time you execute SP, without know the exact reason for this logic. It sound to me, at this point of time (with the information that we have), that this
is very bad logic (application architecture). As I wrote above, basing your application on TRUNCATING the table each time mean that you have problems with multi users. Thins about 2 people that try to execute the same SP at almost the same time. Think about
locking in the SQL Server and bad data (one truncate while the other already inserted the new data and get no rows, if there is no locking).
But TRUNCATE is much better in this case probably then DROP and DELETE, since it is faster, and locking will be shorter (hopefully the application use the correct locking). There are other reasons why TRUNCATE is better, and other people already mentioned
most of them, but time in this scenario might be critical.
>> having a script that handles both dropping and creating the physical table, and also creating the SP?
I do not undestand what is this second step. we said that you truncate the table, so why do you need to
dropping and creating the physical table and who
creating the SP?
Are you meaning that the application create the tables and SP?
There are lot of application that during installation create the database structure. is this what you mean?
Ronen Ariely
[Personal Site] [Blog] [Facebook]

BAPI FOR Deleting a Schedule Line Item from EKES and EKET tables

Dear All,
I would like to for deleting one of the line item from EKES (Po Confirmation ) and the respective line item from the EKET(PO Schedule Line Item Table).
Assume that am allowing the user to select the lineitem from zprogram screen and collecting the PO and Its LIne Item details in an internal table.
Can i Use
BAPI_PO_Change , if so , can anybody tell me the steps to follow to use this bapi for deleting the PO lineItems, since i m going to try BAPI for First time.
pls help me out
Message was edited by: Raja K.P

Hi raja ,
loop at iekko1.
 w_index = sy-tabix.
 item-po_item = itemx-po_item = iekko1-ebelp.
 item-quantity = iekko1-mng01.
 itemx-quantity = iekko1-mng01.
 if iekko1-wamng = iekko1-wemng.
 itemx-no_more_gr = item-no_more_gr = 'X'.
 else.
 itemx-no_more_gr = item-no_more_gr = ''.
 endif.
 append item.
 append itemx.
 clear return[].
 call function 'BAPI_PO_CHANGE'
 exporting
 purchaseorder = iekko1-ebeln
 tables
 return = return
 poitem = item
 poitemx = itemx.
 if return[] is initial.
 commit work and wait.
 call function 'DEQUEUE_ALL'.
search for deletion fields which u have to mark 'X'.
before calling this BAPi u have to lock the PO by using ENQUEUE.

FU BAPI_PO_CHANGE
Text
Change purchase order
Functionality
Function module BAPI_PO_CHANGE enables you to change purchase orders. The Change method uses the technology behind the online transaction ME22N.
Alternatively, the IDoc type PORDCH1 is available. The data from this IDoc populates the interface parameters of the function module BAPI_PO_CHANGE.
Functionality in Detail
Authorization
When you create (activity 02) an Enjoy purchase order, the following authorization objects are checked:
M_BEST_BSA (document type in PO)
M_BEST_EKG (purchasing group in PO)
M_BEST_EKO (purchasing organization in PO)
M_BEST_WRK (plant in PO)
Controlling adoption of field values via X bar
For most tables, you can use your own parameters in the associated X bar (e.g. PoItemX) to determine whether fields are to be set initial, values inserted via the interface, or default values adopted from Customizing or master records, etc. (for example, it is not mandatory to adopt the material group from an underlying requisition - you can change it with the BAPI).
Transfer
Purchase order number
The PurchaseOrder field uniquely identifies a purchase order. This field must be populated in order to carry out the Change method.
Header data
The header data of the Enjoy purchase order is transferred in table PoHeader.
Item data
The item data of the Enjoy purchase order is stored in the tables PoItem (general item data). Changes regarding quantity and delivery date are to be made in the table PoSchedule.
Use the table PoAccount to change the account assignment information.
Services and limits
Changes to existing items cannot be carried out with the Change method. It is only possible to create new items.
Conditions
Conditions are transferred in the table PoCond; header conditions in the table PoCondHeader. A new price determination process can be initiated via the parameter CALCTYPE in the table PoItem.
Vendor and delivery address
The vendor address in the table PoAddrVendor and the delivery address in the table PoAddrDelivery can only be replaced by another address number that already exists in the system (table ADRC). Changes to address details can only be made using the method BAPI_ADDRESSORG_CHANGE.
Partner roles
You can change all partners except the partner role "vendor" via the table PoPartner.
Export/import data
Export/import data can be specified per item in the table PoExpImpItem. Foreign trade data can only be transferred as default data for new items. Changes to the export/import data of existing items are not possible.
Texts
Header and item texts can be transferred in the tables PoTextHeader and PoTextItem. Texts for services are imported in the table PoServicesText. Texts can only be replaced completely.
Version Management
You can make use of the Version Management facility via the table AllVersions.
Return
If the PO was changed successfully, the header and item tables are populated with the information from the PO.
Return messages
Messages are returned in the parameter Return. This also contains information as to whether interface data has been wrongly or probably wrongly (heuristical interface check) populated. If a PO has been successfully created, the PO number is also placed in the return table with the appropriate message.
Restrictions
With this function module, it is not possible to:
Create subcontracting components (you can only use existing ones)
Create configurations (you can only use existing ones)
Change message records (table NAST) and additional message data (this data can only be determined via the message determination facility (Customizing))
Attach documents to the purchase order
Change foreign trade data
Change service data
Change or reexplode BOMs
A firewall prevents the manipulation of data that is not changeable in Purchasing according to the business logic of the purchase order (e.g. PO number, vendor, etc.).
PO items with an invoicing plan cannot be created or changed using the BAPIs
In this connection, please refer to current information in Note 197958.
To change addresses with numbers from Business Address Services (cantral address management), please use the function module BAPI_ADDRESSORG_CHANGE.
To change variant configurations, please use the function module BAPI_UI_CHANGE. More information is available in the BAPI Explorer under the Logistics General node.
In the case of changes that are to be made via the BAPI_PO_CHANGE, a firewall first checks whether the relevant fields are changeable. This approach follows that of the online transaction. Here it is not possible to change the vendor or the document type, for example.
Example
Example of changes made to a purchase order with:
1. Change in header data
2. Change in item
3. Change in delivery schedule
4. Change in account assignment
5. Change in conditions
6. Change in partners
Parameter: PURCHASEORDER 4500049596
Parameter: POHEADER
PMNTTRMS = 0002
PUR_GROUP = 002
Parameter: POHEADERX
PMNTTRMS = X
PUR_GROUP = X
Parameter: POITEM
PO_ITEM = 00001
CONF_CTRL = 0001
Parameter: POITEMX
PO_ITEM = 00001
PO_ITEMX = X
CONF_CTRL = X
Parameter: POSCHEDULE
PO_ITEM = 00001
SCHED_LINE = 0001
QUANTITY = 10.000
PO_ITEM = 00001
SCHED_LINE = 0003
DELETE_IND = X
Parameter: POSCHEDULEX
PO_ITEM = 00001
SCHED_LINE = 0001
PO_ITEMX = X
SCHED_LINEX = X
QUANTITY = X
PO_ITEM = 00001
SCHED_LINE = 0003
PO_ITEMX = X
SCHED_LINEX = X
DELETE_IND = X
Parameter: POACCOUNT
PO_ITEM = 00001
SERIAL_NO = 01
GL_ACCOUNT = 0000400020
Parameter: POACCOUNTX
PO_ITEM = 00001
SERIAL_NO = 01
PO_ITEMX = X
SERIAL_NOX = X
GL_ACCOUNT = X
Parameter: POCOND
ITM_NUMBER = 000001
COND_TYPE = RA02
COND_VALUE = 2.110000000
CURRENCY = %
CHANGE_ID = U
Parameter: POCONDX
ITM_NUMBER = 000001
COND_ST_NO = 001
ITM_NUMBERX = X
COND_ST_NOX = X
COND_TYPE = X
COND_VALUE = X
CURRENCY = X
CHANGE_ID = X
Parameter: POPARTNER
PARTNERDESC = GS
LANGU = EN
BUSPARTNO = 0000001000
Help in the Case of Problems
1. Note 197958 lists answers to frequently asked questions (FAQs). (Note 499626 contains answers to FAQs relating to External Services Management.)
2. If you have detected an error in the function of a BAPI, kindly create a reproducible example in the test data directory in the Function Builder (transaction code SE37). Note 375886 tells you how to do this.
3. If the problem persists, please create a Customer Problem Message for the componente MM-PUR-PO-BAPI, and document the reproducible example where necessary.
Customer Enhancements
The following user exits (function modules) are available for the BAPI BAPI_PO_CREATE1:
EXIT_SAPL2012_001 (at start of BAPI)
EXIT_SAPL2012_003 (at end of BAPI)
The following user exits (function modules) are available for the BAPI BAPI BAPI_PO_CHANGE:
EXIT_SAPL2012_002 (at start of BAPI)
EXIT_SAPL2012_004 (at end of BAPI)
These exits belong to the enhancement SAPL2012 (see also transaction codes SMOD and CMOD).
There is also the option of populating customer-specific fields for header, item, or account assignment data via the parameter EXTENSIONIN.
Further Information
1. Note 197958 contains up-to-date information on the purchase order BAPIs.
2. If you test the BAPIs BAPI_PO_CREATE1 or BAPI_PO_CHANGE in the Function Builder (transaction code SE37), no database updates will be carried out. If you need this function, please take a look at Note 420646.
3. The BAPI BAPI_PO_GETDETAIL serves to read the details of a purchase order. The BAPI cannot read all details (e.g. conditions). However, you can use the BAPI BAPI_PO_CHANGE for this purpose if only the document number is populated and the initiator has change authorizations for purchase orders.
4. Frequently used BAPIs for purchase orders are BAPI_PO_CREATE, BAPI_PO_CREATE1, BAPI_PO_CHANGE, BAPI_PO_GETDETAIL, BAPI_PO_GETITEMS, BAPI_PO_GETITEMSREL, and BAPI_PO_GETRELINFO.
5. For more information on purchase orders, refer to the SAP library (under MM Purchasing -> Purchase Orders) or the Help for the Enjoy Purchase Order, or choose the path Tools -> ABAP Workbench -> Overview -> BAPI Explorer from the SAP menu.
Parameters
PURCHASEORDER
POHEADER
POHEADERX
POADDRVENDOR
TESTRUN
MEMORY_UNCOMPLETE
MEMORY_COMPLETE
POEXPIMPHEADER
POEXPIMPHEADERX
VERSIONS
NO_MESSAGING
NO_MESSAGE_REQ
NO_AUTHORITY
NO_PRICE_FROM_PO
EXPHEADER
EXPPOEXPIMPHEADER
RETURN
POITEM
POITEMX
POADDRDELIVERY
POSCHEDULE
POSCHEDULEX
POACCOUNT
POACCOUNTPROFITSEGMENT
POACCOUNTX
POCONDHEADER
POCONDHEADERX
POCOND
POCONDX
POLIMITS
POCONTRACTLIMITS
POSERVICES
POSRVACCESSVALUES
POSERVICESTEXT
EXTENSIONIN
EXTENSIONOUT
POEXPIMPITEM
POEXPIMPITEMX
POTEXTHEADER
POTEXTITEM
ALLVERSIONS
POPARTNER
Exceptions
Function Group
2012

regards
prabhu
Message was edited by: Prabhu Peram

Poor performance while join of 2 comprehensive large views and small table

Hi,
The following SQL statement has been identified to perform poorly. It currently takes up to 6 seconds to execute, but it's supposed to take ~30-40ms at most.
This is the statement(all bind variables change to numbers):
SELECT v__96.connector_objectid, v__96.connector_classid, v__96.from_objectid,
 v__96.to_objectid, v__96.from_classid, v__96.to_classid,
 v__96.from_firstunit, v__96.to_firstunit, v__96.number_of_units,
 tmp_trace.first_unit, tmp_trace.last_unit, v__96.inv_status_number,
 tmp_trace.first_unit, tmp_trace.last_unit, v__96.answers,
 v__96.priority, v__97.first_unit, v__97.n_units,
 v__97.mid_span_distance
FROM ne.tmp_trace,
 (SELECT b.objectid, b.answers, b.connector_classid,
 b.connector_objectid, b.from_classid, b.from_objectid,
 b.to_classid, b.to_objectid, b.from_firstunit, b.to_firstunit,
 b.number_of_units, b.inv_status_number, b.splice_closure_name,
 b.work_order_name, b.work_order_item_number,
 b.inventory_status_code, b.priority
 FROM ne.connection b
 WHERE b.objectid NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id
 FROM ne.d96
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id = 0)
 UNION ALL
 SELECT a.objectid, a.answers, a.connector_classid,
 a.connector_objectid, a.from_classid, a.from_objectid,
 a.to_classid, a.to_objectid, a.from_firstunit, a.to_firstunit,
 a.number_of_units, a.inv_status_number, a.splice_closure_name,
 a.work_order_name, a.work_order_item_number,
 a.inventory_status_code, a.priority
 FROM ne.a96 a, sde.state_lineages sl
 WHERE (a.objectid, a.sde_state_id) NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id, sde_state_id
 FROM ne.d96
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id > 0)
 AND a.sde_state_id = sl.lineage_id
 AND sl.lineage_name = 2
 AND sl.lineage_id <= 115) v__96,
 (SELECT b.objectid, b.tray_number, b.db_loss, b.first_unit, b.n_units,
 b.connection_objectid, b.connector_type_name,
 b.dedicated_status, b.mid_span_distance
 FROM ne.connection_attributes b
 WHERE b.objectid NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id
 FROM ne.d97
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id = 0)
 UNION ALL
 SELECT a.objectid, a.tray_number, a.db_loss, a.first_unit, a.n_units,
 a.connection_objectid, a.connector_type_name,
 a.dedicated_status, a.mid_span_distance
 FROM ne.a97 a, sde.state_lineages sl
 WHERE (a.objectid, a.sde_state_id) NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id, sde_state_id
 FROM ne.d97
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id > 0)
 AND a.sde_state_id = sl.lineage_id
 AND sl.lineage_name = 2
 AND sl.lineage_id <= 115) v__97
WHERE ( ( ( ( ( ( ne.tmp_trace.equipment_object_id =
 v__96.to_objectid
 AND v__96.to_classid = 9
 OR ( ne.tmp_trace.transmedia_object_id =
 v__96.to_objectid
 AND v__96.to_classid = 5
 AND ( (v__96.to_firstunit
 BETWEEN ne.tmp_trace.first_unit
 AND ne.tmp_trace.last_unit
 OR (ne.tmp_trace.first_unit
 BETWEEN v__96.to_firstunit
 AND v__96.to_firstunit
 + v__96.number_of_units
 - 1
 AND v__96.answers = 0
 AND v__96.objectid = v__97.connection_objectid
 AND (ne.tmp_trace.session_id = -1234)
 );It should return many values from 2 comprehensive views (v__96, v__97) and business table (tmp_trace). 2 comprehensive views ~1,000,000 recs each, business table ~ 10 recs.
The version of the database is 11.1.0.6.
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.6
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string FORCE
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL> select sname, pname, pval1, pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-15-2009 10:27
SYSSTATS_INFO DSTOP 07-15-2009 10:27
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1812.32129
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SNAME PNAME PVAL1 PVAL2
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.Here is the output of EXPLAIN PLAN:
explain plan for -- statement above
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1005186751
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 282 | 268 (2)| 00:00:04 |
| 1 | NESTED LOOPS | | 1 | 282 | 268 (2)| 00:00:04 |
| 2 | MERGE JOIN CARTESIAN | | 1 | 119 | 260 (1)| 00:00:04 |
|* 3 | TABLE ACCESS FULL | TMP_TRACE | 1 | 65 | 2 (0)| 00:00:01 |
| 4 | BUFFER SORT | | 103K| 5467K| 258 (1)| 00:00:04 |
| 5 | VIEW | | 103K| 5467K| 258 (1)| 00:00:04 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 14 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID| A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 23 | VIEW | | 1 | 163 | 8 (13)| 00:00:01 |
| 24 | UNION ALL PUSHED PREDICATE | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 185 | 1 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID | CONNECTION | 1 | 181 | 0 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | R96_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
| 28 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 32 | HASH JOIN ANTI | | 1 | 97 | 7 (15)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 71 | 4 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | A96 | 1 | 64 | 4 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | A96_PK | 1 | | 3 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 37 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 38 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 39 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
 3 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
23 - filter(("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=9
 OR "TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=5) AND
 ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
 "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
 AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
26 - filter("B"."ANSWERS"=0)
27 - access("B"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
30 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
31 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
32 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("A"."ANSWERS"=0)
35 - access("A"."OBJECTID"="V__97"."CONNECTION_OBJECTID" AND "A"."SDE_STATE_ID"<=115)
36 - access("SL"."LINEAGE_NAME"=2 AND "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("SL"."LINEAGE_ID"<=115)
39 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND
 "SDE_DELETES_ROW_ID"="V__97"."CONNECTION_OBJECTID" AND "SDE_STATE_ID">0)
40 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
Note
 - dynamic sampling used for this statement
87 rows selected.Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> set autotrace traceonly arraysize 100
Elapsed: 00:00:01.64
Execution Plan
Plan hash value: 1198408274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 876K| 238M| 1301 (2)| 00:00:16 |
| 1 | CONCATENATION | | | | | |
|* 2 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 3 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 4 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 5 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 8 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 14 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 22 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 23 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 24 | UNION-ALL | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 26 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 27 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 31 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 32 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 34 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | | | | |
| 37 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 38 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 41 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 42 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 43 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 44 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 45 | UNION-ALL | | | | | |
| 46 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 47 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 48 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 50 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 52 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 53 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 54 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 55 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 57 | NESTED LOOPS | | | | | |
| 58 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 59 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 62 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 63 | UNION-ALL | | | | | |
| 64 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 65 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 66 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 70 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 71 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 72 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 73 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 75 | NESTED LOOPS | | | | | |
| 76 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 77 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 79 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
Predicate Information (identified by operation id):
 2 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
 3 - access("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID")
 filter("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
 "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
 AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1)
 4 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
 5 - filter("V__96"."TO_CLASSID"=5)
 8 - filter("B"."ANSWERS"=0)
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
22 - filter("A"."ANSWERS"=0)
29 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
30 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
31 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
35 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
38 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
39 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
41 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
42 - access("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID")
 filter((LNNVL("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID") OR
 LNNVL("V__96"."TO_CLASSID"=5)) AND ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
 "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
 AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
43 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
44 - filter("V__96"."TO_CLASSID"=9)
47 - filter("B"."ANSWERS"=0)
50 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
51 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
52 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
55 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
56 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
59 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
60 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
61 - filter("A"."ANSWERS"=0)
68 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
69 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
70 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
73 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
74 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
77 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
78 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
Note
 - dynamic sampling used for this statementThe TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: pro &

The TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: problem.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT V__96.CONNECTOR_OBJECTID, V__96.CONNECTOR_CLASSID, V__96.FROM_OBJECTID, V__96.TO_OBJECTID, V__96.FROM_CLASSID, V__96.TO_CLASSID,
V__96.FROM_FIRSTUNIT, V__96.TO_FIRSTUNIT, V__96.NUMBER_OF_UNITS, TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.INV_STATUS_NUMBER,
TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.ANSWERS, V__96.PRIORITY, V__97.FIRST_UNIT, V__97.N_UNITS, V__97.MID_SPAN_DISTANCE FROM
NE.TMP_TRACE,(SELECT
b.OBJECTID,b.ANSWERS,b.CONNECTOR_CLASSID,b.CONNECTOR_OBJECTID,b.FROM_CLASSID,b.FROM_OBJECTID,b.TO_CLASSID,b.TO_OBJECTID,b.FROM_FIRSTUNIT,b.TO_FIRSTUNIT,b.NUM
BER_OF_UNITS,b.INV_STATUS_NUMBER,b.SPLICE_CLOSURE_NAME,b.WORK_ORDER_NAME,b.WORK_ORDER_ITEM_NUMBER,b.INVENTORY_STATUS_CODE,b.PRIORITY FROM NE.connection b
WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D96 WHERE DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
l.lineage_name = :"SYS_B_00" AND l.lineage_id <= :"SYS_B_01") AND SDE_STATE_ID = :"SYS_B_02") UNION ALL SELECT
a.OBJECTID,a.ANSWERS,a.CONNECTOR_CLASSID,a.CONNECTOR_OBJECTID,a.FROM_CLASSID,a.FROM_OBJECTID,a.TO_CLASSID,a.TO_OBJECTID,a.FROM_FIRSTUNIT,a.TO_FIRSTUNIT,a.NUM
BER_OF_UNITS,a.INV_STATUS_NUMBER,a.SPLICE_CLOSURE_NAME,a.WORK_ORDER_NAME,a.WORK_ORDER_ITEM_NUMBER,a.INVENTORY_STATUS_CODE,a.PRIORITY FROM NE.A96
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D96 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_03" AND l.lineage_id <= :"SYS_B_04") AND SDE_STATE_ID > :"SYS_B_05") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_06" AND SL.lineage_id <= :"SYS_B_07") V__96,(SELECT
b.OBJECTID,b.TRAY_NUMBER,b.DB_LOSS,b.FIRST_UNIT,b.N_UNITS,b.CONNECTION_OBJECTID,b.CONNECTOR_TYPE_NAME,b.DEDICATED_STATUS,b.MID_SPAN_DISTANCE FROM
NE.connection_attributes b WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D97 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_08" AND l.lineage_id <= :"SYS_B_09") AND SDE_STATE_ID = :"SYS_B_10") UNION ALL SELECT
a.OBJECTID,a.TRAY_NUMBER,a.DB_LOSS,a.FIRST_UNIT,a.N_UNITS,a.CONNECTION_OBJECTID,a.CONNECTOR_TYPE_NAME,a.DEDICATED_STATUS,a.MID_SPAN_DISTANCE FROM NE.A97
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D97 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_11" AND l.lineage_id <= :"SYS_B_12") AND SDE_STATE_ID > :"SYS_B_13") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_14" AND SL.lineage_id <= :"SYS_B_15") V__97 WHERE ((((( (
 NE.tmp_trace.equipment_object_id = V__96.to_objectid
 AND
 V__96.to_classid = :"SYS_B_16"
 OR
 NE.tmp_trace.transmedia_object_id = V__96.to_objectid
 AND
 V__96.to_classid = :"SYS_B_17"
 )) AND (
 (V__96.to_firstunit
 BETWEEN NE.tmp_trace.first_unit AND NE.tmp_trace.last_unit)
 OR
 (NE.tmp_trace.first_unit BETWEEN V__96.to_firstunit
 AND V__96.to_firstunit + V__96.number_of_units - :"SYS_B_18")
 )) AND V__96.answers = :"SYS_B_19") AND V__96.objectid = V__97.connection_objectid) AND (NE.tmp_trace.session_id =
:"SYS_B_20"))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 5.98 5.99 0 22652 0 10
total 3 5.98 5.99 0 22652 0 10
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 45
Rows Row Source Operation
 10 NESTED LOOPS (cr=22652 pr=0 pw=0 time=654515 us cost=67 size=282 card=1)
 10 NESTED LOOPS (cr=22436 pr=0 pw=0 time=653673 us cost=61 size=235 card=1)
 10 TABLE ACCESS FULL TMP_TRACE (cr=5 pr=0 pw=0 time=7 us cost=2 size=65 card=1)
 10 VIEW (cr=22431 pr=0 pw=0 time=0 us cost=59 size=170 card=1)
1773000 UNION-ALL (cr=22431 pr=0 pw=0 time=93649 us)
 0 NESTED LOOPS ANTI (cr=30 pr=0 pw=0 time=0 us cost=3 size=185 card=1)
 0 TABLE ACCESS FULL CONNECTION (cr=30 pr=0 pw=0 time=0 us cost=2 size=181 card=1)
 0 VIEW PUSHED PREDICATE VW_NSO_3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
 0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
 0 INDEX UNIQUE SCAN D96_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35121)
1773000 HASH JOIN RIGHT ANTI (cr=22401 pr=0 pw=0 time=75084 us cost=56 size=46948 card=484)
 0 VIEW VW_NSO_4 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
 0 FILTER (cr=180 pr=0 pw=0 time=0 us)
 0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
 0 INDEX FAST FULL SCAN D96_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35121)
 0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
1773000 NESTED LOOPS (cr=22221 pr=0 pw=0 time=56155 us)
1773000 NESTED LOOPS (cr=3231 pr=0 pw=0 time=15078 us cost=53 size=34364 card=484)
 50 INDEX RANGE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=7 us cost=1 size=7 card=1)(object id 34021)
1773000 INDEX RANGE SCAN A96_STATEID_IX1 (cr=3221 pr=0 pw=0 time=6810 us cost=32 size=0 card=1774)(object id 35116)
1773000 TABLE ACCESS BY INDEX ROWID A96 (cr=18990 pr=0 pw=0 time=0 us cost=52 size=82560 card=1290)
 10 VIEW (cr=216 pr=0 pw=0 time=0 us cost=7 size=47 card=1)
 10 UNION ALL PUSHED PREDICATE (cr=216 pr=0 pw=0 time=0 us)
 0 NESTED LOOPS ANTI (cr=1 pr=0 pw=0 time=0 us cost=2 size=82 card=1)
 0 TABLE ACCESS BY INDEX ROWID CONNECTION_ATTRIBUTES (cr=1 pr=0 pw=0 time=0 us cost=1 size=78 card=1)
 0 INDEX RANGE SCAN GDB_59_CONNECTIO (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 34346)
 0 VIEW PUSHED PREDICATE VW_NSO_1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
 0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
 0 INDEX UNIQUE SCAN D97_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35127)
 10 HASH JOIN ANTI (cr=215 pr=0 pw=0 time=0 us cost=5 size=55 card=1)
 10 NESTED LOOPS (cr=35 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
 10 TABLE ACCESS BY INDEX ROWID A97 (cr=25 pr=0 pw=0 time=0 us cost=2 size=22 card=1)
 10 INDEX RANGE SCAN GDB_59_CONNECTIO_A (cr=15 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 35122)
 10 INDEX UNIQUE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
 0 VIEW VW_NSO_2 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
 0 FILTER (cr=180 pr=0 pw=0 time=0 us)
 0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
 0 INDEX FAST FULL SCAN D97_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35127)
 0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00After manually rewrite query in TOAD it produces nested loops on business table and than access v__96, v__97 produce desired quick performance.
I can use stored outlines but this is the last chance. I am playing with hints right now to produce desired plan with no result yet.
Does anybody know how to insist Oracle to merge internal views to bigger query block, so Oracle can choose better plan?
Or any guide what hints to use from ol$hints to get desired result via hints addition to original sql query (thanks God application don't cut hints just pass-through to Oracle)?
Thanks,
Sergiy

Reg: Fact table and Dimension table in Data Warehousing -

Hi Experts,
I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
Fact table contains data that can be aggregate.
Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
Dimension contains data that is use to generate groups and filters.
This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
Any help is much appreciated.
Pardon me if this's not the correct place for this question. My first question in the new forum.
Thanks and Regards,
Ranit Biswas

ranitB wrote:
But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

Information on HRP1000 and HRP1001 tables

Similar Messages

Maybe you are looking for