• <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-04-14 15:49 Prayer 閱讀(252) 評論(0)  編輯 收藏 引用 所屬分類: DB2
            供稿者:潘致遠
             
               
                 
             

            簡 介

            UNIX 和 Linux 用戶通常會檢查運行在其服務器上的進程,以執行問題分析及檢查服務器中消耗的資源。該信息不僅對執行問題和資源分析的管理員有用,而且對于那些開發高度可用性和故障轉移腳本(這些腳本監控 DB2 進程,以確定何時需要進行諸如數據庫重新啟動或服務器故障轉移之類的操作)的人也很有用。

            如果您正在使用 AIX,則可以使用命令 ps -ef 檢查進程。在 Solaris 和 HP-UX 上,ps -ef 將只顯示所有服務器端進程(例如:代理程序、記錄器、頁面清除程序和預取程序)的 db2sysc 進程(主 DB2 引擎進程)。如果您正在使用 Solaris 或 HP-UX,利用命令 /usr/ucb/ps -axw 您可以看到這些服務器端進程。這兩種版本的 ps 命令都可以在 Linux 上使用。

            當在運行 DB2 通用數據庫客戶機或服務器軟件的計算機上執行該命令時,您可能會看到列出了幾個 DB2 進程。本文的目的是記錄這些進程,并且解釋它們的作用以及它們何時可能會運行。盡管手冊 DB2 UDB V8 Administration Guide - Performance 的第 2 章記錄了大多數重要的進程,但該列表并不完整。通過閱讀本文,您將會理解每個 DB2 進程,當您看到那些進程時,您會開始明白 DB2 正在執行什么操作。

            請注意,DB2 在 Windows 上工作方式的實現與基于 Linux 和 UNIX 環境的實現稍有不同。在 Windows 中,只有一個進程(db2sysc),在該進程下的每個引擎分派單元(engine dispatchable unit,EDU)都被作為線程來實現。盡管本文討論的是進程,但是在 Windows 環境中應當把它們看成線程。通過 Windows 任務管理器(Task Manager),您將能夠看到每個實例的 db2sysc 進程(db2syscs.exe)。還將顯示其它 Windows 服務/進程,我們將在本文中解釋它們是什么。

            警告!請勿直接干預正常 DB2 環境中的 DB2 進程。在 Linux 或 UNIX 中利用 kill -9 命令殺死 DB2 進程可能會導致 DB2 出現異常行為。例如,殺死 db2sysc 進程將使整個 DB2 實例停止運行。本文旨在幫助您理解進程,而不是直接操作它們。

            為什么研究 DB2 進程?

            我們的個人經驗已表明這方面的知識很有價值,并且我們拜訪的客戶也向我們尋求這類信息。還不相信嗎?看一看下面的實際方案,并且親眼看看如何通過檢查在系統上運行的 DB2 進程來解決問題:

            方案 1:罕見的緩沖池頁面的清除

            一個運行電子商務(eCommerce)站點并使用 DB2 作為數據庫服務器的客戶報告說,在一整天里,數據庫對應用程序請求的響應時間會不時地變得很長。數據庫快照未顯示當時有任何異常發生。通過檢查服務器上進程在其中某一時刻的 CPU 使用情況,我們可以確定 I/O 清除程序(db2pclnr)消耗了超過 90% 的 CPU 時間。隨后通過研究 I/O 清除程序觸發器并對其進行相應的調優,我們消除了這種情況,使得電子商務站點每天可以處理的吞吐量提高了 50% 以上。

            方案 2:真相大白

            在拜訪 IBM 的一家業務合作伙伴以進行一些 DB2 性能調優工作時,我們碰到了查詢響應時間全面延長的問題。除了常規的程序之外,顯示應用程序列表的命令并未顯示當時有任何其它程序在運行。在獲得 DB2 快照之前,我們看了一下運行在 DB2 服務器上的 DB2 進程,發現 db2rebal 進程正在運行。當將某個容器添加到 DMS 表空間時,就會使用該進程執行數據的重新均衡工作。客戶“承認”,那天的早些時候他將一個容器添加到了包含 40 GB 表的表空間。一旦重新均衡工作完成,查詢響應時間恢復如初。

            揭開通知和診斷日志的廬山真面目

            管理通知日志和診斷日志(db2diag.log)是重要的工具,管理員可以使用這些工具來理解數據庫的活動和功能。這些日志通常包含有關 DB2 進程的信息,如下面取自

            db2diag.log 項的示例所示:

            2000-03-06-11.53.18.001160 Instance:myInst Node:000

            PID:78121(db2agent (TEST)) TID:352

            Appid:*LOCAL.payroll.000306140834

            lock_manager sqlplrq Probe:111 Database:SAMPLE

            DIA9999E An internal return code occurred. Report the following:

            "0xFFFFE10E".

            在該示例中,消息來自進程標識號為 78121 的進程。該進程的名稱是 db2agent,并與名為 TEST 的數據庫相連。理解進程的功能有助于您了解管理通知日志和 db2diag.log 中各項的意義。

            激情综合色综合久久综合| 久久综合精品国产二区无码| 成人国内精品久久久久影院| 99久久99这里只有免费费精品 | 99久久成人18免费网站| 办公室久久精品| 精品久久久无码21p发布 | 国产精品视频久久久| 久久久艹| 99精品国产在热久久| 伊人久久大香线蕉成人| 久久亚洲精品中文字幕三区| 久久综合日本熟妇| 久久99免费视频| 狠狠色丁香久久婷婷综合| 精品久久久久久国产三级| 成人久久免费网站| 伊人久久大香线蕉综合网站| 青青草原综合久久大伊人精品| 国产精品久久婷婷六月丁香| 狠狠色丁香久久综合五月| 丁香色欲久久久久久综合网| 99久久精品免费看国产一区二区三区 | 久久这里只有精品久久| 久久久久久久97| 三级韩国一区久久二区综合| 久久成人国产精品二三区| 无码伊人66久久大杳蕉网站谷歌 | 久久香综合精品久久伊人| 无码精品久久一区二区三区| 中文字幕成人精品久久不卡| 久久99精品久久久久子伦| 99久久国产综合精品女同图片| 欧美精品一区二区久久| 久久亚洲国产精品一区二区| jizzjizz国产精品久久| 国产午夜免费高清久久影院| 久久久久亚洲av无码专区 | 观看 国产综合久久久久鬼色 欧美 亚洲 一区二区 | 久久天天躁夜夜躁狠狠躁2022| 欧美午夜A∨大片久久 |