oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)

WebIV:View NOTE:159898.1    
             



Article-ID:         <Note:159898.1>

Alias:              VIEW:X$KCBKPFS

Circulation:        PUBLISHED (INTERNAL) ***Oracle Confidential - Internal Use Only***

Folder:             server.Internals.General

Topic:              ** X$ Table Definitions

Title:              VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)

Document-Type:      REFERENCE

Impact:             LOW

Skill-Level:        NOVICE

Server-Version:     09.00

Updated-Date:       05-OCT-2001 05:27:02

References:         

Shared-Refs:        

Authors:            MEPRESTO.US

Attachments:        NONE

Content-Type:       TEXT/PLAIN

Products:           5/RDBMS (9.0);  



View:   X$KCBKPFS

         [K]ernal [C]ache [B]uffer chec[K]point management

           [P]re[F]etch [S]tats





 Column            Type               Description

 --------          ----               --------

 ADDR              RAW(4|8)           address of this row/entry in the array or SGA

 INDX              NUMBER             index number of this row in the fixed table array

 INST_ID           NUMBER             oracle instance number

 BUFFER_POOL_ID    NUMBER             Buffer Pool

 TIMESTAMP         NUMBER             Timestamp

 PREFETCH_OPS      NUMBER             number of prefetch operations

 PREFETCH_BLOCKS   NUMBER             number of blocks prefetched

 WASTED_BLOCKS     NUMBER             number of prefetched blocks wasted

 CLIENTS_PREFETCH  NUMBER             number of clients actually prefetching buffers

 PREFETCH_LIMIT    NUMBER             Limit to be used by for each prefetch operation







Notes: 



This is maintained by the CKPT process which fills in an entry for each timeout period.



Size of prefech history is limited to 50 per buffer pool.





 This section deals with controlling prefetching through the cache. This

 is used to determine whether prefetch is wasteful i.e are prefetched blocks

 being aged out of the cache before they can be used? This can happen,

 for example, if there is a lot of recycling activity in the cache and

 each client of the cache prefetched a large number of blocks into the cache.



 To prevent this the following algorithm is used to limit the amount

 of prefetching done in each buffer pool:



    A history buffer is maintained per buffer pool. This buffer maintains

    a history of prefetching performance. This is populated through a

    timeout action. The history buffer contains the following information

    in each entry (struct kcbkpfs):

      - Timestamp at which entry was created.

      - Number of prefetch operations since the last timeout action.

      - Number of blocks prefetched in this period.

      - Number of prefetched blocks that were wasted - this refers to

        blocks that were prefetched but had to be aged out before

        they could be pinned.

      - Prefetch limit (this is the value computed by this function)

      - Number of prefetching clients (as a snapshot at the time this

        function is executed)

      - Number of buffers being read at this time.



    The algorithm uses the history to determine the prefetch limit. It

    the last few history entries (defined by KCBK_HIST_WINDOW) and then

    computes the cumulative number of prefetch operations, prefetched

    blocks and wasted prefetch blocks over this window. It then applies

    the following rules to adjust the limit:



      - If there are no prefetched blocks, then set the limit to

        Q/C where Q is the prefetch quota (in number of buffers) and

        C is the number of clients performing prefetching



      - If there are prefetched blocks and some of them were wasted.

        In this case, the limit is reduced by the fraction (P - W)/P

        where P is the number of blocks prefetched over the history

        window and W is the number of prefetched blocks that were wasted.

        If W happens to be greater than P, this implies that the buffers

        that were prefetched before the history window were wasted in

        this time interval. In this case, we reduce the limit to half

        its value.



      - If there are no wasted prefetch blocks, then there are 3 cases:



        (a) The number of clients has gone down - in this case we

            double the prefetch limit. If this causes any wasted prefetches

            it will be reduced by that fraction in the next timeout. Note

            that the increase is limited by the ratio (Q/C') where Q is

            the prefetch quota and C' is the new number of clients.



        (b) The number of clients has increased - retain the limit as long

            as the it is less than (Q/C') (same ratio as above). If not,

            set it to Q/C'



        (c) The number of clients remains the same - The limit is doubled

            if the number of prefetched buffers has decreased by atleast

            25% (again subject to the Q/C limit), otherwise the limit is

            retained. The rationale is that if the number of prefetched

            buffers has gone down, the clients have reduced their

            prefetching, so increasing the limit may  not lead to wasted

            prefetches.



 Note that if the increase in the limit leads to wasted prefetching,

 then at the next timeout, the limit will be reduced by the fraction

 of the prefetched blocks that were wasted.



          


你可能感兴趣的:(oracle)