Query efficiency

I have a table I'd like to report on based on ten or so LOV values stored as check boxes. In the past I've used substr to join my filtered key stored in the LOV, separated with colons with the key sandwiched between colons on the table I am querying. As I now have ten LOV values, some LOVs have 40 or so values and am querying against a large data set, I was wondering what the consensus was on doing it this way.
Is there any other technique that may be more efficient I should consider?
Phil

Not keen on posting an example, rather just want generic advice on the following, previously approach has been the following which is not wrong but might be possible to improve upon. FBI are fine but the additional overhead on insert performance might rule them out (we have 20 columns to apply this to).
P123_CHECKBOX_01, based on a LOV, session state '1:2:3:4:43:443:342:432:432:3242:4324:4389:34324:34:66:44:92'
Report Region, SQL:
Select blah from table123 where instr(':'||:P123_CHECKBOX_01||':', ':'||id||':')!=0
I was wondering about use of a pipelined function combined with the WITH approach to move the checkbox item into a "table" and whether this could improve the performance?

Similar Messages

Indexing for Load efficiency or Query Efficiency

Hello,
I've just come to start querying our warehouse which is currently being developed. Unfortunately, although the tables and indexes were spec'd at the design for query performance, the ETL team loading the table have set up indexes to improve load efficiency.
Is there anyway of placing 2 sets of indexes on a table, one for the load process and one for querying? Or should the queries be done on materialised views?
Any help would be much appreciated.
Regards
James

Just to clarify, there may be a harm in having multiple sets of indexes since index maintenance may consume a significant fraction of the ETL time. If the goal is to optimize the load, you may want to drop and rebuild the indexes that exist for query performance (assuming that queries and loads run during separate windows). Depending on volumes and load characteristics, I could envision scenarios where you could drop the indexes used by consumers, build the indexes for ETL, run the ETL, drop the ETL indexes, and rebuild the consumer indexes, but that would be rather rare.
Materialized views can certainly come into play to satisfy warehouse queries, particular for aggregate data. It wouldn't make much sense to drop indexes on base tables and create them on materialized views that were exact copies of those base tables since that wouldn't save you any processing time. If your MV's have sigificantly fewer rows than the base tables, though, indexes on the aggregates may be significantly cheaper to maintain.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

How would you write this query efficiently?

