Oracle DBA 日常管理

  1<sid>/bdump 操   
  2作，并使其能回退到控制数据库的SID。   
  34\. 在提示下，使用UNIX 中的‘TAIL’命令查看alert_<sid>.log，或是   
  4用其他方式检查文件中最近时期的警告日志   
  55\. 如果以前出现过的一些ORA_ERRORS 又出现，将它记录到数据库   
  6恢复日志中并且仔细的研究它们，这个数据库恢复日志在〈FILE〉中   
  7C．查看DBSNMP 的运行情况   
  8检查每个被管理机器的‘DBSNMP’进程并将它们记录到日志中。   
  9在UNIX 中，在命令行中，键入 ps –ef | grep dbsnmp,将回看到2 个   
 10DBSNMP 进程在运行。如果没有，重启DBSNMP。   
 11D．查数据库备份是否成功   
 12E．检查备份的磁带文档是否成功   
 13F．检查对合理的性能来说是否有足够的资源   
 141\. 检查在表空间中有没有剩余空间。   
 15对每一个实例来说，检查在表空间中是否存在有剩余空间来满足当天   
 16的预期的需要。当数据库中已有的数据是稳定的，数据日增长的平均   
 17数也是可以计算出来，最小的剩余空间至少要能满足每天数据的增   
 18长。   
 19A） 运行‘FREE.SQL’来检查表空间的剩余空间。   
 20B） 运行‘SPACE.SQL’来检查表空间中的剩余空间百分率   
 212\. 检查回滚段   
 22回滚段的状态一般是在线的，除了一些为复杂工作准备的专用   
 23段，它一般状态是离线的。   
 24a) 每个数据库都有一个回滚段名字的列表。   
 25b) 你可以用V$ROLLSTAT 来查询在线或是离线的回滚段的现在状   
 26态.   
 27c) 对于所有回滚段的存储参数及名字， 可用   
 28DBA_ROLLBACK_SEGS 来查询。但是它不如V$ROLLSTAT   
 29准确。   
 303\. 识别出一些过分的增长   
 31查看数据库中超出资源或是增长速度过大的段，这些段的存储参   
 32数需要调整。   
 33a） 收集日数据大小的信息， 可以用   
 34‘ANALYZE5PCT.SQL’。如果你收集的是每晚的信息，   
 35则可跳过这一步。   
 36b） 检查当前的范围，可用‘NR.EXTENTS.SQL’。   
 37
 38
 39c） 查询当前表的大小信息。   
 40d） 查询当前索引大小的信息。   
 41e） 查询增长趋势。   
 424\. 确定空间的范围。   
 43如果范围空间对象的NEXT_EXTENT 比表空间所能提供的最大范   
 44围还要大，那么这将影响数据库的运行。如果我们找到了这个目标，可   
 45以用‘ALTER TABLESPACE COALESCE’调查它的位置，或加另外   
 46的数据文件。   
 47A）运行‘SPACEBOUND.SQL’。如果都是正常的，将不返回任何行。   
 485\. 回顾CPU，内存，网络，硬件资源论点的过程   
 49A）检查CPU的利用情况，进到x:\web\phase2\default.htm =&gt;system   
 50metrics=&gt;CPU 利用页，CPU 的最大限度为400，当CPU 的占用保持   
 51在350 以上有一段时间的话，我们就需要查看及研究出现的问题。   
 52G．将存档日志复制到备用数据库中   
 53如果有一个备用数据库，将适当的存档日志复制到备用数据库的期望   
 54位置，备用数据库中保存最近期的数据。   
 55F. 经常查阅DBA 用户手册   
 56如果有可能的话，要广泛的阅读，包括DBA 手册，行业杂志，新闻   
 57组或是邮件列表。   
 58二．晚间维护过程   
 59大部分的数据库产品将受益于每晚确定的检查进程的运行。   
 60A. 收集VOLUMETRIC 数据   
 611\. 分析计划和收集数据   
 62更准确的分析计算并保存结果。   
 63a） 如果你现在没有作这些的话，用‘MK VOLFACT.SQL’来创建测定体积的   
 64表。   
 65b） 收集晚间数据大小的信息，用‘ANALYZE COMP.SQL’。   
 66c） 收集统计结果，用‘POP VOL.SQL’。   
 67d） 在空闲的时候检查数据，可能的话，每周或每个月进行。   
 68我是用MS EXCEL 和ODBC 的联接来检查数据和图表的增长   
 69三．每周维护过程   
 70A． 查找被破坏的目标   
 711\. 对于每个给定表空间的对象来说，NEXT_EXTENT 的大小是相同的，如   
 7212/14/98，缺省的NEXT_EXTENT 的DATAHI 为1G，DATALO 为500MB，   
 73INDEXES 为256MB。   
 74A） 检查NEXT_EXTENT 的设置，可用‘NEXTEXT。SQL’。   
 75B） 检查已有的EXTENTS，可用‘EXISTEXT。SQL’。   
 762\. 所有的表都应该有唯一的主键   
 77a） 查看那些表没有主键，可用‘NO_PK.SQL’。   
 78b） 查找那些主键是没有发挥作用的，可用‘DIS_PK.SQL’。   
 79c） 所有作索引的主键都要是唯一的，可用‘ NONUPK。SQL’来检   
 80查。   
 813\. 所有的索引都要放到索引表空间中。运行‘MKREBUILD_IDX。SQL’   
 824\. 不同的环境之间的计划应该是同样的，特别是测试环境和成品环境之间的   
 83
 84
 85计划应该相同。   
 86a） 检查不同的2 个运行环境中的数据类型是否一致，可用   
 87‘DATATYPE.SQL’。   
 88b） 在2 个不同的实例中寻找对象的不同点， 可用   
 89‘OBJ_COORD.SQL’。   
 90c） 更好的做法是，使用一种工具，象寻求软件的计划管理器那样的   
 91工具。   
 92B． 查看是否有危害到安全策略的问题。   
 93C． 查看报错的SQL*NET 日志。   
 941\. 客户端的日志。   
 952\. 服务器端的日志。   
 96D．.将所有的警告日志存档   
 97E．.供应商的主页   
 981\. ORACLE 供应商   
 99http://www.oracle.com   
