天天看點

不想做dba

        因為工作性質,讓我接觸到了許多IT領域内的東西,其中一個很讓人頭疼的就是oracle dba。

        如果僅是做oracle的應用開發,會很簡單,幾乎不用了解oracle的太多東西,可是現在要面對着整個應用系統的平台,不可避免的要對oracle的dba工作要有所了解,自己原來的那點資料庫知識可就遠遠不夠了。本來機關就有專門的dba,我這種半路出家的人對此不能,也不該去深入了解,但工作中會遇到很多意想不到的情況,不熟悉資料庫的一些管理技巧就沒法很好的完成工作,尤其是碰到系統出現故障的時候。找了本oracle的dba書看了看,發現根本不是一兩天能看懂的,最終束之高閣,還是在實踐中慢慢積累吧。下面是網上搜到的一篇文章,先摘到這裡,慢慢比對工作和消化。

Oracle DBA 日常管理 

===========================================================  

作者: shwenwen(http: // shwenwen.itpub.net)

發表于:  2007.12 . 18   16 : 47

分類: oracle資料庫 

出處: http: // shwenwen.itpub.net/post/34911/443025

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

目的:這篇文檔有很詳細的資料記錄着對一個甚至更多的 ORACLE 資料庫每天的,每月的, 

每年的運作的狀态的結果及檢查的結果,在文檔的附錄中你将會看到所有檢查,修改的 SQL 

和 PL / SQL 代碼。

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 . 周維護過程 

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

一.日維護過程 

A .檢視所有的執行個體是否已起 

确定資料庫是可用的,把每個執行個體寫入日志并且運作日報告或是運作測試 

檔案。當然有一些操作我們是希望它能自動運作的。 

可選擇執行:用 ORACLE 管理器中的‘ PROBE '  事件來檢視 

B .查找新的警告日志檔案 

1 . 聯接每一個操作管理系統 

2 . 使用‘ TELNET '  或是可比較程式 

3 . 對每一個管理執行個體,經常的執行 $ORACLE_BASE /< SID >/ bdump 操 

作,并使其能回退到控制資料庫的 SID 。 

4 . 在提示下,使用 UNIX 中的‘ TAIL  ' 指令檢視 alert_<SID>.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:webphase2default.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: 

--< tablespace_name >   =   < amount >  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  < threshold >  

--  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  < foo >  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