I am having a problem doing a particular join in the most optimal fashion, and this kind of join I do often, so I'd like to learn the best way to do it so I can re-use the same logic every time and be comfortable that it is the most efficient means.
I am using Oracle 11g, and the situation goes like this -- well actually there is a variation of this particular situation, I'll explain the easier one first):
Table PARENT (
PARENT_ID NUMBER [PK],
(OTHER IRRELEVANT DATA COLUMNS)
Table CHILD (
CHILD_ID NUMBER [PK],
PARENT_ID NUMBER,
CHILD_VALUE VARCHAR2(50),
START_DATE DATE NULL(NO),
END_DATE DATE NULL(YES)
I want to query from PARENT, joining to CHILD when possible (e.g. an outer join) but I only want the MOST RECENT record. MOST RECENT means that it is the record with the latest START_DATE, which is a column that cannot be NULL.
I usually try a query where I make a inner SELECT in the FROM clauses, then do an outer join against it. But this seems ot be a terrible practice that slows the query down drastically, because looks like the DB analyzes that sub query for the entire DB before joining on my particular result set. Like the main query might filter it down very quickly to a small set of records, but that sub query still analyzes the entire table then joins to my subset. So something like this:
SELECT
p.(WHATEVER COLUMNS FROM PARENT),
x.CHILD_VALUE,
x.START_DATE,
x.END_DATE
FROM PARENT p,
(SELECT c1.PARENT_ID, c1.CHILD_VALUE, c1.START_DATE, c1.END_DATE
FROM CHILD c1
WHERE c1.START_DATE = (SELECT MAX(START_DATE) FROM CHILD)
) x
WHERE
p.(FILTERING ON PARENT)
AND x.PARENT_ID(+) = p.PARENT_ID
Then a variation of this is that the CHILD table has one other column:
CHILD_TYPE (NUMBER)
And I need to join on the CHILD getting the MOST RECENT record for each CHILD_TYPE... for this I do two inner queries usually, and again I know its not the right way to do it.

with most_recent_child as (
                           select *
                             from (
                                    select c.*,
                                            row_number() over(partition by parent_id order by start_date desc) rn
                                            from child c
                             where rn = 1
select *
from      parent p
        left join
            most_recent_child c
          on p.parent_id = c.parent_id
/SY.

Update multiple fields using select query efficiently – 9i

I need to populate a table called prop_charact used for synching data to a legacy system.
Prop_charact has fields that are found in a few other tables (no one field is found in more than one table outside of prop_charact). I want to pull the data from the corresponding fields in the source tables and put it into prop_charact. I only want to populate prop_charact with records that have been updated, but want to pull all fields for those records (whether or not that field has been updated). I am getting the list of updated records from a transaction history table.
After getting that list, I was not sure what to do with it.
I put what I want to do in terms of strictly SQL. I am thinking there are more efficient (less system resources) ways of doing this, but I am not sure what to pursue. I can use PL/SQL, but please keep in mind I am limited to using version 9i. Anyone have any hints about what I should look into using instead of just thes particular SQL statements?
insert into eval.prop_charact (parcelno, propertyid)
select distinct p.parcelno, p.propertyid
from eval.transaction_history tr,
admin.properties p
where tr.propertyid = p.propertyid
and trim(tr.tablename) in ('PROPERTIES', 'PROPERTYCHARACTERISTICS','EQID','NEWCHARACTERISTICS','DIMENSIONS', 'NON_RESIDENTIALS')
and trim(tr.fieldname) in ('BLDGCODE', 'CATCODE', 'UNFINISHED', 'TOPOGRAPHY', 'GARAGETYPE', 'GARAGESPACES', 'OPENSPACES',
'VIEW', 'GENERALCONSTRUCTION', 'YEARBUILT', 'ESTIMATEDYEAR', 'TOTALROOMS', 'TOTALBEDROOMS',
'BASEMENTTYPE', 'NUMBEROFFIREPLACES', 'HEAT', 'CENTRALAIR','CONDITION','SITE_TYPE','TOTALDWELLINGAREA',
'PLOTFRONT','PLOTDEPTH','PLOTSQFT','SHAPE','STORIES','FULLBATHROOMS','PARTBATHROOMS','MULTIPLE_BLDGS')
and tr.trans_date >= to_date('01-01-2010', 'MM/DD/YYYY')
and tr.trans_date < sysdate
order by p.parcelno;
update
select p.BLDGCODE pBLDGCODE, epc.BLDGCODE epcBLDGCODE, p.CATCODE pCATCODE,epc.CATCODE epcCATCODE,
p.UNFINISHED pUNFINISHED, epc.UNFINISHED epcUNFINISHED,
pc.TOPOGRAPHY pcTOPOGRAPHY, epc.TOPOGRAPHY epcTOPOGRAPHY,
pc.GARAGETYPE pcGARAGETYPE, epc.GARAGETYPE epcGARAGETYPE,
pc.GARAGESPACES pcGARAGESPACES, epc.GARAGESPACES epcGARAGESPACES,
pc.OPENSPACES pcOPENSPACES, epc.OPENSPACES epcOPENSPACES, pc.VIEW_ pcVIEW_, epc.VIEW_ epcVIEW_,
pc.GENERALCONSTRUCTION pcGENERALCONSTRUCTION,
epc.GENERALCONSTRUCTION epcGENERALCONSTRUCTION,
pc.YEARBUILT pcYEARBUILT, epc.YEARBUILT epcYEARBUILT,
pc.ESTIMATEDYEAR pcESTIMATEDYEAR, epc.ESTIMATEDYEAR epcESTIMATEDYEAR,
pc.TOTALROOMS pcTOTALROOMS, epc.TOTALROOMS epcTOTALROOMS,
pc.TOTALBEDROOMS pcTOTALBEDROOMS, epc.TOTALBEDROOMS epcTOTALBEDROOMS,
pc.BASEMENTTYPE pcBASEMENTTYPE, epc.BASEMENTTYPE epcBASEMENTTYPE,
pc.NUMBEROFFIREPLACES pcNUMBEROFFIREPLACES, epc.NUMBEROFFIREPLACES epcNUMBEROFFIREPLACES,
pc.HEAT pcHEAT, epc.HEAT epcHEAT, pc.CENTRALAIR pcCENTRALAIR, epc.CENTRALAIR epcCENTRALAIR,
e.CONDITION eCONDITION, epc.CONDITION epcCONDITION,
n.SITE_TYPE nSITE_TYPE, epc.SITE_TYPE epcSITE_TYPE,
d.TOTALDWELLINGAREA dTOTALDWELLINGAREA, epc.TOTALDWELLINGAREA epcTOTALDWELLINGAREA,
d.PLOTFRONT dPLOTFRONT, epc.PLOTFRONT epcPLOTFRONT,
d.PLOTDEPTH dPLOTDEPTH, epc.PLOTDEPTH epcPLOTDEPTH,
d.PLOTSQFT dPLOTSQFT, epc.PLOTSQFT epcPLOTSQFT,d.SHAPE dSHAPE, epc.SHAPE epcSHAPE,
pc.STORIES pcSTORIES, epc.STORIES epcSTORIES,
n.FULLBATHROOMS nFULLBATHROOMS,epc.FULLBATHROOMS epcFULLBATHROOMS,
n.PARTBATHROOMS nPARTBATHROOMS, epc.PARTBATHROOMS epcPARTBATHROOMS,
nr.MULTIPLE_BLDGS nrMULTIPLE_BLDGS, epc.MULTIPLE_BLDGS epcMULTIPLE_BLDGS
from eval.prop_charact epc, admin.properties p, admin.propertycharacteristics pc, admin.eqid e,
admin.dimensions d, eval.newcharacteristics n, EVAL.non_residentials nr
where epc.propertyid = p.propertyid and epc.propertyid = pc.propertyid and epc.propertyid = e.propertyid(+)
and epc.propertyid = d.propertyid(+) and epc.propertyid = n.propertyid(+) and epc.propertyid = nr.propertyid(+)
set epcBLDGCODE= pBLDGCODE, epcCATCODE= pCATCODE, epcUNFINISHED = pUNFINISHED,
epcTOPOGRAPHY = pcTOPOGRAPHY, epcGARAGETYPE = pcGARAGETYPE, epcGARAGESPACES = pcGARAGESPACES,
epcOPENSPACES = pcOPENSPACES, epcVIEW_ = pcVIEW_, epcGENERALCONSTRUCTION = pcGENERALCONSTRUCTION,
epcYEARBUILT = pcYEARBUILT, epcESTIMATEDYEAR = pcESTIMATEDYEAR, epcTOTALROOMS = pcTOTALROOMS,
epcTOTALBEDROOMS = pcTOTALBEDROOMS, epcBASEMENTTYPE = pcBASEMENTTYPE,
epcNUMBEROFFIREPLACES = pcNUMBEROFFIREPLACES, epcHEAT = pcHEAT, epcCENTRALAIR = pcCENTRALAIR,
epcCONDITION = eCONDITION, epcSITE_TYPE = nSITE_TYPE, epcTOTALDWELLINGAREA = dTOTALDWELLINGAREA,
epcPLOTFRONT = dPLOTFRONT, epcPLOTDEPTH = dPLOTDEPTH, epcPLOTSQFT = dPLOTSQFT,
epcSHAPE = dSHAPE, epcSTORIES = pcSTORIES, epcFULLBATHROOMS = nFULLBATHROOMS,
epcPARTBATHROOMS = nPARTBATHROOMS, epcMULTIPLE_BLDGS = nrMULTIPLE_BLDGS;

The following example may be of help.
SQL> create table mytable(col1 number(1),
2 col2 date);
Table created.
SQL> insert into mytable values(1,sysdate);
1 row created.
SQL> select * from mytable;
      COL1 COL2
         1 20-AUG-04
SQL> update mytable
2 set (col1,col2) = (select 2, sysdate-1 from dual);
1 row updated.
SQL> select * from mytable;
      COL1 COL2
         2 19-AUG-04

Sql query efficiency problem.

Hello,
I have a table - Users: | id | name | manager_id |
The manager_id references the User.id,
I need to find an employee by an id or name and this employee has to be a manager to someone else.
Creating a sub-select that checks if employee's id is present within manager_id column takes a bit of time, is there a way to, for example, inner join the table to it self leaving only the rows that are managers.

Thank you both for your quick answers.
@ Rene Argento
The self-join is something I am interested in, but I don't exactly know how to write it so that it returns the same result set as the sub-select query you wrote.
@ Frank Kulash
Thanks for the query, but is there a possibility to re-write Rene's query to a JOIN query which excludes all the employees who are not managers to someone.
Or maybe there is another way to create the needed query which would be faster than using sub-select for each user ?
Thanks in advance.
Edited by: 909522 on 2012.22.1 10:09
Edited by: 909522 on 2012.22.1 10:10

How to make query efficient

I have 14 million records (15 columns) in a table and I am using view to query it... It's taking a lot of time to pull the data, please advice how to improve the query...
Thanks

Check out these links:
{message:id=1812597}
{thread:id=863295}

How to make this query efficient

create table temp)au_sa_poi_geocoding2 as select idx, address_form, suburb_form
from temp_au_Sa_poi_geocoding a where idx not in (select idx from gc1_Sa_sub where status='m' ) and exists (select null from sh_poi_small cites c
where upper (trim(a.suburb_form))=c.city)
one table contain round 74214 records while the other has less than that.
the tables were not indexed, i created index using the following commands.
create index sa_idx on temp_au_sa_poi_geocoding(idx)
create index sa1_idx on gc1_sa_sub(idx)
anyhelp would be appreciated.
thanks

create index sa0_idx on temp_au_Sa_poi_geocoding(upper(trim(suburb_form)));
create index sa1_idx on gc1_sa_sub(status,idx); -- instead of only (idx)
create index sh_idx on sh_poi_small (city);
then try as follows
create table temp_au_sa_poi_geocoding2 as select idx,
address_form, suburb_form
from temp_au_Sa_poi_geocoding a where idx not in
(select /*+ index gc1 */ idx from gc1_Sa_sub gc1 where status='m' ) and
exists (select /*+ index_join c a */ null from sh_poi_small cites c
where upper (trim(a.suburb_form))=c.city)
however effects of indexes will vary by cardinality.

SQL Query efficiency

Can anyone tell me , is there any difference between count(*) and count(1)
I believe count(1) is faster than count(*), as it is taking count for 1st column.
Is there any other difference or my belief is not right.
Can anyone plz explain it with example....

1) There is no difference in performance for any vaguely recent version of Oracle.
2) If there ever is a difference, COUNT(*) would be the form that would be optimized. So if there ever is a difference COUNT(*) will be faster.
3) COUNT(1) does not count the first column. It counts the literal number 1 for every row. You'd get the same behavior if you did COUNT('BadgerBadgerBadger') or COUNT( date '2012-01-15' ).
4) If I see code that has a bunch of COUNT(1)'s, I generally assume that whoever wrote it is prone to believing random myths they've found on the internet rather than testing thing for themselves so I assume that the surrounding code is more likely to have bugs. Particularly if I'm doing a code review.
Justin

