数据库的运维分享--一切从简
众所周知，数据库的运维既是个技术活儿也是个苦差事，不仅要有广阔的知识面，强大的技术能力，主机、存储、网络、操作系统最好样样精通，而且要会写SQL、shell、最好也会Java…同时，还需要拥有超强的耐心、谨慎的态度以及强健的体魄。
首先跟大家分享下我在运维过程二个案例1、我的第一个运维工具：ora
2008年刚进公司转做专职DBA，发现DBA竟然比以前干程序员还苦逼，通宵施工如家常便饭，而且有大量的重复工作。当时每个dba在共享服务器上都有自己的脚本集，每当应用侧有任何异动DBA们就找到自己的脚本集文件，然后替换条件复制粘贴执行，遇到没找到的就一顿狂敲键盘输SQL。
特别是在遇到大故障时，身后便会围着一群人，有各方领导，还有开发商，里外好几层。那可真是令人抓狂，因为做过几年的开发，我便想，为何不做一个shell程序，统一的入口，只要传入参数即可。于是我开发了我的第一款简单的Oracle运维工具，当时脚本集就叫ora。这个工具后来在运维团队不断被完善、扩散。至今该工具还在使用。
Ora脚本集的优点：
●让日常监控、维护操作等标准化。
●减少出错机会，提高效率。
●让DBA从容应对故障应急。
当然缺点也是明显的，正是有了这个工具，现在很多DBA们到了非驻场的服务现场就不会写SQL了。（怪我喽…）
2、智能HANG分析
在运维期间碰到系统常发生HANG，当数据库发生在争夺内核级别的资源时，比如Latch等，在11G之前oracle不能自动的检测并处理这种死锁。这时候需用Hanganalyze工具dump资源持有的相互关系。而这时候当二线DBA到场时已基本Hang死，或无法登陆，即使能做出dumptrace也无法反映真实原因。
另外分析trace定位堵塞源也要一定时间。所以分析出结果时往往应用已中断。既然hang住后要重启或终止掉所有前台发起数据库进程才能解决，何不在hang 开始初期就发起自动hang分析，识别引起hang的源头，记录相关信息，终止源头。
具体过程如下：
1．通过等待事件识别Hang症状
2．根据上一步骤判断触发搜集hanganalyze
3. 分析hang的dump信息，并确认是否存在hang。
4. 识别hang的源头记录相关信息并解决hang问题。
这是我编写的第二个程序（由于该程序已申请了专利，代码在此就不分享了）。
注：在Oracle 11g 11.2.0.2版本发布后，在其新特性中才出现了hang 管理器(Hang Manager)，
HM配置参数（开启后会根据配置终止实例或进程，请谨慎使用）：
_hang_resolution=TRUE 或者 FALSE。这个参数用于控制HM是否解决hang。
_hang_resolution_scope=OFF,PORCESS或者 INSTANCE。这个参数用于控制HM解决问题的范围。
_hang_detection=
小结
后面只要碰到能重复的、具有一定规则的工程，如长事务分析、二阶段事务（DX 锁）分析、自动生命周期管理、自动优化调度、巡检工具、离线巡检工具等等。如果你能把你日常需要做的工具化或自动化了，DBA还是苦差活么?那么就有更多时间研究更深层次技术。
我只是一个不安分的、会写程序的、“会偷懒”的DBA。
二、OraZ之路
至此越来越想做一个较为完整能帮助DBA的工具，该工具将运行SQL查询视图监控数据库的性能，识别数据库存在隐患。
在数据库的运维工作包括部署安装、性能优化、备份容灾、故障恢复、预防性巡检等工作，而这几个方面都存在不少重复度高、工作量大的任务，有的甚至还可以并行处理，这些都是该工具需解决目标。
1、运行需求?
Oraz是基于JDBC+SSH的JAVA应用，监测和分析数据库实例活动，系统要求是相当简单，只需jdbc能连接上数据库即可，该工具不会安装任何额外软件在你的服务器和终端上。
2、Oraz目前能做什么
?有关数据库和实例的一般信息。
?有关数据库结构和数据存储的详细信息: 表空间，数据库文件重做日志、归档的日志等。表空间/数据文件使用情况和可用空间
?内存信息: SGA/PGA 组件和大小，共享的池和缓冲区缓存统计数据。
?实例活动洞察-CPU消耗、等待事件、顶级的会话、顶级SQL语句等。
?会话信息-活动会话，排在前面的会话等。
?顶级的 SQL 语句和有关每个语句包括语句活动、执行统计信息、资源消耗、执行计划、版本等详细的信息。
?Oracle 数据库全系统统计信息、操作系统统计、指标和时间模型。3、DBA日常运维之巡检
规避系统风险运维自动化体系形成之前，我们DBA的日常例行工作在总工作量中占比较高，很消耗人力，员工疲于奔命但工作效率不高，也很容易出差错。自动化平台把我们的员工从繁琐的常规工作中解放出来，更专注于做架构优化类有创造性的工作，效率也有了进一步的改善.
每日检查是工程师上班的第一件事，通过脚本来进行，脚本输出仅提示异常部分，检查内容例如：
等，编写对应查询SQL，再通过JDBC访问远程服务器获取该值进行判断，如分析指定用户下是否存在失效主键：
SELECT owner, constraint_name, table_name, status
FROM all_constraints
WHERE owner = '&OWNER' AND status = 'DISABLED' AND constraint_type = 'P';
建立一系列巡检规则，实现如360式的一键体检方式：
上图列出体检结果，黄色需dba关注的，为不匹配预定检查项的，点击对应图标，可以看到具体体检结果。
通过该体检功能可快速检测数据库问题；目前该巡检暂不支持自定义，如需可以考虑建立可分享的自定义巡检项，这视大家的反馈情况而定。
4、实例活动洞察
实例活动洞察分析功能当前已同步发布更新，在很多情况下，当数据库发生性能问题的时候，我们是来不及收集足够的诊断信息，或者收到告警，甚至问题发生的时候DBA根本不在场。这给我们诊断问题带来很大的困难。那么在这种情况下，我们是否能在事后收集一些信息来分析问题的原因呢
首先我们看看Oracle重器oem，而Top Activity功能是使用最为频繁的功能点：
对于分析指定时段内的顶级消耗、会话等一目了然。上图中负载均以Average Active Sessions（AAS）平均活动会话进行计算。
每一个会话执行过程如下：
而每一个语句在执行过程又可以分解为不同活动时间:CPU执行中、等待IO或其它资源中，
即可分为CPU、IO、Wait
当有多个会话连接到库，并活动时：
通过时间片段来看同一时刻有多少会话处于活动状态，而该值为AAS值，以相同方法以sql语句维度统计该时刻活动，则找出顶级活动SQL，同样可以计算顶级活动program、user、会话等待。。
由于DBTime=某一时段时间总和，故顶级活动SQL即为TOPSQL，所以
AAS=DB Time / elapsed time (历时)，之所以该指标叫做黄金指标，通过AAS指标可以衡量一个系统的繁忙程度，这里有个CPU时间片概念，每一个CPU时间由操作系统分成CPU 时间片，然后CPU时间片轮询模式分配给线程或进程（视操作新系统而定），在最小单位CPU片段内整个系统允许的最大允许数为cpu个数，故通过比较AAS值与CPU之间可以衡量数据库繁忙度，与CPU数量关联分析：
●AAS/CPU_Count~= 0 非常空闲
●AAS/CPU_Count<=0.5没堵塞
●AAS /CPU_Count< 1部分进程已达100%，应用开始出现缓慢
●AAS/CPU_Count>或>> 1 出现性能问题或堵死、HANG状态
AAS在Oracle中OEM、ASH中的应用：
OEM中：
ASH：
从Oracle 数据库10g开始增加V$ACTIVE_SESSION_HISTORY视图，通过它可以容易地得知当前Instance的活动状态，主要是各个时刻系统都在等待哪些事件，通过对这些等待事件和相应等待次数的统计，就可以清晰地了解系统的历史工作负载特征和压力情况。此视图提供了大量宝贵的信息，而且不需要繁重的跟踪活动
ASH数据采集有mmon进程与mmnl进程负责：
快照由MMON和MMNL后台进程自动地每隔固定时间采样一次。
MMON进程负责：
?当某个测量值（metrics）超过了预设的限定值（threshold value）后提交警告
?创建新的 MMON 隶属进程（MMON slave process）来进行快照（snapshot）
?捕获最近修改过的 SQL 对象的统计信息
MMNL进程负责执行轻量级的且频率较高的后台任务，如捕获会话历史信息，测量值计算等。
AWR的采样工作由MMON进程每个1小时执行一次，ASH信息同样会被采样写出到AWR负载库中。ASH buffer根据被设计为保留1小时的信息，但很多时候这个内
存是不够的，当ASH buffer写满后，另外一个后台进程MMNL将会主动将ASH 信息写出。
ASH buffer大小
-按照公式Size of ASH Circular Buffer = Max [Min [ #CPUs * 2 MB, 5% of Shared Pool Size, 30MB ], 1MB ]计算，默认1M左右，该参数可以同隐含参数进行调整：
"_ash_size"隐含参数控制ash buffer的大小
ASH对应视图关系为：
通过按分钟从v$active_session_history视图采集数据，展示如下：
从上图可看到选择时段内TOPSQL为“cvn54b7yz0s8u”，占该时段内的19.5%，主要在等待IO资源。
三、OraZ后续计划开发或扩展功能
?表空间增加读写走势分析、碎片率分析
?计划作业执行详细信息和当前正在运行的作业。
?闪回去/快速恢复区使用情况和备份信息。
?深度体检
?进程跟踪（10046、10053）以及trace分析
?自动化优化分析等
?Alert日志查询图形化展示
深度体检功能预告
对于数据库、中间件设计，在系统上线前，针对应用系统的主要业务场景，应用要求，对数据库、中间件软硬件配置，系统参数，数据存储进行优化设计，包括但不限于如下内容：
数据库适用应用特点的最佳实践配置
性能及稳定性满足设计需求
系统与数据库特性及设置的最佳匹配
数据库版本对已知BUG的修复
●花5-10分钟发现系统存在的风险
●直接提供来自MOS推荐的专业解决方案
如果你所在部门有如运维自动化、标准化、可视化、一体化（集中化）这些需求建设，可以与邹老师联系，他们有AMP（自动化运维平台）和APM（应用性能管理），即使是已部署了IxM的Txxxx软件的企业依然会再使用他们的产品。
邹德裕
新炬网络首席专家，DBA+社群联合发起人，OraZ产品作者，轻维软件产品架构师。十年以上运维管理经验，Oracle OCM，精通Oracle9i、10g和11g数据库技术和Linux/Unix技术；对数据库系统架构具有深刻的理解，并在数据库诊断、故障排除、优化、架构设计等方面具有丰富的经验。
数据库日常维护工作
数据库日常维护工作是系统管理员的重要职责。其内容主要包括以下几个部分： 一、备份系统数据 SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。 1、备份数据库 每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。 除了按计划周期卸出数据库之外，还需在每次运行没有日志的操作后卸出数据库。例如：·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）； ·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，或使用了 WRITETEXT 命令。 卸出数据库的命令为： DUMP DATABASE database_name TO dump_device database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得设备的信息。 下面一条命令用来卸出数据库 my_db ： DUMP DATABASE my_db TO db_bk_dev 2、备份事务日志 如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单独备份日志。 备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。 备份事务日志的命令格式为： DUMP TRANsaction database_name [TO dump_device] [WITH TRUNCATE_ONL Y|WITH NO_LOG|WITH NO_TRUNCA TE] 其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH TRUNCA TE_ONL Y 或 WITH NO_LOG 子句时，才可以备份到设备。 注意：如果总是用 DUMP DA TEBASE （备份数据库及其日志），而不用 DUMP TRAN ，事务日志将不会刷新，而变得非常庞大。
IT运维部年度工作总结
IT运维部年度工作总结 一、年度部门工作回顾 即将到来的XX年对于IT运维部是崭新的一年。IT运维部是A中心新增的技术部门，成员来自原技术中心和A中心各个部门，经过近一年的磨合和成长，IT 运维部取得了良好的成绩。以下是IT运维部年度主要完成工作任务： 1．软件维护和开发 1)每日报表自动生成系统：4月初，IT运维部完成开发了每日报表自动生成系统， 以提高生产率，减少数据处理人员的人力投入。 2)人员管理系统：10月初，开发完成了人员管理系统第一期，为业务部门提供质 量控制的工具。 3)运营支撑系统：为了规范A中心技术工作内部管理，提高响应速度，进行精确 化管理，IT运维部开发了以下四套系统：
4)协助业务部门进行各种软件维护工作，包括…项目，报表的维护，等等。
2．平台系统维护 1)年度一级故障数据分析： 2)完善A中心平台系统维护规范： 3)加强系统平台主动维护工作，以防患于未然： 4)快速响应，及时处理一系列重大故障。 5)进行A中心平台产品调研工作。 6)知难而上，接手数据库维护工作： 7)维护人员培养工作： 3．终端维护 1)整理终端维护资料：。 2)搭建上网代理服务器： 3)优化域服务器：。 4)C网日常技术支持：为CDMA客服区域、马场区域的座席提供技术支持工作。4．数据处理和分析 1)配合s项目：。 2)配合业务部门进行多项数据分析工作：。 二、经验教训和相关建议 在这一年中，虽然取得了不错的工作成绩，但是也存在着一些问题和不足。 1)需加强与A中心其他部门互动，以更顺利开展相关工作。
2)需加强大项目的开发进度的管理能力。 在年度公司的转型和发展过程中，我们很欣喜地看到公司蓬勃发展的良好局势。在展望持续发展的远景的同时，也提出我们对公司的相关建议： 1)增加员工职业发展、培训和继续教育的机会。员工的发展是公司保持持续创新 和进步的重要因素。 三、2009年工作思路和工作计划 1、继续做好A中心各种技术支撑工作，各项工作都要比08年做的更好。 2、开发人员管理系统第二期：包括薪酬计算模块，话务统计系统模块等等。 3、加强团队的团结性、高效性的培养，提高员工的积极性。同时，加强团队内部 沟通工作，提高团队开发水平。完善管理制度与工作规范，锻炼培养管理团队，提高部门整体管理水平。 4、加强部门内部的培训力度，活跃IT运维部内部的学术氛围。 IT运维部
Oracle DBA 数据库日常维护手册 常用SQL 脚本
Oracle数据库日常维护 【版本整理日期：2011/02/26 】 版本整理人：1634068400@https://www.wendangku.net/doc/dc285502.html, 本文档包含以下内容： 1．Oracle数据库日常维护 2．Oracle DBA 常用管理脚本 3．Oracle DB 常用SQL 语句
/******************************************************** https://www.wendangku.net/doc/dc285502.html,(若跳转不成功，请复制到浏览器或联系Q) https://www.wendangku.net/doc/dc285502.html,/item.htm?id=7437120468Metalink Sharing ********************************************************/
在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。 一、Oracle警告日志文件监控 Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况： l数据库的启动、关闭，启动时的非缺省参数； l数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因； l对数据库进行的某些操作，如创建或删除表空间、增加数据文件； l数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA －600)
DBA 应该定期检查日志文件，根据日志中发现的问题及时进行处理 问题 处理 启动参数不对 检查初始化参数文件 因为检查点操作或归档操作没有完成造成重做日志不能切换 如果经常发生这样的情况，可以考虑增加重做日志文件组；想办法提高检查点 或归档操作的效率； 有人未经授权删除了表空间 检查数据库的安全问题，是否密码太简 单；如有必要，撤消某些用户的系统权 限 出现坏块 检查是否是硬件问题(如磁盘本生有坏 块)，如果不是，检查是那个数据库对象 出现了坏块，对这个对象进行重建 表空间不够 增加数据文件到相应的表空间 出现ORA-600 根据日志文件的内容查看相应的TRC 文件，如果是Oracle 的bug ，要及时打 上相应的补丁 二、数据库表空间使用情况监控（字典管理表空间） 数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA 应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。 select tablespace_name,
数据库维护工作介绍说明
数据库维护工作手册 文档编号：文档名称：编写：审核：批准: 批准日期：
目录 1概述 (4) 2数据库监控 (4) 2.1 数据库监控工作内容 (4) 2.2 数据库监控工作步骤 (4) 2.2.1 查看数据库日志 (4) 2.2.2 检查是否有失效的数据库对象 (5) 2.2.3 查看数据库剩余空间 (5) 2.2.4 重点表检查 (5) 2.2.5 查看数据库是否正常 (5) 2.2.6 死锁检查 (6) 2.2.7 监控SQL语句的执行 (6) 2.2.8 操作系统级检查 (6) 2.2.9 其他 (6) 3数据库维护 (6) 3.1 数据库维护工作内容 (6) 3.2 数据库维护工作事项 (6) 3.2.1 页面修复 (6) 3.2.2 数据库对象重建 (7) 3.2.3 碎片回收（数据重组） (7) 3.2.4 删除不用的数据 (7) 3.2.5 备份恢复 (7) 3.2.6 历史数据迁移 (7) 3.2.7 定期修改密码 (8) 3.2.8 删除掉不必要的用户 (8) 3.2.9 其他 (8) 4数据库管理常用SQL脚本 (8) 5日常维护和问题管理 (17) 5.1 目的 (17) 5.2 例行工作建议 (17) 5.3 相关填表说明 (17)
1概述 数据库的日常监控是使管理员及时了解系统异常的手段。大部分情况下，系统总是正常运行的。只有对正常情况的充分了解，才能通过对比正常情况发现异常情况。对于数据库的日常监控要有记录，文字记录或者电子文档保存。对于数据库异常进行分析，提出解决方案。 日常工作包括监控和维护两个部分。 此文档中关于数据库的运行命令示例主要针对于ORACLE数据库，但对于SYBASE数据库同样有参考价值，只要换用相对应的语句即可。 数据库监控 2数据库监控 数据库监控工作内容 制定和改进监控方案，编写监控脚本。 对于数据库进行日常监测，提交记录。 根据监测结果进行分析、预测，提交相应的系统改进建议方案。 数据库监控工作步骤 2.1.1查看数据库日志 数据库的日志上会有大量对于管理员有用的信息。ORACLE的Alert日志纪录了数据库系统所报的系统级错误信息，以及数据块失效等严重错误信息。错误信息的产生，会产生相应的跟踪文件，通过查看警告日志和跟踪文件可查找错误原因，对于发现的问题应及时解决和汇报。如： 1.表空间是否满，是否需要进行添加或者扩展。Alert文件中会显示有表块无法扩展 的提示。 2.表的块或者页面是否损坏。（往往这时alert文件中会显示ora-600的错误。） 3.数据库是否进行了异常操作。（如：drop tablespace等等）。 实用命令： ·报警日志文件（alert.log或alrt
it运维年终工作总结
it运维年终工作总结 作为整个企业的IT“管家”，首先应该对管理的资产情况了然于胸。比如说： 现在的IT规模是怎样的?网络链路总长是多少?网络设备和服务器的数量、类型各是什么?都是什么品牌的?还有每个服务器上运行的数据库、中间件的类型和数量等等，这些情况都应该一个不漏、有条理地梳理清楚。 搞清楚“有什么”的问题以后，还应该做个比较，目前的资产情况和历年相比有什么变化，是增加还是减少了，这些变动都体现在哪里?这些数据整理出来，一张清晰的“资产图”便被轻松地“绘制”出来了 二、业务构成及分析 一个企业里，最重要的应该就是业务系统的稳定运行和增效。所以IT运维管理员的总结里，必然不能缺少对业务系统保障情况的描述。 首先也应该勾勒出“业务”的大体形象：目前我们所有的业务系统有哪些?哪些是核心的业务，它们在解决何种问题，为用户提供了哪些服务?这些业务又运行在哪些服务器上，它们的运行状态如何…?这样我们先直观地把“业务系统”介绍给大家。 接下来我们可以深入地去剖析一下这些业务的运行状况，比如：我们的业务系统一年中平均每月主干链路的总流量达到了多少?将这些业务流量排名，前几位的是哪些?这些高流量的业务有多少人次在
访问?这些业务的平均无故障运行时间是多少?根据其设计，这些业务的可用性指标达到多少?是远未达到使用预设，差一些到满负荷，还是已经超负荷…等等。还有“变化”的视角是应该一直具备的，还需要与往年比，哪些业务是新增的，这些新增业务的使用情况如何，是用得较多还是较少? 三、事件处理情况 对一年中所做的事件处理情况进行汇总。你是否能说清楚IT部门这一年处理的事件数量有多少?这些事件分类有哪些?哪些是重大事件?这一年里产生过哪些重大的事件?这些重大事件对整个IT系统的影响是什么?是否针对此进行过全面的分析，并给到过改进的意见?采取了哪些措施保障了核心业务的SLA?这些数据也有助于对全年的运维工作进行了解。 四、未来工作开展建议 一份年终总结，除了要说清楚这一年发生的事儿，还应该能对下一年乃至未来几年的工作开展提供客观依据。并且作为一个合格的IT运维管理员，眼界应该更宽一些，除了着眼于本职工作，也应该不断地关注业界的新技术、新趋势，并去分析这些新技术对本企业的IT规划是否会产生影响，可能产生的影响又是什么?结合之前对业务使用情况的统计和分析，你就可以为决策者提供出一些更有意义的信息和建议：未来企业上马一些什么样的IT业务能为企业可持续发展带来先机，哪些IT系统需要改进以满足未来不断增长的需要等等。
it运维服务工作总结
It运维服务工作总结 至2010年10月底，0000000000000000000有限公司在0000000000000000公司的运维又届满一年的时间了。在这为期一年的运维工作当中，xxxx的业务飞速发展，设备数量不断增加，人员的技术水平和业务知识有了显著的提升。我们的队伍在技术水平和管理经验上也有了本质的提高。 1. xxxx 2. 3. 和解决故障的效率；通过制定有效的安全机制和培训，健全了xxxx信息外包人员安全机制；通过保密制度的培训使运维人员能够树立自觉维护xxxx的信息安全防范意识；通过客户服务意识的培训提高了客户的满意度。 二、吸收先进经验，保质保量的完成运维的各项任务： 运维期内主机、服务器、网络和桌面均没有发生严重的生产安全事故，对于一
些潜在的威胁也都在得到信息技术部门的批示下，审慎周密的完成了整改工作。运用先进的技术和经验提高劳动效率和运维工作质量： 1.运用先进的运维工具提高劳动效率。通过监控软件随时保持信息的及时性、可控性，一旦发生问题可以迅速定位和修复。 2.经过信息技术部指导，我们在运维工作中大量了采用WEB2.0技术。使我们在高效完成运维工作的情况下，为xxxx节约了大量的费用投入。 3. 息。 1. 2. 3. 我们一方面做好运维工作的情况下，另一方面派出部分或全部人员协助信息技术部的各项工作，以弥补其人力不足的状况； 4.对于机房的升级改造过程中积极配合，全程派员监理施工过程，及时出具各种施工方案和设计资料。施工完成后及时完善各类图表的变更、标识。 5.配合行政部门做好资产管理工作，对于资产管理系统派出专门人员参与学习，
Oracle数据库日常维护手册
Oracle数据库日常维护手册 在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。 一、Oracle警告日志文件监控 Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况: ●数据库的启动、关闭，启动时的非缺省参数; ●数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因; ●对数据库进行的某些操作，如创建或删除表空间、增加数据文件; ●数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA-600) DBA应该定期检查日志文件，根据日志中发现的问题及时进行处理 问题处理 启动参数不对检查初始化参数文件 因为检查点操作或归档操作没有完成造成重做日志不能切换如果经常发生这样的情况，可以考虑增加重做日志文件组;想办法提高检查点或归档操作的效率; 有人未经授权删除了表空间检查数据库的安全问题，是否密码太简单;如有必要，撤消某些用户的系统权限 出现坏块检查是否是硬件问题(如磁盘本生有坏块)，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建 表空间不够增加数据文件到相应的表空间 出现ORA-600根据日志文件的内容查看相应的TRC文件，如果是Oracle的bug，要及时打上相应的补丁 二、数据库表空间使用情况监控(字典管理表空间)
数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。 select tablespace_name, count(*) chunks , max(bytes/1024/1024) max_chunk from dba_free_space group by tablespace_name; 个人收集整理 上面的SQL列出了数据库中每个表空间的空闲块情况,如下所示: TABLESPACE_NAME CHUNKS MAX_CHUNK -------------------- ---------- ---------- INDX 1 57.9921875 RBS 3 490.992188 RMAN_TS 1 16.515625 SYSTEM 1 207.296875 TEMP 20 70.8046875 TOOLS 1 11.8359375 USERS 67 71.3671875个人收集整理 其中，CHUNKS列表示表空间中有多少可用的空闲块(每个空闲块是由一些连续的Oracle 数据块组成)，如果这样的空闲块过多，比如平均到每个数据文件上超过了100个，那么该表空间的碎片状况就比较严重了，可以尝试用以下的SQL命令进行表空间相邻碎片的接合: alter tablespace 表空间名 coalesce; 然后再执行查看表空间碎片的SQL语句，看表空间的碎片有没有减少。如果没有效果，并且表空间的碎片已经严重影响到了数据库的运行，则考虑对该表空间进行重建。 MAX_CHUNK列的结果是表空间上最大的可用块大小，如果该表空间上的对象所需分配的空间(NEXT值)大于可用块的大小的话，就会提示ORA-1652、ORA-1653、ORA-1654的错误信息，DBA应该及时对表空间的空间进行扩充，以避免这些错误发生。 对表空间的扩充对表空间的数据文件大小进行扩展，或向表空间增加数据文件，具体操作见“存储管理”部份。 三、查看数据库的连接情况
MySQL数据库运维
MySQL数据库运维 MySQL数据库作为世界上最流行的开源数据库，以简单、易用、开源等特点，收到互联网行业的推崇。随着去IOE运动的如火如荼，MySQL数据库已经深入到传统行业，大有改变行业格局。而与此同时，MySQL数据库规模成倍的增长，如何快速定位问题，解决问题？如何规模化、自动化运维？如何进行优化，提高MySQL数据库的性能？如何架构部署MySQL集群、架构跨IDC的分布式MySQL集群？如何实现MySQL数据库的HA？将在本课程中跟大家分享。 课程大纲： 第1课机器选型、系统规划 机器选型 业务评估--根据业务进行评估，转化为机器资源需求。 SSD vs HDD--熟悉SSD和HDD的架构设计，了解SSD的发展趋势。 成本评估--通过成本评估，选择合适机型。 系统规划 文件系统规划--根据MySQL的特点，规划文件系统，IO调度。 数据库配置--根据IO写入特点，配置MySQL数据库。 第2课安装部署 源码编译--源码编译安装操作处理方法。
功能定制--定制mysql的Server限流，SQL限流，并行复制，ThreadPool功能。 规模化部署--了解打包、配置模板、数据目录等统一管理方法。 版本升级--跨版本升级如何做到安全可靠？ 资源池管理--资源管理、实例分配、资源利用率等。 第3课压力测试 TPC-C模型--了解TPC-C模型设计。 测试工具--熟悉常用的数据库测试工具。 基准测试--介绍只读测试、TPCC测试、读写比测试方法。 定制测试--介绍定制sql模型、定制测试工具、流量加速回放等方法。 评估标准--介绍评估测试结果的基本参数标准。 第4课性能优化 参数优化--详细介绍与MySQL数据库息息相关的性能参数和优化方法。 性能优化--详细介绍系统层优化和MySQL功能优化。（NUMA、MALLOC等） 第5课字符集和权限安全 字符集 常见问题--介绍字符集乱码的常见问题以及解决方法。 注意事项--介绍字符集设置的注意事项，以及如何规避。 权限安全
IT部运维年终工作总结
2016年XX科技IT部运维年终工作总结 2016年，在XX公司及XX科技领导的正确带领及对公司信息化建设的高度重视下，经过it部门全员长期努力，公司信息化工作取得了明显的成效。现将2016年it运维工作总结如下： 第一部分：取得的成绩 （一）建立企业机房 为了深入贯彻落实公司关于建设“规范化”和“信息化”的决策精神，不断提高管理效率，提高资源使用效率，统一管理网络运营设备。 在公司领导XX的率领下，在各部门同事的配合下，XX科技机房建设随着新办公地址的装修正式全面启动。 (二) 增加服务器，为各部门提供了更加强大的工作信息平台 公司为了提高工作效率，建立强大快速的工作信息平台。于2016年购进新款联想服务器，作为第三只眼桌面监控专属服务器。 (三) 加强对信息设备的日常维护，为各部门提供更稳定的网络环境 1.按照XX公司的内控文件，公司首席运营官XX总的工作指导,XXIT部协助，建立了稳定、安全的工作信息平台。特别是针对可能发生的服务器损坏，人为或非人为的数据丢失，做出一下防范策略。 (四) 加强信息安全工作，严格防范计算机病毒引起的信息外泄，各部门顺利工作及危害业务开展的情况 为防止计算机病毒在局域网内扩散，降低因病毒造成的安全风险，公司在网络设备防火墙中设定了相关策略，并在每台计算机上均安装了360安全卫士套装，做到从源头上防止病毒在网内扩散。 (五) 加强对公司公共办公设备的检测及维护
按照XX公司内控文件的工作指导，加强对公司公共办公设备的检测及维护，定期对相关设备进行巡检，方便后期工作随时启用。公司于2016年购进索尼高清投影机2台，公用（复印）一体机1台。 (六) 对公司国际电路的网络改良，提高电路专线的传输效率及减少故障率，双重保障国际专线的稳定运营。 为了减少主要运营专线的使用压力，加强专线的功能性及使用率。IT部于2016年10月要求网络供应商进行专线电路改良，在原路由的基础上再增加一台路由设备。由于建设成本费用过高，供应商要求追加费用，后来经过XX科技XX总及IT部与供应商友好协商后，将作为样版工程免费提供给XX公司使用，使其将具备双路由功能，即其中一设备故障不影响公司网络运营。 （七）信息化数据规范管理 在XX科技XX总的指导下，我们从即时信息平台（企业QQ）开始，向着规范化行程逐步前进。 第二部分：工作中的不足 (一) 加深专业技术知识及服务水平 以XXIT部为学习榜样，要在专业技术知识及服务水平这两个方面加强学习，提升自身综合素质，全面发展。 (二) 严格按照IT部门的工作流程及落实各项规章制度 按照公司it部门管理制度，将it部的工作细致化、流程化。继续进行高效的时间管理，按照工作重要性、紧迫程度合理分配时间，尽量做到及时完成运维的工作。 第三部分：2017年IT运维信息管理工作的思路及工作目标 (一) 新方案调研及相关培训 对于在工作中其它部门所提出的新要求、新方案，我们及时相应配合，本着“严格要求”的原则，对于提出的要求科学性的分析研究，及时提出完整周密的解决方案，并上报金利IT部审核，实施完成后拟请用户试行或测试后使用。有力的保障了运维工作的及时有效性。
it运维试用期转正工作总结
it运维试用期转正工作总结篇一：运维中心试用期工作总结 尊敬的公司领导： 我于XX年09月07日起正式成为公司一员。 时间飞逝，转眼间，做为一名我友正式员工已经有两个月之久。在这个难忘而又夸姣的日子里，我深入体会到了公司的积极氛围和各个部门的巨大魅力，目睹了公司一步步走向成熟，看到了公司网络的不断健全和系统不断完善，并日渐不乱，同时，也看到了运维中心给于系统管理职员带下世人向往的学习平台和和无穷的机遇与挑战，所以，我在此对于过去的工作做下总结。 总结历史 在运维中心工作期间，我工作认真，具有较强的责任心和进取心，极富工作热情，确实完成上级交付的工作，善于与他人沟通，和公司部门同事之间能够通力合作，关系相处融洽而辑穆，配合各部分负责人成功的完成各项工作，具有很强的团队合作精神。注重自己的个人发展，不断努力学习系统、网站架构知识。所以我现在已经能够纯熟维护公司的系统服务和监控网站架构，包括前段节点，源站各个站点服务的流量信息等，能及时查看并报警所引起的网络服务相关故障，能注重公司的种种流程细节，拥有了一名系统管理维护员的基本工作技能。
回顾历史 瞻望未来 在今后的工作过程中，我会更加严格要求自己，同时也有几个大方向是我需要努力。nagios监控系统拥有极其多的复杂服务，它是我的核心工作，它的完成情况反映着我的工作是否尽职。我会努力做好本职工作。还有,cacti监控设备系统，因为时间的分配，有很多多知识未能及时巩固，同时也需要紧抓时间实践操纵，并参加实际建设和规划，使自己能更加灵活应用系统网络知识，并积累处理相关异常经验。同时，自己也要不断努力与充实自己，研究shell,pure各种脚本的编写，使自己处理处理突发事件的效率提高，以及nginx和squid这些常用的服务搭建。在今后的一年里，也会参加相应的证书考核，不断晋升自己，并紧抓利用业余时间努力学习it知识，搭建各种服务器知识，包括自己学习小型机跟进步英语水平。 篇二：IT运维个人工作总结 it运维经验小结 工作上事情太多，难免繁琐，难免被人抱怨，被人投诉。仔细想想，需要改进的地方的 确很多。毕业四年多了，从最基础的windows局域网维护，后来学习active directory， isa,exchange。后来去考ccna，想从事网络方面的工
数据库项目组日常运维与应急故障处理手册范本
常见问题及处理方案 CPU使用率高的问题 通过操作系统命令top topas glance等查看top进程号，确认是系统进程还是oracle应用进程，查询当前top进程执行的操作和sql语句进行分析。 根据进程号获取正在执行的sql SELECT a.osuser, https://www.wendangku.net/doc/dc285502.html,ername,b.address,b.hash_value, b.sql_text from v$session a, v$sqltext b, v$process p where p.spid = &spid and p.addr = a.paddr and a.STATUS = 'ACTIVE' and a.sql_address =b.address order by address, piece; 数据库无法连接 数据库无法连接，一般可能是如下原因造成： （1）数据库宕了 （2）监听异常 （3）数据库挂起 （4）归档目录满 （5）数据库或应用主机的网卡出现问题不能正常工作 （6）应用主机到数据库主机的网络出现问题。 1、数据库宕了 立即启动数据库。 2、监听异常 此时一般体现为： 监听进程占用CPU资源大； 监听日志异常。 此时，立即重启监听，监听重启一般能在1分钟之完成。 3、数据库挂起 立即重启数据库。 4、归档目录满 （1）在没有部署OGG数据同步的情况下，立即清理归档日志文件。
（2）如果部署了OGG数据同步，查看OGG正在读取的归档日志文件，立即 清理OGG不再需要的日志文件。 5、数据库或应用主机的网卡出现问题不能正常工作。 立即联系主机工程师处理。 6、应用主机到数据库主机的网络出现问题。 立即联系网络维护人员查看。 CRS/GI无法启动 对于10g及11gR1版本的CRS问题 1、进入/tmp目录下，看是否产生了crsctl.xxxxx文件 如果有的话，看文件容，一般会提示OCR无法访问，或者心跳IP无法 正常绑定等信息。 2、如果/tmp目录下没有crsctl.xxxxx文件 此时查看ocssd.log文件，看是否能从中得到有价值的信息。 可能的问题：网络心跳不通。 3、/tmp目录无crsctl.xxxxx且日志中没有报错信息，只有停CRS时的日志信 息。 此时可能是RAC两个节点对并发裸设备的访问有问题，此时考虑： （1）停掉两个节点的CRS。 （2）两个节点先同时去激活并发VG，然后再激活VG。 （3）重新启动CRS。 对于11gR2的GI问题 分析$GRID_HOME/log/nodename目录下的日志文件，看是否能从中找出无法启动的原因。常见问题： 1、心跳IP不同。 2、ASM实例无法启动。 对CRS的故障诊断和分析,参加本文档中RAC部分的MOS文档. 数据库响应慢
2020年运维部人员年度工作总结三篇
运维部人员年度工作总结三篇 运维部人员年度工作总结1去年的年末，我来到了运维部。这是一个技术岗位，刚来的我，对于我的工作可以说是相当的陌生。大多数仪器、设备都不认识，不像书本上讲的那些。它们对于我来说都是新的，需要学习来完成工作。我对我的工作充满了热情，如饥似渴的去学习书籍，请教同事，慢慢的汲取知识和经验。刚开始，每一次出去解决故障，我都有点担心，怕工作做不好，所以每一次，我都认真向前辈们学习，看他们如何去操作仪器，如何去分析故障点，不懂的我就问为什么。 还有不懂的，我就回来查电脑，自己消化，直到理解。正是自己对知识渴求的欲望和缺乏专业知识带来的恐慌，一直鞭策着我，风风雨雨走过了这一年。值得欣慰的是，这一年，我通过向别人学习和自己的努力，学到了不少东西，积累了一些经验，有时候也可以独立完成一些工作。下面我就自己这一年来的工作做个总结： 1、学会了做标准的_网线，学会了做2m线。知道了网线的线序，知道了2m线的用途。 2、认识了光纤和odf架，知道了法兰盘子，知道了如何用光纤连接法兰盘子。 3、学会了如何使用光源和光功。知道了它们各自的功能和
所显示的数值所代表意义。 4、知道了如何使用otdr去打光纤的全程长度，熟悉了如何用otdr测试新融光纤的质量，如何查故障点、测衰耗。 5、学会使用了熔接机。了解了熔接机的结构，知道了如何区分单模熔接机和多模熔接机。 6、学会了如何在几个基站之间进行跳纤。并在同事的协助下为广电跳通了2条有线电视专线。 7、对sdh有了一定的了解，并且知道了常用的oi2d和oi4d 光口板和一些以太网板。知道了如何从型号上来辨别板子的类型。 8、学会了如何去基站更换板块以及该注意的一些事项。 9、协助资产盘查。对基站的各个设备有了进一步的了解，并且熟悉了好多基站的地理位置，为以后的维护打号了基础。 10、参与并协助完成相关割接。 11、管理应急库房。为日常的维护工作和割接等提供保障。这些或许对于别人，不算什么。但是对于我来说，这就是成绩，是对自己的鼓励。随着我对工作的深入了解，我越来越发现我有很多的知识点没有弄懂，正应了这句话：知道的越多，不知道的就越多。对于处于学习阶段的我来说，不断的积累工作经验、提高自身工作能力是首要任务。所以，我在以后的工作中会更加认
it运维工程师工作总结(共5篇汇总)
第1篇it运维工作总结 it运维年度工作总结 总结一it运维管理工作总结 至20XX年10月底，XX有限公司在xx公司的运维又届满一年的时间了。在这为期一年的运维工作当中，xxxx的业务飞速发展，设备数量不断增加，人员的技术水平和业务知识有了显著的提升。我们的队伍在技术水平和管理经验上也有了本质的提高。 一、细致缜密的完成计划中的日常运维工作严把质量；服务至上；严格要求；技术领先。 承接运维工作初始信息技术部的各位领导就对我们的运维工作给予厚望，并提出了认真完善服务水平的方针。我们在服务过程中严格按照这一要求，以对保障xxxx的发展，对用户负责的精神，把“严把质量，服务至上”的原则贯穿于日常工作的各个环节之中。使本运维期过程中的客户满意度有了非常显著的提高，多次获得了用户的认可。 对于在工作息技术部提出的新要求、新方案，我们及时相应配合，本着“严格要求”的原则，对于提出的要求科学性的分析研究，及时提出完整周密的解决方案，并拟请用户试行或测试后实施。有力的保障了运维工作的及时有效性。 对于提高服务业务技术水平上，按照信息技术部的统一规划，按时完成一系列的既定培训计划。按照“技术领先”的原则，通过技术上的培训提高了业务水平和解决故障的效Word 资料率；通过制定有效的安全机制和培训，健全了xxxx信息外包人员安全机制；通过保密制度的培训使运维人员能够树立自觉维护xxxx的信息安全防意识；通过客户服务意识的培训提高了客户的满意度。 二、吸收先进经验，保质保量的完成运维的各项任务运维期主机、服务器、网络和桌面均没有发生严重的生产安全事故，对于一些潜在的威胁也都在得到信息技术部门的批示下，审慎周密的完成了整改工作。运用先进的技术和经验提高劳动效率和运维工作质量 运用先进的运维工具提高劳动效率。通过监控软件随时保持信息的及时性、可控性，一旦发生问题可以迅速定位和修复。 经过信息技术部指导，我们在运维工作量了采用WEB0技术。使我们在高效完成运维工作的情况下，为xxxx节约了大量的费用投入。 在工作的过程中注意新技术和新方法的学习和收集，对于有利于运维工作的成功方案及时整理并提交信息技术部。经过5年来的维护工作存储了大量的知识库信息。 三、适应任务需要，及时解决运维过程中的遇到的问题 在运维过程中遇到突发问题及时与信息技术部门相关人员进行沟通，对于紧急情况的处理按照《应急预案》进行对应处理。在节假日安排主要人员进行值班和备勤，保障24Word 资
ORACLE数据库日常维护与管理手册
全球眼?（MEGAEYES）网络图像管理系统2.0 ORACLE日常维护与管理手册 北京互信互通信息技术有限公司 2004-08-08
目录 全球眼?（MEGAEYES）网络图像管理系统2.0 (1) 1引言 (3) 1.1 目的 (3) 1.2 范围 (3) 1.3 参考资料 (3) 2日常维护与管理说明 (3) 2.1 运行环境 (3) 2.1.1硬件环境 (3) 2.1.2软件环境 (3) 2.2 数据库日常维护 (4) 2.2.1数据库初始设置 (4) 2.2.2每日工作内容 (5) 2.2.3每周工作内容 (6) 2.2.4每月工作内容 (7)
1引言 1.1目的 对于重要的商业系统来说，数据库系统的正常运行是保证商业应用平稳运行的关键。但是数据库在运行过程中可能会因为种种原因发生问题。这时，数据库的管理与日常维护工作将变得尤为重要。 为了指导数据库管理员做好日常维护工作，保证数据库系统的正常运行，特制定本文档。当然，数据库的日常维护是复杂和繁琐的，本文仅涉及一些常见的数据库日常维护的内容，在实际工作中，数据库管理员还需要做更多的工作。 1.2范围 本文档使用的人员：数据库维护管理人员和相关人员。 本文档涉及内容：oracle数据库的日常维护与管理解决方案。 1.3参考资料 中国电信网络视频监控技术（暂行）规范 2日常维护与管理说明 2.1运行环境 程序的运行环境包括硬件运行环境和软件运行环境。 2.1.1硬件环境 ◆CPU类型：Intel及其兼容系列CPU ◆内存容量：剩余内存要达2G以上 ◆硬盘容量：剩余硬盘容量要达1G以上 ◆网卡类型：100M网卡 2.1.2软件环境 ◆操作系统：RedHat Linux AS 3.0 ◆数据库：Oracle9i Database Release 2 (9.2.0.4.0) for Linux x86
IT运维工程师年终个人工作总结范文
IT运维工程师年终个人工作总结范文 总结这事，说易也难。如果只是单纯地罗列一下这一年自己都干了点什么工作，相信这难不倒大家，但要用一份总结不仅表明这一年做了哪些工作，还要说清楚工作成效，甚至为明年的工作提出改进的建议，这就不是那么简单的了。 作为it运维管理人员，除了自己的工作表现，更肩负着整个企业it系统健康运营的重任，所以我认为运维人员的年终总结更应该倾向于结合本单位整体运维情况，以便于来年it工作的有序发展。 那么，it运维管理员如何写好一份年终总结呢?我建议可以从以下几个方面入手： 一、资产清点 作为整个企业的it“管家”，首先应该对管理的资产情况了然于胸。比如说： 现在的it规模是怎样的?网络链路总长是多少?网络设备和服务器的数量、类型各是什么?都是什么品牌的?还有每个服务器上运行的数据库、中间件的类型和数量等等，这些情况都应该一个不漏、有条理地梳理清楚。 搞清楚“有什么”的问题以后，还应该做个比较，目前的资产情况和历年相比有什么变化，是增加还是减少了，这些变动都体现在哪里?这些数据整理出来，一张清晰的“资产图”便被轻松地“绘制”出来了。 二、业务构成及分析
it系统说到底是为业务来服务的，一个企业里，最重要的应该就是业务系统的稳定运行和增效。所以it运维管理员的总结里，必然不能缺少对业务系统保障情况的描述。 当然我们首先也应该勾勒出“业务”的大体形象：目前我们所有 的业务系统有哪些?哪些是核心的业务，它们在解决何种问题，为用户提供了哪些服务?这些业务又运行在哪些服务器上，它们的运行状态如何…?这样我们先直观地把“业务系统”介绍给大家。 接下来我们可以深入地去剖析一下这些业务的运行状况，比如： 我们的业务系统一年中平均每月主干链路的总流量达到了多少?将这些业务流量排名，前几位的是哪些?这些高流量的业务有多少人次在访问?这些业务的平均无故障运行时间是多少?根据其设计，这些业务的可用性指标达到多少?是远未达到使用预设，差一些到满负荷，还是已经超负荷…等等 还有“变化”的视角是应该一直具备的，还需要与往年比，哪些 业务是新增的，这些新增业务的使用情况如何，是用得较多还是较少? 通过以上的梳理和总结，相信看到报告的人都会对这一年的业务 系统情况有一个相对清晰的了解了。 三、事件处理情况 理清了资产和业务情况，还应该对一年中所做的事件处理情况进 行汇总。你是否能说清楚it部门这一年处理的事件数量有多少?这些 事件分类有哪些?哪些是重大事件?这一年里产生过哪些重大的事件?这些重大事件对整个it系统的影响是什么?是否针对此进行过全面的分析，并给到过改进的意见?采取了哪些措施保障了核心业务的sla?这些数据也有助于对全年的运维工作进行了解。
运维手册_数据库_DataGuard日常运维手册
文档标识 文件状态：[] 草稿 [√] 正式发布 [ ] 正在修改 Oracle RAC+DataGuard 运维手册 版本：1.0.0 编制周光晖2015年01月20 审核 批准年月日 生效日期：年月日
修订历史记录 日期版本修订说明作者
目录 第一章引言 (3) **. 编写目的 (3) **. 定义、首字母缩写词和缩略语 (4) 第二章......................................................................................................... D ATA G UARD状态查询4 **. 检查主备库的D ATA G UARD状态信息 (4) **. 检查进程 (4) **. 检查归档状态 (4) **. 检查最后应用的日志S EQUENCE (5) **. 查看是否使用实时应用 (5) **. 检查GAP (5) **. 检查保护模式 (5) **. 相关视图 (6) 第三章................................................................................................................... SWITCHOVER 6 **. 确认主库状态是否支持切换操作 (6) **. 执行主库转换 (7) **. 关闭并MOUNT新备库 (7) **. 确认老备库状态 (7) **. 切换目标备库为主库 (7) **. 打开新主库 (8) **. 启动新备库的日志应用 (8) **. 开启新备库的ADG (8) 第一章引言 1.1. 编写目的 本文档描述了Oracle 11gR2 RAC+ADG操作手册。包含RAC DOWN机测试，日常查询状态，启停RAC等指令同时包含oracle 11g R2 ACTIVE DATAGUARD 的日常维护指令。
Oracle数据库维护手册
Oracle 数据库定期维护手册 定期备份任务计划执行检查 打开附件(系统工具(任务计划 查看状态，如果状态是未能启动,则打开菜单高级(查看日志，看未能执行任务计划的原因，并处理，处理完成后，右击任务计划运行。 使用DBA 图形工具(8.1.7 DBA Studio,9i Oracle Enterprise manager Console,10G 网页的EM )检查数据库状态 主要检查空间使用情况，重点对超过80%已使用的表空间进行检查，必要时增加数据文件或将相应的数据文件设为自动扩展，注意单个数据文件大小不要超过3.9G Oracle警告日志文件监控 Oracle在运行过程中，会在警告日志文件(alert.log或alert_SID.log)中记录数据库的一些运行情况: ●数据库的启动、关闭，启动时的非缺省参数; ●数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因; ●对数据库进行的某些操作，如创建或删除表空间、增加数据文件; ●数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA-600) DBA应该定期检查日志文件，根据日志中发现的问题及时进行处理 问题处理 如提示启动参数不对，则检查初始化参数文件 因为检查点操作或归档操作没有完成造成重做日志不能切换如果经常发生这样的情况，可以考虑增加重做日志文件组;想办法提高检查点或归档操作的效率; 有人未经授权删除了表空间则检查数据库的安全问题，是否密码太简单;如有必要，撤消某些用户的系统权限 出现坏块检查是否是硬件问题(如磁盘本生有坏块)，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建 表空间不够增加数据文件到相应的表空间 出现ORA-600根据日志文件的内容查看相应的TRC文件，如果是Oracle的bug，要及时打上相应的补丁 数据库表空间使用情况检查 数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。 select tablespace_name, count(*) chunks , max(bytes/1024/1024) max_chunk from dba_free_space group by tablespace_name; 其中，CHUNKS列表示表空间中有多少可用的空闲块(每个空闲块是由一些连续的Oracle 数据块组成)，如果这样的空闲块过多，比如平均到每个数据文件上超过了100个，那么该