100http://technet.oracle.com   
101http://www.oracle.com/support   
102http://www.oramag.com   
1032\. Quest Software   
104http://www.quests.com   
1053\. Sun Microsystems   
106http://www.sun.com   
107四．月维护过程   
108A．查看对数据库会产生危害的增长速度   
1091\. 从以前的记录或报告中回顾段增长的变化以此来确定段增长带来危害   
110B． 回顾以前数据库优化性能的调整   
1111\. 回顾一般ORACLE 数据库的调整点，比较以前的报告来确定有害的发展   
112趋势。   
113C． 查看I/O 的屏颈问题   
1141\. 查看前期数据库文件的活动性，比较以前的输出来判断有可能导致屏颈   
115问题的趋势。   
116D． 回顾 FRAGMENTATION   
117E． 计划数据库将来的性能   
1181\. 比较ORACLE 和操作系统的CPU，内存，网络，及硬盘的利用率以此   
119来确定在近期将会有的一些资源争夺的趋势   
1202\. 当系统将超出范围时要把性能趋势当作服务水平的协议来看   
121F． 完成调整和维护工作   
1221.使修改满足避免系统资源的争夺的需要，这里面包括增加新资源或使预期   
123的停工。   
124五．附录   
125A. 日常程序   
126
127
128\--   
129\-- free.sql   
130\--   
131\--To verify free space in tablespaces   
132\--Minimum amount of free space   
133\--document your thresholds:   
134\--<tablespace_name> = <amount> m   
135\--   
136SELECT tablespace_name, sum ( blocks ) as free_blk , trunc ( sum ( bytes ) /   
137(1024*1024) ) as free_m, max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks   
138FROM dba_free_space   
139GROUP BY tablespace_name   
1401\. Space.sql   
141\--   
142\-- space.sql   
143\--   
144\-- To check free, pct_free, and allocated space within a tablespace   
145\--   
146\-- 11/24/98   
147SELECT tablespace_name, largest_free_chunk   
148, nr_free_chunks, sum_alloc_blocks, sum_free_blocks   
149, to_char(100*sum_free_blocks/sum_alloc_blocks, '09.99') || '%'   
150AS pct_free   
151FROM ( SELECT tablespace_name   
152, sum(blocks) AS sum_alloc_blocks   
153FROM dba_data_files   
154GROUP BY tablespace_name   
155)   
156, ( SELECT tablespace_name AS fs_ts_name   
157, max(blocks) AS largest_free_chunk   
158, count(blocks) AS nr_free_chunks   
159, sum(blocks) AS sum_free_blocks   
160FROM dba_free_space   
161GROUP BY tablespace_name )   
162WHERE tablespace_name = fs_ts_name   
1632\. analyze5pct.sql   
164\--   
165\-- analyze5pct.sql   
166\--   
167\-- To analyze tables and indexes quickly, using a 5% sample size   
168\-- (do not use this script if you are performing the overnight   
169
170
171\-- collection of volumetric data)   
172\--   
173\-- 11/30/98   
174BEGIN   
175dbms_utility.analyze_schema ( '&amp;OWNER', 'ESTIMATE', NULL, 5 ) ;   
176END ;   
177/   
1783\. nr_extents.sql   
179\--   
180\-- nr_extents.sql   
181\--   
182\-- To find out any object reaching <threshold>   
183\-- extents, and manually upgrade it to allow unlimited   
184\-- max_extents (thus only objects we *expect* to be big   
185\-- are allowed to become big)   
186\--   
187\-- 11/30/98   
188SELECT e.owner, e.segment_type , e.segment_name , count(*) as nr_extents ,   
189s.max_extents   
190, to_char ( sum ( e.bytes ) / ( 1024 * 1024 ) , '999,999.90') as MB   
191FROM dba_extents e , dba_segments s   
192WHERE e.segment_name = s.segment_name   
193GROUP BY e.owner, e.segment_type , e.segment_name , s.max_extents   
194HAVING count(*) &gt; &amp;THRESHOLD   
195OR ( ( s.max_extents - count(*) ) &lt; &amp;&amp;THRESHOLD )   
196ORDER BY count(*) desc   
1974\. spacebound.sql   
198\--   
199\-- spacebound.sql   
200\--   
201\-- To identify space-bound objects. If all is well, no rows are returned.   
202\-- If any space-bound objects are found, look at value of NEXT extent   
203\-- size to figure out what happened.   
204\-- Then use coalesce (alter tablespace <foo> coalesce;).   
205\-- Lastly, add another datafile to the tablespace if needed.   
206\--   
207\-- 11/30/98   
208SELECT a.table_name, a.next_extent, a.tablespace_name   
209FROM all_tables a,   
210( SELECT tablespace_name, max(bytes) as big_chunk   
211
212
213FROM dba_free_space   
214GROUP BY tablespace_name ) f   
215WHERE f.tablespace_name = a.tablespace_name   
216AND a.next_extent &gt; f.big_chunk   
217B. 每晚处理程序   
2181\. mk_volfact.sql   
219\--   
220\-- mk_volfact.sql (only run this once to set it up; do not run it nightly!)   
221\--   
222\-- -- Table UTL_VOL_FACTS   
223CREATE TABLE utl_vol_facts   
224(   
225table_name VARCHAR2(30),   
226num_rows NUMBER,   
227meas_dt DATE   
228)   
229TABLESPACE platab   
230STORAGE (   
231INITIAL 128k   
232NEXT 128k   
233PCTINCREASE 0   
234MINEXTENTS 1   
235MAXEXTENTS unlimited   
236)   
237/   
238\-- Public Synonym   
239CREATE PUBLIC SYNONYM utl_vol_facts FOR &amp;OWNER..utl_vol_facts   
240/   
241\-- Grants for UTL_VOL_FACTS   
242GRANT SELECT ON utl_vol_facts TO public   
243/   
2442\. analyze_comp.sql   
245\--   
246\-- analyze_comp.sql   
247\--   
248BEGIN   
249
250
251sys.dbms_utility.analyze_schema ( '&amp;OWNER','COMPUTE');   
252END ;   
253/   
2543\. pop_vol.sql   
255\--   
256\-- pop_vol.sql   
257\--   
258insert into utl_vol_facts   
259select table_name   
260, NVL ( num_rows, 0) as num_rows   
261, trunc ( last_analyzed ) as meas_dt   
262from all_tables -- or just user_tables   
263where owner in ('&amp;OWNER') -- or a comma-separated list of owners   
264/   
265commit   
266/   
267C. 每周处理程序   
2681\. nextext.sql   
269\--   
270\-- nextext.sql   
271\--   
272\-- To find tables that don't match the tablespace default for NEXT extent.   
273\-- The implicit rule here is that every table in a given tablespace should   
274\-- use the exact same value for NEXT, which should also be the tablespace's   
275\-- default value for NEXT.   
276\--   
277\-- This tells us what the setting for NEXT is for these objects today.   
278\--   
279\-- 11/30/98   
280SELECT segment_name, segment_type, ds.next_extent as Actual_Next   
281, dt.tablespace_name, dt.next_extent as Default_Next   
282FROM dba_tablespaces dt, dba_segments ds   
283WHERE dt.tablespace_name = ds.tablespace_name   
284AND dt.next_extent !=ds.next_extent   
285AND ds.owner = UPPER ( '&amp;OWNER' )   
286ORDER BY tablespace_name, segment_type, segment_name   
2872\. existext.sql   
288\--   
289\-- existext.sql   
290\--   
291
292
293\-- To check existing extents   
294\--   
295\-- This tells us how many of each object's extents differ in size from   
296\-- the tablespace's default size. If this report shows a lot of different   
297\-- sized extents, your free space is likely to become fragmented. If so,   
298\-- this tablespace is a candidate for reorganizing.   
299\--   
300\-- 12/15/98   
301SELECT segment_name, segment_type   
302, count(*) as nr_exts   
303, sum ( DECODE ( dx.bytes,dt.next_extent,0,1) ) as nr_illsized_exts   
304, dt.tablespace_name, dt.next_extent as dflt_ext_size   
305FROM dba_tablespaces dt, dba_extents dx   
306WHERE dt.tablespace_name = dx.tablespace_name   
307AND dx.owner = '&amp;OWNER'   
308GROUP BY segment_name, segment_type, dt.tablespace_name, dt.next_extent   
3093\. No_pk.sql   
310\--   
311\-- no_pk.sql   
312\--   
313\-- To find tables without PK constraint   
314\--   
315\-- 11/2/98   
316SELECT table_name   
317FROM all_tables   
318WHERE owner = '&amp;OWNER'   
319MINUS   
320SELECT table_name   
321FROM all_constraints   
322WHERE owner = '&amp;&amp;OWNER'   
323AND constraint_type = 'P'   
3244\. disPK.sql   
325\--   
326\-- disPK.sql   
327\--   
328\-- To find out which primary keys are disabled   
329\--   
330\-- 11/30/98   
331
332
333SELECT owner, constraint_name, table_name, status   
334FROM all_constraints   
335WHERE owner = '&amp;OWNER' AND status = 'DISABLED’ AND constraint_type = 'P'   
3365\. nonuPK.sql   
337\--   
338\-- nonuPK.sql   
339\--   
340\-- To find tables with nonunique PK indexes. Requires that PK names   
341\-- follow a naming convention. An alternative query follows that   
342\-- does not have this requirement, but runs more slowly.   
343\--   
344\-- 11/2/98   
345SELECT index_name, table_name, uniqueness   
346FROM all_indexes   
347WHERE index_name like '&amp;PKNAME%'   
348AND owner = '&amp;OWNER' AND uniqueness = 'NONUNIQUE'   
349SELECT c.constraint_name, i.tablespace_name, i.uniqueness   
350FROM all_constraints c , all_indexes i   
351WHERE c.owner = UPPER ( '&amp;OWNER' ) AND i.uniqueness = 'NONUNIQUE'   
352AND c.constraint_type = 'P' AND i.index_name = c.constraint_name   
3536\. mkrebuild_idx.sql   
354\--   
355\-- mkrebuild_idx.sql   
356\--   
357\-- Rebuild indexes to have correct storage parameters   
358\--   
359\-- 11/2/98   
360SELECT 'alter index ' || index_name || ' rebuild '   
361, 'tablespace INDEXES storage '   
362|| ' ( initial 256 K next 256 K pctincrease 0 ) ; '   
363FROM all_indexes   
364WHERE ( tablespace_name != 'INDEXES'   
365OR next_extent != ( 256 * 1024 )   
366)   
367AND owner = '&amp;OWNER'   
368/   
3697\. datatype.sql   
370
371
372\--   
373\-- datatype.sql   
374\--   
375\-- To check datatype consistency between two environments   
376\--   
377\-- 11/30/98   
378SELECT   
379table_name,   
380column_name,   
381data_type,   
382data_length,   
383data_precision,   
384data_scale,   
385nullable   
386FROM all_tab_columns -- first environment   
387WHERE owner = '&amp;OWNER'   
388MINUS   
389SELECT   
390table_name,   
391column_name,   
392data_type,   
393data_length,   
394data_precision,   
395data_scale,   
396nullable   
397FROM all_tab_columns@&amp;my_db_link -- second environment   
398WHERE owner = '&amp;OWNER2'   
399order by table_name, column_name   
4008\. obj_coord.sql   
401\--   
402\-- obj_coord.sql   
403\--   
404\-- To find out any difference in objects between two instances   
405\--   
406\-- 12/08/98   
407SELECT object_name, object_type   
408FROM user_objects   
409MINUS   
410SELECT object_name, object_type   
411FROM user_objects@&amp;my_db_link   
412
413
414六. 参考文献   
4151\. Loney, Kevin Oracle8 DBA Handbook   
4162\. Cook, David Database Management from Crisis to Confidence   
417[http://www.orapub.com/]   
4183\. Cox, Thomas B. The Database Administration Maturity Model</foo></threshold></amount></tablespace_name></sid></sid>