Oracle - Query taking too long (Materialized view)

Hi,
I am extracting billing informaiton and storing in 3 different tables... in order to show total billing (80 to 90 columns, 1 million rows per month), I've used a materialized view... I do not have indexes on 3 billing tables - do have 3 indexes on Materialized view...
at the moment it's taking too long to query the data (running a query via toad fails and shows "Out of Memory" error message; runing a query via APEX though is providing results but taking way too long)...
Please advice how to make the query efficient...

tparvaiz,
Is it possible when building your materialized view to summarize and consolidate the data?
Out of a million rows, what would your typical user do with that amount data if they could retrieve it readily? The answer to this question may indicate if and how to summarize the data within the materialized view.
Jeff
Edited by: jwellsnh on Mar 25, 2010 7:02 AM

Please Suggest, How to make this view efficient ?

Hi there,
Could you please suggest me,how to make the following VIEW (QUERY) efficient regarding performance point of view.
CREATE OR REPLACE VIEW XXX_TRX_TO_NUM_V
(ROW_NUM, ORIG_TRX_NUM, TRX_NUMBER, TRX_DATE, PURCHASE_ORDER,INTERFACE_HEADER_ATTRIBUTE6, INTERFACE_HEADER_ATTRIBUTE1, INTERFACE_HEADER_ATTRIBUTE5, BILL_TO_CONTACT_ID, REMIT_TO_ADDRESS_ID, BILL_TO_CUSTOMER_ID, BILL_TO_SITE_USE_ID, ORG_ID)
AS
Select rownum row_num,trx_number orig_trx_num,to_number(a.trx_number) trx_number,a.trx_date,a.purchase_order,a.interface_header_attribute1
,a.interface_header_attribute6,a.interface_header_attribute5,a.bill_to_contact_id
,a.remit_to_address_id,a.bill_to_customer_id,a.bill_to_site_use_id,a.org_id
from ra_customer_trx_all a
where a.trx_number is not null
and a.trx_number not in
(select trx_number
from
(select rownum,/*+ ALL_ROWS ,16 */ r.trx_number,ltrim(rtrim(translate(/*+ ALL_ROWS ,16 */ r.TRX_number,'0123456789',' '), ' ' ), ' ' ) tx
from ra_customer_trx_all r)
where tx is not null)
order by trx_number
Thanks in Advance !
Shahzad

