• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Prayer

            在一般中尋求卓越
            posts - 1256, comments - 190, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            DB2通用數據庫性能調整的常用方法

            Posted on 2009-11-10 13:56 Prayer 閱讀(2495) 評論(0)  編輯 收藏 引用 所屬分類: DB2
            統計值更新--runstats
            調整Buffer pool
            調整日志緩沖區大小
            應用程序堆大小
            排序堆大小和排序堆值
            代理程序的數目

            活動應用程序的最大數目
            頁清除程序的數目
            I/O服務器的數目
            編入組的提交數目


            統計信息更新

            當對SQL 查詢進行優化時,SQL 編譯器所做出的決定會受到優化器
            的數據庫內容模型的重大影響。
            優化器使用該數據模型來估計可以用于解決某個特定查詢的其它存取
            路徑的成本。
            數據模型中的關鍵元素是一組統計信息,該統計信息收集了有關數據
            庫中所包含的數據和系統目錄表中所存儲的數據的信息。這包括表、
            別名(nickname)、索引、列和用戶定義的函數(UDF)的統計信
            息。
            優化器根據這些統計信息決定最有效方法訪問數據的方法,數據統計
            信息中的變化會引起對存取方案的選擇發生變化。
            適時更新數據統計信息。

             

            統計信息更新

            適時更新數據統計信息。
            –當向表裝入數據并創建了合適的索引時。
            –當用REORG 實用程序重新組織表時。
            –當存在大量影響表及其索引的更新、刪除和插入操作時。(此處的“大量”可能意味
            著10% 到20% 的表和索引數據都受到了影響。)
            –在綁定性能至關重要的應用程序之前。
            –當預取數量發生變化時。
            只有當進行顯式的請求時,對象的統計信息才會在系統目錄表中被更新。更新
            部分或全部統計信息方法:
            –使用RUNSTATS(運行統計信息,run statistics)實用程序。
            –使用“reorgchk update statistics”命令。
            在使用RUNSTATS 之后需要重新綁定使用靜態SQL 的應用程序,使查詢優
            化器就可以選擇新統計信息所給出的最佳存取方案。但是,對于使用動態SQL
            的應用程序而言,沒必要進行重新綁定,因為語句的優化是根據統計信息在運
            行時進行的。


            reorgchk update statistics

            當您不完全知道所有表名或表名實在太多時,進行RUNSTATS 的最簡單方
            法就是使用“db2 reorgchk update statistics”命令。


            正確的腳本如下:

            db2 -v connect to DB_NAME

            db2 -v "select tbname, nleaf, nlevels, stats_timefrom sysibm.sysindexes“

            db2 -v reorgchk update statistics on table all

            db2 -v "select tbname, nleaf, nlevels, stats_timefrom sysibm.sysindexes“

            db2 -v terminate


            Runstats實用程序

            如果您知道表名并且想避免對大量表運行RUNSTATS 實用程序(因
            為這樣做可能要花很長時間),那么一次對一張表進行RUNSTATS
            更為可取。
            命令如下:


            db2 -v runstats on table TAB_NAME and indexes all

            這個命令將收集該表及其所有索引(基本級別)的統計信息。
            要查看是否對數據庫執行了RUNSTATS,一種快捷方法便是查詢一
            些系統目錄表。例如:


            db2 -v "select tbname, nleaf, nlevels, stats_timefrom
            sysibm.sysindexes"


            調整Bufferpool大小

            緩沖池是內存中的一塊存儲區域,用于臨時讀入和更改數據頁(含表行或索引
            項)。緩沖池的用途是為了提高數據庫系統的性能。
            缺省情況下,應用程序使用緩沖池IBMDEFAULTBP,它是在創建數據庫時創
            建的。當SYSCAT.BUFFERPOOLS 目錄表中該緩沖池的NPAGES 值為-1
            時,DB2 數據庫配置參數BUFFPAGE 控制著緩沖池的大小。
            可以增大所有數據庫的BUFFPAGE 值。


            db2 -v connect to DB_NAME

            db2 -v select * from syscat.bufferpools

            db2 -v alter bufferpool IBMDEFAULTBP size -1

            db2 -v connect reset

            db2 -v update db cfg for dbname using BUFFPAGE bigger_value

            db2 -v terminate

            要確定數據庫的緩沖池大小是否由BUFFPAGE 參數所決定,運行:


            db2 -v connect to DB_NAME

            db2 -v SELECT * from SYSCAT.BUFFERPOOLS

            db2 -v connect reset

            db2 -v terminate

            檢查結果。如果每個緩沖池都有一個為“-1”的NPAGES 值,那么緩沖池大小是
            由數據庫配置中的BUFFPAGE 參數控制的。


            調整Bufferpool大小(續)

            要確定緩沖池大小是否足夠大,請在運行應用程序時收集數據庫和/
            或緩沖池的快照。下面的腳本為您提供這些所需的信息:


            db2 -v update monitor switches using bufferpool on

            db2 -v get monitor switches

            --運行程序–

            db2 -v get snapshot for all databases > snap.out

            db2 -v get snapshot for dbm>> snap.out

            db2 -v get snapshot for all bufferpools>> snap.out

            db2 -v reset monitor all

            db2 -v terminate

            請確保您在斷開數據庫連接之前發出“db2 -v get snapshot”,否則,該
            數據庫停止運行,同時所有快照統計信息將會丟失。

             

            調整Bufferpool大小(續)

            在數據庫快照或緩沖池快照的快照輸出中,查找下列“logical reads”和“physical
            reads”,這樣就可以計算出緩沖池命中率,它可以幫助您調優緩沖池:


            --Related lines from a sample of bufferpoolsnapshots –

            Buffer pool data logical reads = 702033

            Buffer pool data physical reads = 0

            Buffer pool data writes = 414

            Buffer pool index logical reads = 168255

            Buffer pool index physical reads = 0

            按如下計算緩沖池命中率:


            (1 -((buffer pool data physical reads + buffer pool index physical reads)
            /(buffer pool data logical reads + pool index logical reads))) *100%

            這個計算考慮了緩沖池高速緩存的所有頁(索引和數據)。理想情況下,該比
            率應當超過95%,并盡可能接近100%。

            要提高緩沖池命中率,請嘗試下面這些方法:
            –增加緩沖池大小。如果您的機器上有足夠大的內存,請將BUFFPAGE 設置成
            40000 個頁(160 MB),或者等于機器總內存的10%。對于大型OLTP 數據庫,在
            保持系統穩定的同時為緩沖池留出盡可能多的內存。可以先嘗試使用1.6 GB 的內
            存,然后嘗試用更多內存。
            –考慮分配多個緩沖池,如果可能的話,為每個經常被訪問的大表所屬的表空間分配一
            個緩沖池,為一組小表分配一個緩沖池,然后嘗試一下使用不同大小的緩沖池以查看
            哪種組合會提供最佳性能。表空間的頁大小與緩沖池的頁大小一樣。

             

            調整Bufferpool大小(續)

            create db testdb

            --using codesetiso8859-1 territory US

            on /data/misserver/dbimages

            collate using identity

            dft_extent_sz8

            catalog tablespace managed by database

            using (device '/dev/rds01' 131072,

            device '/dev/rds02' 131072,

            device '/dev/rds03' 131072)

            extentsize 32 prefetchsize 96

            ;

            connect to testdb;

            create bufferpool databp size 25000 pagesize 32768;

            create bufferpool bp8k size 16 pagesize 8192;

            disconnect all;


            調整Bufferpool大小(續)

            create tablespace datatblsp pagesize 32K

            managed by database

            using (

            device '/dev/rdata0' 30720M ,

            device '/dev/rdata1' 30720M ,

            )

            extentsize 8 prefetchsize 48

            bufferpool databp;

             

            create tablespace idxtblsp pagesize 32K

            managed by database

            using (

            device '/dev/ridxa0' 6144M ,

            device '/dev/ridxa1' 6144M ,

            )

            extentsize 8 prefetchsize 48

            bufferpool databp;


            調整日志緩沖區

            LOGBUFSZ 是一個數據庫配置參數。它是用于日志緩沖區的參數。
            它允許您指定數據庫共享內存的大小以用作在將日志記錄寫到磁盤之
            前這些記錄的緩沖區。
            當下列事件之一發生時會將日志記錄寫到磁盤:
            –事務提交。
            –日志緩沖區已滿。
            –其它某個內部數據庫管理器事件發生時。
            將日志記錄存在緩沖區將產生更加有效的日志文件I/O。如果對專用
            的日志磁盤有相當多的讀操作,或者希望有較高的磁盤利用率,那么
            可以增加這個緩沖區的大小。
            當增加這個參數的值時,也要考慮DBHEAP 參數,日志緩沖區使用
            的空間由DBHEAP 參數所控制。

             

            調整日志緩沖區

            LOGBUFSZ 是一個數據庫配置參數。它是用于日志緩沖區的參數。
            它允許您指定數據庫共享內存的大小以用作在將日志記錄寫到磁盤之
            前這些記錄的緩沖區。
            當下列事件之一發生時會將日志記錄寫到磁盤:
            –事務提交。
            –日志緩沖區已滿。
            –其它某個內部數據庫管理器事件發生時。
            將日志記錄存在緩沖區將產生更加有效的日志文件I/O。如果對專用
            的日志磁盤有相當多的讀操作,或者希望有較高的磁盤利用率,那么
            可以增加這個緩沖區的大小。
            當增加這個參數的值時,也要考慮DBHEAP 參數,日志緩沖區使用
            的空間由DBHEAP 參數所控制。

             

            調整日志緩沖區(續)

            LOGBUFSZ的缺省值為8(4KB 頁),這對于OLTP 數據庫而言通
            常不夠大。LOGBUFSZ 的最佳值為128 個或256 個4KB 頁。
            可以使用下面這個命令來更改該參數值:


            db2 -v update database cfg for DB_NAME using LOGBUFSZ 256

            db2 -v terminate

            使用數據庫快照來確定LOGBUFSZ 參數的值是否為最佳值:


            Log pages read = 0

            Log pages written = 12644

            一般而言,“log pages read”和“log pages written”之比應當盡可能
            小。理想情況下,“log pages read”的值應為0,而“log pages written”
            的值應很大。當log pages read 太多時,意味著需要一個較大的
            LOGBUFSZ。

             

            調整應用程序堆大小(APPHEAPSZ)

            APPHEAPSZ 是一個數據庫配置參數,它定義了代表某個特定代理程
            序或子代理程序的數據庫管理器可以使用的私有內存頁數。
            在為應用程序初始化代理程序或子代理程序時分配堆。
            分配的堆大小是處理給予代理程序或子代理程序的請求所需的最小
            值。當代理程序或子代理程序需要更多的堆空間以處理較大的SQL
            語句時,數據庫管理器將按照需要分配內存,所分配的內存大小最大
            可達到該參數所指定的最大值。
            缺省值是128 個4KB 頁,更改命令是:


            db2 -v update db cfg for DB_NAME using applheapsz 256

            db2 -v terminate

            當應用程序接收到一個表明應用程序堆中存儲空間不夠的錯誤時,應
            該增加APPHEAPSZ 的值。

             

            排序堆大小(SORTHEAP)和排序堆閾值(SHEAPTHRES)

            SORTHEAP 是一個數據庫配置參數,它定義了私有排序所使用的私有內存頁的
            最大數目,或共享排序所使用的共享內存頁的最大數目。如果排序是私有排
            序,那么該參數影響代理程序私有內存。如果排序是共享排序,那么該參數影
            響數據庫的共享內存。每個排序都有單獨的由數據庫管理器按需分配的排序
            堆,在排序堆中對數據進行排序。如果由優化器來指導排序堆大小的分配,那
            么用優化器提供的信息來分配的排序堆的大小要小于由該參數所指定的排序堆
            大小。
            SHEAPTHRES 是一個數據庫管理器配置參數。私有和共享排序所使用內存的
            來源不一樣。共享排序內存區的大小是在第一次連接到數據庫時根據
            SHEAPTHRES 值以靜態方式預先確定的。私有排序內存區的大小是不受限制
            的。
            對于私有排序和共享排序,應用SHEAPTHRES 參數的方式不同:
            –對于私有排序,SHEAPTHRES 是對私有排序在任何給定的時間可以消耗的全部內
            存的實例級“軟”限制。當實例的總私有排序內存消耗量達到這一限制時,為其它進入
            的私有排序請求而分配的內存會大大減少。
            –對于共享排序,SHEAPTHRES 是對共享排序在任何給定的時間可以消耗的全部內
            存的數據庫級“硬”限制。當達到這一限制時,不允許有其它共享排序內存請求,直到
            總的共享內存消耗量回落到SHEAPTHRES 所指定的限制以下。

             

            排序堆大小(SORTHEAP)和排序堆閾值(SHEAPTHRES)

            要更改SORTHEAP 和SHEAPTHRES 的值,可以運行如下命令:


            db2 -v update db cfg for DB_NAME using SORTHEAP a_value

            db2 -v update dbmcfgusing SHEAPTHRES b_value

            db2 -v terminate

            SORTHEAP是針對單個數據庫的,SHEAPTHRES是針對數據庫例程
            的。

             

            排序堆大小(SORTHEAP)和排序堆閾值(SHEAPTHRES)

            OLTP 應用程序不應該執行大型排序,通常,SORTHEAP 大小的缺省值(256
            個4KB 頁)就足夠了。事實上,對于高并發性OLTP,您可能希望降低這個缺
            省值。
            當需要進一步研究時,可以發出下面這條命令:


            db2 -v update monitor switches using sort on

            然后,讓您的應用程序運行一會,然后輸入:

            db2 -v get snapshot for database on DBNAME

            看一下下面這個示例中的輸出:


            Total sort heap allocated = 0

            Total sorts = 1

            Total sort time (ms) = 0

            Sort overflows = 0

            Active sorts = 0

            Commit statements attempted = 1

            Rolback statements attempted = 0

            Dynamic statements attempted = 4

            Static statements attempted = 1

            Binds/precompilesattempted = 0


            排序堆大小(SORTHEAP)和排序堆閾值(SHEAPTHRES)

            根據該輸出,計算每個事務的排序數目、計算溢出了可用于排序的內
            存的那部分排序的百分比。


            SortsPerTransaction= (Total Sorts) / (Commit statements attempted +
            Rollback statements attempted)

            PercentSortOverflow= (Sort overflows * 100 ) / (Total sorts)

            如果SortsPerTransaction大于5,它可能表明每個事務的排序太多。
            如果PercentSortOverflow大于3%,那么可能發生了嚴重的、未曾預
            料到的大型排序。發生這種情況時,增加SORTHEAP 只會隱藏性能
            問題-卻無法修正它。這個問題的正確解決方案是通過添加正確的索
            引改進有問題的SQL 語句的存取方案。

             

            排序堆大小(SORTHEAP)和排序堆閾值(SHEAPTHRES)

            建議:

            使用合適的索引使排序堆的使用降到最低。
            當需要頻繁進行大型排序時,增加SORTHEAP 的值。
            如果增加SORTHEAP,請確定是否還需要調整數據庫管理器配置文件
            中的SHEAPTHRES 參數。
            優化器用排序堆大小來確定存取路徑。在更改該參數后請考慮重新綁
            定應用程序(使用REBIND PACKAGE 命令)。
            理想情況下,應當將排序堆閾值(SHEAPTHRES)參數合理地設置為
            在數據庫管理器實例中設置的SORTHEAP 參數最大值的倍數。該參
            數至少應當是實例中任何數據庫所定義的最大SORTHEAP 的兩倍。

             

            代理程序的數目(MAXAGENTS、NUM_POOLAGENTS 和NUM_INITAGENTS)

            這些是數據庫管理器配置參數。
            MAXAGENTS 參數表明在任何給定時間接受應用程序請求的數據庫管理器代理
            程序的最大數目。MAXAGENTS 的值應當至少是每個被并發地訪問的數據庫中
            的MAXAPPLS(并發應用程序最大數目)值的總和。如果數據庫的數量大于
            NUMDB 參數,那么最安全的方案就是使用NUMDB 和MAXAPPLS 最大值的乘
            積。
            NUM_POOLAGENTS 參數是用于評定您希望代理程序池增加到多大的準則。如
            果所創建的代理程序多于該參數值所指明的數目,那么當代理程序執行完自己當
            前的請求后將終止運行而不是返回給代理程序池。如果該參數的值為0,將按照
            需要創建代理程序,在代理程序執行完自己當前的請求后終止運行。
            要避免因在并發連接許多應用程序的OLTP 環境中頻繁創建和終止代理程序而產
            生的成本,請將NUM_POOLAGENTS 的值增加到接近MAXAGENTS 值。
            NUM_INITAGENTS 參數決定空閑代理程序的初始數量,這些代理程序是在
            DB2START 時在代理程序池中創建的。指定初始代理程序數目要合適。
            在大多數情況下,將MAXAGENTS 和NUM_POOLAGENTS 的值設置成略微大
            于并發應用程序連接的最大預計數目。NUM_INITAGENTS 保留為缺省值。

             

            代理程序的數目(MAXAGENTS、NUM_POOLAGENTS 和NUM_INITAGENTS)

            更改這些參數的命令:


            db2 -v update dbm cfg using MAXAGENTS a_value

            db2 -v update dbm cfg using NUM_POOLAGENTS b_value

            db2 -v update dbm cfg using NUM_INITAGENTS c_value

            db2 -v terminate


            代理程序的數目(MAXAGENTS、NUM_POOLAGENTS 和NUM_INITAGENTS)

            在運行期間的任何時候,您都可以使用下面這個命令來獲取數據庫管理
            器的快照數據:


            db2 -v get snapshot for dbm

            看一下下列輸出行:


            High water mark for agents registered = 4

            High water mark for agents waiting for a token = 0

            Agents registered = 4Agents waiting for a token = 0

            Idle agents = 0

            Agents assigned from pool = 5

            Agents created from empty pool = 4

            Agents stolen from another application = 0

            High water mark for coordinating agents = 4

            Max agents overflow = 0

            如果發現“Agents waiting for a token”或“Agents stolen from another
            application”不等于0,則可能需要增加MAXAGENTS 以允許數據庫管
            理器可以使用更多的代理程序。



            鎖(LOCKLIST、MAXLOCKS 和LOCKTIMEOUT)

            這些與鎖相關的控制都是數據庫配置參數。
            LOCKLIST 表明分配給鎖列表的存儲容量。每個數據庫都有一個鎖列表,鎖定
            是數據庫管理器用來控制多個應用程序并發訪問數據庫中數據的機制。行和表
            都可以被鎖定。根據對象是否還持有其它鎖,每把鎖需要32 個或64 個字節
            的鎖列表:
            –需要64 個字節來持有某個對象上的鎖,在這個對象上,沒有持有其它鎖。
            –需要32 個字節來記錄某個對象上的鎖,在這個對象上,已經持有一個鎖。
            MAXLOCKS 定義了應用程序持有的鎖列表的百分比,在數據庫管理器執行鎖
            升級之前必須填充該鎖列表。當一個應用程序所使用的鎖列表百分比達到
            MAXLOCKS 時,數據庫管理器會升級這些鎖,這意味著用表鎖代替行鎖,從
            而減少列表中鎖的數量。當任何一個應用程序所持有的鎖數量達到整個鎖列表
            大小的這個百分比時,對該應用程序所持有的鎖進行鎖升級。如果用一個表鎖
            替換這些行鎖,將不再會超出MAXLOCKS 值,那么鎖升級就會停止。否則,
            鎖升級就會一直進行,直到所持有的鎖列表百分比低于MAXLOCKS。
            MAXLOCKS 參數乘以MAXAPPLS 參數不能小于100。
            雖然升級過程本身并不用花很多時間,但是鎖定整個表(相對于鎖定個別行)
            降低了并發性,而且數據庫的整體性能可能會由于對受鎖升級影響的表的后續
            訪問而降低。

             

            鎖(LOCKLIST、MAXLOCKS 和LOCKTIMEOUT)

            使用下列步驟確定鎖列表所需的頁數:
            –計算鎖列表大小的下限:(512 * 32 * MAXAPPLS) / 4096,其中512 是
            每個應用程序平均所含鎖數量的估計值,32 是對象(已有一把鎖)上每
            把鎖所需的字節數。
            –計算鎖列表大小的上限:(512 * 64 * MAXAPPLS) / 4096,其中64 是某
            個對象上第一把鎖所需的字節數。
            –對于您的數據,估計可能具有的并發數,并根據您的預計為鎖列表選擇
            一個初始值,該值位于您計算出的上限和下限之間。
            使用數據庫系統監視器調優MAXLOCKS 值。
            設置MAXLOCKS 時,請考慮鎖列表的大小(LOCKLIST):
            –MAXLOCKS = 100 * (512 鎖/應用程序* 32 字節/鎖* 2) /
            (LOCKLIST * 4096 字節)
            –該樣本公式允許任何應用程序持有的鎖是平均數的兩倍。如果只有幾個
            應用程序并發地運行,則可以增大MAXLOCKS,因為在這些條件下鎖
            列表空間中不會有太多爭用。

             

            鎖(LOCKLIST、MAXLOCKS 和LOCKTIMEOUT)

            LOCKTIMEOUT 指定了應用程序為獲取鎖所等待的秒數。這有助于
            應用程序避免全局死鎖。
            如果將該參數設置成0,那么應用程序將不等待獲取鎖。在這種情形
            中,如果請求時沒有可用的鎖,那么應用程序立刻會接收到-911。
            如果將該參數設置成-1,那么將關閉鎖超時檢測。在這種情形中,
            應用程序將等待獲取鎖(如果請求時沒有可用的鎖),一直到被授
            予了鎖或出現死鎖為止。
            在聯機事務處理(OLTP)環境中,這個值從30 秒開始。在只進行
            查詢的環境中可以從一個更大的值開始。

             

            鎖(LOCKLIST、MAXLOCKS 和LOCKTIMEOUT)

            更改鎖參數的命令:


            db2 -v update db cfg for DB_NAME using LOCKLIST a_number

            db2 -v update db cfg for DB_NAME using MAXLOCKS b_number

            db2 -v update db cfg for DB_NAME using LOCKTIMEOUT c_number

            db2 -v terminate


            鎖(LOCKLIST、MAXLOCKS 和LOCKTIMEOUT)

            使用數據庫系統監視器來確定是否發生鎖升級,跟蹤應用程序(連接)遭遇鎖超時
            的次數,或者數據庫檢測到的所有已連接應用程序的超時情形。
            首先,運行下面這個命令以打開針對鎖的DB2 監視器:


            db2 -v update monitor switches using lock ondb2 -v terminate

            然后收集數據庫快照:


            db2 -v get snapshot for database on DB_NAME

            在快照輸出中,檢查下列各項:


            Locks held currently = 0

            Lock waits = 0

            Time database waited on locks (ms) = 0

            Lock list memory in use (Bytes) = 504

            Deadlocks detected = 0

            Lock escalations = 0

            Exclusive lock escalations = 0

            Agents currently waiting on locks = 0

            Lock Timeouts = 0

            Internal rollbacks due to deadlock = 0

            如果“Lock list memory in use (Bytes)”超過定義的LOCKLIST 大小的50%,那么就
            增加LOCKLIST 的數量。鎖升級、鎖超時和死鎖將表明系統或應用程序中存在某
            些潛在問題。
            鎖定問題通常表明應用程序中存在一些相當嚴重的并發性問題,在增大鎖列表參數
            的值之前應當解決這些問題。

             

            活動應用程序的最大數目(MAXAPPLS)

            MAXAPPLS 是一個數據庫配置參數。它指定了可以連接到數據庫的
            并發應用程序(本地和遠程)的最大數量。
            該參數值必須大于等于已連接應用程序的數量,加上這些相同的應用
            程序中完成兩階段提交或回滾過程中可能并發存在的數量的總和。
            在OLTP 應用中,請確保將MAXAPPLS 的值設置正確,以容納最多
            的并發用戶/連接。
            對于那些使用連接池的應用程序,可以將MAXAPPLS 的值設置成比
            連接池的大小大1 或2(這樣做只是為了以防需要調用命令行連接來
            同時做一些事情)。

             

            活動應用程序的最大數目(MAXAPPLS)

            更改MAXAPPLS 值的命令:


            db2 -v update db cfgfor DB_NAME using MAXAPPLS a_number

            db2 -v terminate

            當應用程序嘗試連接數據庫,但是連接到數據庫的應用程序數已經達
            到了MAXAPPLS 的值時,會向應用程序返回下面這個錯誤,表明連
            接到該數據庫的應用程序數已達到了最大值。


            SQL1040N The maximum number of applications is already
            connected to thedatabase. SQLSTATE=57030


            異步頁清除程序的數量(NUM_IOCLEANERS)

            NUM_IOCLEANERS 是一個數據庫配置參數,指定數據庫的異步頁
            清除程序的數目。在數據庫代理程序需要緩沖池中的空間之前,這些
            頁清除程序將緩沖池中已更改的頁寫到磁盤,這允許代理程序不必等
            待已更改頁被寫到磁盤就可以讀取新頁,提高應用系統性能。
            如果將該參數設置成0,則不啟動頁清除程序,結果,數據庫代理程
            序將緩沖池中的所有頁寫到磁盤。該參數會對存儲在多個物理存儲設
            備上的單個數據庫的性能產生顯著影響,因為在這種情況下其中某個
            設備極有可能處于空閑狀態。如果沒有配置頁清除程序,則應用程序
            可能會遇到不時發生的“日志已滿”情況。
            如果連接到數據庫的應用程序主要執行更新數據的事務,那么增加清
            除程序的數目會提高性能。
            增加頁清除程序的數量還會減少“軟”故障(比如斷電)的恢復時間,
            因為磁盤上數據庫的內容在任何給定時候都是比較新的。

             

            異步頁清除程序的數量(NUM_IOCLEANERS)

            設置該參數時要考慮的因素:
            –如果有多個事務針對數據庫運行,則將該參數的值設置在1 到該數據庫
            所使用的物理存儲器的數量之間。
            –至少將該參數的值設置成您系統上CPU 的數量。
            –在具有高更新事務率的環境下,可能需要配置較多的頁清除程序。
            –在具有大緩沖池的環境下,也可能需要配置較多的頁清除程序。

             

            異步頁清除程序的數量(NUM_IOCLEANERS)

            更改該參數的命令:


            db2 -v update db cfg for DB_NAME using NUM_IOCLEANERS a_number

            db2 -v terminate

            使用數據庫系統監視器,利用有關從緩沖池進行寫操作的快照數據(或
            事件監視器)信息來幫助您調優該配置參數。
            當使用快照和收集緩沖池的快照數據時,監控下列計數器:


            Buffer pool data writes = 0

            Asynchronous pool data page writes = 0

            Buffer pool index writes = 0

            Asynchronous pool index page writes = 0

            LSN Gap cleaner triggers = 0

            Dirty page steal cleaner triggers = 0

            Dirty page threshold cleaner triggers = 0


            異步頁清除程序的數量(NUM_IOCLEANERS)

            如果下面這兩個條件成立,減少NUM_IOCLEANERS:


            “Buffer pool data writes”約等于“Asynchronous pool data page writes”。

            “Buffer pool index writes”約等于“Asynchronous pool index page writes”。

            只要下面這兩個條件有一個成立,增加NUM_IOCLEANERS:


            “Buffer pool data writes”遠遠大于“Asynchronous pool data page writes”。

            “Buffer pool index writes”遠遠大于“Asynchronous pool index page writes”。

            Dirty page steal cleaner triggers 指出調用頁清除程序的次數,為了有更好的響應
            時間,該數值應當盡可能低。利用上面所示的計數器,可以使用下面的公式計算用
            該元素表示的所有清除程序調用的百分比:


            Dirty page steal cleaner triggers / (Dirty page steal cleaner triggers +
            Dirty page threshold cleaner triggers +
            LSN Gap cleaner triggers)

            如果該比率很高,則它可能表明您所定義的頁清除程序太少了。


            I/O 服務器的數目(NUM_IOSERVERS)

            該參數是一個數據庫配置參數,用于指定數據庫的I/O 服務器的數目。
            諸如備份和恢復之類的實用程序使用I/O 服務器代表數據庫代理程序執行
            預取I/O 和異步I/O。
            超過這個數量的預取和實用程序I/O 在任何時候都不能在數據庫中運行。
            在啟動I/O 操作時,I/O 服務器處于等待狀態。
            由于從數據庫代理程序直接調度非預取I/O,因此非預取I/O 不受
            NUM_IOSERVERS 約束。
            在OLTP 環境中,使用缺省值就可以。
            更改NUM_IOSERVERS參數的命令:


            db2 -v update db cfg for DB_NAME using NUM_IOSERVERS a_number

            db2 -v terminate


            編入組的提交數目(MINCOMMIT)

            MINCOMMIT 是數據庫配置參數,它讓您把將日志記錄寫到磁盤的工
            作一直延遲到執行了最小數量的提交為止。
            該延遲有助于減少與寫日志記錄相關的數據庫管理器開銷。這意味著
            當您針對數據庫運行多個應用程序并且在非常短的時間范圍內應用程
            序請求大量提交時可以提高性能。
            只有當該參數值大于1 并且當連接到數據庫的應用程序數量大于或等
            于該參數值時,才會發生這個提交分組。
            當執行提交分組時,應用程序提交請求會被掛起,直到時間過去1 秒
            或提交請求的數量等于該參數值。
            使用下面的命令更改MINCOMMIT 值:


            db2 -v update db cfg for DB_NAMEusing MINCOMMIT a_numberdb2 -v terminate


            編入組的提交數目(MINCOMMIT)

            MINCOMMIT 的缺省值為1。
            如果多個讀/寫應用程序通常請求并發數據庫提交,則從缺省值開始
            遞增該參數值,這將產生更有效率的日志文件I/O,因為使用日志文件
            I/O 的次數比較少,而每次使用日志文件I/O 時所寫的日志記錄比較
            多。
            如果您認為缺省值不夠大,可以從3 開始進行調整,在3 的附近嘗試
            以查看性能對工作負載的影響。
            可以對每秒鐘的事務量進行采樣,并調整該參數以適應每秒鐘的峰值
            事務量(或者采用它的某個較大的百分比)。適應峰值活動使得在重
            負載期間寫日志記錄的開銷減到了最低。
            如果增大MINCOMMIT,可能還需要增大LOGBUFSZ 參數以避免在
            這些重負載期間強制將已滿的日志緩沖區寫入磁盤。在這種情況下,
            LOGBUFSZ 應該等于:


            MINCOMMIT * (每個交易平均日志空間的使用量)


            編入組的提交數目(MINCOMMIT)

            計算每秒鐘的峰值事務數:


            通過采用典型一天中的監視器樣本,可以確定重負載時期。

            1. 在測量開始時,發出下面這個命令:

            –db2 -v reset monitor for database db_name(這不會使高水位的計數器復位。)


            2. 在測量完畢后,發出下面這個命令:

            –db2 -v get snapshot for database on db_name


            3. 使用以下輸出來計算事務的峰值:

            Last reset timestamp = 06-12-2001 14:51:43.786876

            Snapshot timestamp = 06-12-2001 14:56:27.787088

            Commit statements attempted = 1011

            Rolback statements attempted = 10

            Log space used by the database (Bytes) = 3990

            4. 讓totalTransactions等于“commit statements attempted”和“rollback statements
            attempted”的總和。

            5. 讓totalElapsedTime(單位為秒)等于“Last reset timestamp”和“Snapshot
            timestamp”的差。

            6. 如下計算每秒事務數:

            –NumOfTransPerSecond= totalTransactions/ totalElapsedTime

             

            編入組的提交數目(MINCOMMIT)

            計算每個事務所使用的日志空間:
            通過在一段時間內對一些事務使用抽樣技術,可以通過下面這個監視器元
            素:log_space_used(所使用的工作日志空間單元)計算出使用的日志
            空間的平均值。


            1. 在測量開始時使用下面這個命令將感興趣的數據庫的監視器復位:

            db2 -v reset monitor for database db_name.

            2. 在測量完畢后使用下面這個命令獲取快照:

            db2 -v get snapshot for database on db2_name.

            3. 使用下面這個公式計算出每個事務所使用的日志空間:

            LogSpaceUsedPerTrans= log_space_used/ totalTransactions

            女人高潮久久久叫人喷水| 国内精品久久久久久中文字幕| 久久精品国产WWW456C0M| 亚洲国产成人久久综合碰| 久久无码AV一区二区三区| 精品一区二区久久久久久久网站| 国产福利电影一区二区三区,免费久久久久久久精 | 无码国内精品久久人妻蜜桃| 91精品国产高清久久久久久io| 久久青青草原亚洲av无码| 欧美噜噜久久久XXX| 伊人色综合九久久天天蜜桃| 久久精品国产99国产电影网 | 99999久久久久久亚洲| 理论片午午伦夜理片久久| 国产欧美一区二区久久| 久久精品成人欧美大片| 久久91精品综合国产首页| 色综合久久久久无码专区| 久久久久亚洲爆乳少妇无| 国产精品久久自在自线观看| 久久久久99这里有精品10| 国产精品xxxx国产喷水亚洲国产精品无码久久一区 | 久久精品无码一区二区WWW| 精品99久久aaa一级毛片| 久久99国产综合精品| 中文字幕人妻色偷偷久久| 亚洲人成电影网站久久| 国内精品伊人久久久久影院对白 | 久久国产乱子伦精品免费强| 人妻无码αv中文字幕久久 | 免费精品久久天干天干| 亚洲Av无码国产情品久久| 久久天天躁狠狠躁夜夜av浪潮| 久久九九全国免费| 久久综合狠狠综合久久激情 | 久久A级毛片免费观看| 丁香狠狠色婷婷久久综合| 久久精品国产亚洲综合色 | 亚洲第一永久AV网站久久精品男人的天堂AV | 国产精品久久久久久久久久影院 |