Oracle数据库运维案例介绍
数据库运维面试题
数据库运维面试题1. 介绍数据库运维的重要性和职责 (200字左右)数据库运维是确保企业数据库系统正常运作的关键任务之一。
作为数据库运维人员，我们负责维护和管理数据库系统，以保证数据的完整性、可靠性和安全性。
我们需要监控数据库性能，优化查询和存储过程，处理数据库故障和备份恢复，以及制定和实施数据库安全策略和灾难恢复计划。
数据库运维的目标是提供高效稳定的数据库服务，确保企业的数据在任何情况下都能得到保护和可靠使用。
2. 数据库运维面试常见问题及回答 (800字左右)2.1 数据库性能监控和优化面试官可能会问到如何监控和优化数据库性能的问题。
我会回答说，我们可以使用性能监控工具，如Oracle Enterprise Manager或MySQL Performance Schema来监控数据库的性能参数，如CPU利用率、内存利用率、磁盘I/O等，并根据监控结果进行性能调优，如优化查询语句、创建索引、调整数据库参数等。
2.2 数据库备份和恢复备份和恢复是数据库运维的重要任务之一。
面试官可能会问到如何备份和恢复数据库的问题。
我会回答说，我们可以使用数据库自带的备份工具，如Oracle的RMAN或MySQL的mysqldump来进行数据库备份，同时保证备份的完整性和一致性。
在恢复数据库时，我们可以使用备份文件进行完全恢复或部分恢复，以确保数据的可靠性和可用性。
2.3 数据库安全和灾难恢复数据库安全和灾难恢复是数据库运维的重要任务。
面试官可能会问到如何保护数据库安全和进行灾难恢复的问题。
我会回答说，我们可以通过实施访问控制、加密传输、审计日志等措施来保护数据库安全；同时，我们还应该定期制定和测试数据库的灾难恢复计划，以应对自然灾害、硬件故障等情况下的数据丢失恢复。
2.4 数据库版本升级和迁移面试官可能会问到如何进行数据库版本升级和迁移的问题。
我会回答说，我们需要先制定版本升级或迁移的计划，然后备份原有数据库，在测试环境中进行版本升级或迁移的测试。
面向企业级数据库的故障分析及运维研究：以Oracle数据库为例
2017年软 件2017, V ol. 38, No. 10作者简介: 金鑫(1985-)，女，国家电网公司信息通信分公司职员，工程师，主要从事信息运维工作；闫龙川(1979-)，男，国家电网公司信息通信分公司处长，高级工程师，主要从事信息运维工作；刘军(1970-)，男，国家电网公司信息通信分公司主任，高级工程师，主要从事信息通信运维管理工作；耿亮(1985-)，男，全球能源互联网集团有限公司职员，工程师，主要从事能源研究工作。
面向企业级数据库的故障分析及运维研究：以Oracle 数据库为例金 鑫1，闫龙川1，刘 军1，耿 亮2（1. 国家电网公司信息通信分公司，北京 100761；2. 全球能源互联网集团有限公司，北京 100031）摘 要: 数据库是信息系统的核心组件，数据库故障是信息系统故障的主要因素，数据库运维是信息系统运行维护工作的重点。
基于Oracle 数据库的架构分析和故障机理深层次研究，创新性提出故障原因分类体系，提出实用运维操作方法，给出数据库故障典型案例，为信息系统运维工作人员做好数据库运维工作的提供系统方法论。
关键词: Oracle ；数据库故障；诊断分析中图分类号: TP319 文献标识码: A DOI ：10.3969/j.issn.1003-6970.2017.10.035本文著录格式：金鑫，闫龙川，刘军，等. 面向企业级数据库的故障分析及运维研究：以Oracle 数据库为例[J]. 软件，2017，38（10）：178-181Research on Failure Analysis and Operational Maintenance focused onEnterprise Databases: an Example on OracleJIN Xin 1, YAN Long-chuan 1, LIU Jun 1, GENG Liang 2(1. State Grid Information & Telecommunication Branch, Beijing 100761, China ; 2. Global Energy Interconnection Group Co., Ltd., Beijing 100031, China )【Abstract 】: Database is the core component of information system, database failure is the main factor of informa-tion system failure, database operation and maintenance is the focus of information system operation and mainte-nance work. Based on the Oracle database architecture analysis and deep research on failure mechanism, innova-tively proposed fault classification system, put forward the practical operation and maintenance operation method, given the typical case of database failure, and provided system methodology for the information system operation and maintenance staff to do the work of database operation and maintenance. 【Key words 】: Oracle; Database failures; Diagnosis and analysis;0 引言数据库承担数据的存储、读取等功能，是信息系统重要组成部分，数据库故障可能导致信息系统瘫痪，对企业运营和安全生产的威胁极大，数据丢失可能会对企业造成不可挽回的影响。
(完整版)Oracle数据库规划设计和运行维护方案
Oracle数据库规划设计和运行维护方案（V1。
0）目录1。
前言 (6)1。
1. 编写目的 (6)1。
2。
方案说明 (6)1.3. 预期读者 (7)2。
数据库部署模式 (7)2.1. 单机模式 (7)2.2. 双机热备模式（HA模式) (8)2.3。
集群模式（RAC） (9)2。
4. 主从模式（DataGuard） (10)2.5。
混合模式(DataGrard+RAC） (10)2。
6。
数据库运行模式选择 (11)3。
系统特点和数据库类型 (11)3。
1。
业务系统的特点 (11)3。
1.1。
OLTP特点 (12)3.1.2。
OLAP特点 (13)3。
2。
数据库的规模 (13)3.3。
数据库版本建议 (13)4. 数据库运行环境规划 (14)4.1。
主机规划 (14)4。
2. 网络规划 (15)4.3. 存储规划 (17)5。
数据库安装部署规划 (19)5.1。
软件安装路径 (19)5。
2. 表空间设计 (19)5.2.1. 业务数据量估算 (19)5。
2。
2。
表空间使用规则 (21)5.2.3。
表空间的概念和分配原则 (25)5。
2.4。
表空间的参数配置 (26)5.2。
5. Undo/temp表空间的估算 (30)5.2。
6. 表的参数设置 (30)5.2。
7. 索引的使用原则 (31)5。
3. 文件设计 (32)5.3。
1. RAC配置文件 (32)5.3。
2. 参数文件 (33)5。
3。
3. 控制文件 (34)5。
3.4。
重做日志文件 (35)6。
数据库应用规划 (37)6。
1。
数据库用户设计 (37)6。
1。
1。
用户权限规划 (37)6.1.2。
用户安全实现 (39)6。
1。
3. 用户类型及角色命名规范 (41)6.2. 数据库分区 (44)6.2。
1. 数据库分区介绍 (44)6。
2.3. 物理分割 (45)6。
2。
4. 数据分区的优点 (45)6.2.5. 数据分区的不足 (45)6.2。
系统运维常见案例分析
故障修复过程
重启应用系统，检查是否 恢复正常
增加系统资源，如增加内 存、CPU等
检查应用程序日志，定位 问题代码并进行修复
检查网络连接，确保稳定 可靠
06
案例五：安全漏洞修补与加固
安全漏洞描述
某大型企业网站遭受黑客攻击，导致 网站数据泄露和服务器瘫痪。
黑客利用网站的安全漏洞，获取了网 站管理员的账号和密码，进而控制了 整个网站系统。
背景
随着信息技术的快速发展，企业对于系统的稳定性和可用性要求越来越高。系 统运维作为保障系统稳定运行的关键环节，需要不断总结经验，提高运维水平 。
汇报范围
01
本次汇报将涵盖常见的系统运维 案例，包括硬件故障、软件故障 、网络故障、数据恢复等方面。
02
通过案例分析，总结出相应的经 验教训和解决方案，为今后的系 统运维工作提供参考和借鉴。
故障恢复过程
软件冲突解决
重新安装或更新应 用程序，修复系统 漏洞。
数据备份与恢复
对重要数据进行备 份，使用备份数据 进行恢复。
硬件故障排查
检查硬件设备是否 正常工作，如更换 内存条、硬盘等。
网络问题解决
检查网络连接是否 正常，重新配置网 络参数。
系统优化
对系统进行优化， 提高服务器性能和 稳定性。
安全漏洞原因分析
网站系统存在多个安全漏洞，包括但不限于SQL注入、跨站脚本攻击、文件上传 漏洞等。
管理员对安全问题的重视程度不够，没有及时更新系统和补丁，也没有对网站进 行定期的安全检查。
安全漏洞修补与加固过程
发现安全漏洞后，立即采取措施隔离 网站服务器，防止黑客进一步攻击。
对网站系统进行全面检查，找出所有 可能存在的安全漏洞，并进行分类和
系统运维常见案例分析
资源调整
增加数据库内存或调整CPU使 用率，提高数据库性能。
网络检查
检查网络连接是否正常，确保 网络通信畅通无阻。
ቤተ መጻሕፍቲ ባይዱ
04
案例四：软件升级引起的 兼容性问题
现象描述
某公司在进行软件系统升级后，发现 新版本软件与旧系统存在兼容性问题 ，导致系统运行缓慢、频繁崩溃或某 些功能无法正常使用。
用户投诉数量大幅增加，严重影响业 务正常运行。
在升级前，对可能涉及到的所有软硬件环境进行充分的兼 容性测试，包括不同版本间的接口、数据格式和外部依赖 项的验证。
回滚计划
为避免升级失败导致业务中断，应预先制定回滚计划，确 保系统能在升级失败时快速恢复到旧版本。
制定详细的升级计划
明确升级过程中的风险点，制定应急预案，并按照计划执 行升级操作。
监控与日志
出现崩溃或异常退出的情况。
服务器在高负载情况下，可能会 引发其他问题，如网络连接不稳
定、磁盘I/O瓶颈等。
问题分析
不合理的应用设计
应用程序存在性能瓶颈或代码 不良设计，导致服务器负载过 高。
不良的网络环境
网络带宽不足或网络延迟高等 问题，影响服务器性能。
服务器硬件资源不足
服务器硬件配置不足以支持当 前运行的应用程序和业务需求 。
系统运维常见案例分析
汇报人： 日期:
目录
• 案例一：服务器负载过高 • 案例二：网络连接异常 • 案例三：数据库故障 • 案例四：软件升级引起的兼容性问题 • 案例五：病毒攻击
01
案例一：服务器负载过高
现象描述
服务器的CPU或内存使用率持续 高于80%或90%，甚至达到 100%。
由于负载过高，服务器响应变慢 ，导致应用程序性能下降，甚至
系统运维常见案例分析
案例十七：如何做FS扩容、缩容
Aix：jfs2
# chfs …
Linux：ext3、reiserfs
先扩展lv,再扩展fs,ext3为例如下： # lvextend -L+3G /dev/appvg/lvol0 # e2fsck -f /dev/appvg/lvol0 # resize2fs /dev/appvg/lvol0 缩容必须离线做，先缩fs，再缩lv # umount /test # e2fsck -f /dev/appvg/lvol0 # resize2fs /dev/appvg/lvol0 2G # lvreduce -L-Leabharlann G /dev/appvg/lvol0
一、一般主机IP地址的解析顺序依次是host,DNS 1、Aix相关配置文件主要如下： /etc/netsvc.conf、/etc/resolv.conf /etc/netsvc.conf文件中设置如下行: hosts=local,bind 这样主机IP地址就先从本地档案(/etc/hosts)开始搜索,2、 其次再去找DNS server /etc/resolv.conf 设置domain 、dns地址 2、Linux配置文件是怎么样的呢？如果解析顺序为 DNS,host，会有什么问题么？
迁移命令例： migratelp hd2/$lpartnum/2 hdisk5
案例十：rm 清理文件失败，参数过长
rm 清理文件时遭遇无法删除，提示："ksh: /usr/bin/rm 0403-027 The parameter list is too long.“
# ls –l |awk ‘{print “rm “ $9 }’ |sh # find . -name \*.FDC |xargs rm
Oracle数据库性能优化与案例分析
Oracle数据库性能优化与案例分析
性能优化探讨
• 原因：为什么？ • 慢（响应时间） • 慢（吞吐量）
性能优化探讨
• 目的：为了什么？ • 快（响应时间） • 快（吞吐量）
性能优化之案例分析
• 案例之方法论 • 案例之登录访问 • 案例之资源 • 案例之锁
性能优化方法论发展
• 登录输入指标测量 • Logons：= EndSnap. logons cumulative– StartSnap. logons
cumulative。 • Logons Per Second:= Logons / TimeInterval
案例之登录访问
登录输出指标测量：
Logon Response Time:= Network Response Time * 10 + Native TCP Logon :=Network Response Time * 10 + Listener Response Time + Native IPC Logon Time 。
案例之登录访问
• 例：
•
某医院HIS业务系统的账户登录操作异常缓慢，部分情况下
甚至会出现长时间的卡壳情况，业务影响主要发生在每天早上
的上班时刻。
案例之登录访问
优化过程： • 账户登录过程一般涉及到在账户表格以及对应日志表格上的冲
突，比如Buffer busy waits或者TX lock。AWR未体现该特征。 • AWR报告显示connection management call elapsed time时间偏长
成功率：98% 高 失败率：2% 低
失败人数：500*2%=10
十三起惨痛宕机案例
十三起惨痛宕机案例01Oracle系统参数过小导致数据库宕机数据库双机安装完成后，数据库实例能够正常启动，但当启动全部应用软件后约10分钟，主机数据库出现自动切换至备机，再运行约10分钟备机数据库自动宕机。
原因分析：启动应用软件前，数据库双机运行正常且能正常切换。
当启动全部应用软件后，数据库发生异常切换。
查看双机状态发现，网卡、磁盘等资源均正常，数据库应用资源状态异常。
从上述情况初步分析为数据库问题导致双机异常。
进一步分析/var/adm/message日志消息，发现引起数据库异常的原因为会话数达到最大值，新的应用连接无法获取会话资源，导致数据库管理软件判断运行系统异常后自动停止数据库。
处理过程：1、使用sys用户以sysdba权限登陆数据库sqlplus ‘/as sysdba’2、查看数据库当前最大进程数show parameter processes;NAME TYPE VALUEaq_tm_processes integer 1db_writer_processes integer 1job_queue_processes integer 10log_archive_max_processes integer 1processes integer 150其中processes＝150为oracle数据库安装后的默认值3、根据实际情况修改数据库最大进程数alter system set processes=800 scopo=spfile;oracle的最大会话数与系统参数processes有关，其关系为sessions＝1.1×processes＋5。
根据实际情况将processes参数修改为800。
4、重启oracle数据库，再使用show parameter processes检查参数修改情况。
由社区会员“hp_hp”分享02P720异常宕机故障一例主机：P720 8202-E4B现象：运行正常的某一天，在未出现任何告警的情况下，系统突然访问不了。
oracle 集群故障处理案例
标题：Oracle 集裙故障处理案例正文：一、概述Oracle 数据库在企业应用中扮演着重要的角色，为了保障数据的安全性和稳定性，很多企业都会采用集裙的方式来部署 Oracle 数据库。
然而，即使采用了集裙部署，也无法完全避免故障的发生。
在实际运维中，处理集裙故障是数据库管理员必须面对的挑战之一。
本文将以实际案例为例，探讨在 Oracle 集裙中常见的故障处理方法。
二、故障现象描述我们的案例是发生在一家电商企业的 Oracle 数据库集裙上。
在一天凌晨的数据库备份过程中，其中一台节点的数据库突然宕机，无法对外提供服务。
这导致部分业务受到影响，需要尽快将故障排除恢复服务。
三、排查故障原因1. 查看日志信息我们登入到集裙中的其他正常节点，查看日志信息。
日志中显示了一些关于存储和网络异常的报警信息。
2. 检查存储状态我们通过存储管理工具查看存储的状态。
发现存储设备上的部分磁盘出现了异常，可能是造成数据库宕机的原因之一。
3. 检查网络连接我们也检查了集裙节点之间的网络连接状态，发现了某个节点与存储之间的网络连接存在异常。
四、故障处理过程1. 修复存储设备针对存储设备上的异常，我们立即通联存储设备厂家进行了紧急维护。
通过他们的帮助，我们成功修复了存储设备上的磁盘异常，并恢复了存储的正常状态。
2. 修复网络连接我们对节点与存储之间的网络连接进行了调试和修复。
最终找到了网络连接异常的原因，并采取相应措施进行了修复。
3. 数据库恢复在经过以上步骤的处理之后，我们重新启动了故障节点上的数据库实例，并进行了数据完整性检查和恢复操作。
故障节点顺利恢复，并重新加入到了集裙中，正常对外提供服务。
五、故障处理总结通过以上的故障处理过程，我们总结了以下几点经验和教训：1. 定期检查存储设备的健康状态，及时排除潜在风险。
2. 注意集裙节点之间的网络连接状态，及时发现并解决异常。
3. 在处理集裙故障时，要有条不紊地逐步排查，不要操之过急。
oracle数据库应用案例
oracle数据库应用案例
以下是一些常见的Oracle数据库应用案例：
1. 企业级应用：许多大型企业使用Oracle数据库来支持企业资源规划（ERP）系统、客户关系管理（CRM）系统和供应链管理系统等重要业务应用。
2. 金融领域：银行和金融机构经常使用Oracle数据库来管理大量的交易数据、客户账户信息和风险分析等。
3. 电信行业：电信运营商使用Oracle数据库来管理用户资料、通信记录和计费信息等。
4. 零售业：零售业公司使用Oracle数据库来管理存货、销售数据、订单处理和供应链信息等。
5. 健康保健：医院和保健机构使用Oracle数据库来管理患者记录、医疗图像和诊断数据等。
6. 教育部门：大学和学校使用Oracle数据库来管理学生信息、教职工信息和学术研究数据等。
7. 公共部门：政府和政府机构使用Oracle数据库来管理公
民信息、税务数据和人口统计数据等。
oracle数据库故障处理案例
oracle数据库故障处理案例Oracle数据库是一种常见的关系数据库管理系统，它在企业应用中被广泛使用。
然而，由于各种原因，Oracle数据库可能会遇到各种故障和问题。
本文将列举一些常见的Oracle数据库故障处理案例，并提供解决方案。
1. 数据库无法启动：在某些情况下，Oracle数据库可能无法启动。
这可能是由于数据库文件损坏、数据库实例配置错误、内存不足等原因引起的。
解决此问题的方法包括修复数据库文件、重新配置数据库实例和增加内存容量。
2. 数据库性能下降：当Oracle数据库的性能下降时，可能会导致应用程序变慢或无响应。
这可能是由于数据库表空间过度使用、索引失效、SQL语句优化不当等原因引起的。
解决此问题的方法包括清理表空间、重新创建索引和优化SQL语句。
3. 数据库连接问题：有时候，应用程序无法连接到Oracle数据库。
这可能是由于网络问题、数据库实例未启动、监听器配置错误等原因引起的。
解决此问题的方法包括检查网络连接、启动数据库实例和检查监听器配置。
4. 数据库备份和恢复：数据库备份和恢复是保证数据安全和可用性的关键。
当数据库发生故障或数据丢失时，需要进行数据库恢复。
解决此问题的方法包括使用RMAN工具进行备份和恢复、使用闪回5. 数据库锁定和死锁：在多用户环境下，可能会发生数据库锁定和死锁问题。
这可能是由于事务并发操作引起的。
解决此问题的方法包括查找锁定和死锁的相关会话、释放锁定和解决死锁。
6. 数据库日志文件满：Oracle数据库的日志文件用于记录数据库操作和恢复信息。
当日志文件满时，可能会导致数据库无法继续进行操作。
解决此问题的方法包括增加日志文件大小、清理旧的日志文件和优化日志文件切换策略。
7. 数据库表空间不足：Oracle数据库的表空间用于存储数据和索引。
当表空间不足时，可能会导致无法插入新数据或创建新索引。
解决此问题的方法包括增加表空间大小、清理无效数据和重新分配表空间。
运维手册_数据库_Oracle11gRAC日常运维手册(352)
Oracle运维手册恒生电子客服总部系统服务部本文所述内容（包括文字和图片），恒生电子股份有限公司（以下简称“恒生”或“恒生公司”）拥有完全独立的唯一版权。
未经恒生公司书面同意或授权，任何单位和个人都不得将其复制、影印或引用。
目录第一章通过SQL*Plus管理Oracle系统 (3)**. 登录oracle系统 (3)**. 退出SQL*Plus (3)**. 在sqlplus下得到帮助信息 (3)第二章Oracle11gR2 RAC日常管理 4**. 监控oracle (4)**. 监控Oracle日志 (4)**. 监控oracle状态 (5)**. 监控表空间使用情况 (6)**. 监控主机 (8)**. 监控CPU (8)**. 使用vmstat 命令监控cpu使用情况 (8)**. 监控主机日志 (9)**. 监控OS文件系统使用情况 (9)**. 启动、关闭数据库 (9)**. 启动数据库 (9)**. 关闭数据库 (11)**. 监听器启动、关闭 (13)**. 表统计信息维护 (14)**. 修改主机系统时间 (15)**. 时间管理原则 (15)**. 时间修改方法 (15)**. 数据库日志收集 (15)**. OS日志 (16)**. DB日志 (16)**. grid日志 (16)**. AWR和ASH报告生成 (16)**. AWR报告生成（同10g） (16)**. ASH报告生成（同10g） (19)**. Recyclebin管理 (23)**. 归档日志的清理 (23)**. 查看回收站中的对象 (23)**. 指定删除某些特定对象 (23)**. 指定删除某表空间的所有回收站对象 (23)**. 清除某用户下的回收站对象 (23)**. 清除所有回收站对象 (23)**. 数据库性能监控 (24)**. 查看系统当前等待事件 (24)**. 通过sid查看sql语句24第一章通过SQL*Plus管理Oracle 系统登录oracle系统以oracle用户登录主机1)以sys用户登录oracle系统[oracle@rac1 ~]$ sqlplus / as sysdba2)其他用户登录oracle系统[oracle@rac1 ~]$ sqlplus hs_user/handsome@jsswdb1退出SQL*PlusSQL>exit在sqlplus下得到帮助信息列出全部SQL命令和SQL*Plus命令SQL> help index列出某个特定的命令的信息SQL>help 命令名或者SQL>? 命令名第二章Oracle11gR2 RAC日常管理监控oracle2.1.1.监控Oracle日志2.1.1.1. DB日志以oracle用户登录该日志文件在每个节点主机的$ORACLE_BASE/diag/rdbms/<dbname>/<sid>/trace目录下，文件名为：alert_XXXX.log （节点1）例如：/u01/app/oracle/diag/rdbms/hsdb/hsdb1/trace/alert_hsdb1.log在出现oracle故障前或故障时，数据库会将一些警告、错误信息写入该文件，交易时应随时监控该文件，及时发现警告、错误信息。
医院信息系统中Oracle数据库运维管理
医院信息系统中Oracle数据库运维管理随着现代医疗技术的不断发展，医院信息系统已经成为现代医院必不可少的一部分。
其中，Oracle数据库是医院信息系统中应用广泛的数据库管理系统之一。
本文将介绍医院信息系统中Oracle数据库运维管理的重要性及其运维管理工作。
一、医院信息系统中Oracle数据库的重要性Oracle数据库作为一种关系型数据库管理系统，广泛应用于计算机信息管理领域，特别是在医院信息系统中。
医院信息系统中的数据管理工作，不仅需要保证数据的安全性和完整性，还需要保证数据库系统的高效性和稳定性。
Oracle数据库可以帮助医院信息系统管理数据，提升系统的性能和可靠性。
二、Oracle数据库运维管理工作1. 数据库安装和部署：Oracle数据库系统的安装和部署是数据库运维管理工作的重要组成部分。
数据库管理员需要根据实际需求，选择合适的版本和配置参数，完成数据库的安装和初始化。
2. 数据库备份和恢复：数据库备份恢复是数据库运维管理中必不可少的工作，其目的是保证数据的安全性和完整性。
数据库管理员需要定期进行备份操作，并测试恢复数据的可行性。
3. 数据库性能监控和优化：数据库的性能直接影响系统的稳定性和响应时间。
数据库管理员需要监控数据库的性能指标，及时发现和解决潜在问题，同时优化数据库的配置和参数设置。
4. 数据库安全管理：医院信息系统中的数据极为重要，数据库管理员需要制定数据库的安全策略，并定期进行漏洞扫描和权限管理工作，防止黑客攻击和数据泄露。
5. 系统维护和升级：数据库系统的维护和升级工作也是数据库运维管理不可缺少的环节。
管理员需要跟踪数据库的技术发展和新版本的发布，及时升级数据库系统，并解决兼容性和升级问题。
三、总结医院信息系统中Oracle数据库运维管理的重要性不言而喻。
数据库管理员需要具备扎实的技术与管理经验，合理规划数据库系统架构，保证数据库高可用性和可靠性。
同时，定期进行备份和恢复操作，优化数据库性能，加强安全管理，及时进行数据库系统的维护和升级，确保医院信息系统的有效运行。
江苏电信网上营业厅Oracle_RAC_on_vSphere案例介绍
架构图：全部云化之后
Oracle RAC集群 WEB/应用/接口/资源/后台/数据库等虚拟机
虚拟化资源池（DRS/HA）
IBM HX5刀片服务器（4C/128GB）
IBM HX5刀片服务器（4C/128GB）
SAN LAN
IBM/EMC 光纤通道 存储阵列
7
Oracle RAC节点虚拟机配置
8
业务高峰时
Oracle RAC集群 WEB/应用/接口/资源/后台/数据库等虚拟机
虚拟化资源池（DRS/HA）
IBM HX5刀片服务器（4C/128GB）
IBM HX5刀片服务器（4C/128GB）
SAN LAN
IBM/EMC 光纤通道 存储阵列
9
物理服务器故障时
Oracle RAC集群 WEB/应用/接口/资源/后台/数据库等虚拟机
虚拟化资源池（DRS/HA）
X
IBM HX5刀片服务器（4C/128GB）
IBM HX5刀片服务器（4C/128GB）
SAN LAN
IBM/EMC 光纤通道 存储阵列
10
Oracle RAC扩展节点
Oracle RAC集群 WEB/应用/接口/资源/后台/数据库等虚拟机
虚拟化资源池（DRS/HA）
13
谢谢
14
IBM HX5刀片服务器（4C/128GB）
IBM HX5刀片服务器（4C/128GB）
SAN LAN
IBM/EMC 光纤通道 存储阵列
11
目录
1
2 3
背景和驱动因素 方案介绍 实施经验分享
12
经验分享
1. Oracle RAC的每个节点位于不同的ESXi 主机上，通过DRS Affinity来设置 RAC各节点互斥运行在独立的ESXi主机上。 2. Oracle RAC的私网应使用独立VLAN，该VLAN只有各RAC节点可以访问。 3. 管理网络、VMotion网络、Oracle RAC私网与公网应分别使用独立的物理网卡。 4. 存放数据库文件的共享存储LUN应保证高性能（使用多个磁盘组成的独立 RAID组），同时存储本身性能也应有保证，可以结合Storage DRS功能实现存 储卷负载均衡。 5. ESXi主机和虚拟机都应使用同一个NTP服务器实现时间同步，并且在虚拟机 使用了NTP服务器后应当禁止使用VMtools的时间同步功能。 6. 使用VMwarre 虚拟并行控制器（默认LSI Logic 并行控制器）连接共享RDM 磁盘可提高IO性能，需要安装VMtools。 7. 安装VMtools，使用vmxnet3网卡可提高网络性能，默认为E1000网卡。 更多关于Oracle RAC on vSphere最佳实践请参考： /files/pdf/partners/oracle/vmware-oracle-rac-deploy-guide.pdf
ORACLE数据库日常运维操作手册(带有具体代码2017)
数据库日常运维操作手册目录1.日维护过程1.1 确认所有的INSTANCE状态正常1.2 检查文件系统的使用（剩余空间）1.3 检查日志文件和trace文件记录1.4 检查数据库当日备份的有效性。
1.5 检查数据文件的状态1.6 检查表空间的使用情况1.7 检查剩余表空间1.8 监控数据库性能1.9 检查数据库系统性能1.10 日常出现问题的处理。
2.每周维护过程2.1 监控数据库对象的空间扩展情况2.2 监控数据量的增长情况2.3 系统健康检查2.4 检查无效的数据库对象2.5 检查不起作用的约束2.6 检查无效的trigger3．月维护过程3.1 Analyze Tables/Indexes/Cluster3.2 检查表空间碎片3.3 寻找数据库性能调整的机会3.4 数据库性能调整3.5 提出下一步空间管理计划数据库日常运维操作手册主要针对ORACLE数据库管理员对数据库系统做定期监控：(1). 每天对ORACLE数据库的运行状态日志文件、备份情况、数据库的空间使用情况、系统资源的使用情况进行检查，发现并解决问题。
(2). 每周对数据库对象的空间扩展情况、数据的增长情况进行监控、对数据库做健康检查、对数据库对象的状态做检查。
(3). 每月对表和索引等进行Analyze、检查表空间碎片、寻找数据库性能调整的机会、进行数据库性能调整、提出下一步空间管理计划。
对ORACLE数据库状态进行一次全面检查1．日维护过程1.1 确认所有的INSTANCE状态正常登陆到所有数据库或例程,检测ORACLE后台进程:$ps –ef|grep ora1.2 检查文件系统的使用（剩余空间）如果文件系统的剩余空间小于20%，需删除不用的文件以释放空间。
#df –k1.3 检查日志文件和trace文件记录检查相关的日志文件和trace文件中是否存在错误。
A 连接到每个需管理的系统使用secureCRT远程登陆工具B 对每个数据库,进入到数据库的bdump目录,unix系统中BDUMP目录通常是$ORACLE_BASE/<SID>/bdump#$ORACLE_BASE/<SID>/bdumpC 使用Unix 和linux ‘tail’命令来查看alert_<SID>.log文件#tail $ORACLE_BASE/<SID>/bdump/alert_<SID>.logD 如果发现任何新的ORA-错误,记录并解决1.4 检查数据库当日备份的有效性。
Oracle数据库运维案例介绍
14:29
.......
1 gc buffer busy acquire 278 20170805 14:57 1 gc buffer
busy release 300 20170805 14:57 1 gc cr block lost 6
20170805 14:57 1 gc buffer busy acquire 184 20170805
Oracle数据库运维案例介绍
技术创新 变革未来
Sat Oct 08 16:14:10 2016 IPC Send timeout detected. Sender: ospid 11292 [oracle@xxxx (LMS3)] Receiver: inst 1 binc 429417348 ospid 11405 …… IPC Send timeout detected. Sender: ospid 11278 [oracle@xxxx (LMD0)] Receiver: inst 1 binc 429417294 ospid 11388 IPC Send timeout to 1.0 inc 10 for msg type 65518 from opid 12 Sat Oct 08 16:14:51 2016 IPC Send timeout detected. Sender: ospid 11270 [oracle@xxxx (PING)] Receiver: inst 1 binc 429417288 ospid 11376 Sat Oct 08 16:14:59 2016 Detected an inconsistent instance membership by instance 2 Evicting instance 1 from cluster
dba 案例
dba 案例DBA（数据库管理员）案例通常涉及数据库的管理、维护、诊断和恢复等方面。
以下是一个典型的DBA案例：假设某企业拥有一台Oracle数据库，数据库管理员（DBA）负责监控和维护数据库。
在某一天，DBA发现数据库性能下降，查询响应时间变长，于是开始进行故障排查。
1. 分析现象：DBA首先查看数据库的性能指标，如CPU利用率、内存使用情况、I/O吞吐量等，发现并无明显异常。
然而，在检查数据库日志时，发现有大量ORA错误日志，提示可能存在数据文件损坏。
2. 诊断问题：DBA根据日志信息，定位到可能损坏的数据文件，并使用Oracle提供的诊断工具，如ADMIN_EXPORT和ADMIN_IMPORT 等，对损坏的数据文件进行诊断。
诊断结果显示，数据文件存在物理损坏。
3. 制定恢复方案：DBA根据诊断结果，制定数据文件恢复方案。
在此案例中，可以选择以下几种方法：-手动恢复：通过Oracle的备份和恢复工具，如RMAN（远程管理工具），手动恢复损坏的数据文件。
-自动恢复：如果数据库配置了自动备份和恢复机制，可以触发自动恢复过程。
-紧急恢复：在数据文件无法恢复的情况下，可以选择紧急恢复，通过重建数据文件或使用备用数据文件等方式，尽快恢复数据库正常运行。
4. 实施恢复：DBA根据恢复方案，执行数据文件恢复操作。
在此过程中，需要密切关注数据库的运行状况，确保恢复成功。
5. 验证恢复结果：恢复完成后，DBA需要对数据库进行验证，确保数据完整性和正确性。
可以使用Oracle提供的数据校验工具，如ANALYZE TABLE、CHECK TABLE等，对数据库进行校验。
6. 优化数据库：为了防止类似问题再次发生，DBA需要对数据库进行优化。
这包括调整数据库参数、优化表结构和索引、调整查询性能等。
通过以上步骤，DBA成功解决了数据库性能下降的问题，确保了企业数据的稳定和安全性。
需要注意的是，这里提供的案例仅供参考，实际工作中的DBA案例可能涉及更多技术和工具，具体操作需要根据实际情况进行。
Oracle数据库日常维护方案书
Oracle数据库日常维护方案书ORACLE数据库日常运行维护年度服务项目方案书目录12 3项目背景及目标 (5)1.1项目背景 (5)1.2项目目标 (5)需求分析 (5)项目总体方案 (7)3.1数据库性能优化 (8)3.1.1检查Oracle数据库性能 (8)3.1.1.13.1.1.23.1.1.33.1.1.43.1.1.53.1.1.63.1.1.73.1.1.83.1.1.9检查数据库的等待事件 (9)Disk Read最高的SQL语句的获取 (9)查找前十条性能差的sql (9)等待时间最多的5个系统等待事件的获取 (9)检查运行很久的SQL (9)检查消耗CPU最高的进程 (10)检查碎片程度高的表 (10)检查表空间的I/O比例 (10)检查文件系统的I/O比例 (10)3.1.1.10检查死锁及处理 (10)3.1.1.11检查数据库cpu、I/O、内存性能 (11)3.1.1.12查看是否有僵死进程 (12)3.1.1.13检查行链接/迁移 (13)3.1.1.14定期做统计分析 (13)3.1.1.15检查缓冲区命中率 (14)3.1.1.16检查共享池命中率 (14)3.1.1.17检查排序区 (14)3.1.1.18检查日志缓冲区 (15)3.1.2性能调优及方法 (15)3.1.2.1Oracle数据库日常维护方案书3.1.2.2 3.1.2.3 3.1.2.4 3.1.2.5 寻找问题根源 (16)System_Event事件 (16)Session_Event事件 (16)Session_Wait (17)应用优化 (17)3.1.2.5.1 3.1.2.5.2 3.1.2.5.3 3.1.2.5.4例程调优 (17)I-O优化 (19)竞争优化 (19)O-S监控 (20)3.2数据库备份恢复 (21)3.2.1检查Oracle数据库备份结果 (21)3.2.1.1 3.2.1.2 3.2.1.3 检查数据库备份日志信息 (21)检查backup卷中文件产生的时间 (22)检查oracle用户的email (22)3.3数据库迁移 (22)3.4数据库运维 (23)3.4.1检查数据库基本状况 (23)3.4.1.1 3.4.1.2 3.4.1.3 检查Oracle实例状态 (23)检查Oracle服务进程 (24)检查Oracle监听状态 (24)3.4.2检查系统和oracle日志文件 (25)3.4.2.1 3.4.2.2 3.4.2.3 3.4.2.4 检查操作系统日志文件 (25)检查oracle日志文件 (26)检查Oracle核心转储目录 (26)检查Root用户和Oracle用户的email (27)3.4.3检查Oracle对象状态 (27)3.4.3.1 3.4.3.2 3.4.3.3 3.4.3.4 3.4.3.5 3.4.3.6 检查Oracle控制文件状态 (27)检查Oracle在线日志状态 (27)检查Oracle表空间的状态 (28)检查Oracle所有数据文件状态 (28)检查无效对象 (29)检查所有回滚段状态 (29)3.4.4检查Oracle相关资源的使用情况 (30)3.4.4.1 3.4.4.2 3.4.4.3 3.4.4.4 3.4.4.5 3.4.4.6 3.4.4.7 检查Oracle初始化文件中相关参数值 (30)检查数据库连接情况 (31)检查系统磁盘空间 (32)检查表空间使用情况 (32)检查一些扩展异常的对象 (33)检查system表空间内的内容 (33)检查对象的下一扩展与表空间的最大扩展值 (34)3.4.5检查数据库安全性 (34)3.4.5.1 3.4.5.2 检查系统安全日志信息 (35)检查用户修改密码 (35)3.4.6其他检查 (36)3.4.6.1 3.4.6.2 3.4.6.3 3.4.6.4 3.4.6.5 Oracle Job是否有失败 (36)监控数据量的增长情况 (36)检查失效的索引 (37)检查不起作用的约束 (37)检查无效的trigger (37)4 项目实施及管理 (38)4.1项目实施方案 (38)4.1.1项目实施策略 (38)4.1.2项目实施计划 (38)4.1.3项目交付文档 (39)4.1.3.1 4.1.3.2 交付要求 (39)提交文件资料 (39)5 支持服务体系 (40)5.1.1售后服务 (40)5.1.2电话支持 (40)5.1.3现场服务 (40)5.1.4电子邮件支持 (41)5.1.5紧急故障处理 (41)5.1.6 ORACLE定期巡检服务（24次/年） (41)6 培训方案 (41)6.1.1培训方式 (42)6.1.2教师、教材使用及授课语言 (42)6.1.3培训计划 (44)6.1.4培训分工 (44)Oracle数据库日常维护方案书1项目背景及目标1.1项目背景xxx信息化建设经过多年的发展和完善，已经建立成熟的网络环境及生产经营管理的各类应用系统，目前全厂在线运行的PC近600台，近年来建设的企业资产管理、基建 MIS 管理系统、全面预算管理系统、生产综合管理系统技术监督管理系统等若干应用信息系统多数是基于 Oracle 数据库系统的应用。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
29740, 00000, "evicted by member %s, group incarnation %s"
// *Cause: This member was evicted from the group by another member of the
//
cluster database for one of several reasons, which may
//
include a communications error in the cluster, failure to issue
//
a heartbeat to the control file, etc.
// *Action: Check the trace files of other active instances in the cluster
xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:10:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 19535 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:11:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 25890 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:12:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 33085 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:13:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 41839 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:14:09 CST 2016 …... xxdb1_netstat_16.10.08.1600.dat: 62215 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:17:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 63082 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:18:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 64273 packet reassembles failed xxdb1_netstat_16.10.08.1600.dat:zzz ***Sat Oct 8 16:19:09 CST 2016 xxdb1_netstat_16.10.08.1600.dat: 65436 packet reassembles failed
我们能够得到什么信息？
LMS进程的作用是什么 ？ LMD进程的作用是什么？ Oracle Rac 脑裂机制的判断方式？
数据库节点1的情况如何
Sat Oct 08 16:14:59 2016
？
Detected an inconsistent instance membership by instance 2
Errors in file /u01/../xxxx1_lmon_11382.trc (incident=363695):
ORA-29740: evicted by instance number 2, group incarnation 12
Incident details in: /u01/../xxxx1_lmon_11382_i363695.trc
Oracle数据库运维案例介绍
技术创新 变革未来
Sat Oct 08 16:14:10 2016 IPC Send timeout detected. Sender: ospid 11292 [oracle@xxxx (LMS3)] Receiver: inst 1 binc 429417348 ospid 11405 …… IPC Send timeout detected. Sender: ospid 11278 [oracle@xxxx (LMD0)] Receiver: inst 1 binc 429417294 ospid 11388 IPC Send timeout to 1.0 inc 10 for msg type 65518 from opid 12 Sat Oct 08 16:14:51 2016 IPC Send timeout detected. Sender: ospid 11270 [oracle@xxxx (PING)] Receiver: inst 1 binc 429417288 ospid 11376 Sat Oct 08 16:14:59 2016 Detected an inconsistent instance membership by instance 2 Evicting instance 1 from cluster
……
Errors in file /u01/../xxxx1_lmon_11382.trc:
ORA-29740: evicted by instance number 2, group incarnation 12
LMON (ospid: 11382): terminating the instance due to error 29740
//
group for indications of errors that caused a reconfiguration.PC Send timeout
网络问题造成丢包或通讯异常 主机资源（CPU、内存、I/O等）问题导致进程无法响应 Oracle BUG(例如Oracle DRM的一些bug)