三.每周维护过程
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.日常程序
0. free.sql
To verify free space in tablespaces
Minimum amount of free space
document your thresholds:
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/bianchengyuyan/）= m
SELECTtablespace_name,sum(blocks)asfree_blk,trunc(sum(bytes)/
(1024*1024))asfree_m,max(bytes)/(1024)asbig_chunk_k,count(*)asnum_chunks
FROMdba_free_spaceGROUPBYtablespace_name;
1. Space.sql
-- space.sql
-- To check free, pct_free, and allocated space within a tablespace
-- 11/24/98
SELECTtablespace_name,largest_free_chunk,nr_free_chunks,sum_alloc_blocks,sum_free_blocks
,to_char(100*sum_free_blocks/sum_alloc_blocks,'09.99')||'%'ASpct_free
FROM(SELECTtablespace_name,sum(blocks)ASsum_alloc_blocks
FROMdba_data_filesGROUPBYtablespace_name)
,(SELECTtablespace_nameASfs_ts_name
,max(blocks)ASlargest_free_chunk
,count(blocks)ASnr_free_chunks
,sum(blocks)ASsum_free_blocksFROMdba_free_space
GROUPBYtablespace_name)WHEREtablespace_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
SELECTe.owner,e.segment_type,e.segment_name,count(*)asnr_extents,s.max_extents
,to_char(sum(e.bytes)/(1024*1024),'999,999.90')asMB
FROMdba_extentse,dba_segmentss
WHEREe.segment_name=s.segment_name
GROUPBYe.owner,e.segment_type,e.segment_name,s.max_extents
HAVINGcount(*)&THRESHOLD
OR((s.max_extents-count(*))&&THRESHOLD)
ORDERBYcount(*)desc;
4. spacebound.sql
spacebound.sql
To identify space-bound objects. If all is well, no rows are returned.
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/bianchengyuyan/）f 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
SELECTa.table_name,a.next_extent,a.tablespace_name
FROMall_tablesa,
(SELECTtablespace_name,max(bytes)asbig_chunk
FROMdba_free_space
GROUPBYtablespace_name)f
WHEREf.tablespace_name=a.tablespace_name
ANDa.next_extentf.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
CREATETABLEutl_vol_facts(
table_nameVARCHAR2(30),
num_rowsNUMBER,
meas_dtDATE)
TABLESPACEplatab
STORAGE(
INITIAL128k
NEXT128k
PCTINCREASE0
MINEXTENTS1
MAXEXTENTSunlimited
)
/
--PublicSynonym
CREATEPUBLICSYNONYMutl_vol_factsFOR&OWNER..utl_vol_facts
/
Grants for UTL_VOL_FACTS
GRANTSELECTONutl_vol_factsTOpublic
