How to reduce buffer gets

Dear All,
My query is taking 575,618,610, executions 86,114 and CPU Time is 3982.59s which i found in the statspack report.
Then i checked the query to tune, but it's execution plan is showing only CPU cost 5.
So, what is the problem and what is the solution. Please let me know.
Thanks in advance
Mahi

Hi Richard Foote,
The below is the function, in that i am using a cursor with the SQL in Bold letters.
That SQL query is taking more buffer gets as i expalined previously.
FUNCTION get_shortcuts(
p_org_id IN VARCHAR2,
p_usr_id IN VARCHAR2,
p_sws_id IN VARCHAR2,
p_lan_id IN VARCHAR2)
RETURN pglobal.g_ref_cur
AS
c_1 pglobal.g_ref_cur;
BEGIN
IF NVL(p_lan_id, 'ENG') = 'ENG' THEN
OPEN c_1
FOR
SELECT amnu.url_value, swssh.sws_id_1, sws.title
FROM SOFTWARE_SERVICE_SHORTCUTS swssh, SERVICE_PROVISIONS sp, SOFTWARE_SERVICES sws, APPLICATION_MENUS amnu
WHERE swssh.sws_id = p_sws_id
AND swssh.sws_id_1 = sp.sws_id
AND sp.rol_org_id = p_org_id
AND sp.sws_id = sws.id
AND sws.id = swssh.sws_id_1
AND sws.sws_id = amnu.sws_id
AND EXISTS(SELECT rol_id
FROM USER_ROLES
WHERE rol_org_id = p_org_id
AND usr_id = p_usr_id
AND rol_id = sp.rol_id); ELSE
OPEN c_1
FOR
SELECT sws.url_value, swssh.sws_id_1, sws.title
FROM SOFTWARE_SERVICE_SHORTCUTS swssh,
SERVICE_PROVISIONS sp,
SOFTWARE_SERVICES sws,
SOFTWARE_SERVICE_LANGUAGES swsl
WHERE swssh.sws_id = p_sws_id
AND swssh.sws_id_1 = sp.sws_id
AND swsl.sws_id = sws.id
AND swsl.lan_id = p_lan_id
AND sp.rol_id = p_org_id
AND sp.sws_id = sws.id
AND EXISTS(SELECT rol_id
FROM USER_ROLES
WHERE rol_org_id = p_org_id
AND usr_id = p_usr_id
AND rol_id = sp.rol_id)
GROUP BY sws.url_value, swssh.sws_id_1, sws.title;
END IF;
RETURN c_1;
END;
So, please can u explain me is there any possiblity to reduce the buffer gets after checking the above function.
Thanks in advance
Mahi