I think you have the hints in the wrong place - as far as I was aware, the hint had to come straight after the SELECT/UPDATE/INSERT/DELETE key word - but I could be wrong as I've never really tried it elsewhere. Also, unless the optimiser mode for your database is set to FIRST_ROWS or RULE (god help you!:), ALL_ROWS is the default behaviour.
Basically what you are trying to say is bring me back all ra_customer_trx_all rows that have purely numeric trx_numbers right?
Why, if you need to be able to represent trx_number as a number, do you have non-numeric data in there???? That's a bit dodgy isn't it?
Anyway, what about:
CREATE TABLE dt_test_num (id varchar2(10))
insert
into
     dt_test_num
select
     chr(47 + rownum)
from
     all_tables
where
     rownum <= 20
select
     to_number(id),
     id
from
     dt_test_num
where
     translate(id,'0123456789',' ') IS NULL
update
     dt_test_num
set
     id=id||chr(67-rownum)
select
FROM
     dt_test_num
select
     to_number(id),
     id
from
     dt_test_num
where
     translate(id,'0123456789',' ') IS NULL
/Also, you are selecting rownum and aliasing it. Why? rownum will be assigned before the sort.
HTH
David
Message was edited by:
david_tyler
Hello
Slight correction to the where clause. Art first I thought you didn't need the trim on there, but that was just down to the number sequence in translate...
SQL> select nvl(translate('1A','1234567890',''),'NULL') from dual
2 /
NVL(
NULL
SQL> select nvl(translate('1A','1234567890',' '),'NULL') from dual
2 /
NV
A
SQL> select nvl(translate('1','1234567890',' '),'NULL') from dual
2 /
N
SQL> select nvl(translate('2','1234567890',' '),'NULL') from dual
2 /
NVL(
NULL
SQL> select nvl(translate('2','0123456789',' '),'NULL') from dual
2 /
NVL(
NULL
SQL> select nvl(translate('1','0123456789',' '),'NULL') from dual
2 /
NVL(
NULL
SQL> select nvl(translate('0','0123456789',' '),'NULL') from dual
2 /
N
SQL> select nvl(TRIM(translate('0','0123456789',' ')),'NULL') from dual
2 /
NVL(
NULL
SQL> select nvl(TRIM(translate('1','0123456789',' ')),'NULL') from dual
2 /
NVL(
NULLTranslate still confuses me :-(

Stuck on sql query to find parent records that have the same child records

Oracle 10gR2 Enterprise Edition.
Hi,
I'm trying to write some logic to look for records in a parent table, which have the exact same values in a child table.
This is part of a bigger query, but I'm stuck on this part for now, so I've mocked up some simplified tables below to capture the core of the
problem I'm stuck on.
Let say I've got a parent table Manager, a child table Employee and there's a many to many relationship between them.
The aptly named Join_Table handles the relationship between them. So one manager can manage many employees, one employee can be managed by
many managers.
I've a feeling this is stupidly easy, but I seem to be suffering from a bad bout of brain freeze today!
-- parent table
CREATE TABLE manager (
id      number primary key,
name      varchar2(100));
-- child table
CREATE TABLE employee (
id          number primary key,
name      varchar2(100));
-- link table
CREATE TABLE join_table (
manager_id          NUMBER,
employee_id      NUMBER,
CONSTRAINT join_table_pk PRIMARY KEY (manager_id, employee_id),
CONSTRAINT manager_fk FOREIGN KEY (manager_id) REFERENCES manager(id),
CONSTRAINT employee_fk FOREIGN KEY (employee_id) REFERENCES employee(id)
-- Insert some managers
INSERT INTO manager (id, name) VALUES (1, 'John');
INSERT INTO manager (id, name) VALUES (2, 'Bob');
INSERT INTO manager (id, name) VALUES (3, 'Mary');
INSERT INTO manager (id, name) VALUES (4, 'Sue');
INSERT INTO manager (id, name) VALUES (5, 'Alan');
INSERT INTO manager (id, name) VALUES (6, 'Mike');
-- Insert some employees
INSERT INTO employee (id, name) VALUES (101, 'Paul');
INSERT INTO employee (id, name) VALUES (102, 'Simon');
INSERT INTO employee (id, name) VALUES (103, 'Ken');
INSERT INTO employee (id, name) VALUES (104, 'Kevin');
INSERT INTO employee (id, name) VALUES (105, 'Jack');
INSERT INTO employee (id, name) VALUES (106, 'Jennifer');
INSERT INTO employee (id, name) VALUES (107, 'Tim');
-- Insert the links
-- John manages Paul, Simon, Ken
INSERT INTO join_table (manager_id, employee_id) VALUES (1, 101);
INSERT INTO join_table (manager_id, employee_id) VALUES (1, 102);
INSERT INTO join_table (manager_id, employee_id) VALUES (1, 103);
-- Bob manages Paul, Simon, Kevin, Jack
INSERT INTO join_table (manager_id, employee_id) VALUES (2, 101);
INSERT INTO join_table (manager_id, employee_id) VALUES (2, 102);
INSERT INTO join_table (manager_id, employee_id) VALUES (2, 104);
INSERT INTO join_table (manager_id, employee_id) VALUES (2, 105);
-- Mary manages Jennifer, Tim
INSERT INTO join_table (manager_id, employee_id) VALUES (3, 106);
INSERT INTO join_table (manager_id, employee_id) VALUES (3, 107);
-- Sue manages Jennifer, Tim
INSERT INTO join_table (manager_id, employee_id) VALUES (4, 106);
INSERT INTO join_table (manager_id, employee_id) VALUES (4, 107);
-- Alan manages Paul, Simon, Ken, Jennifer, Tim
INSERT INTO join_table (manager_id, employee_id) VALUES (5, 101);
INSERT INTO join_table (manager_id, employee_id) VALUES (5, 102);
INSERT INTO join_table (manager_id, employee_id) VALUES (5, 103);
INSERT INTO join_table (manager_id, employee_id) VALUES (5, 106);
INSERT INTO join_table (manager_id, employee_id) VALUES (5, 107);
-- Mike manages Paul, Simon, Ken
INSERT INTO join_table (manager_id, employee_id) VALUES (6, 101);
INSERT INTO join_table (manager_id, employee_id) VALUES (6, 102);
INSERT INTO join_table (manager_id, employee_id) VALUES (6, 103);
-- For sanity
CREATE UNIQUE INDEX employee_name_uidx ON employee(name);So if I'm querying for manager John, I want to find the other managers who manage the exact same list of employees.
Answer should be Mike.
If I'm querying for manager Mary, answer should be Sue.
This query will give me the list of managers who manage some of the same employees as John, but not the exact same employees...
SELECT DISTINCT m.name AS manager
FROM manager m, join_table jt, employee e
WHERE m.id = jt.manager_id
AND jt.employee_id = e.id
AND e.id IN (
     SELECT e.id
     FROM manager m, join_table jt, employee e
     WHERE m.id = jt.manager_id
     AND jt.employee_id = e.id
     AND m.name = 'John')
ORDER BY 1;I thought about using set operations to find managers whose list of employees minus my employees is null and where my employees minus their list of employees is null. But surely there's a simpler more elegant way.
Any ideas?
Btw, I need to run this as a batch job against tables with >20 million rows so query efficiency is key.

What about...
WITH manager_list AS
SELECT name,
        LTRIM(MAX(SYS_CONNECT_BY_PATH(id,','))
        KEEP (DENSE_RANK LAST ORDER BY curr),',') AS employees
FROM   (SELECT m.name,
                e.id,
                ROW_NUMBER() OVER (PARTITION BY m.name ORDER BY e.id) AS curr,
                ROW_NUMBER() OVER (PARTITION BY m.name ORDER BY e.id) -1 AS prev
         FROM   manager m,
                join_table jt,
                employee e
WHERE m.id           = jt.manager_id
AND   jt.employee_id = e.id
AND   m.name = :P_MANAGER)
GROUP BY name
CONNECT BY prev = PRIOR curr AND name = PRIOR name
START WITH curr = 1
), all_list AS
SELECT name,
        LTRIM(MAX(SYS_CONNECT_BY_PATH(id,','))
        KEEP (DENSE_RANK LAST ORDER BY curr),',') AS employees
FROM   (SELECT m.name,
                e.id,
                ROW_NUMBER() OVER (PARTITION BY m.name ORDER BY e.id) AS curr,
                ROW_NUMBER() OVER (PARTITION BY m.name ORDER BY e.id) -1 AS prev
         FROM   manager m,
                join_table jt,
                employee e
WHERE m.id           = jt.manager_id
AND   jt.employee_id = e.id)
GROUP BY name
CONNECT BY prev = PRIOR curr AND name = PRIOR name
START WITH curr = 1
SELECT a.*
FROM   manager_list m,
       all_list a
WHERE m.employees = a.employeesWould be easier in 11g, but I don't have an installation here so this is based on 10g.
Cheers
Ben

Arraysize in glogin.sql need install suggestion.

hello.
My co is developing software to interface with Oracle. And we would really like to change the arraysize in the glogin.sql script to be about 6000 during the installation of our program. 6000 seems to make our software run faster anything larger shows marginal performance gains.
What are the pro's/con's of doing this? (Assuming we change it to ~6000 if arraysize has not been set or set to something smaller in glogin.sql.)
Would a prompt during our install step giving the admins the choice whether to change glogin.sql be reasonable? Or should we just print a suggestion during the install and in our manuals?
thanks.

It will increase sqlplus query efficiency, but will use more memory.
BTW- The maximum you can set arraysize is 5000. So you cannot set it to 6000. Also any values more than 100 will not add significant change over when it is set to 100

Confused about transaction, checkpoint, normal recovery.

After reading the documentation pdf, I start getting confused about it's description.
Rephrased from the paragraph on the transaction pdf:
"When database records are created, modified, or deleted, the modifications are represented in the BTree's leaf nodes. Beyond leaf node changes, database record modifications can also cause changes to other BTree nodes and structures"
"if your writes are transaction-protected, then every time a transaction is committed the leaf nodes(and only leaf nodes) modified by that transaction are written to JE logfiles on disk."
"Normal recovery, then is the process of recreating the entire BTree from the information available in the leaf nodes."
According to the above description, I have following concerns:
1. if I open a new environment and db, insert/modify/delete several million records, and without reopen the environment, then normal recovery is not run. That means, so far, the BTree is not complete? Will that affact the query efficiency? Or even worse, will that output incorrect results?
2. if my above thinking is correct, then every time I finish commiting transactions, I need to let the checkpoint to run in order to recreate the whole BTree. If my above thinking is not correct, then, that means that, I don't need to care about anything, just call transaction.commit(), or db.sync(), and let je to care about all the details.(I hope this is true :>)
michael.

http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/chkpoint.html
Checkpoints are normally performed by the checkpointer background thread, which is always running. Like all background threads, it is managed using the je.properties file. Currently, the only checkpointer property that you may want to manage is je.checkpointer.bytesInterval. This property identifies how much JE's log files can grow before a checkpoint is run. Its value is specified in bytes. Decreasing this value causes the checkpointer thread to run checkpoints more frequently. This will improve the time that it takes to run recovery, but it also increases the system resources (notably, I/O) required by JE.
"""

Facin problems in the 'Select... for all entries'

I am facing problem with this piece of code, please share ur thoughts on it. I have specified the inputs.
I am extracting the open items from the BSIS table for specified 3 account number.
Inputs to the prg:
field     No. of values
r_bukrs       1
r_hkont      2
r_blart     6
r_budat date range of 1 yr
r_bldat nil
v_tosdef contain 1 account number
" In each FI document posted, one line will have the 'v_tosdef' account number and one account from the 'r_hkont' values."
So will this query efficient.
SELECT bukrs
         hkont
         gjahr
         belnr
         budat
         bldat
         xblnr
         blart
         shkzg
         dmbtr
    FROM bsis
    INTO TABLE i_bsis
   WHERE bukrs IN r_bukrs                    " Company code
     AND hkont = v_tosdef                  " Account number
     AND budat IN r_budat                    " Posting date
     AND bldat IN r_bldat                    " Document date
     AND blart IN r_blart.                   " Document type
IF sy-subrc <> 0.
    MESSAGE i003.
    STOP.
ENDIF.
*@ Collecting the BELNR & GJAHR From the extracted records
li_bsis[] = i_bsis[].
SORT li_bsis BY bukrs gjahr belnr.
DELETE ADJACENT
DUPLICATES FROM li_bsis
        COMPARING bukrs gjahr belnr.
IF NOT li_bsis[] IS INITIAL.
    SELECT bukrs
           hkont
           gjahr
           belnr
           budat
           bldat
           xblnr
           blart
           shkzg
           dmbtr
      FROM bsis
APPENDING TABLE i_bsis
       FOR ALL ENTRIES IN li_bsis
     WHERE bukrs = li_bsis-bukrs               " Company code
       AND hkont IN r_hkont                    " Account number
       AND gjahr = li_bsis-gjahr              " Fiscal year
       AND belnr = li_bsis-belnr.             " Document num
BSIS table size around 86GB
primary index size aroung 33GB
and the index quality is 54%
the CBO shows less cost, but the actual runs takes too much disk read's / bgets..
Message was edited by:
        Sandy

Hi Sandy,
You indicated the size of the tables and index, what is the total number of records in your BSIS?
In your range tables, make sure they are postive formed.
Ex. r_bukrs : I EQ '1001', and not I NE '1000'.
You should consider coding your statements to check for input for bldat, code it with r_bldat and then another set without. It should be better performance to not have empty where conditions. So two routines, Selects with bldat and without.
Don't know if you have a Basis person to help analyze the performance, but you should look at the indexes in BSIS. You may have several indexes that contain some of your input fields but they may be spread across several indexes or there may be none. But say you have 5 indexes and it happens that just one of your parameters are in each of those indexes. Well, it can only use one index so while you think you are providing alot of parameters to help performance only one field is being used to access the index. What you need to do then is to find an index that has the most fields in your where clause and see if you can add to that, so long it's not an SAP index. If it's a z index consider adding additional fields to it, or consider creating a new index.
You can at least analyze the first Select in your DEV client. Run a trace, ST05 and then execute your code. It will show you which index it has used if any.
Also, look at the query values it is passing to the database. You said you get 6 M records on the first Select. This just seem like a lot of records, which is for just one account number (v_tosdef) along with the other parameters. I'm wondering if there's a problem with your input data. With 6M in your first table, your FOR ALL ENTRIES statement will be executed 1.2 million times. Tyically the database interface breaks down your Select-For All entries statement into 5 records per query. Again, run ST05 and you will see this.
In SE16, on your BSIS table, what is your count of records if you enter only the account number?
As a test, you might want to try entering all your parameters in SE16, run ST05 to trace the SQL to see what it is doing. You may have to kill your SE16 session or it may time out on you. You can stop your ST05 trace before your SE16 finishes and it will still show how SAP is going after the data and what index it used.
Let me know if this helped any.
Regards,
Filler

Rbo + history data index/no index table (cast ())

Hi guys,
I have couple of questions and maybe you can help me with some advices.
I have the misfortune to work with a 10g system that works on RBO.
1. and I have a lot of tables containing activity per id.
for example:
i have a table like: moved_history
lets say I have 100 k ids in system, and each month there are some ids moved (lets say 20 k rows. an Id can be moved multiple types.
so each month we will add extra 20k lines to this table. most of my queries are accessing this type of table with a predicate like entry_date between sysdate and sysdate - 2 months(or 1.5 months or 1 month).
I have a lot of tables like this: change_history, pay_history...etc
the question: it is Ok to create an index on entry_date. at the beginning this will not be useful, because it will select entire table using the index. but after a lot of months, this index will start to be usable?!.(I am using RBO and oracle it is using it no matter what)
2.(second question)
let’s say a have a table called dummy: ~100k records.
a part of it ~80k it is used multiple times in selects in a pl/sql process.
Initially I select with bulk collect and put those 80k(or in other case 10K or 1k) rows in nested tables.
after that I use in sql the nested table, instead of using the table (with table(cast (.....)).
Is this a correct approach?
What are the advantages and the disadvantages.
When using the nested table, I dont have any index on it(although I want to access all rows from that nested table and a full scan will be best), any statistics on it (in case, at some point I will move on CBO :) ), I use memory from PGA.
When using the table directly, oracle knows the date, I am using SGA, maybe the data from table is cached, so the access speed will be the same like the one with nested tables.
please correct me if I am wrong.
How can I test/benchmark this? what should I look at?
there is another option. the solution depends on how I will join, access, select from tables? and again, how can I test this in a good way.
thanks guys for your time

Well it is a bit hard to say. Someone has decided to go with a desupported optimizer
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/glossary.htm#sthref1601
>
Note:
This feature has been desupported.
>
And since the optimizer is responsible for the efficient execution of queries
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/sqlplsql.htm#sthref3528
>
All SQL statements use the optimizer, a part of Oracle that determines the most efficient means of accessing the specified data.
>
I can only deduce that they do not care about optimization or query efficiency and that unfortunately your hands are pretty much tied.

Query efficiency

Similar Messages

Maybe you are looking for