DBA-数据库管理员

DBA即数据库管理员，是一个负责管理和维护数据库服务器的人。数据库管理员负责全面管理和控制数据库系统。这个职位对不同的人意味着不同的意义。一个小的软件开发工作室和一个分工高度明细的大公司相比，DBA的职责来得更加宽泛一些。一个公司，不管它是自己开发应用软件，还是购买第三方的应用软件，只要涉及到数据库（有多少不涉及数据库的应用软件呢？数据库是商业的灵魂和大脑啊），就需要确定是否雇佣一个或几个DBA。知道DBA这个职位有哪些要求，对于企业内部这个职位的定义或者对于那些未来的DBA将是至关重要的。
一 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/SQL、SQL或者SQL*PLUS方面的经验，这些问题将把你从从来没有编写过自己需要的脚本的那些DBA们区分开。
　　不用说和用户，就是和程序员和管理人员打交道，也需要你足够老练。一个一点不会处事的DBA不会为你做什么好事，只会在你的部门点燃敌对情绪的烈火。老练是这样一种能力，你劝告某个人到地府去，哈哈，最后这个人怀着渴望的心情去了。很多时候，开发者、管理者、用户，他们会提出毫无道理的需求，DBA们需要老练地引导、修正它们的要求，说服他们。在应试时，你的应对就很能说明你是否老练。
最后说说注意细节，这种性格倾向非常重要。注意细节的DBA们衣着整洁，有自己的日程安排，在应试前对应聘的单位做过调查。注意细节的DBA们深入了解数据库的内核，并能理解视图、表之间的关系。
二 DBA的等级
　　DBA的等级并不是很严格的。按照对数据库的掌握情况，我简单地分成三个等级：初级Primary、中级Intermediate和高级Senior。
　　初级DBA又称为DBBS，是英文Database Baby Sitter的缩写。初级DBA常常是兼职的，他们往往同时是程序员或者兼任其他的工作。初级DBA往往把个人简历写得很棒，参与了很多和数据库有关的项目或工作。但是，这些项目或者工作往往是：第三方软件供应商已经安装并配置了数据库，他们只做一些监控的工作。他们能处理一些简单的问题，但大多数时候他们向应用软件供应商求救。初级DBA更喜欢图形化的数据库管理或者监控工具，他们喜欢Access这样的桌面数据库简单易用，并把这些小型数据库的经验简单地应用到大型数据库相关的工作中。
　　初级DBA是最好区分的。而中级DBA和高级DBA就不太好区分。他们的差别在于经验的不同和个性特点、能力方面的差异。中级DBA比较多，他们可以胜任高级DBA的大部分工作，包括：
数据库安装
数据库配置和管理
权限设置和安全管理
监控和性能调节
备份和恢复
解决一般的问题
　　中级DBA往往从业一年左右，熟悉某种操作系统环境下的数据库。因为对中级DBA来讲，Windows NT和Unix是有很大差别的。中级DBA对SQL比较熟悉，他们自己购买了几本数据库方面的书籍，并深入钻研。中级DBA往往同时兼任数据库程序员，他们的工作对性能、稳定性、安全性的追求基本上不是很高，往往配合高级DBA做一些例行工作。
　　高级DBA在国内是非常少的。他们购买了太多的数据库方面的英文资料，也许是托朋友从Amazon买的。相对于他们的报酬来讲，买书的钱是很少的一个比例。高级DBA一般都熟悉很多种操作平台下的几种大型数据库。他们知道各种不同数据库在不同环境下的优势和劣势，并能在数据库平台和数据库环境的选择方面做出决策。他们一般通晓系统架构和数据库设计，并能对数据库进行各种级别的优化。高级DBA一般都配有助手，他们更偏向做决策和计划。高级DBA往往在银行业、保险业、在线交易等对稳定性、安全性、性能都要求比较高的关键业务处理领域大显身手。
　　很多时候，是否取得数据库专家认证证书并不是很重要。我知道很多数据库厂商的培训只要你去了都会获得证书。有很多的公司提供商业化的培训，他们的服务质量也有好有劣。所以证书并不是特别地有意义。
三 几种流行的数据库系统
最”容易”的数据库系统-Microsoft SQL Server
　　如果你打算做一个DBA，建议你选择那些现在比较流行的数据库系统。这意味着你将有更多的就业机会、交流和培训机会，而且，流行自有流行的理由，你可以因此省心很多。当然，就业竞争压力也比较大。一般的入门者选择Microsoft SQL Server，这是非常适合中小型企业的数据库系统，熟悉Access的读者很容易就能初步使用Microsoft SQL Server，成为一个DBBS。 J
Microsoft SQL Server 7.0的报价，5用户版1399美金，增加用户时，127美金每用户。
最”难”的数据库-无冕之王Oracle
　　如果你有机会接触到Oracle，那可是个好机会。Oracle是目前最看好的数据库厂商，由于其强大的功能和可配置、可管理能力，Oracle DBA的薪资一般比其他数据库管理员的薪资要高。而且，Oracle在大中型企业的关键应用也更加普遍了。Oracle可以运行在Windows NT、Sun Solaris、Linux等平台下。很多情况下要求你不仅仅熟悉NT，还要你熟悉Unix；而且Oracle不太友善的界面和成箱的Oracle产品资料可能也是一个障碍。
oracle 8i标准版的报价，如果运行在Windows NT，附带JServer和interMedia，支持5个并发用户，报价是3925美金每CPU。增加并发用户时，785美金每用户。增加附加的命名用户时，392.5美金每用户。
数据库系统的贵族-IBM UDB/DB2
　　作为30年数据库研究的成果，IBM DB2确实称得上”数据库系统的贵族”。不管是小型商业系统，还是大的银行系统，用DB2都是可以高枕无忧的。最近推出的新版DB2 6.1， 管理和调节工具更加卓越和便于使用。DB2 可以运行在Intel架构上，也可以运行在IBM的S/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公司是率先将多媒体特性加入到关系数据库系统的大型数据库厂商之一。但是如今，IBM、Oracle、Sybase都已经跨越了这个概念。所以，Informix不得不寻求新的支撑来使自己区别于其他数据库厂商。这就是Informix Centaur的目标。Informix Centaur结合了Informix Dynamic Server 7.3的对象-关系数据库和Informix Universal Data Option 9.1，意在获得更好的适应性和多媒体支持。详情如何，我们拭目以待！
四 DBA的薪资
有很多因素影响到你作为DBA的薪资：
你的经验和能力所决定的DBA等级
你所熟悉的数据库系统
你的个性特点和潜力
五 数据库管理员的职责
一、 一般监视
1． 监控数据库的警告日志。Alert.log,定期做备份删除。
2． Linstener.log的监控，/network/admin/linstener.ora。
3． 重做日志状态监视，留意视图v$log，v$logfile，该两个视图存储重做日志的信息。
4． 监控数据库的日常会话情况。
5． 碎片、剩余表空间监控，及时了解表空间的扩展情况、以及剩余空间分布情况，如果有连续的自由空间，手工合并。
6． 监控回滚段的使用情况。生产系统中，要做比较大的维护和数据库结构更改时，用rbs_big01来做。
7． 监控扩展段是否存在不满足扩展的表。
8． 监控临时表空间。
9． 监视对象的修改。定期列出所有变化的对象。
10． 跟踪文件，有初始化参数文件、用户后台文件、系统后台文件
二、 对数据库的备份监控和管理
数据库的备份至关重要，对数据库的备份策略要根据实际要求进行更改，数据的日常备份情况进行监控。由于我们使用了磁带库，所以要对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

转载请注明：HANLEI'BLOG » DBA-数据库管理员