Similar Messages

  • How to reduce buffer busy waits, session hanging due to buffer busy waits

    Hi,
    How to reduce buffer busy waits, session hanging due to buffer busy waits.
    Thanks,
    Sathis.

    When I see through enterprise manager I see lot of
    tables with buffer busy waits.
    Is there any way by table name we can check the
    blocks info.
    The simple way is to look at the SQL statement and corresponding table name?
    P1=file#, P2=block#. You can extract segment name(table or index) using this info.
    Query v$bh like following:
    SQL> select file#, block#, class#, objd from v$bh where file# = P1 and block# = P2;
    SQL> select object_name from all_objects where object_id = <objd>;See following doc:
    http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_1051.htm
    Or you can dump block:
    SQL> alter system dump datafie <P1> block <P2>;Some excerpts from block dump:
    scn: 0x07df.17e70782 seq: 0x01 flg: 0x04 tail: 0x07822301
    frmt: 0x02 chkval: 0x61d0 type: 0x23=PAGETABLE SEGMENT HEADER
    Map Header:: next  0x00000000  #extents: 1    obj#: 55881  flag: 0x10000000>
    Can we do something at table level that will reduce
    the waits.
    Yes, some methods are known. But before thinking of that, you must verify which block class and which access are involved.
    Typo... always. :(
    Message was edited by:
    Dion_Cho

  • How to calculate #Buffer Gets    # Exec           Buffer Gets/Exec

    Hi,
    How to calculate #Buffer Gets,# Execution time,Buffer Gets/Exec for a sql query?

    Nirmal
    You can find out these statistics from two places
    1) using SQL_TRACE (10046 trace) and then TKPROF (or Autotrace in SQL*Plus)
    2) or looking at V$SQL which records the cost assigned to each SQL statement since the statement was first cached.
    If you use Statspack or AWR, you can see the difference between two points in time, so you can calculate the cost for a period of time.
    See Using SQL_Trace and TKPROF
    http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96533/sqltrace.htm#1018
    and Using Statspack
    http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96533/statspac.htm#34837
    (see the 10g documentation equivalents if necessary).
    Remember, ratios (eg gets/exec) aren't always very helpful. You're best off concentrating on those operations which take longest (ie where there is the most potential to save time). See (eg) www.hotsos.com, www.oraperf.com, and others to identify effective performance methodologies.
    HTH
    Regards Nigel

  • Help me to reduce buffer gets of following query

    Buffer gets with this query is 460K.
    We want to reduce it drastically.
    SELECT temp21.resource_code
    ,temp21.employee_type employee_type
         ,temp21.resource_name resource_name
         ,temp21.manager_id
         ,temp21.manager_name
         ,temp21.period_start
         ,temp21.period_finish
         ,temp21.avail_hours
         ,temp21.act_hours
         ,temp21.timesheet_status timesheet_status
         ,temp21.email,temp21.ouc
         ,temp21.work_country
         ,f.level1_unit_id level1_id
         ,f.level2_unit_id level2_id
         ,f.level3_unit_id level3_id
         ,f.level4_unit_id level4_id
         ,f.level5_unit_id level5_id
         ,f.level6_unit_id level6_id
         ,f.level7_unit_id level7_id
         ,f.level8_unit_id level8_id
         ,f.level9_unit_id level9_id
         ,f.level10_unit_id level10_id
         ,f.level1_name
         ,f.level2_name
         ,f.level3_name
         ,f.level4_name
         ,f.level5_name
         ,f.level6_name
         ,f.level7_name
         ,f.level8_name
         ,f.level9_name
         ,f.level10_name
    FROM (SELECT avail.res_id
         ,avail.resource_code
              ,avail.employee_type
                        ,avail.person_type
                        ,avail.resource_name
                        ,avail.manager_id
                        ,avail.manager_name
                        ,avail.period_start
                        ,avail.period_finish
                        ,avail.avail_hours
                        ,NVL(act.act_hours,0) act_hours
                        ,act.timesheet_status
                        ,avail.prid
                        ,avail.email
                        ,avail.ouc
                        ,avail.work_country
    FROM (SELECT /*+ALL_ROWS*/r.id res_id
         ,lk.name employee_type
              ,r.unique_name resource_code
                                            ,r.person_type
                                            ,r.first_name||' '||r.last_name resource_name
                                            ,r.manager_id manager_id
                                            ,r1.first_name||' '||r1.last_name manager_name
                                            ,TRUNC(tp.prstart) period_start
                                            ,TRUNC(tp.prfinish - 1) period_finish
                                            ,NVL(o.gs_hrs_avail_week,0) avail_hours
                                            ,r.email
                                            ,o.ouc
                                            ,o.work_country
                                            ,tp.prid
                   FROM niku.ODF_CA_RESOURCE o
                   ,niku.SRM_RESOURCES r
                        ,niku.SRM_RESOURCES r1
                        ,niku.PRTIMEPERIOD tp
                        ,niku.CMN_SEC_USER_GROUPS usr_grp
                        ,niku.CMN_SEC_GROUPS grp
                        ,(SELECT
                             NLS.NAME
                             ,LKP.ID
                             FROM CMN_CAPTIONS_NLS NLS,CMN_LOOKUPS LKP
                             WHERE NLS.PK_ID=LKP.ID
                             AND LKP.LOOKUP_TYPE='SRM_RESOURCE_TYPE'
                             AND NLS.TABLE_NAME='CMN_LOOKUPS'
                             AND NLS.LANGUAGE_CODE='en') lk
    WHERE r.id=o.id
    AND r1.user_id(+)=r.manager_id
    AND r.user_id=usr_grp.user_id
    AND usr_grp.GROUP_ID=grp.id
         AND r.person_type=lk.id
    AND r.is_active = 1
    AND r1.is_active = 1
    AND grp.GROUP_CODE='gs_tb'
    AND tp.prisopen = 1
    ) avail
                   ,(SELECT r.id
                   ,tp.prid
                                            ,SUM(NVL(practsum,0)/3600) act_hours
                                            ,ts.prstatus timesheet_status
    FROM niku.SRM_RESOURCES r
                   ,niku.PRTIMESHEET ts
    SELECT /*+ALL_ROWS*/ MAX(prid) prid
                             ,prtimeperiodid
                             ,prresourceid
    FROM niku.prtimesheet
                             GROUP BY prtimeperiodid,prresourceid
    ) ts_new
                        ,niku.PRTIMEENTRY te
                        ,niku.PRTIMEPERIOD tp
                        ,niku.CMN_SEC_USER_GROUPS usr_grp
                        ,niku.CMN_SEC_GROUPS grp
    WHERE ts.prid=ts_new.prid
    AND ts.prtimeperiodid=ts_new.prtimeperiodid
    AND ts.prresourceid=ts_new.prresourceid
    AND r.id=ts.PRRESOURCEID
    AND ts.PRID=te.PRTIMESHEETID
    AND ts.PRTIMEPERIODID=tp.prid
    AND usr_grp.USER_ID=r.USER_ID
    AND grp.id=usr_grp.group_id
    AND r.is_active=1
    AND tp.PRISOPEN=1
    AND ts.prstatus not in(0,2,5)
    AND grp.group_code='gs_tb'
    AND TRUNC(tp.PRSTART) >= TRUNC(TO_DATE('7/24/2006','MM/DD/YYYY HH:MI:SS AM'))
    AND TRUNC(tp.PRFINISH-1) <= TRUNC(TO_DATE('9/25/2006','MM/DD/YYYY HH:MI:SS AM'))
              GROUP BY r.ID
                   ,tp.PRID
                             ,ts.prstatus) act
    WHERE act.id(+) = avail.res_id
    AND act.prid(+) = avail.prid
    AND (avail.avail_hours - NVL(act.act_hours,0) > 0))temp21
         ,prj_obs_associations o1
         ,nbi_dim_obs f
         WHERE 1=1
    AND temp21.prid in (SELECT prid
    FROM PRTIMEPERIOD
    WHERE TRUNC(PRSTART) >= TRUNC(TO_DATE('7/24/2006','MM/DD/YYYY HH:MI:SS AM'))
    AND TRUNC(PRFINISH-1) <= TRUNC(TO_DATE('9/25/2006','MM/DD/YYYY HH:MI:SS AM'))
    AND
    temp21.res_id = o1.record_id
    AND o1.unit_id = f.obs_unit_id
    AND o1.table_name = 'SRM_RESOURCES'
    AND f.obs_type_id = 5000009
    AND f.level5_unit_id = 5013334
                                       ORDER BY temp21.manager_name
                                       ,temp21.manager_id
                                       ,temp21.resource_name
                                       ,temp21.resource_code
                                       ,temp21.period_start
                                       ,temp21.period_finish
                                       ,temp21.timesheet_status

    ...Also
    AND TRUNC(tp.PRSTART) >= TRUNC(TO_DATE('7/24/2006','MM/DD/YYYY HH:MI:SS AM'))
    AND TRUNC(tp.PRFINISH-1) <= TRUNC(TO_DATE('9/25/2006','MM/DD/YYYY HH:MI:SS AM'))Although this won't fail, you have specified the time portion of the date without supplying data to be converted....which you don't need as it will automatically be set to midnight if you don't specify it.
    In addition, you are applying the TRUNC function to the column you are comparing which will prevent any indexes from being used. You should perform the arithmetic on the litterals, not the columns, and set up the range correctly:
    AND tp.PRSTART >= TO_DATE('7/24/2006','MM/DD/YYYY)
    AND tp.PRFINISH < TO_DATE('9/25/2006','MM/DD/YYYY) + 2This should yeild the same result and will allow any indexes to be used.
    Without a formatted execution plan and more info from you, this is just a wild guess as to what part of the problem might be.
    HTH
    David
    After a further look, the cartesian product appears to be in the bold section:
    SELECT
         temp21.resource_code
         ,temp21.employee_type employee_type
         ,temp21.resource_name resource_name
         ,temp21.manager_id
         ,temp21.manager_name
         ,temp21.period_start
         ,temp21.period_finish
         ,temp21.avail_hours
         ,temp21.act_hours
         ,temp21.timesheet_status timesheet_status
         ,temp21.email,temp21.ouc
         ,temp21.work_country
         ,f.level1_unit_id level1_id
         ,f.level2_unit_id level2_id
         ,f.level3_unit_id level3_id
         ,f.level4_unit_id level4_id
         ,f.level5_unit_id level5_id
         ,f.level6_unit_id level6_id
         ,f.level7_unit_id level7_id
         ,f.level8_unit_id level8_id
         ,f.level9_unit_id level9_id
         ,f.level10_unit_id level10_id
         ,f.level1_name
         ,f.level2_name
         ,f.level3_name
         ,f.level4_name
         ,f.level5_name
         ,f.level6_name
         ,f.level7_name
         ,f.level8_name
         ,f.level9_name
         ,f.level10_name
    FROM (     SELECT
                   avail.res_id
                   ,avail.resource_code
                   ,avail.employee_type
                   ,avail.person_type
                   ,avail.resource_name
                   ,avail.manager_id
                   ,avail.manager_name
                   ,avail.period_start
                   ,avail.period_finish
                   ,avail.avail_hours
                   ,NVL(act.act_hours,0) act_hours
                   ,act.timesheet_status
                   ,avail.prid
                   ,avail.email
                   ,avail.ouc
                   ,avail.work_country
              FROM (     SELECT /*+ALL_ROWS*/
                             r.id res_id
                             ,lk.name employee_type
                             ,r.unique_name resource_code
                             ,r.person_type
                             ,r.first_name||' '||r.last_name resource_name
                             ,r.manager_id manager_id
                             ,r1.first_name||' '||r1.last_name manager_name
                             ,TRUNC(tp.prstart) period_start
                             ,TRUNC(tp.prfinish - 1) period_finish
                             ,NVL(o.gs_hrs_avail_week,0) avail_hours
                             ,r.email
                             ,o.ouc
                             ,o.work_country
                             ,tp.prid
                        FROM
                             niku.ODF_CA_RESOURCE o
                             ,niku.SRM_RESOURCES r
                             ,niku.SRM_RESOURCES r1
                             ,niku.PRTIMEPERIOD tp
                             ,niku.CMN_SEC_USER_GROUPS usr_grp
                             ,niku.CMN_SEC_GROUPS grp
                             ,(     SELECT
                                       NLS.NAME
                                       ,LKP.ID
                                  FROM
                                       CMN_CAPTIONS_NLS NLS,
                                       CMN_LOOKUPS LKP
                                  WHERE
                                       NLS.PK_ID=LKP.ID
                                  AND LKP.LOOKUP_TYPE='SRM_RESOURCE_TYPE'
                                  AND NLS.TABLE_NAME='CMN_LOOKUPS'
                                  AND NLS.LANGUAGE_CODE='en'
                             ) lk
                        WHERE r.id=o.id
                        AND r1.user_id(+)=r.manager_id
                        AND r.user_id=usr_grp.user_id
                        AND usr_grp.GROUP_ID=grp.id
                        AND r.person_type=lk.id
                        AND r.is_active = 1
                        AND r1.is_active = 1
                        AND grp.GROUP_CODE='gs_tb'
                        AND tp.prisopen = 1
                   ) avail
                   ,(     SELECT
                             r.id
                             ,tp.prid
                             ,SUM(NVL(practsum,0)/3600) act_hours
                             ,ts.prstatus timesheet_status
                        FROM
                             niku.SRM_RESOURCES r
                             ,niku.PRTIMESHEET ts
                             ,(      SELECT /*+ALL_ROWS*/
                                       MAX(prid) prid
                                       ,prtimeperiodid
                                       ,prresourceid
                                  FROM
                                       niku.prtimesheet
                                  GROUP BY
                                       prtimeperiodid,
                                       prresourceid
                             ) ts_new
                             ,niku.PRTIMEENTRY te
                             ,niku.PRTIMEPERIOD tp
                             ,niku.CMN_SEC_USER_GROUPS usr_grp
                             ,niku.CMN_SEC_GROUPS grp
                        WHERE
                             ts.prid=ts_new.prid
                        AND ts.prtimeperiodid=ts_new.prtimeperiodid
                        AND ts.prresourceid=ts_new.prresourceid
                        AND r.id=ts.PRRESOURCEID
                        AND ts.PRID=te.PRTIMESHEETID
                        AND ts.PRTIMEPERIODID=tp.prid
                        AND usr_grp.USER_ID=r.USER_ID
                        AND grp.id=usr_grp.group_id
                        AND r.is_active=1
                        AND tp.PRISOPEN=1
                        AND ts.prstatus not in(0,2,5)
                        AND grp.group_code='gs_tb'
                        AND TRUNC(tp.PRSTART) >= TRUNC(TO_DATE('7/24/2006','MM/DD/YYYY HH:MI:SS AM'))
                        AND TRUNC(tp.PRFINISH-1) <= TRUNC(TO_DATE('9/25/2006','MM/DD/YYYY HH:MI:SS AM'))
                        GROUP BY r.ID
                        ,tp.PRID
                             ,ts.prstatus
                   ) act
              WHERE act.id(+) = avail.res_id
              AND act.prid(+) = avail.prid
              AND (avail.avail_hours - NVL(act.act_hours,0) > 0)
         )temp21
         ,prj_obs_associations o1
         ,nbi_dim_obs f
    WHERE 1=1
         AND temp21.prid in (     SELECT prid
                                       FROM PRTIMEPERIOD
                                       WHERE TRUNC(PRSTART) >= TRUNC(TO_DATE('7/24/2006','MM/DD/YYYY HH:MI:SS AM'))
                                       AND TRUNC(PRFINISH-1) <= TRUNC(TO_DATE('9/25/2006','MM/DD/YYYY HH:MI:SS AM'))
    AND
         temp21.res_id = o1.record_id
         AND o1.unit_id = f.obs_unit_id
         AND o1.table_name = 'SRM_RESOURCES'
         AND f.obs_type_id = 5000009
         AND f.level5_unit_id = 5013334
    ORDER BY temp21.manager_name
    ,temp21.manager_id
    ,temp21.resource_name
    ,temp21.resource_code
    ,temp21.period_start
    ,temp21.period_finish
    ,temp21.timesheet_status Message was edited by:
    david_tyler

  • How to tune "Buffer Get"  offender

    QUESTION: How to tune following sql
    SELECT *
    FROM trans
    WHERE accountid = NVL (NULL, accountid)
    AND transtypeid = 171
    AND NVL (description, '-1') = NVL ('Card Activation Fee ', '-1')
    AND ABS (transamt) = ABS (9.95)
    AND accountid <> 7689966
    AND postdate BETWEEN ( TO_DATE ('03/14/2006 00:17:43',
    'mm/dd/yyyy hh24:mi:ss'
    - .00011574
    AND ( TO_DATE ('03/14/2006 00:17:53',
    'mm/dd/yyyy hh24:mi:ss'
    + .00011574
    DETAILS:
    Statspack has shown this piece of SQL as the largest contender for "Buffer Gets" chewing up 513.28 seconds of CPU time out of 3,475 (See Top 5 Timed Events below)
    However, when I run the sql statement by itself in TOAD, it takes 90ms to complete and has a cost of 202 (See plan below). TRANS table has over 18m rows.
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Optimizer Mode=CHOOSE          1           202                     
    TABLE ACCESS BY INDEX ROWID     SVOLTP.TRANS     1      65      202                     
    INDEX RANGE SCAN     SVOLTP.TRANS_POSTDATE_NIDX     1 K          7                     
    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    CPU time 3,475 49.99
    db file sequential read 1,340,884 3,197 45.99
    db file scattered read 180,048 70 1.01
    db file parallel write 3,983 49 .70
    log file sync 20,593 43 .63

    here is the actual statement taken from the package:
    select transid
    into lFromTransID
    from trans
    where accountid = nvl(lacctid, accountid)
    and transtypeid = lToTrans.transtypeid
    and nvl(description, '-1') = nvl(lToTrans.description, '-1')
    and abs(transamt) = abs(lToTrans.transamt)
    and accountid <> lToTrans.accountid
    -- Transactions must be posted within 10 seconds of each other
    and postdate between (lToTrans.postdate - .00011574) and (lToTrans.postdate + .00011574);

  • How to reduce max buffer/cache size?

    Hi,
    every time I copy a file which is bigger or similiar in size to my total RAM (4gb) I notice very low responsibility from firefox (which is totally unresponsive, can't switch tabs or scroll for 30-60s). Of course my free memory is very low (something like 50-100mb) and I notice some swap usage. AFAIK linux caches everthing that is being copied, but in case of such big files it seems unnecessary.
    Is there a way to reduce max buffer size?
    I know that buffering is good in general, but I get a feeling that firefox is giving up ram and he has to read everything again from disk which slows him down. I always have many tabs open, so often it has around 30% of memory.
    I searched many times on how to reduce buffer sizes, but I've always found only articles with "buffering is always good and never an issue" attitude.
    I would be very happy to hear any suggestrions,
    cheers,
    kajman

    This seems a popular problem, going back years. The default Linux setup is bad for responsiveness, it seems.
    Here's the summary of what I do:
    Firstly, install a BFS-patched kernel, for a better kernel scheduler, and also so that the ionice and schedtool commands will work. Bonus points for switching to BFQ while you're at it - or stick with CFQ, which also supports ionice.
    In /etc/fstab, use commit=60 rather than default of 5 seconds, and also noatime, e.g.:
    UUID=73d55f23-fb9d-4a36-bb25-blahblah / ext4 defaults,noatime,nobarrier,commit=60 1 1
    In /etc/sysctl.conf
    # From http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
    vm.swappiness=0
    # https://lwn.net/Articles/572921/
    vm.dirty_background_bytes=16777216
    vm.dirty_bytes=50331648
    In ~/.bashrc - see post, e.g.:
    alias verynice="ionice -c3 nice -n 15"
    In /etc/security/limits.d/ - see post. Read CK's excellent blog article, for info.
    In your cp command, add the word verynice to the start, to stop the large batch copy from having the same priority as your UI.
    Compile sqlite without fsync, to make e.g. firefox smoother.
    Potentially use threadirqs to prioritize the interrupt-handling.
    Edit: Updated vm.swappiness from 0 to 10, from CK's blog.
    Edit2: Also see patch and e.g. nr_requests in thread.
    Edit3: Using nice instead of schedtool - not sure whether schedtool can hog the CPU.
    Edit4: Added threadirqs.
    Edit5: Tweaked sysctl.conf settings.
    Edit6: Added nobarrier option to mount, and sqlite's fsync.
    Edit7: Removed swap comment - I do use a swapfile, these days, mainly because firefox needs so much virtual RAM to compile.
    Last edited by brebs (2014-03-10 09:51:34)

  • How to reduce physical reads - very interesting issue

    HI,
    Every week i generate a statspack report which will give me top20 buffer gets queries and top 20 physical reads query.When i start reducing physical reads by placing the heavy accessed table in buffer i will get the same query in top 20 higher buffer gets list in the next week.If i want to reduce buffer gets i have to remove the heavy accessed table from buffer which will cause higer physical reads.How can i solve this problem.I am trying to tune query as much as possible.
    Your help is appreciated..
    Thanks and Regards
    Anand

    I think that you are labouring under a misapprehension. Buffer gets and physical reads are basically the same thing. In order to satisfy your query, Oracle needsto read X number of blocks to find all of the data. Admittedly, it is generally faster to read those blocks from memory (buffer gets) than from disk (physical reads), but the blocks have to be read (this is called logical I/O). The only way to reduce I/O is to re-write the query to be more efficient. This may or may not be possible.
    As Kamal said, if the query is fast enough, then you are done. If it is too slow, then you need to look at ways of reducing I/O. It is unlikely that any database parameters will have a significant impact on the I/O. You need to look at the statisitics on the table and the actual sql statement.
    John

  • Version count in statspack report-How to reduce this

    I generate stats report every week for 24 Hr time period and analyze all top20 queries interms of buffer gets,physical reads and executions.I could tune the queries with the help of you.Recently my Boss asked me to look in to top version count queries and reduce the number of versions.
    I have 4-5 queries which are running 300,000 times and has version count of 35.How can I reduce this number.please suggest me how to approach it.
    Your help will be appreciated.Thanks in advance.
    Thanks
    Anand

    Version count 35 out of 300000 doesn't look like a problem to me. Are you having performance issue on your system at all?
    <br>
    <br>
    1. Are the subject queries using Bind variables ?<br>
    2. What's the setting of CURSOR_SHARING?<br>
    should have CURSOR_SHARING=FORCE<br>
    3. check if Bug 3406977 apply to your case <br>

  • Reduce buffer busy waits

    Can you please provide me the suggestion on how to reduce the number of buffer busy waits for the below query?
    Please find the query where the buffer busy waits is taking 11091 and 13160 seconds.
    INSERT INTO RPM_CLEARANCE (CLEARANCE_ID, CLEARANCE_DISPLAY_ID, STATE,
    REASON_CODE, CLEARANCE_RESET_ID, RESET_IND, ITEM, ZONE_ID, LOCATION,
    ZONE_NODE_TYPE, EFFECTIVE_DATE, OUT_OF_STOCK_DATE, RESET_DATE, CHANGE_TYPE,
    CHANGE_AMOUNT, CHANGE_PERCENT, CHANGE_CURRENCY, VENDOR_FUNDED_IND,
    CREATE_DATE, CREATE_ID, APPROVAL_DATE, APPROVAL_ID, TSL_EVENT_REF,
    TSL_MARKDOWN_REF, TSL_EVENT_PHASE, TSL_COVER_GROUP, TSL_END_DATE,
    TSL_EVENT_POS_IND, TSL_EVENT_SEL_IND, TSL_HOPOS_TEMPLATE_ID )
    VALUES
    (:B23 , 'reset:'||:B22 , :B21 , :B20 , NULL, '1', :B19 , :B18 , :B17 , :B16 ,
    :B15 , :B15 - 1, NULL, :B14 , :B13 , :B12 , :B11 , '0', :B10 , :B9 , :B10 ,
    :B9 , :B8 , :B7 , :B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
    call count cpu elapsed disk query current rows
    Parse 1849 0.06 0.05 0 0 0 0
    Execute 1895091 2539.06 2606.23 32 119694 31084693 1895091
    Fetch 0 0.00 0.00 0 0 0 0
    total 1896940 2539.12 2606.28 32 119694 31084693 1895091
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 202 (recursive depth: 1)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file sequential read 32 0.01 0.22
    buffer busy waits 11091 0.02 0.29
    latch: cache buffers chains 30 0.00 0.00
    enq: TX - index contention 563 0.01 0.11
    log file switch completion 15 0.06 0.42
    latch: In memory undo latch 7 0.00 0.00
    buffer deadlock 88 0.00 0.00
    cursor: pin S 59 0.00 0.00
    cursor: pin S wait on X 1 0.00 0.00
    INSERT INTO RPM_CLEARANCE (CLEARANCE_ID, CLEARANCE_DISPLAY_ID, STATE,
    REASON_CODE, CLEARANCE_RESET_ID, RESET_IND, ITEM, ZONE_ID, LOCATION,
    ZONE_NODE_TYPE, EFFECTIVE_DATE, OUT_OF_STOCK_DATE, RESET_DATE, CHANGE_TYPE,
    CHANGE_AMOUNT, CHANGE_PERCENT, CHANGE_CURRENCY, VENDOR_FUNDED_IND,
    CREATE_DATE, CREATE_ID, APPROVAL_DATE, APPROVAL_ID, TSL_EVENT_REF,
    TSL_MARKDOWN_REF, TSL_EVENT_PHASE, TSL_COVER_GROUP, TSL_END_DATE,
    TSL_EVENT_POS_IND, TSL_EVENT_SEL_IND, TSL_HOPOS_TEMPLATE_ID )
    VALUES
    (:B23 , 'reset:'||:B22 , :B21 , :B20 , NULL, '1', :B19 , :B18 , :B17 , :B16 ,
    :B15 , :B15 - 1, NULL, :B14 , :B13 , :B12 , :B11 , '0', :B10 , :B9 , :B10 ,
    :B9 , :B8 , :B7 , :B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
    call count cpu elapsed disk query current rows
    Parse 575 0.02 0.01 0 0 0 0
    Execute 1066687 1460.30 1478.77 0 121065 17556349 1066687
    Fetch 0 0.00 0.00 0 0 0 0
    total 1067262 1460.32 1478.79 0 121065 17556349 1066687
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 202 (recursive depth: 1)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    latch: cache buffers chains 28 0.01 0.01
    buffer busy waits 13160 0.07 0.46
    enq: TX - index contention 522 0.00 0.09
    buffer deadlock 108 0.00 0.00
    latch: In memory undo latch 17 0.00 0.00
    cursor: pin S 8 0.00 0.00
    log file switch completion 2 0.05 0.07
    cursor: pin S wait on X 1 0.00 0.00
    ********************************************************************************

    For reducing buffer busy waits you need to increase DB_CACHE_SIZE parameter value.
    Try the query below
    14:40:23 SQL> select name,size_for_estimate,size_factor,estd_physical_reads,buffers_for_estimate fro
    m v$db_cache_advice order by 4;
    NAME    SIZE_FOR_ESTIMATE SIZE_FACTOR ESTD_PHYSICAL_READS BUFFERS_FOR_ESTIMATE
    DEFAULT               960       1.875              252983               119760
    DEFAULT               912      1.7813              268597               113772
    DEFAULT               864      1.6875              269415               107784
    DEFAULT               816      1.5938              269673               101796
    DEFAULT               768         1.5              270449                95808
    DEFAULT               720      1.4063              270923                89820
    DEFAULT               672      1.3125              272107                83832
    DEFAULT               624      1.2188              276651                77844
    DEFAULT               576       1.125              282272                71856
    DEFAULT               528      1.0313              308869                65868
    DEFAULT               512           1              334346                63872
    DEFAULT               480       .9375              411617                59880
    DEFAULT               432       .8438              467955                53892
    DEFAULT               384         .75              520223                47904
    DEFAULT               336       .6563              575829                41916
    DEFAULT               288       .5625              628226                35928
    DEFAULT               240       .4688              670286                29940
    DEFAULT               192        .375              725289                23952
    DEFAULT               144       .2813              784512                17964
    DEFAULT                96       .1875              921481                11976
    DEFAULT                48       .0938             1948144                 5988
    21 rows selected.You will get a result like above. SIZE_FOR_ESTIMATE column shows values in MB.
    Then from the result, choose a size for the buffer cache in which there is minimal physical reads but according to the avaliability of your physical memory and set it.

  • How to Reduce Clusetering Factor on Table?

    I am seeing a very high clustering factor on an SDO geometry table in our 10g RAC DB on our Linux boxes. This slow performance is repeateable on othe r Linux as well as Solaris DBs for the same table. Inserts go in at a rate of 44 milliseconds per insert and we only have about 27000 rows in the table. After viewing a VERY slow insert of about 600 records into this same table, I saw the clustering factor in OEM. The clustering factor is nearly identical to the # rows in the table indicating that useability of the index is fairly low now. I have referenced Metalink Tech Note 223117.1 and, while it affirms what I've seen, I am still trying to determine how to reduce the Clustering Factor. The excerpt on how to do this is below:
    "The only method to affect the clustering factor is to sort and then store the rows in the table in the same order as in they appear in the index. Exporting rows and putting them back in the same order that they appeared originally will have no affect. Remember that ordering the rows to suit one index may have detrimental effects on the choice of other indexes."
    Sounds great, but how does one actually go about storing the rows in the table in the same order as they appear in the index?
    We have tried placing our commits after the last insert as well as after every insert and the results are fairly neglible. We also have a column of type SDE.ST_GEOMETRY in the table and are wondering if this might also be an issue. Thanks in advance for any help.
    Matt Sauter

    Joel is right that the clustering factor is going to have absolutely no effect on the speed of inserts. The clustering factor is merely one, purely statistical, factor the optimiser makes use of to determine how to perform a SELECT statement (i.e., do I bother to use this index or not for row retrieval). It's got nothing to do with the efficiency of inserts.
    If I were you, I'd be looking at factors such as excessive disk I/O taking place for other reasons, inadequate buffer cache and/or enqueue and locking issues instead.
    If you're committing after every insert, for example, then redo will have to be flushed (a commit is about the only foreground wait event -i.e., one that you get to experience in real time- that Oracle has, so a commit after every insert's really not a smart idea). If your redo logs are stored on, say, the worst-performing disk you could buy that's also doing duty as a fileserver's main hard disk, then LGWR will be twiddling its thumbs a lot! You say you've tested this, and that's fine... I'm just saying, it's one theoretical possibility in these sorts of situations. You still want to make sure you're not suffering any log writer-related waits, all the same.
    Similarly, if you're performing huge reads on a (perhaps completely separate) table that is causing the buffer cache to be wiped every second or so, then getting access to your table so your inserts can take place could be problematic. Check if you've got any database writer waits, for example: they are usally a good sign of general I/O bottlenecks.
    Finally, you're on a RAC... so if the blocks of the table you're writing to are in memory over on another instance, and they have to be shipped to your instance, you could have high enqueue waits whilst that shipment is taking place. Maybe your interconnect is not up to the job? Maybe it's faulty, even, with significant packet loss along the way? Even worse if someone's decided to switch off cache fusion transfer for the datafiles invoved (for then block shipment happens by writing them to disk in one instance and reading from disk in the other). RAC adds a whole new level of complexity to things, so good luck tracking that lot down!!
    Also, maybe you're using Freelists and Freelist groups rather than ASSM, so perhaps you're fighting for access to the freelist with whatever else is happening on your database at the time...
    You get the idea: this could be a result of activity taking place on the server for reasons completely unconnected with your insert. It could be a feature of Spatial (with which not many people will be familiar, so good luck if so!) It could be a result of the way your RAC is configured. It could be any number of things... but I'd be willing to bet quite a bit that it's got sod-all to do with the clustering factor!
    You'll need to monitor the insert using a tool like Insider or Toad so you can see if waits and so on happen, more or less in real time -or start using the built-in tools like Statspack or AWR to analyze your workload after it's completed- to work out what your best fix is likely to be.

  • What causes BUFFER GETS and PHYSICAL READS in INSERT operation to be high?

    Hi All,
    Am performing a huge number of INSERTs to a newly installed Oracle XE 10.2.0.1.0 on Windows. There is no SELECT statement running, but just INSERTs one after the other of 550,000 in count. When I monitor the SESSION I/O from Home > Administration > Database Monitor > Sessions, I see the following stats:
    BUFFER GETS = 1,550,560
    CONSISTENT GETS = 512,036
    PHYSICAL READS = 3,834
    BLOCK CHANGES = 1,034,232
    The presence of 2 stats confuses. Though the operation is just INSERT in database for this session, why should there be BUFFER GETS of this magnitude and why should there by PHYSICAL READS. Aren't these parameters for read operations? The BLOCK CHANGES value is clear as there are huge writes and the writes change these many blocks. Can any kind soul explain me what causes there parameters to show high value?
    The total columns in the display table are as follows (from the link mentioned above)
    1. Status
    2. SID
    3. Database Users
    4. Command
    5. Time
    6. Block Gets
    7. Consistent Gets
    8. Physical Reads
    9. Block Changes
    10. Consistent Changes
    What does CONSISTENT GETS and CONSISTENT CHANGES mean in a typical INSERT operation? And does someone know which all tables are involved in getting these values?
    Thank,
    ...

    Flake wrote:
    Hans, gracias.
    The table just have 2 columns, both of which are varchar2 (500). No constraints, no indexes, neither foreign key references are in place. The total size of RAM in system is 1GB, and yes, there are other GUI's going on like Firefox browser, notepad and command terminals.
    But, what does these other applications have to do with Oracle BUFFER GETS, PHYSICAL READS etc.? Awaiting your reply.Total RAM is 1GB. If you let XE decide how much RAM is to be allocated to buffers, on startup that needs to be shared with any/all other applications. Let's say that leaves us with, say 400M for the SGA + PGA.
    PGA is used for internal stuff, such as sorting, which is also used in determing the layout of secondary facets such as indexes and uniqueness. Total PGA usage varies in size based on the number of connections and required operations.
    And then there's the SGA. That needs to cover the space requirement for the data dictionary, any/all stored procedures and SQL statements being run, user security and so on. As well as the buffer blocks which represent the tablespace of the database. Since it is rare that the entire tablespace will fit into memory, stuff needs to be swapped in and out.
    So - put too much space pressure on the poor operating system before starting the database, and the SGA may be squeezed. Put that space pressure on the system and you may enbd up with swapping or paging.
    This is one of the reasons Oracle professionals will argue for dedicated machines to handle Oracle software.

  • [Oracle 10.2.0.3] What exactly are "buffer gets" in V$SQLAREA?

    I've found this page
    [http://www.billmagee.co.uk/oracle/sqltune/080_identify.html]
    in which is said:
    BUFFER_GETS Cumulative total of memory blocks read for this statement
    so if I want to see how many blocks a query read per execution I must do ((disk_reads+buffer_gets)/executions) as suggested from the query on the same page.
    select sql_text,
    executions,
    to_char((((disk_reads+buffer_gets)/executions) * 8192)/1048576,
    '9,999,999,990.00')  as total_gets_per_exec_mb,
    to_char((( disk_reads             /executions) * 8192)/1048576,
    '9,999,999,990.00')  as disk_reads_per_exec_mb,
    to_char((( buffer_gets            /executions) * 8192)/1048576,
    '9,999,999,990.00')  as buffer_gets_per_exec_mb,
    parsing_user_id
    from   v$sqlarea
    where  executions &gt; 0
    order by 6 descThis is correct?
    Buffer gets refers only to the block found in the buffer cache (not loaded from disk) or to the total amount of db block on which the query works (indipendetly if they are found immediately in the buffer cache or must be read from disk) ?
    Hope you can help me.
    Thanks
    Adriano Aristarco

    Yes, the index is appearing on the dba_indexes table, however its state is 'UNUSABLE'.
    It looks impdp takes its state from origin metadata, puts into destination, and even is not trying to rebuild it.
    Of course, after running ALTER INDEX REBUILD its status was changed to VALID.
    So, what's the point impdp tells about its state? It can be hundreds of unusable indexes, why it's not just rebuilding it?

  • Sudden increase in buffer gets per executions in update statement

    Hi,
    Recently we have encountered one performance issue, which is most likely caused by a sudden increase in the buffer gets per execution.
    The SQL is an update statement, updating a table using a primary key (we have checked to confirm the running execution plan is using the primary key), and one field being updated is a BLOB column.
    As shown in the below statistics, there is no major change in the number of executions during the every 20 minutes monitoring interval. However, the buffer gets per executions has been more than double, and the CPU time is almost doubled, hence the exec_time (elapsed time) has been doubled.
    The same SQL has been running for the past four years in multiple similar databases. The database is Oracle 9.2.0.4 running on Solaris 9. For the past 300 days, the average elapsed time per execution is about 0.0093s, while the average buffer gets per execution is about 670. The update statement has been executed about 9 times per second.
    The question is why there is a sudden increase in the buffer gets? The sudden increase happened twice for the past two days.
    <pre>
    B_TIME E_TIME EXECUTIONS_DIFF EXEC_TIME CPU_TIME BUFFER_GETS EXEC_PER_DAY
    2009-11-25-14:04 2009-11-25-14:23 8513 .0069 .0068 315.56 646329
    2009-11-25-14:23 2009-11-25-14:43 10170 .007 .0068 312.28 726188
    2009-11-25-14:43 2009-11-25-15:05 11873 .0072 .0069 320.17 787885
    2009-11-25-15:05 2009-11-25-15:23 8633 .011 .0101 844.83 675014
    2009-11-25-15:23 2009-11-25-15:44 9668 .0144 .0137 1448.51 680778
    2009-11-25-15:44 2009-11-25-16:04 9671 .0163 .0156 1809.04 702163
    2009-11-25-16:04 2009-11-25-16:25 10260 .0188 .0177 2107.67 711447
    2009-11-25-16:25 2009-11-25-16:44 9827 .0157 .0151 1834.3 739593
    2009-11-25-16:44 2009-11-25-17:05 10586 .0171 .0164 2008.25 714555
    2009-11-26-08:04 2009-11-26-08:24 11028 .0182 .0172 1979.61 800688
    2009-11-26-08:24 2009-11-26-08:44 10533 .0154 .0149 1734.62 750248
    2009-11-26-08:44 2009-11-26-09:04 9367 .018 .0168 2043.95 685274
    2009-11-26-09:04 2009-11-26-09:24 10307 .0214 .0201 2552.43 729938
    2009-11-26-09:24 2009-11-26-09:45 10932 .0251 .0234 3111.48 762328
    2009-11-26-09:45 2009-11-26-10:05 10992 .0278 .0254 3386.41 797404
    2009-11-26-15:03 2009-11-26-15:16 7183 .0425 .0348 4615.42 746824
    2009-11-26-15:16 2009-11-26-15:23 2921 .0417 .0373 4887.75 682092
    2009-11-26-15:23 2009-11-26-15:43 9597 .0393 .0352 4603.62 679656
    2009-11-26-15:43 2009-11-26-16:03 8797 .0411 .0362 4783.66 630755
    2009-11-26-16:03 2009-11-26-16:23 9957 .0453 .0391 5168.28 718100
    2009-11-26-16:23 2009-11-26-16:43 11209 .0436 .0369 4870.77 808395
    2009-11-26-16:43 2009-11-26-17:03 10729 .0428 .0375 5119.56 766103
    2009-11-26-17:03 2009-11-26-17:23 9116 .0409 .0363 4912.58 659098
    </pre>
    Yesterday I did a trace on one of the sessions running the update statement, and below is the tkprof output:
    <pre>
    call count cpu elapsed disk query current rows
    Parse 76 0.03 0.00 0 0 0 0
    Execute 76 4.58 5.14 0 567843 19034 76
    Fetch 0 0.00 0.00 0 0 0 0
    total 152 4.61 5.14 0 567843 19034 76
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 88
    Rows Row Source Operation
    1 UPDATE (cr=30 r=0 w=0 time=6232 us)
    1 INDEX UNIQUE SCAN <PK Index Name> (cr=3 r=0 w=0 time=58 us)(object id 81122)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    Waited--------------------------------------------------------------------------------
    SQL*Net message to client 152 0.00 0.00
    SQL*Net message from client 152 0.00 0.22
    SQL*Net more data from client 1894 0.00 0.03
    SQL*Net break/reset to client 152 0.00 0.00
    buffer busy waits 14 0.00 0.00
    enqueue 1 0.61 0.61
    </pre>
    GaoYuan

    Hi,
    I've reformatted your output for better understanding (with {noformat}...{noformat}):
    B_TIME           E_TIME           EXECUTIONS_DIFF  EXEC_TIME   CPU_TIME BUFFER_GETS EXEC_PER_DAY
    2009-11-25-14:04 2009-11-25-14:23            8513      .0069      .0068      315.56       646329
    2009-11-25-14:23 2009-11-25-14:43           10170       .007      .0068      312.28       726188
    2009-11-25-14:43 2009-11-25-15:05           11873      .0072      .0069      320.17       787885
    2009-11-25-15:05 2009-11-25-15:23            8633       .011      .0101      844.83       675014
    2009-11-25-15:23 2009-11-25-15:44            9668      .0144      .0137     1448.51       680778
    2009-11-25-15:44 2009-11-25-16:04            9671      .0163      .0156     1809.04       702163
    2009-11-25-16:04 2009-11-25-16:25           10260      .0188      .0177     2107.67       711447
    2009-11-25-16:25 2009-11-25-16:44            9827      .0157      .0151      1834.3       739593
    2009-11-25-16:44 2009-11-25-17:05           10586      .0171      .0164     2008.25       714555
    2009-11-26-08:04 2009-11-26-08:24           11028      .0182      .0172     1979.61       800688
    2009-11-26-08:24 2009-11-26-08:44           10533      .0154      .0149     1734.62       750248
    2009-11-26-08:44 2009-11-26-09:04            9367       .018      .0168     2043.95       685274
    2009-11-26-09:04 2009-11-26-09:24           10307      .0214      .0201     2552.43       729938
    2009-11-26-09:24 2009-11-26-09:45           10932      .0251      .0234     3111.48       762328
    2009-11-26-09:45 2009-11-26-10:05           10992      .0278      .0254     3386.41       797404
    2009-11-26-15:03 2009-11-26-15:16            7183      .0425      .0348     4615.42       746824
    2009-11-26-15:16 2009-11-26-15:23            2921      .0417      .0373     4887.75       682092
    2009-11-26-15:23 2009-11-26-15:43            9597      .0393      .0352     4603.62       679656
    2009-11-26-15:43 2009-11-26-16:03            8797      .0411      .0362     4783.66       630755
    2009-11-26-16:03 2009-11-26-16:23            9957      .0453      .0391     5168.28       718100
    2009-11-26-16:23 2009-11-26-16:43           11209      .0436      .0369     4870.77       808395
    2009-11-26-16:43 2009-11-26-17:03           10729      .0428      .0375     5119.56       766103
    2009-11-26-17:03 2009-11-26-17:23            9116      .0409      .0363     4912.58       659098
    call     count       cpu    elapsed       disk      query    current        rows
    Parse       76      0.03       0.00          0          0          0           0
    Execute     76      4.58       5.14          0     567843      19034          76
    Fetch        0      0.00       0.00          0          0          0           0
    total      152      4.61       5.14          0     567843      19034          76
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 88
    Rows     Row Source Operation
          1  UPDATE  (cr=30 r=0 w=0 time=6232 us)
          1   INDEX UNIQUE SCAN <PK Index Name(cr=3 r=0 w=0 time=58 us)(object id 81122)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      SQL*Net message to client                     152        0.00          0.00
      SQL*Net message from client                   152        0.00          0.22
      SQL*Net more data from client                1894        0.00          0.03
      SQL*Net break/reset to client                 152        0.00          0.00
      buffer busy waits                              14        0.00          0.00
      enqueue                                         1        0.61          0.61
    ********************************************************************************Can you please provide a DDL for the table, indexes, type of the tablespace(s) they reside in (ASSM/MSSM, extents sizes), the UPDATE statement, how many sessions on average/peaks are doing the same thing concurrently, how many sessions are working this table concurrently and how do they use it?

  • How to reduce the database size based on MS SQL/Oracle?

    Hi,
    I had deleted severy clients via SCC5, but the database size is more and more bigger. Do you know how to reduce the database size.
    my platform is: NT, MS SQL 2005
                           NT, Oracle 10.2
    Best Regards,
    Simon Shen

    Hi Simon,
    In the case of SQL you need to check how many space free you have in your datafiles and the based on that you need to Shrink them using DBCC SHRINKFILE command.
    Find a couple of reference docs here,
    http://www.intermedia.net/support/kb/default.asp?id=996
    http://doc.ddart.net/mssql/sql70/dbcc_21.htm
    Also i'm pretty sure that if your check the properties of the datafiles in MSSQL Enterprise Manager you get a "Shrink" option.
    Regards
    Juan
    Please reward with points if helpful

  • How to reduce the silence gap of ringtone made by Garageband

    Garageband will add an extra silence (about 0.05 ~ 0.1 second) on the ending. The extra silence is automatically add on while garageband mixdown the track and send to iTunes.
    Maybe Apple just made garageband to be so, just like the ringtone sold by iTunes store, it has at least a 0.5 sec gap. But that makes the ringtone won't be a perfect loop. So, I'd like to know how to reduce the extra silence that I don't want if there's a solution for this.

    you're right, it appears the behavior of the Cycle function has changed, it is very small, but it's enough to mess up looping.
    you could cut off the excess with an audio editor:
    http://www.bulletsandbones.com/GB/GBFAQ.html#audioeditors
    but being one of the few cellphoneless people in the world, I couldn't tell you how to get the edited file into the phone. perhaps someone in the iPhone forum can give you a tip for getting that final part done?

Maybe you are looking for