評論(0

DBA[資料庫管理員]

標籤: 暫無標籤

     DBA(英文是database administrator)即資料庫管理員,負責管理和維護資料庫系統的方方面面。

 

1 DBA[資料庫管理員] -個性特點

很多時候管理人員都忽視了DBA的個性特點,他們只關注DBA的技術能力。實際上,上面談到的每個職責都意味著:DBA需要跟各種人員打交道,這些人員可能是銷售商、用戶、開發人員或者管理人員。這說明:DBA必須具有下面的個性特點:

自信心
好奇心
堅韌的意志力
老練
自我驅動
注意細節

為什麼這些個性特點很重要呢?

我就有幾個缺乏自信心的部下,他們反覆問我一些事無巨細的問題,他們沒有信心哪怕做最小的決定。他們也缺乏工作的主動性。這對於初級DBA來說可能問題不太大,但對於那些高級DBA來說,如果他們缺乏自信心,他們又可以依賴誰幫他們決策呢?在DBA的面試中,即使你不能回答某個技術問題,你也要表現出足夠的自信心。最致命的不是不知道問題的答案,而是不知道從哪兒得到答案。

幾乎所有的資料庫系統都在不停地更新。但並不是所有的更新都有技術文檔。對於好的DBA來說,好奇心是必需的。沒有好奇心和求知慾的DBA總是等待有人告訴他們答案。而一個求知慾強的DBA將安裝最新版本的資料庫系統,並立即開始搜尋那些哪怕是細微的功能和性能上的差異和增強,從而改進自己的工作。應試時一個必然問及的問題是:你手頭有哪些參考資料?你如何使用它們?毫無疑問,如果你只回答了資料庫的文檔,或者你甚至沒有讀過他們,你的"股票市值"將大大下降。好奇心會驅使DBA們理解數據字典(Data Dictionary)、管理工具(Tools)或者其他支持包(Packages)

DBA常常會碰到棘手的問題。尋找答案是一個需要堅韌意志力、可以經受摔打的個性特點。我常常在一些討論組或者論壇上看到DBA們提出的問題,這些問題往往是提問者自己可以解決的,如果他們具有堅韌的個性特點,並努力尋求問題的答案。

自我驅動對每個人都是很重要的,對DBA尤其如此。DBA要能想辦法使問題出現,而不是等待問題的出現。自驅力強的DBA常常設法取得或者自己寫一些必要的腳本(Script)來監控包括數據表大小(Table Size)、表空間使用(Tablespace Usage)等項目,這些項目如果被忽視,他們將遇到麻煩。應試的時候DBA們常常被問及在PL/SQLSQL或者SQL*PLUS方面的經驗,這些問題將把你從從來沒有編寫過自己需要的腳本的那些DBA們區分開。

不用說和用戶,就是和程序員和管理人員打交道,也需要你足夠老練。一個一點不會處事的DBA不會為你做什麼好事,只會在你的部門點燃敵對情緒的烈火。老練是這樣一種能力,你勸告某個人到地府去,哈哈,最後這個人懷著渴望的心情去了。很多時候,開發者、管理者、用戶,他們會提出毫無道理的需求,DBA們需要老練地引導、修正它們的要求,說服他們。在應試時,你的應對就很能說明你是否老練。
最後說說注意細節,這種性格傾向非常重要。注意細節的DBA們衣著整潔,有自己的日程安排,在應試前對應聘的單位做過調查。注意細節的DBA們深入了解資料庫的內核,並能理解視圖、表之間的關係。

2 DBA[資料庫管理員] -等級

DBA的等級並不是很嚴格的。按照對資料庫的掌握情況,我簡單地分成三個等級:初級Primary、中級Intermediate和高級Senior

初級DBA又稱為DBBS,是英文Database Baby sitter的縮寫。初級DBA常常是兼職的,他們往往同時是程序員或者兼任其他的工作。初級DBA往往把個人簡歷寫得很棒,參與了很多和資料庫有關的項目或工作。但是,這些項目或者工作往往是:第三方軟體供應商已經安裝並配置了資料庫,他們只做一些監控的工作。他們能處理一些簡單的問題,但大多數時候他們嚮應用軟體供應商求救。初級DBA更喜歡圖形化的資料庫管理或者監控工具,他們喜歡Access這樣的桌面資料庫簡單易用,並把這些小型資料庫的經驗簡單地應用到大型資料庫相關的工作中。

初級DBA是最好區分的。而中級DBA和高級DBA就不太好區分。他們的差別在於經驗的不同和個性特點、能力方面的差異。中級DBA比較多,他們可以勝任高級DBA的大部分工作,包括:

資料庫安裝
資料庫配置和管理
許可權設置和安全管理
監控和性能調節
備份和恢復
解決一般的問題

中級DBA往往從業一年左右,熟悉某種操作系統環境下的資料庫。因為對中級DBA來講,Windows NTUnix是有很大差別的。中級DBASQL比較熟悉,他們自己購買了幾本資料庫方面的書籍,並深入鑽研。中級DBA往往同時兼任資料庫程序員,他們的工作對性能、穩定性、安全性的追求基本上不是很高,往往配合高級DBA做一些例行工作。

高級DBA在國內是非常少的。他們購買了太多的資料庫方面的英文資料,也許是托朋友從Amazon買的。相對於他們的報酬來講,買書的錢是很少的一個比例。高級DBA一般都熟悉很多種操作平台下的幾種大型資料庫。他們知道各種不同資料庫在不同環境下的優勢和劣勢,並能在資料庫平台和資料庫環境的選擇方面做出決策。他們一般通曉系統架構和資料庫設計,並能對資料庫進行各種級別的優化。高級DBA一般都配有助手,他們更偏向做決策和計劃。高級DBA往往在銀行業、保險業、在線交易等對穩定性、安全性、性能都要求比較高的關鍵業務處理領域大顯身手。

很多時候,是否取得資料庫專家認證證書並不是很重要。我知道很多資料庫廠商的培訓只要你去了都會獲得證書。有很多的公司提供商業化的培訓,他們的服務質量也有好有劣。所以證書並不是特別地有意義。

3 DBA[資料庫管理員] -幾種流行的資料庫系統

"容易"的資料庫系統-MicrosoftSQL Server

如果你打算做一個DBA,建議你選擇那些現在比較流行的資料庫系統。這意味著你將有更多的就業機會、交流和培訓機會,而且,流行自有流行的理由,你可以因此省心很多。當然,就業競爭壓力也比較大。一般的入門者選擇Microsoft SQL Server,這是非常適合中小型企業的資料庫系統,熟悉Access的讀者很容易就能初步使用Microsoft SQL Server,成為一個DBBSJ
Microsoft SQL Server 7.0
的報價,5用戶版1399美金,增加用戶時,127美金每用戶。

""的資料庫-無冕之王Oracle

如果你有機會接觸到Oracle,那可是個好機會。Oracle是目前最看好的資料庫廠商,由於其強大的功能和可配置、可管理能力,Oracle DBA的薪資一般比其他資料庫管理員的薪資要高。而且,Oracle在大中型企業的關鍵應用也更加普遍了。Oracle可以運行在Windows NTSun SolarisLinux等平台下。很多情況下要求你不僅僅熟悉NT,還要你熟悉Unix;而且Oracle不太友善的界面和成箱的Oracle產品資料可能也是一個障礙。
Oracle 8i
標準版的報價,如果運行在Windows NT,附帶JServerinterMedia,支持5個併發用戶,報價是3925美金每CPU。增加併發用戶時,785美金每用戶。增加附加的命名用戶時,392.5美金每用戶。

資料庫系統的貴族-IBM udb/DB2

作為30年資料庫研究的成果,IBM DB2確實稱得上"資料庫系統的貴族"。不管是小型商業系統,還是大的銀行系統,用DB2都是可以高枕無憂的。最近推出的新版DB2 6.1管理和調節工具更加卓越和便於使用。DB2可以運行在Intel架構上,也可以運行在IBMS/390大型計算機上。如果你所在的行業對IBM的機器特別地稱道,建議你學習IBM DB2

DB2有兩種版本:工作組版和企業版。工作組版999美元每伺服器,外加249美元每個併發用戶。而企業版是12500美元每個CPU,不限併發用戶數量。

Java為中心的資料庫-Sybase Adaptive Server Enterprise(ASE) 12.0

即將發布的Sybase ASE 12.0,直接面向Java程序員。這種以Java為中心的資料庫系統,為那些準備在Java平台下構建企業應用的企業來說,將是最好的選擇。但是ASE稱不上一個資料庫領域的領先者,儘管相對於它以前的版本已經改進很多,並支持多個CPU和更多的併發,還有很多的新的特性。但Sybase的風光似乎已經不再。

值得期盼的Informix Centaur

有時候"第一"只是意味著你的對手需要等待更長的時間去趕上你。這正是1997年創立的Informix所面臨的。Informix公司是率先將多媒體特性加入到關係資料庫系統的大型資料庫廠商之一。但是如今,IBMOracleSybase都已經跨越了這個概念。所以,Informix不得不尋求新的支撐來使自己區別於其他資料庫廠商。這就是Informix Centaur的目標。Informix Centaur結合了Informix Dynamic Server 7.3的對象-關係資料庫和Informix Universal Data Option 9.1,意在獲得更好的適應性和多媒體支持。詳情如何,我們拭目以待!

4 DBA[資料庫管理員] -薪資

有很多因素影響到你作為DBA的薪資:

你的經驗和能力所決定的DBA等級
你所熟悉的資料庫系統
你的個性特點和潛力

5 DBA[資料庫管理員] -職責

一、 一般監視
1. 監控資料庫的警告日誌。Alert.log,定期做備份刪除。
2. Linstener.log的監控,/network/admin/linstener.ora。
3. 重做日誌狀態監視,留意視圖v$log,v$logfile,該兩個視圖存儲重做日誌的信息。
4. 監控資料庫的日常會話情況。
5. 碎片、剩餘表空間監控,及時了解表空間的擴展情況、以及剩餘空間分佈情況,如果有連續的自由空間,手工合併。
6. 監控回滾段的使用情況。生產系統中,要做比較大的維護和資料庫結構更改時,用rbs_big01來做。
7. 監控擴展段是否存在不滿足擴展的表。
8. 監控臨時表空間。
9. 監視對象的修改。定期列出所有變化的對象。%BB%B6 target="_new" class=innerlink>文件,有初始化參數文件、用戶後台文件、系統後台文件

二、 對資料庫的備份監控和管理
資料庫的備份至關重要,對資料庫的備份策略要根據實際要求進行更改,數據的日常備份情況進行監控。由於我們使用了磁帶庫,所以要對legato備份軟體進行監控,同時也要對rman備份資料庫進行監控。

三、 規範資料庫用戶的管理
定期對管理員等重要用戶密碼進行修改。對於每一個項目,應該建立一個用戶。DBA應該和相應的項目管理人員或者是程序員溝通,確定怎樣建立相應的資料庫底層模型,最後由DBA統一管理,建立和維護。任何資料庫對象的更改,應該由DBA根據需求來操作。

四、 對SQL語句的書寫規範的要求
一個SQL語句,如果寫得不理想,對資料庫的影響是很大的。所以,每一個程序員或相應的工作人員在寫相應的SQL語句時,應該嚴格按照《SQL書寫規範》一文。最後要有DBA檢查才可以正式運行。

五、 DBA深層次要求
一個資料庫能否健康有效的運行,僅靠這些日常的維護還是不夠的,還應該致力於資料庫的更深一層次的管理和研究:資料庫本身的優化,開發上的性能優化;項目的合理化;安全化審計方面的工作;資料庫的底層建模研究、規劃設計;各種數據類型的處理;內部機制的研究;ora-600錯誤的研究、故障排除,等等很多值得探討的問題。
ORACLE資料庫管理員應按如下方式對Oracle資料庫系統做定期監控:
  (1). 每天對ORACLE資料庫的運行狀態,日誌文件,備份情況,數據
  庫的空間使用情況,系統資源的使用情況進行檢查,發現並解決
  問題。
  (2). 每周對資料庫對象的空間擴展情況,數據的增長情況進行監控,對資料庫做健康檢查,對資料庫對象的狀態做檢查。
  (3). 每月對錶和索引等進行Analyze,檢查表空間碎片,尋找資料庫
  性能調整的機會,進行資料庫性能調整,提出下一步空間管理
  計劃。對ORACLE資料庫狀態進行一次全面檢查。
  每天的工作
  (1).確認所有的INSTANCE狀態正常
  登陸到所有資料庫或常式,檢測ORACLE後台進程:
  $ps –ef|grep ora
  (2). 檢查文件系統的使用(剩餘空間)。如果文件系統的剩餘空間小於20%,需刪除不用的文件以釋放空間。
  $df –k
  (3). 檢查日誌文件和trace文件記錄alert和trace文件中的錯誤。
  連接到每個需管理的系統
  ? 使用』telnet』
  ? 對每個資料庫,cd 到bdump目錄,通常是$ORACLE_BASE//bdump
  ? 使用 Unix 『tail』命令來查看alert_.log文件
  ? 如果發現任何新的ORA- 錯誤,記錄並解決
  (4). 檢查資料庫當日備份的有效性。
  對RMAN備份方式:
  檢查第三方備份工具的備份日誌以確定備份是否成功
  對EXPORT備份方式:
  檢查exp日誌文件以確定備份是否成功
  對其他備份方式:
  檢查相應的日誌文件
  (5). 檢查數據文件的狀態記錄狀態不是「online」的數據文件,並做恢復。
  Select file_name from dba_data_files where status=』OFFLINE』
  (6). 檢查表空間的使用情況
  SELECT tablespace_name, max_m, count_blocks free_blk_cnt, sum_free_m,to_char(100*sum_free_m/sum_m, 『99.99『) || 『%『 AS pct_free
  FROM ( SELECT tablespace_name,sum(bytes)/1024/1024 AS sum_m FROM dba_data_files GROUP BY tablespace_name),
  ( SELECT tablespace_name AS fs_ts_name, max(bytes)/1024/1024 AS max_m, count(blocks) AS count_blocks, sum(bytes/1024/1024) AS sum_free_m FROM dba_free_space GROUP BY tablespace_name )
  WHERE tablespace_name = fs_ts_name
  (7). 檢查剩餘表空間
  SELECT tablespace_name, sum ( blocks ) as free_blk ,
  trunc ( sum ( bytes ) /(1024*1024) ) as free_m,
  max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks
  FROM dba_free_space GROUP BY tablespace_name;
  (8). 監控資料庫性能
  運行bstat/estat生成系統報告
  或者使用statspack收集統計數據
  (9). 檢查資料庫性能,記錄資料庫的cpu使用、IO、buffer命中率等等
  使用vmstat,iostat,glance,top等命令
  (10). 日常出現問題的處理。
  每周的工作
  (1). 控資料庫對象的空間擴展情況
  根據本周每天的檢查情況找到空間擴展很快的資料庫對象,並採取相
  應的措施
  -- 刪除歷史數據
  --- 擴表空間
  alter tablespace add datafile 『』 size
  --- 調整數據對象的存儲參數
  next extent
  pct_increase
  (2). 監控數據量的增長情況
  根據本周每天的檢查情況找到記錄數量增長很快的資料庫對象,並采
  取相應的措施
  -- 刪除歷史數據
  --- 擴表空間
  alter tablespace add datafile 『』 size
,   (3). 系統健康檢查
  檢查以下內容:
  init.ora
  controlfile
  redo Log File
  archiving
  sort area size
  tablespace(system,temporary,tablespace fragment)
  datafiles(autoextend,location)
  object(number of extent,next extent, index)
  rollback segment
  logging &tracing(alert.log,max_dump_file_size,sqlnet)
  (4). 檢查無效的資料庫對象
  SELECT owner, object_name, object_type FROM dba_objects
  WHERE status=』INVALID』。
  (5). 檢查不起作用的約束
  SELECT owner, constraint_name, table_name,
  constraint_type, status
  FROM dba_constraints
  WHERE status = 『DISABLED』 AND constraint_type = 『P『
  (6). 檢查無效的trigger
  SELECT owner, trigger_name, table_name, status
  FROM dba_triggers
  WHERE status = 『DISABLED』
  每月的工作
  (1). Analyze Tables/Indexes/Cluster
  analyze table estimate statistics sample 50 percent;
  (2). 檢查表空間碎片
  根據本月每周的檢查分析資料庫碎片情況,找到相應的解決方法
  (3). 尋找資料庫性能調整的機會
  比較每天對資料庫性能的監控報告,確定是否有必要對資料庫性能進 行調整
  (4). 資料庫性能調整
  如有必要,進行性能調整
  (5). 提出下一步空間管理計劃
  根據每周的監控,提出空間管理的改進方法
  Oracle DBA 日常管理
  目的:這篇文檔有很詳細的資料記錄著對一個甚至更多的ORACLE 資料庫每天的,每月的,
  每年的運行的狀態的結果及檢查的結果,在文檔的附錄中你將會看到所有檢查,修改的SQL
  和PL/SQL 代碼。
  目錄
  1.日常維護程序
  A. 檢查已起的所有實例
  B. 查找一些新的警告日誌
  C. 檢查DBSNMP 是否在運行
  D. 檢查資料庫備份是否正確
  E. 檢查備份到磁帶中的文件是否正確
  F. 檢查資料庫的性能是否正常合理,是否有足夠的空間和資源
  G. 將文檔日誌複製到備份的資料庫中
  H. 要常看DBA 用戶手冊
  2.晚間維護程序
  A.收集volumetric 的數據
  3.每周維護工作
  A. 查找那些破壞規則的OBJECT
  B. 查找是否有違反安全策略的問題
  C. 查看錯誤地方的SQL*NET 日誌
  D. 將所有的警告日誌存檔
  E. 經常訪問供應商的主頁
  4.月維護程序
  A. 查看對資料庫會產生危害的增長速度
  B. 回顧以前資料庫優化性能的調整
  C. 查看I/O 的屏頸問題
  D. 回顧FRAGMENTATION
  E. 將來的執行計劃
  F. 查看調整點和維護
  5.附錄
  A. 月維護過程
  B. 晚間維護過程
  C. 周維護過程
  6.參考文獻
  ----------------------------------------------------------------
  一.日維護過程
  A.查看所有的實例是否已起
  確定資料庫是可用的,把每個實例寫入日誌並且運行日報告或是運行測試
  文件。當然有一些操作我們是希望它能自動運行的。
  可選擇執行:用ORACLE 管理器中的『PROBE』事件來查看
  B.查找新的警告日誌文件
  1. 聯接每一個操作管理系統
  2. 使用『TELNET』或是可比較程序
  3. 對每一個管理實例,經常的執行$ORACLE_BASE//bdump 操
  作,並使其能回退到控制資料庫的SID。
  4. 在提示下,使用UNIX 中的『TAIL』命令查看alert_.log,或是
  用其他方式檢查文件中最近時期的警告日誌
  5. 如果以前出現過的一些ORA_ERRORS 又出現,將它記錄到資料庫
  恢復日誌中並且仔細的研究它們,這個資料庫恢復日誌在〈FILE〉中
  C.查看DBSNMP 的運行情況
  檢查每個被管理機器的『DBSNMP』進程並將它們記錄到日誌中。
  在UNIX 中,在命令行中,鍵入ps –ef | grep dbsnmp,將回看到2 個
  DBSNMP 進程在運行。如果沒有,重啟DBSNMP。
  D.查資料庫備份是否成功
  E.檢查備份的磁帶文檔是否成功
  F.檢查對合理的性能來說是否有足夠的資源
  1. 檢查在表空間中有沒有剩餘空間。
  對每一個實例來說,檢查在表空間中是否存在有剩餘空間來滿足當天
  的預期的需要。當資料庫中已有的數據是穩定的,數據日增長的平均
  數也是可以計算出來,最小的剩餘空間至少要能滿足每天數據的增 長。
  A) 運行『FREE.SQL』來檢查表空間的剩餘空間。
  B) 運行『SPACE.SQL』來檢查表空間中的剩餘空間百分率
  2. 檢查回滾段
  回滾段的狀態一般是在線的,除了一些為複雜工作準備的專用 段,它一般狀態是離線的。
  a) 每個資料庫都有一個回滾段名字的列表。
  b) 你可以用V$ROLLSTAT 來查詢在線或是離線的回滾段的現在狀 態.
  c) 對於所有回滾段的存儲參數及名字, 可用
  DBA_ROLLBACK_SEGS 來查詢。但是它不如V$ROLLSTAT 準確。
  3. 識別出一些過分的增長
  查看資料庫中超出資源或是增長速度過大的段,這些段的存儲參 數需要調整。
  a) 收集日數據大小的信息, 可以用
  『ANALYZE5PCT.SQL』。如果你收集的是每晚的信息, 則可跳過這一步。
  b) 檢查當前的範圍,可用『NR.EXTENTS.SQL』。
  c) 查詢當前表的大小信息。
  d) 查詢當前索引大小的信息。
  e) 查詢增長趨勢。
  4. 確定空間的範圍。
  如果範圍空間對象的NEXT_EXTENT 比表空間所能提供的最大范
  圍還要大,那麼這將影響資料庫的運行。如果我們找到了這個目標,可
  以用『ALTER TABLESPACE COALESCE』調查它的位置,或加另外 的數據文件。
  A)運行『SPACEBOUND.SQL』。如果都是正常的,將不返回任何行。
  5. 回顧CPU,內存,網路,硬體資源論點的過程
  A)檢查CPU的利用情況,進到x:.htm =>system
  metrics=>CPU 利用頁,CPU 的最大限度為400,當CPU 的佔用保持
  在350 以上有一段時間的話,我們就需要查看及研究出現的問題。
  G.將存檔日誌複製到備用資料庫中
  如果有一個備用資料庫,將適當的存檔日誌複製到備用資料庫的期望
  位置,備用資料庫中保存最近期的數據。
  H. 經常查閱DBA 用戶手冊
  如果有可能的話,要廣泛的閱讀,包括DBA 手冊,行業雜誌,新聞 組或是郵件列表。
  -------------------------------------------------------------
 
  二.晚間維護過程
  大部分的資料庫產品將受益於每晚確定的檢查進程的運行。
  A. 收集VOLUMETRIC 數據
  1. 分析計劃和收集數據
  更準確的分析計算並保存結果。
  a) 如果你現在沒有作這些的話,用『MK VOLFACT.SQL』來創建測定體積的 表。
  b) 收集晚間數據大小的信息,用『ANALYZE COMP.SQL』。
  c) 收集統計結果,用『POP VOL.SQL』。
  d) 在空閑的時候檢查數據,可能的話,每周或每個月進行。
  我是用MS EXCEL 和ODBC 的聯接來檢查數據和圖表的增長
  -------------------------------------------------------------
  三.每周維護過程
  A. 查找被破壞的目標
  1. 對於每個給定表空間的對象來說,NEXT_EXTENT 的大小是相同的,如
  12/14/98,預設的NEXT_EXTENT 的DATAHI 為1G,DATALO 為500MB,
  INDEXES 為256MB。
  A) 檢查NEXT_EXTENT 的設置,可用『NEXTEXT。SQL』。
  B) 檢查已有的EXTENTS,可用『EXISTEXT。SQL』。
  2. 所有的表都應該有唯一的主鍵
  a) 查看那些表沒有主鍵,可用『NO_PK.SQL』。
  b) 查找那些主鍵是沒有發揮作用的,可用『DIS_PK.SQL』。
  c) 所有作索引的主鍵都要是唯一的,可用『 NONUPK。SQL』來檢 查。
  3. 所有的索引都要放到索引表空間中。運行『MKrebuild_IDX。SQL』
  4. 不同的環境之間的計劃應該是同樣的,特別是測試環境和成品環境之間的 計劃應該相同。
  a) 檢查不同的2 個運行環境中的數據類型是否一致,可用
  『DATATYPE.SQL』。
  b) 在2 個不同的實例中尋找對象的不同點, 可用
  『OBJ_COORD.SQL』。
  c) 更好的做法是,使用一種工具,象尋求軟體的計劃管理器那樣的 工具。
  B. 查看是否有危害到安全策略的問題。
  C. 查看報錯的SQL*NET 日誌。
  1. 客戶端的日誌。
  2. 伺服器端的日誌。
  D..將所有的警告日誌存檔
  E..供應商的主頁
  1. ORACLE 供應商
  http://www.oracle.com
  http://technet.oracle.com
  http://www.oracle.com/support
  http://www.oramag.com
  2. Quest Software
  http://www.quests.com
  3. Sun Microsystems
  http://www.sun.com
  ----------------------------------------------------------------
  四.月維護過程
  A.查看對資料庫會產生危害的增長速度
  1. 從以前的記錄或報告中回顧段增長的變化以此來確定段增長帶來危害
  B. 回顧以前資料庫優化性能的調整
  1. 回顧一般ORACLE 資料庫的調整點,比較以前的報告來確定有害的發展 趨勢。
  C. 查看I/O 的屏頸問題
  1. 查看前期資料庫文件的活動性,比較以前的輸出來判斷有可能導致屏頸 問題的趨勢。
  D. 回顧FRAGMENTATION
  E. 計劃資料庫將來的性能
  1. 比較ORACLE 和操作系統的CPU,內存,網路,及硬碟的利用率以此
  來確定在近期將會有的一些資源爭奪的趨勢
  2. 當系統將超出範圍時要把性能趨勢當作服務水平的協議來看
  F. 完成調整和維護工作
  1.使修改滿足避免系統資源的爭奪的需要,這裡面包括增加新資源或使預期 的停工。
  ----------------------------------------------------------------
  五.附錄
  A. 日常程序
  -- free.sql
  --To verify free space in tablespaces
  --Minimum amount of free space
  --document your thresholds:
  -- = m
  SELECT tablespace_name, sum ( blocks ) as free_blk , trunc ( sum ( bytes ) /
  (1024*1024) ) as free_m, max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks
  FROM dba_free_space GROUP BY tablespace_name
  1. Space.sql
  -- space.sql
  -- To check free, pct_free, and allocated space within a tablespace
  -- 11/24/98
  SELECT tablespace_name, largest_free_chunk
  , nr_free_chunks, sum_alloc_blocks, sum_free_blocks
  , to_char(100*sum_free_blocks/sum_alloc_blocks, 『09.99『) || 『%『
  AS pct_free
  FROM ( SELECT tablespace_name , sum(blocks) AS sum_alloc_blocks
  FROM dba_data_files GROUP BY tablespace_name )
  , ( SELECT tablespace_name AS fs_ts_name
  , max(blocks) AS largest_free_chunk
  , count(blocks) AS nr_free_chunks
  , sum(blocks) AS sum_free_blocks FROM dba_free_space
  GROUP BY tablespace_name ) WHERE tablespace_name = fs_ts_name
  2. analyze5pct.sql
  -- analyze5pct.sql
  -- To analyze tables and indexes quickly, using a 5% sample size
  -- (do not use this script if you are performing the overnight
  -- collection of volumetric data)
  -- 11/30/98
  BEGIN
  dbms_utility.analyze_schema ( 『&OWNER『, 『ESTIMATE『, NULL, 5 ) ;
  END ;
  /
  3. nr_extents.sql
  -- nr_extents.sql
  -- To find out any object reaching
  -- extents, and manually upgrade it to allow unlimited
  -- max_extents (thus only objects we *expect* to be big
  -- are allowed to become big)
  -- 11/30/98
  SELECT e.owner, e.segment_type , e.segment_name , count(*) as nr_extents ,
  s.max_extents
  , to_char ( sum ( e.bytes ) / ( 1024 * 1024 ) , 『999,999.90『) as MB
  FROM dba_extents e , dba_segments s
  WHERE e.segment_name = s.segment_name
  GROUP BY e.owner, e.segment_type , e.segment_name , s.max_extents
  HAVING count(*) > &THRESHOLD
  OR ( ( s.max_extents - count(*) ) < &&THRESHOLD )
  ORDER BY count(*) desc
  4. spacebound.sql
  -- spacebound.sql
  -- To identify space-bound objects. If all is well, no rows are returned.
  -- If any space-bound objects are found, look at value of NEXT extent
  -- size to figure out what happened.
  -- Then use coalesce (alter tablespace coalesce .
  -- Lastly, add another datafile to the tablespace if needed.
  -- 11/30/98
  SELECT a.table_name, a.next_extent, a.tablespace_name
  FROM all_tables a,
  ( SELECT tablespace_name, max(bytes) as big_chunk
  FROM dba_free_space
  GROUP BY tablespace_name ) f
  WHERE f.tablespace_name = a.tablespace_name
  AND a.next_extent > f.big_chunk
  B. 每晚處理程序
  1. mk_volfact.sql
  -- mk_volfact.sql (only run this once to set it up; do not run it nightly!)
  -- -- Table UTL_VOL_FACTS
  CREATE TABLE utl_vol_facts (
  table_name VARCHAR2(30),
  num_rows NUMBER,
  meas_dt DATE )
  TABLESPACE platab
  STORAGE (
  INITIAL 128k
  NEXT 128k
  PCTINCREASE 0
  MINEXTENTS 1
  MAXEXTENTS unlimited
  )
  /
  -- Public synonym
  CREATE PUBLIC SYNONYM utl_vol_facts FOR &OWNER..utl_vol_facts
  /
  -- Grants for UTL_VOL_FACTS
  GRANT SELECT ON utl_vol_facts TO public
  /
  2. analyze_comp.sql
  --
  -- analyze_comp.sql
  --
  BEGIN
  sys.dbms_utility.analyze_schema ( 『&OWNER『,『COMPUTE『);
  END ;
  /
  3. pop_vol.sql
  --
  -- pop_vol.sql
  --
  insert into utl_vol_facts
  select table_name
  , nvl ( num_rows, 0) as num_rows
  , trunc ( last_analyzed ) as meas_dt
  from all_tables -- or just user_tables
  where owner in (『&OWNER『) -- or a comma-separated list of owners
  /
  commit
  /
   
  C. 每周處理程序
  1. nextext.sql
  --
  -- nextext.sql
  --
  -- To find tables that don『t match the tablespace default for NEXT extent.
  -- The implicit rule here is that every table in a given tablespace should
  -- use the exact same value for NEXT, which should also be the tablespace『s
  -- default value for NEXT.
  --
  -- This tells us what the setting for NEXT is for these objects today.
  --
  -- 11/30/98
  SELECT segment_name, segment_type, ds.next_extent as Actual_Next
  , dt.tablespace_name, dt.next_extent as Default_Next
  FROM dba_tablespaces dt, dba_segments ds
  WHERE dt.tablespace_name = ds.tablespace_name
  AND dt.next_extent !=ds.next_extent
  AND ds.owner = UPPER ( 『&OWNER『 )
  ORDER BY tablespace_name, segment_type, segment_name
  2. existext.sql
  --
  -- existext.sql
  --
  -- To check existing extents
  --
  -- This tells us how many of each object『s extents differ in size from
  -- the tablespace『s default size. If this report shows a lot of different
  -- sized extents, your free space is likely to become fragmented. If so,
  -- this tablespace is a candidate for reorganizing.
  --
  -- 12/15/98
  SELECT segment_name, segment_type
  , count(*) as nr_exts
  , sum ( DECODE ( dx.bytes,dt.next_extent,0,1) ) as nr_illsized_exts
  , dt.tablespace_name, dt.next_extent as dflt_ext_size
  FROM dba_tablespaces dt, dba_extents dx
  WHERE dt.tablespace_name = dx.tablespace_name
  AND dx.owner = 『&OWNER『
  GROUP BY segment_name, segment_type, dt.tablespace_name, dt.next_extent
  3. No_pk.sql
  --
  -- no_pk.sql
  --
  -- To find tables without PK constraint
  --
  -- 11/2/98
  SELECT table_name
  FROM all_tables
  WHERE owner = 『&OWNER『
  MINUS
  SELECT table_name
  FROM all_constraints
  WHERE owner = 『&&OWNER『
  AND constraint_type = 『P『
  4. disPK.sql
  --
  -- disPK.sql
  --
  -- To find out which primary keys are disabled
  --
  -- 11/30/98
  SELECT owner, constraint_name, table_name, status
  FROM all_constraints
  WHERE owner = 『&OWNER『 AND status = 『DISABLED』 AND constraint_type = 『P『
  5. nonuPK.sql
  --
  -- nonuPK.sql
  --
  -- To find tables with nonunique PK indexes. Requires that PK names
  -- follow a naming convention. An alternative query follows that
  -- does not have this requirement, but runs more slowly.
  --
  -- 11/2/98
  SELECT index_name, table_name, uniqueness
  FROM all_indexes
  WHERE index_name like 『&PKNAME%『
  AND owner = 『&OWNER『 AND uniqueness = 『NONUNIQUE『
  SELECT c.constraint_name, i.tablespace_name, i.uniqueness
  FROM all_constraints c , all_indexes i
  WHERE c.owner = UPPER ( 『&OWNER『 ) AND i.uniqueness = 『NONUNIQUE『
  AND c.constraint_type = 『P『 AND i.index_name = c.constraint_name
  6. mkrebuild_idx.sql
  --
  -- mkrebuild_idx.sql
  --
  -- Rebuild indexes to have correct storage parameters
  --
  -- 11/2/98
  SELECT 『alter index 『 || index_name || 『 rebuild 『
  , 『tablespace INDEXES storage 『
  || 『 ( initial 256 K next 256 K pctincrease 0 ) ; 『
  FROM all_indexes
  WHERE ( tablespace_name != 『INDEXES『
  OR next_extent != ( 256 * 1024 )
  )
  AND owner = 『&OWNER『
  /
  7. datatype.sql
  --
  -- datatype.sql
  --
  -- To check datatype consistency between two environments
  --
  --11/30/98
  SELECT
  table_name,
  column_name,
  data_type,
  data_length,
  data_precision,
  data_scale,
  nullable
  FROM all_tab_columns -- first environment
  WHERE owner = 『&OWNER『
  MINUS
  SELECT
  table_name,
  column_name,
  data_type,
  data_length,
  data_precision,
  data_scale,
  nullable
  FROM all_tab_columns@&my_db_link -- second environment
  WHERE owner = 『&OWNER2『
  order by table_name, column_name
  8. obj_coord.sql
  --
  -- obj_coord.sql
  --
  -- To find out any difference in objects between two instances
  --
  -- 12/08/98
  SELECT object_name, object_type
  FROM user_objects
  MINUS
  SELECT object_name, object_type
  FROM user_objects@&my_db_link
  六. 參考文獻
  1. Loney, Kevin Oracle8 DBA Handbook
  2. Cook, David Database Management from Crisis to Confidence
  【http://www.orapub.com/】
  3. Cox, Thomas B. The Database Administration Maturity Model

上一篇[索愛w810c]    下一篇 [資料庫管理員]

相關評論

同義詞:暫無同義詞