Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from smtp-aa.freelists.org (smtp-aa.freelists.org [23.23.80.81]) by malta2546.startdedicated.com (Postfix) with ESMTPS id C6E89100316EA5 for ; Thu, 26 Aug 2021 10:00:40 +0200 (CEST) Received: from turing.freelists.org (ip-10-0-0-164.ec2.internal [10.0.0.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp-aa.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 7D5DF4088D; Thu, 26 Aug 2021 08:00:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 6A2B54141E; Thu, 26 Aug 2021 08:00:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1629964835; bh=xxigGg7wm2a2sreimjENNtQ48yD0Gm7L/Mt5hcsc6Eg=; h=From:Sender:Sender:From; b=M3fQsfa3HRhJ8N+gK0015OoJeM6NKMCePqcomX2KdPUORUA5cJKZRdoeO7LMTAatn HCeZZyJ7GBR0yVWdTiQeOrEPUXBYjRwAIqiQHQvMD1CyEyxtXzFujPftniGUK6UXgR GEDnVPLj7zakmdBG+JsrwhD7moeTf4tJg+U0p6IY= X-Virus-Scanned: by FreeLists at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f7_rIa1GAGq; Thu, 26 Aug 2021 08:00:35 +0000 (UTC) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 52A4C4141F; Thu, 26 Aug 2021 08:00:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1629964833; bh=xxigGg7wm2a2sreimjENNtQ48yD0Gm7L/Mt5hcsc6Eg=; h=From:Sender:Sender:From; b=uClqXnJOBWlssVNo2DyPoTK1zYiJnX4WZVhiozL3ZFyLwS85a8rlyCkOvneuwWTAt 9HyF972ulqL6DFm5ziiirZkXytyaqnjetV8Bc5fvsYygedjxMNT4rSUiEE9/1DlZ1c 0ES8DGQcHD3uGYzB87nyE3W3IbferZVmITxotRuA= Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 26 Aug 2021 08:00:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id A97BE4141D for ; Thu, 26 Aug 2021 08:00:30 +0000 (UTC) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq7Dwa7m2qrH for ; Thu, 26 Aug 2021 08:00:30 +0000 (UTC) Received: from vimdzmsp-mail06.bluewin.ch (vimdzmsp-mail06.bluewin.ch [195.186.227.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Postfix) with ESMTPS id 42D604141C for ; Thu, 26 Aug 2021 08:00:30 +0000 (UTC) Received: from vimdzmsp-rich13.bluewin.ch ([195.186.122.145]) by vimdzmsp-mail06.bluewin.ch Swisscom AG with ESMTP id JAJImI0CmQQaKJAJIm8yLj; Thu, 26 Aug 2021 10:00:28 +0200 X-Bluewin-Spam-Analysis: v=2.4 cv=e8Bl9Yl/ c=1 sm=1 tr=0 ts=61274a1d a=aFbsJ4lmEbDsG/izSui5Pg==:117 a=MhDmnRu9jo8A:10 a=pGLkceISAAAA:8 a=D_VmOLqjAAAA:8 a=yPCof4ZbAAAA:8 a=Gj8dnitCAAAA:8 a=4qEjKKPKAAAA:8 a=DXzvs9fi5Nx7Z8F6U6AA:9 a=QEXdDO2ut3YA:10 a=4Ax8a3yNAAAA:8 a=RHYnxk84dB4WNNI69KEA:9 a=04Wl5mEj4-WJvlaw:21 a=d_xflH664_jzgZDB7q-c:22 a=VzkFtbJgvWz0uMt2ml5n:22 a=osbS6WoqMCpc9yocYKA6:22 a=u_dTPGf-M_uITx4KRomd:22 X-Bluewin-Spam-Score: 0.00 Received: from vimdzmsp-rich13.bluewin.ch (localhost.bluewin.ch [127.0.0.1]) by vimdzmsp-rich13.bluewin.ch (Postfix) with ESMTP id DBD49C02811; Thu, 26 Aug 2021 10:00:28 +0200 (CEST) Date: Thu, 26 Aug 2021 10:00:28 +0200 (CEST) From: "l.flatz@bluewin.ch" To: loknath.73@gmail.com Cc: oracle-l@freelists.org Message-ID: <261226719.8338.1629964828902@bluewin.ch> In-Reply-To: References: <079b01d799bd$b1e03ad0$15a0b070$@rsiz.com> <080c01d799d5$6b9b1b90$42d152b0$@rsiz.com> Subject: Re: Re: Fixing Performance issue with less selective columns MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8337_98656429.1629964828896" X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-UID: 153454 X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-FXIT-IP: IPv4[92.60.13.196] Epoch[1629964828898] X-CMAE-Envelope: MS4xfAHuA0oQL9EKWlQpMHtzueTdFPk2NZy777nWuEduJeK5ey/9F6jQ5sRMXDV0wvo6bjR91GETRG1AHxm8xr/xIE+8bb+DfY0cC1g8mTDb648tkWBObYZP A5Pa3PVnc1/VgNhTGXGddjm/ROZOYK14JjdviZHPpgDH5PTkDGQa33WoRY+60IRkiRrxRGYrBLran8ewtGQKAbgx/moOuAZ72X+BJPbLRWo8a7lXiZWfaSQe Jjja4J/ztq4tM+3ZDToBmQ== X-archive-position: 80816 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: l.flatz@bluewin.ch Precedence: normal Reply-To: l.flatz@bluewin.ch List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-Subscribe: List-Owner: List-post: List-Archive: X-list: oracle-l ------=_Part_8337_98656429.1629964828896 Content-Type: multipart/alternative; boundary="----=_Part_8336_1533411668.1629964828896" ------=_Part_8336_1533411668.1629964828896 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lok, I have to say that I lost track of which columns are how selective. So what I would do is the classical bitmap use, which are single column Bit= map which can be combined. Maybe n=C3=B3t the best way, but the most flexible. For all column where <> and not null is used, you should create a bitmap in= dex.=20 Thus we have one bitmap on NVL (I.MA_FLG, 'N') and one on NVL (I.D_UNMTCH= , 'N'). For not <> only bitmap would work. For is null and is not null we can also make a single column bitmap index. It all depends how often this table is inserted and how often the columns a= re updated. How much is too much is hard to decide and quite often the trut= h will show only at runtime. There is some risk on bimap in an OLTP, always= . For all the other columns you can create a combined B*Tree index. There is an other option like creating a big combined B*Tree with the colum= ns compare with =3D in the leading positions. You can use the other columns as filter . This is a low risk option E.g. something like this (in that sequence) TRIM(I.M_TXT) , PT_Code, DC_CO= DE, D_CUR_CODE, ED_AMT, PR_CTGRY, NVL (I.MA_FLG, 'N'), NVL (I.D_UNMTCH, 'N'= ), WOF_DATE, PE, PT_MCODE. How good this index is will show in the combined selectivity of the =3D com= pared columns. You can check this by :=20 select count(*) from ( select distinct TRIM(I.M_TXT) , PT_Code, DC_CODE, D_CUR_CODE, ED_AMT, PR_CT= GRY from PP_IN_TAB) ; I the selectivity is not good enough, you can increase the selektivity by u= sing a transformation like Mark described it.=20 Regards Lothar ----Urspr=C3=BCngliche Nachricht---- Von : loknath.73@gmail.com Datum : 25/08/2021 - 21:33 (MS) An : l.flatz@bluewin.ch Cc : oracle-l@freelists.org Betreff : Re: Fixing Performance issue with less selective columns Thank you Lothar. Actually this is an OLTP kind of database and I do see U= PDATE queries on these table columns. Need to see in detail about the frequ= ency of those and how concurrent they are. I am Not very familiar with the = usage of bitmap indexes , so trying to understand what exact column you are= suggesting for the bitmap index to help this query? =20 On Wed, Aug 25, 2021 at 11:45 PM Lothar Flatz < l.flatz@bluewin.ch> wrote: =20 =20 =20 =20 =20 This scenario cries for bitmap indexes. =20 Bitmap Indexes can deal with "not equal" as well as "is null". =20 The columns seems to be low cardinality too. =20 The only open question is how often these columns get updated. ( https://asktom.oracle.com/pls/apex/asktom.search?tag=3Dbitmap-indexes-a= nd-locking). =20 =20 Regards =20 =20 Lothar =20 =20 Am 25.08.2021 um 19:19 schrieb Mark W. Farnham: =20 =20 =20 =20 =20 unfortunately you keep nearly all the rows of both MA_FLG and D_UNMTCH, so = this query is the opposite of those indexes being useful. =20 =20 =20 IF you were looking for =E2=80=98Y=E2=80=99 instead of not =E2=80=98Y=E2=80= =99 on either one it would be extremely good. I didn=E2=80=99t see initiall= y that these two columns are extremely inclusive. =20 =20 =20 I think Sayan was checking that in his query request. MA_FLG could reject a= t most about 6 million rows, so that=E2=80=99s pretty worthless. =20 =20 =20 From: Lok P [mailto:loknath.73@gmail.com]=20 Sent: Wednesday, August 25, 2021 1:09 PM To: Mark W. Farnham Cc: Sayan Malakshinov; Oracle L Subject: Re: Fixing Performance issue with less selective columns =20 =20 =20 =20 Thank You Mark.=20 =20 =20 I may be wrong but in this situation I was unable to think of any other way= we could make this query faster , so I was thinking of creating a new inde= x. If there exists any other way to make this query faster without creating= any new index that would really be helpful. =20 =20 =20 =20 =20 =20 =20 I am not able to get your point fully, If you can help me understand it a b= it more here please. Below is the data pattern for MA_FLG and D_UNMTCH.=20 =20 =20 =20 =20 =20 =20 =20 Thus , in this query condition " NVL (I.MA_FLG, 'N') <> 'Y' results in ~105= million and NVL (I.D_UNMTCH, 'N') <> 'Y' results in ~111million. So how sh= ould I create index or modify code to make it the best access/filter criter= ia so as to make the query faster? =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 MA_FLG =20 Count(*) =20 =20 =20 N =20 105228656 =20 =20 =20 Y =20 6000938 =20 =20 =20 =20 =20 643566 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 D_UNMTCH =20 Count(*) =20 =20 =20 Y =20 13715 =20 =20 =20 =20 =20 111859445 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 On Wed, Aug 25, 2021 at 8:00 PM Mark W. Farnham wrote: =20 =20 =20 =20 =20 The other thing, for flag values like AND NVL (I.MA_FLG, 'N') <> 'Y' = AND NVL (I.D_UNMTCH, 'N') <> 'Y' =20 =20 =20 if you=E2=80=99re thinking about adding an index, and even if you need a vi= rtual column to do this because you have too much code depending on values = =E2=80=98N=E2=80=99 and =E2=80=98Y=E2=80=99, define the final status (the o= ne where nearly all of them land) as NULL, being the ones you are NOT inter= ested in most of the time. In both these cases it looks like =E2=80=98Y=E2= =80=99 would then be NULL, so =20 =20 =20 i.ma_flg_v is defined decoding Y to NULL and anything else to N and your co= de becomes and i.ma_flg_v =3D =E2=80=98N=E2=80=99 and you deal with variab= ility in non-nulls that are not =E2=80=98Y=E2=80=99 on the original, =20 or =20 i.ma_flg_v decodes Y to NULL, NULL to =E2=80=98N=E2=80=99 and anything else= unchanged and your code becomes i.ma_flg_v is NOT NULL, =20 or =20 you make a functional index on i.ma_flg that does the equivalent. =20 =20 =20 I can=E2=80=99t remember off the top of my head whether either way gives yo= u a real advantage over the other in stats collections and the CBO doing so= mething smart and that probably changed over the releases. That might be in= one of my papers. =20 =20 =20 When you then index that column the nulls disappear, leaving you with a ver= y tiny index to prune your result set immediately to very small and you can= usually filter the rest fast without an index. =20 =20 =20 Remember, ORACLE cannot assign a value to NULL in anything they do. But YOU= can. =20 =20 =20 When this is appropriate, it is one of the neatest and easiest =E2=80=9Cmag= ic tricks=E2=80=9D in the Oracle kit. =20 =20 =20 Good luck, =20 =20 =20 mwf =20 =20 =20 From:oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] O= n Behalf Of Sayan Malakshinov Sent: Wednesday, August 25, 2021 9:40 AM To: Lok P Cc: Oracle L Subject: Re: Fixing Performance issue with less selective columns =20 =20 =20 =20 =20 Hi Lok, =20 =20 =20 =20 =20 =20 > SUBSTR(:B8,0.50) =20 =20 =20 Looks like this query should be analyzed and tested better. =20 =20 =20 You haven't provided histograms and bind values statistics, so not enough i= nfo to analyze it properly.=20 =20 =20 =20 For now it looks like "I.WOF_DATE IS NULL" is one of the most selective pre= dicates - it gives only 83154 nulls. =20 =20 =20 In addition to histogram statistics(dba_tab_histograms) and most often bind= s values, I would like also to see what does return this query: =20 =20 =20 select=20 NVL(I.MA_FLG, 'N'),NVL(I.D_UNMTCH, 'N'),I.DC_CODE,count(*) FROM PP_IN_TAB I group by NVL(I.MA_FLG, 'N'),NVL(I.D_UNMTCH, 'N'),I.DC_CODE; =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 On Wed, Aug 25, 2021 at 4:14 PM Lok P wrote: =20 =20 =20 =20 Hello , This database has version 11.2.0.4 of Oracle. We have the below que= ry which is executed thousands of times. It's used in a plsql function whic= h in turn gets called from a procedure. And this procedure gets called from= java thousands of times. And I see from dba_hist_sqlstat , for most of th= e runs this below query results in zero rows. We see from the active sessio= n history for the overall process this query is consuming most time/resourc= es and making the process run longer. So wanted to understand if we can mak= e this individual query execution faster which would eventually make the p= rocess faster? The base table- PP_IN_TAB is holding ~111million rows and is ~43GB in size= . Column PP_ID is the primary key here. The filter predicates used in this = query are below. Many of them were not very selective in nature. So I am no= t able to conclude if any composite index is going to help us here. Can you= please guide me , what is the correct approach to tune this process in suc= h a scenario? Below is the column data pattern used as filter predicate in this query. M= ost of these are less selective in nature. =20 =20 =20 =20 =20 =20 =20 =20 =20 TABLE_NAME =20 COLUMN_NAME =20 NUM_DISTINCT =20 NUM_NULLS =20 =20 =20 PP_IN_TAB =20 EF_ID =20 39515 =20 6151686 =20 =20 =20 PP_IN_TAB =20 PE =20 103074806 =20 647050 =20 =20 =20 PP_IN_TAB =20 PT_Code =20 24 =20 0 =20 =20 =20 PP_IN_TAB =20 PT_MCODE =20 20 =20 0 =20 =20 =20 PP_IN_TAB =20 D_CUR_CODE =20 13 =20 592784 =20 =20 =20 PP_IN_TAB =20 ED_AMT =20 320892 =20 6 =20 =20 =20 PP_IN_TAB =20 WOF_DATE =20 2572 =20 83154 =20 =20 =20 PP_IN_TAB =20 PR_CTGRY =20 2 =20 86 =20 =20 =20 PP_IN_TAB =20 PDE_RSN_CAT =20 6 =20 0 =20 =20 =20 PP_IN_TAB =20 MA_FLG =20 2 =20 648172 =20 =20 =20 PP_IN_TAB =20 M_TXT =20 29460248 =20 9118572 =20 =20 =20 PP_IN_TAB =20 D_UNMTCH =20 1 =20 111766716 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 SELECT NVL (I.PP_ID, 0) FROM PP_IN_TAB I WHERE TRIM(I.M_TXT) =3D TRIM (SUBSTR ( :B8, 0.50)) AND I.PT_Cod= e =3D :B7 AND NVL ( :B6, I.PT_MCODE) =3D NVL ( :B6, :B5) AND I.DC_CODE = =3D :B4 AND I.D_CUR_CODE =3D :B3 AND I.ED_AMT =3D :B2 AND I.PR_CTGRY =3D :B1 AND I.PE IS NOT NULL AND I.EF_ID IS NULL AND I.WOF_DATE IS NULL AND NVL (I.MA_FLG, 'N') <> 'Y' AND NVL (I.D_UNMTCH, 'N') <> '= Y' AND ROWNUM =3D 1; =20 Global Information ------------------------------ Status : DONE (ALL ROWS) =20 Instance ID : 1 =20 SQL Execution ID : 16777216 =20 Execution Started : 08/25/2021 03:53:25 =20 First Refresh Time : 08/25/2021 03:53:25 =20 Last Refresh Time : 08/25/2021 03:53:28 =20 Duration : 3s =20 Module/Action : SQL*Plus/- =20 Program : sqlplus.exe =20 Fetch Calls : 1 =20 Global Stats =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Elapsed | Cpu | IO | Application | Fetch | Buffer | Read | Re= ad | Cell | | Time(s) | Time(s) | Waits(s) | Waits(s) | Calls | Gets | Reqs | By= tes | Offload | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 3.30 | 1.15 | 2.15 | 0.00 | 1 | 6M | 44379 | 4= 3GB | 99.99% | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SQL Plan Monitoring Details (Plan Hash Value=3D1096440065) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Id | Operation | Name | Rows | Cost | = Time | Start | Execs | Rows | Read | Read | Cell | Mem | A= ctivity | Activity Detail | | | | | (Estim) | | = Active(s) | Active | | (Actual) | Reqs | Bytes | Offload | (Max) | = (%) | (# samples) | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 0 | SELECT STATEMENT | | | | = | | 1 | | | | | | = | | | 1 | COUNT STOPKEY | | | | = | | 1 | | | | | | = | | | 2 | TABLE ACCESS STORAGE FULL | PP_IN_TAB | 1 | 128K | = 3 | +2 | 1 | 0 | 44379 | 43GB | 99.99% | 6M | = 100.00 | cell smart table scan (3) | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(ROWNUM=3D1) 2 - storage("I"."WOF_DATE" IS NULL AND "I"."EF_ID" IS NULL AND "I"."PT_= Code"=3D:B7 AND "I"."D_CUR_CODE"=3D:B3 AND "I"."PR_CTGRY"=3D:B1 AND "I"."DC_CODE"=3D:B4 AND "I"."ED_AMT"=3DTO_NUMBER(:B2) AND NVL(:B6,"I"."PT_MCODE")=3DNVL(:B6,:B5) AND TRIM("I"."M_TXT")= =3DTRIM(SUBSTR(:B8,0.50)) AND "I"."PE" IS NOT NULL AND NVL("I"."MA_FLG",'N')<>'Y' AND NVL("I"."D_UNMTCH",'N')<>'Y') filter("I"."WOF_DATE" IS NULL AND "I"."EF_ID" IS NULL AND "I"."PT_C= ode"=3D:B7 AND "I"."D_CUR_CODE"=3D:B3 AND "I"."PR_CTGRY"=3D:B1 AND "I"."DC_CODE"=3D:B4 AND "I"."ED_AMT"=3DTO_NUMBER(:B2) AND NV= L(:B6,"I"."PT_MCODE")=3DNVL(:B6,:B5) AND TRIM("I"."M_TXT")=3DTRIM(SUBSTR(:B= 8,0.50)) AND "I"."PE" IS NOT NULL AND NVL("I"."MA_FLG",'N')<>'Y' AND= NVL("I"."D_UNMTCH",'N')<>'Y') =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 --=20 =20 =20 =20 =20 =20 =20 Best regards, Sayan Malakshinov =20 =20 Oracle performance tuning engineer =20 =20 Oracle ACE Associate http://orasql.org =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_Part_8336_1533411668.1629964828896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lok,

I have to say that I lost track of wh= ich columns are how selective.
So what I would do is the classica= l bitmap use, which are single column Bitmap which can be combined.
Maybe n=C3=B3t the best way, but the most flexible.
For all co= lumn where <> and not null is used, you should create a bitmap index.=
Thus we have one bitmap on NVL (I.MA_FLG, 'N') and one on&= nbsp; NVL (I.D_UNMTCH, 'N'). For not <> only b= itmap would work.
For is null and is not null we can also make a = single column bitmap index.
It all depends how often this table i= s inserted and how often the columns are updated. How much is too much is h= ard to decide and quite often the truth will show only at runtime. There is= some risk on bimap in an OLTP, always.

For al= l the other columns you can create a combined B*Tree index.

<= /div>
There is an other option like creating a big combined B*Tree with= the columns compare with =3D in the leading positions.
You can u= se the other columns as filter . This is a low risk option
E.g. something like this (in that sequence)  TRIM(I.M_TXT= ) , PT_Code, DC_CODE, D_CUR_CODE, ED_AMT, PR_CTGRY, NVL (I.MA_FLG, 'N'), NV= L (I.D_UNMTCH, 'N'), WOF_DATE, PE, PT_MCODE.
How good this index= is will show in the combined selectivity of the =3D compared columns.

You can check this by :
select count(*)= from (
select distinct TRIM(I.M_TXT) , PT_Code, DC_CODE, D_C= UR_CODE, ED_AMT, PR_CTGRY
from  PP_IN_TAB)
;

I the sele= ctivity is not good enough, you can increase the selektivity by using a tra= nsformation like Mark described it.

=
Regards

Lothar
----Urspr=C3=BCngliche Nachrich= t----
Von : loknath.73@gmail.com
Datum : 25/08/2021 - 21:33 (MS)
A= n : l.flatz@bluewin.ch
Cc : oracle-l@freelists.org
Betreff : Re: Fixi= ng Performance issue with less selective columns

Thank you Lothar. Actually this is an OLTP kind of database and I do see U= PDATE queries on these table columns. Need to see in detail about the frequ= ency of those and how concurrent they are. I am Not very familiar with= the usage of bitmap indexes , so trying to understand what exact colu= mn you are suggesting for the bitmap index to help this query?

On Wed, Aug 25, 2021 at 11:45 PM Lothar Flatz < l.flatz@bluewin= .ch> wrote:
This scenario cries for bitmap indexes.
Bitmap Indexes can deal with "not equal" as well as "is null".
The columns seems to be low cardinality too.
The only open question is how often these columns get updated. ( https://asktom.oracle.com/pls/apex/asktom.search?tag= =3Dbitmap-indexes-and-locking).

Regards

Lothar

Am 25.08.2021 um 19:19 schrieb Mark W. Farnham:

unfortunately you keep nearly a= ll the rows of both MA_FLG and D_UNMTCH, so this query is the opposite of t= hose indexes being useful.

 

IF you were looking for =E2=80= =98Y=E2=80=99 instead of not =E2=80=98Y=E2=80=99 on either one it would be = extremely good. I didn=E2=80=99t see initially that these two columns are e= xtremely inclusive.

 

I think Sayan was checking that= in his query request. MA_FLG could reject at most about 6 million rows, so= that=E2=80=99s pretty worthless.

 

From: Lok P [mailto:loknath.73@gmail.com]
Sent:= Wednesday, August 25, 2021 1:09 PM
To: Mark W. Farnham
Cc:= Sayan Malakshinov; Oracle L
Subject: Re: Fixing Performance = issue with less selective columns

 

Thank You Mark. 

I may be wrong but in this situation I w= as unable to think of any other way we could make this query faster , = so I was thinking of creating a new index. If there exists any other way&nb= sp;to make this query faster without creating any new index that would= really be helpful.

 

I am not able to get your point fully, If you= can help me understand it a bit more here please. Below is the data p= attern for MA_FLG and D_UNMTCH. 

 

Thus , in this query condition " NVL (I.MA_FL= G, 'N') <> 'Y' results in ~105million and  = NVL (I.D_UNMTCH, 'N') <> 'Y' results in ~111million. So how sh= ould I create index or modify code to make it the best access/filter criter= ia so as to make the query faster?

 

 

MA_FLG

Count(*)=

N

105228656<= u>

Y

6000938=

 

643566<= /u>

 

D_UNMTCH

Count(*)=

Y

13715

 

111859445<= u>

 

 

 

On Wed, Aug 25, 2021 at 8:00 PM Mark W. Farnh= am <mwf@rsiz.com= > wrote:

The other thing, for flag v= alues like AND NVL (I.MA_FLG, 'N') <> 'Y'    &nbs= p;  AND NVL (I.D_UNMTCH, 'N') <> 'Y'

 =

if you=E2=80=99re thinking = about adding an index, and even if you need a virtual column to do this bec= ause you have too much code depending on values =E2=80=98N=E2=80=99 and =E2= =80=98Y=E2=80=99, define the final status (the one where nearly all of them= land) as NULL, being the ones you are NOT interested in most of the time. = In both these cases it looks like =E2=80=98Y=E2=80=99 would then be NULL, s= o

 =

i.ma_flg_v is defined decod= ing Y to NULL and anything else to N and your code becomes and  i.ma_f= lg_v =3D =E2=80=98N=E2=80=99 and you deal with variability in non-nulls tha= t are not =E2=80=98Y=E2=80=99 on the original,

or

i.ma_flg_v decodes Y to NUL= L, NULL to =E2=80=98N=E2=80=99 and anything else unchanged and your code be= comes i.ma_flg_v is NOT NULL,

or

you make a functional index= on i.ma_flg that does the equivalent.

 =

I can=E2=80=99t remember of= f the top of my head whether either way gives you a real advantage over the= other in stats collections and the CBO doing something smart and that prob= ably changed over the releases. That might be in one of my papers.

 =

When you then index that co= lumn the nulls disappear, leaving you with a very tiny index to prune your = result set immediately to very small and you can usually filter the rest fa= st without an index.

 =

Remember, ORACLE cannot ass= ign a value to NULL in anything they do. But YOU can.<= /p>

 =

When this is appropriate, i= t is one of the neatest and easiest =E2=80=9Cmagic tricks=E2=80=9D in the O= racle kit.

 =

Good luck,=

 =

mwf

 =

From:oracle-l-bounce@freelists.org [mailto:oracle-l= -bounce@freelists.org] On Behalf Of Sayan Malakshinov
Sent= : Wednesday, August 25, 2021 9:40 AM
To: Lok P
Cc: = Oracle L
Subject: Re: Fixing Performance issue with less selectiv= e columns

 

Hi Lok,

 

> SUBSTR(:B8,0.50)

Looks like this query should be analyzed= and tested better.

You haven't provided histograms and bind= values statistics, so not enough info to analyze it properly.&nb= sp;

For now it looks like "I.WOF_DATE IS NUL= L" is one of the most selective predicates - it gives only 83154 = nulls.

In addition to histogram statistics= (dba_tab_histograms) and most often binds values, I would like = also to see what does return this query:

select
  NVL(I.MA_FLG, 'N'),NV= L(I.D_UNMTCH, 'N'),I.DC_CODE,count(*)
FROM PP_IN_TAB I
group by NVL= (I.MA_FLG, 'N'),NVL(I.D_UNMTCH, 'N'),I.DC_CODE;

 

 

 

On Wed, Aug 25, 2021 at 4:14 PM Lok P &l= t;loknath.73@gm= ail.com> wrote:

Hello , This database has version 11.2.= 0.4 of Oracle. We have the below query which is executed thousands of times= . It's used in a plsql function which in turn gets called from a procedure.= And this procedure gets called from java thousands of times.  And I s= ee from dba_hist_sqlstat , for most of the runs this below query resul= ts in zero rows. We see from the active session history for the overall pro= cess this query is consuming most time/resources and making the process run= longer. So wanted to understand if we can make this individual query execu= tion faster which would  eventually make the process faster?

T= he base table- PP_IN_TAB is holding ~111million rows and is ~43GB in size. = Column PP_ID is the primary key here. The filter predicates used in this qu= ery are below. Many of them were not very selective in nature. So I am not = able to conclude if any composite index is going to help us here. Can you p= lease guide me , what is the correct approach to tune this process in such = a scenario?

Below is the column data pattern used as filter predica= te in this query. Most of these are less selective in nature.=

 

TABLE_NAME=

COLUM= N_NAME

NUM_D= ISTINCT

NUM_N= ULLS

PP_IN_TAB

EF_ID

39515

6151686

PP_IN_TAB

PE

103074806<= /span>

647050

PP_IN_TAB

PT_Code

24<= u>

0

PP_IN_TAB

PT_MCODE

20<= u>

0

PP_IN_TAB

D_CUR_CODE

13<= u>

592784

PP_IN_TAB

ED_AMT

320892

6

PP_IN_TAB

WOF_DATE

2572

83154

PP_IN_TAB

PR_CTGRY

2

86<= u>

PP_IN_TAB

PDE_RSN_CAT

6

0

PP_IN_TAB

MA_FLG

2

648172

PP_IN_TAB

M_TXT

29460248

9118572

PP_IN_TAB

D_UNMTCH

1

111766716<= /span>

 

 

SELECT   NVL (I.PP_ID, 0)
&n= bsp; FROM PP_IN_TAB I
 WHERE     TRIM(I.M_TXT) =3D TRIM = (SUBSTR ( :B8, 0.50))       AND I.PT_Code =3D :B7
 =      AND NVL ( :B6, I.PT_MCODE) =3D NVL ( :B6, :B5)   =     AND I.DC_CODE =3D :B4
       AND I.D_= CUR_CODE =3D :B3       AND I.ED_AMT =3D :B2
   = ;    AND I.PR_CTGRY =3D :B1       AND I.PE IS NOT NULL
       AND I.EF_ID= IS NULL       AND I.WOF_DATE IS NULL
    &nbs= p;  AND NVL (I.MA_FLG, 'N') <> 'Y'       AND NVL = (I.D_UNMTCH, 'N') <> 'Y'
       AND ROWNUM = =3D 1;
 

Global Information
--------------------= ----------
 Status              = ;:  DONE (ALL ROWS)          
 Inst= ance ID         :  1         &= nbsp;              
 SQL Execu= tion ID    :  16777216           &n= bsp;      
 Execution Started   :  08/25/= 2021 03:53:25      
 First Refresh Time  : &n= bsp;08/25/2021 03:53:25      
 Last Refresh Time &= nbsp; :  08/25/2021 03:53:28      
 Duration =            :  3s       &n= bsp;                
 Modu= le/Action       :  SQL*Plus/-       &nbs= p;        
 Program        = ;     :  sqlplus.exe           &nbs= p;  
 Fetch Calls         :  1 &nbs= p;                     &n= bsp;

Global Stats
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
| Elapsed |   Cpu   |    IO    | Applica= tion | Fetch | Buffer | Read  | Read  |  Cell   |
|= Time(s) | Time(s) | Waits(s) |  Waits(s)   | Calls |  Gets =  | Reqs  | Bytes | Offload |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
|    3.30 |    1.15 |     2.= 15 |        0.00 |     1 |     6M |= 44379 |  43GB |  99.99% |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

SQL Plan Monitoring Details (Plan Hash Value=3D1096440065= )
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| Id |       &nb= sp;  Operation           |     &nbs= p; Name       |  Rows   | Cost |   Time  = ;  | Start  | Execs |   Rows   | Read  | Read &nbs= p;|  Cell   |  Mem  | Activity |      Ac= tivity Detail      |
|    |     &nbs= p;                     &n= bsp;  |                  = | (Estim) |      | Active(s) | Active |      = | (Actual) | Reqs  | Bytes | Offload | (Max) |   (%)   &nbs= p;|        (# samples)        |
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|  0 | SELECT STATEMENT  = ;           |           &= nbsp;      |         |     &nb= sp;|           |        | &nbs= p;   1 |          |       | &n= bsp;     |         |       | &= nbsp;        |            = ;               |
|  1 |  = COUNT STOPKEY              |   &nb= sp;              |       =   |      |           |   =      |     1 |          |=       |       |         = |       |          |     =                      = ; |
|  2 |    TABLE ACCESS STORAGE FULL | PP_IN_TAB &nbs= p;      |       1 | 128K |     &nbs= p;   3 |     +2 |     1 |       &nb= sp;0 | 44379 |  43GB |  99.99% |    6M |   100.00 = | cell smart table scan (3) |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  = ;

Predicate Information (identified by operation id):
--------= -------------------------------------------

   1 - filter= (ROWNUM=3D1)
   2 - storage("I"."WOF_DATE" IS NULL AND "I"."E= F_ID" IS NULL AND "I"."PT_Code"=3D:B7 AND "I"."D_CUR_CODE"=3D:B3 AND "I"."P= R_CTGRY"=3D:B1 AND
              "I"= ."DC_CODE"=3D:B4 AND "I"."ED_AMT"=3DTO_NUMBER(:B2) AND
    &n= bsp;         NVL(:B6,"I"."PT_MCODE")=3DNVL(:B6,:B5) AND= TRIM("I"."M_TXT")=3DTRIM(SUBSTR(:B8,0.50))
       =        AND "I"."PE" IS NOT NULL AND NVL("I"."MA_FLG",'= N')<>'Y' AND
              NVL= ("I"."D_UNMTCH",'N')<>'Y')
       filter("I".= "WOF_DATE" IS NULL AND "I"."EF_ID" IS NULL AND "I"."PT_Code"=3D:B7 AND "I".= "D_CUR_CODE"=3D:B3 AND "I"."PR_CTGRY"=3D:B1 AND
      &n= bsp;       "I"."DC_CODE"=3D:B4 AND "I"."ED_AMT"=3DTO_NUMBER(= :B2) AND NVL(:B6,"I"."PT_MCODE")=3DNVL(:B6,:B5) AND TRIM("I"."M_TXT")=3DTRI= M(SUBSTR(:B8,0.50))
              &n= bsp;AND "I"."PE" IS NOT NULL AND NVL("I"."MA_FLG",'N')<>'Y' AND  = ;NVL("I"."D_UNMTCH",'N')<>'Y')


 

--

Best regards,
Sayan Malakshinov

Ora= cle performance tuning engineer

Oracle ACE Associate
http://orasql.org




------=_Part_8336_1533411668.1629964828896-- ------=_Part_8337_98656429.1629964828896-- -- http://www.freelists.org/webpage/oracle-l