Oracle 数据库服务内容-赵.docx

ORACLE 数据库

咨询服务提纲

赵元杰

2008年5月28日

目 录
第1章 技术支持与服务内容 3
1.1 应用系统前期咨询 3
1.1.1 应用系统规模分析 3
1.1.2 数据库系统选择分析 3
1.2 应用系统环境规划 4
1.2.1 服务环境的分析与规划 4
1.2.2 数据库系统的安装与环境配置 4
1.3 数据库系统维护服务 4
1.3.1 系统健康检查 4
1.3.2 系统安全分析 6
1.3.3 数据库系统性能问题分析与调整 6
1.4 数据库系统升级服务 7
1.5 应用系统数据重组 8
第2章 技术支持与服务案例 8
2.1 天津东方海陆集装箱码头应用系统 8
2.1.1 系统空间的回收 8
2.1.2 应用系统表行链接的消除 9
2.1.3 应用系统索引占用空间与扩展次数比较 9
2.1.4 应用系统表占用空间与扩展次数比较 10
2.1.5 应用系统性能上的改善比较 10
2.2 天津海关Quick Pass应用系统咨询与服务 10
2.2.1 应用系统需求分析 10
2.2.2 应用系统规划与安装服务 11
2.2.3 现场Oracle系统安装服务 11
2.3 天津汽车研究所应用系统升级服务 11
2.3.1 Oracle系统问题分析与方案 11
2.3.2 Oracle系统升级操作 12
2.3.3 Oracle系统升级报告 12

第1章 技术支持与服务内容

1.1 应用系统前期咨询
对于国内的用户来说，要进行信息化管理，就要上网络系统、服务器、购买相应的软件产品，比如：要求购置小型机、购买关系数据库系统、网络交换机等。那么，配置什么样的服务器、磁盘容量多少是一个关键的问题，这些问题如果没有事先进行严谨的分析，可能会在系统投入使用后不久就立即突显出来，比如：磁盘容量占满80%以上，性能不断下降等。归根到底，这是在上应用系统前没有针对应用系统的规模进行分析和估计的结果。

1.1.1 应用系统规模分析
我们将与用户一起对现有系统（无论是手工系统或已经在使用的MIS系统）进行分析、然后提出合理的服务器要求和磁盘空间需要，此外，可根据用户的特点给高可用性的方案。主要任务有：
l 应用系统规模分析；
l 服务器需求分析；
l 数据容量与磁盘空间分析；
l 安全性与高可用性分析。

1.1.2 数据库系统选择分析
我们通过对应用系统的规模，特点进行分析后，可提出应用对数据库系统的选择方案，如：
l 应用并发用户数量；
l 特殊对象数据量要求分析；
l 高峰期数据的I/O能力要求；
l 选择数据库系统建议。

1.2 应用系统环境规划
一般中大型的应用系统，在实际进行测试和正式使用前，都要进行严谨的分析、规划后，才能进行安装、测试、最后正式系统上线。如果我们对一个实际的应用系统不针对性的分析和设计，那么这个应用的性能问题就会在几个月后暴露出许多的问题，比如，经常产生死锁、某些大表一旦被使用导致所有用户感到速度慢等。这是在因为实际的应用与我们的测试环境有很大的差别。因此，我们建议进行下面的工作。

1.2.1 服务环境的分析与规划
我们一般都是根据应用系统的需要来制订购买服务器，比如，各子系统的数据容量、用户的分工与权限、磁盘实际空间的分配等。根据应用的需要和服务器实际的情况进行合理的规划是一项非常重要的工作，如果我们不加思考就将系统安装上去，就会导致有的系统资源需求不能满足要求，而有的应用系统则显得很空闲。为了使用整个系统能发挥整体的性能，我们要在系统正式安装与测试前进行规划，包括：
l 各子系统数据容量的分析；
l 特殊系统对资源需求分析，如月报统计等；
l 磁盘空间的规划与设置；
l 各子系统与权限的需求分析；
l Oracle系统的自定义安装方案与建议。
1.2.2 数据库系统的安装与环境配置
在完成规划后，给出完整的规划方案，在与用户交流和征求有关人员意见后，可进行具体的实施，包括：
l Oracle系统的自定义安装；
l 应用系统的配置(表空间的创建、用户的创建、权限的授予等)；
l 资源的分配（如使用CPU的比例等）
l Oracle系统的初始设置(如SGA设置、撤消表、排序区的设置等)

1.3 数据库系统维护服务
1.3.1 系统健康检查
一个应用系统投入运行后，希望系统能长期稳定、高性能地运行是每个用户的期望。但是往往在系统投入运行后不久就出现各种问题，如错误频繁、性能下降等。即使没有发现问题但可能潜在地存在一些问题。那么如何及时或预防性地处理一些即将发生的问题，采取主动的方式应对呢？关键就是要定期进行健康检查。我们提供的健康主要针对中大型应用在投入运行后潜在的问题的及时发现和对系统的趋势分析以预期发现系统的一些问题。如空间的增加趋势、撤消空间的需求变化、已经出现问题的分析与解决建议等。主要包括下面工作：

1.应用系统检查
l 用户所有表的约束信息
l 用户表的依赖关系信息
l 用户表中无效的主键
l 用户不被使用的索引

2.应用系统数据库安全检查
l 对象及其授予权限信息
l 用户及其被授予的系统权限
l 用户与被授予对象权限

3.应用系统PL/SQL程序检查
l 应用有关的存储过程信息
l 应用中触发器代码与状态
l 数据库快照
l 数据库作业
l 实体视图

4.Oracle系统检查
l ORACLE系统用户
l ORACLE系统资源文件
l ORACLE系统参数

5.Oracle系统数据文件与表空间
l ORACLE系统数据文件
l 表空间的自由空间信息
l 表空间碎片信息
l 数据文件的I/O情况

6.Oracle系统日志文件与控制文件检查
l ORACLE系统日志文件组信息
l ORACLE系统日志文件成员大小信息
l ORACLE系统控制文件个数
l ORACLE系统控制文件分布

7.Oracle系统撤消表空间
l 撤消表与数据文件
l 撤消表空间使用统计

8.Oracle系统排序与临时段
l ORACLE系统排序区参数
l ORACLE系统临时表空间与数据文件
l 排序操作情况统计

9.Oracle系统SGA区
l 数据缓冲区
l 共享池
l 重做日志缓冲区

10.Oracle系统竞争
l ORACLE系统竞争检查
l 过多的分析SQL语句
l Latch 检查

11.Oracle系统警告日志文件
l 检查错误为ORA-
l 检查警告信息
l 是否存在严重错误

1.3.2 系统安全分析
由于应用系统的数据的重要性，确保应用数据的安全性一是项重要的工作。我们不但从认识上重视，而且从技术上要落实。那么一个基于Oracle数据库系统的应用系统，他的安全是否存在漏洞呢？，我们要对系统进行具体分析。分析的任务包括：

l 数据库安全管理设计与设置
l 应用系统精细审计
l 重要表操作数据丢失的预防
l 系统访问与权限授权分析与调整

1.3.3 数据库系统性能问题分析与调整
国外有专家说过，“计算机再快，用户也不会嫌太快”。而实际情况是：当应用运行半年后，应用系统的性能下降很快，有些系统到了用户不能忍受的地步。性能慢的原因可能除了硬件的原因外，更多的情况是在于应用系统的设计与环境的配置等。也就是说，系统慢不一定是服务的配置不够造成的。这就希望我们能找出系统性能不能满足需要的原因。
1.3.3.1 数据库系统性能维护
检查系统性能问题的主要任务之一就是检查Oracle系统的有关项，比如：
l SGA性能监视、分析与调整
l 临时段（或回滚段）监测与调整
l 排序区运行情况分析与调整
l 数据库并发用户检测与运行模式的调整
l 数据文件与日志文件等的分布调整

1.3.3.2 应用系统设计问题分析与调整
除了检查Oracle系统的配置是否合理外，应用系统的设计是否合理也是导致系统性能的原因之一，所以我们将根据多年来对应用系统设计与开发的经验，对应用系统的结构等进行分析，找出是否存在明显不合理的设计问题，主要任务是：

l 逻辑设计与物理设计存在问题分析与调整
l 表结构设计问题检测与调整
l 特殊大表设计问题检测与调整
l 数据库表存储问题检测与调整
l 数据库表一致性与完整性问题检查与调整
l 特殊长时间运行程序的分析与修改
l 一般的SQL优化

1.3.3.3 数据库系统故障排除
对数据库发生的故障(如数据库不能正常运行，备份与恢复不能进行，数据文件一致性破坏等)或错误进行捕获与分析，从而提出解决方法。

l 数据库系统错误的自动捕捉与显示
l 应用系统固定错误的分析
l 错误的解决方法与建议
l 现场解决错误

1.4 数据库系统升级服务
一般来说，在下面几种情况下用户希望将系统进行升级，比如：目前的版本太旧，产品供应尚不能再提供技术支持；当前版本存在一些BUG，系统升级后可避免；上新的服务器或应用系统升级等。我们可提供下面的升级服务技术支持。
l 旧系统问题分析；
l 升级所需要的环境与问题分析；
l 升级的实施建议方案；
l 现场升级操作或指导。

1.5 应用系统数据重组
任何经过严谨的分析、规划、设计的系统，也会存在可优化或可完善的地方。这是因为前期我们所做的工作是一种估算或预测，即使我们是一些很有经验的专家，也不能完全保证应用系统的需要没有变化。总之，应用系统存在不合理的地方可通过重组来消除或减少等。我们可提供下面的应用系统重组技术服务：
l 应用系统问题分析；
l 磁盘空间的平衡分析；
l 应用系统关键对象重组方案；
l 应用系统数据库结构的重组方案；
l 磁盘文件重组方案；
l 现场重组操作或指导。

第2章 技术支持与服务案例
本章给出三个有代表性的技术服务案例的说明供用户参考，类似的技术支持案例省去。
2.1 天津东方海陆集装箱码头应用系统
天津东方海陆集装箱码头应用系统是一个24X365不间断运行的应用系统，它与世界的多个系统进行连接，自从2002年开始投入运行。由于系统本身具有不允许停机的特点和业务数据的不断增加，导致系统性能不断下降，更为严重的是磁盘的可用空间越来越少，因此，在不增加现有环境的磁盘容量的前提下，通过对系统的调整和重组来实现性能的改善与空间的部分回收是用户的需求。
我们通过与用户的交流和对应用系统的认真分析，提出系统优化与重组的建议方案，选择系统的重组的时机，制定严谨的重组操作步骤，分别选择在2005年和2006年的两个春节业务最少的时间段内对系统进行了调整，收到较好的效果。
下表是应用系统调整前后磁盘空间的使用情况对比。
2.1.1 系统空间的回收
下表是调整前后空间占用情况的对比：
表空间
调整前占空间
调整后占空间
说明
数据表空间
16GB
10GB
调整前表空间为USER_DATA
调整前表空间为USER_DATA1
索引表空间
9.4GB
5.5GB
调整前表空间为USER_IDX
调整前表空间为USER_IDX1
小计
25.4GB
15.5GB

2.1.2 应用系统表行链接的消除
行链接是影响查询处理的关键因素，在调整前有几个表（分析过的表才能查询到是否存在行链接）存在较多的行链接，在移植后行链接全部消除。
表 名
调整前行链接数
调整前行链接数
CONTAINER
80334
0
STOW_HIST
44183
0
CARGO_DTL
320
0
CARGO_RMK
300
0
CARGO_ACTIVITY
52
0
CNTR_LOC
46
0
CARGO_ORDER
1
0
TRAF_HIST
1
0

2.1.3 应用系统索引占用空间与扩展次数比较
下表是CTMS主要前10个索引的空间扩展情况比较。
索引名
重建前
重建后
占空间字节数
扩展次数
占空间字节数
扩展总数
CNTR_HIST_SEQ
1,049,034,752
26
629,145,600
3
IDX_CARGO_HIST_DOC_NO
360,652,800
31
230,686,720
3
PK_YARD_POOL
199,229,440
23
209,715,200
11
IDX_CARGO_MORE
251,740,160
21
167,772,160
7
CNTR_LOC_HIST_VVD
262,144,000
16
157,286,400
6
IDX_CHARGE_NO_SEQ
251,658,240
15
146,800,640
5
IDX_CLIENT_INVOICE_VESSEL
230,219,776
14
146,800,640
5
IDX_CNTR_MOVE_HIST
262,144,000
16
136,314,880
4
IDX_CLIENT_INVOICE
241,172,480
14
125,829,120
3
IDX_CARGO_HIST_SVCDATE
134,938,624
13
120,586,240
14
小计
3243,004,272 B
189
2070,937,600 B
61

2.1.4 应用系统表占用空间与扩展次数比较
表是前10个关键表在重组前、后所占空间的比较。

表名
调整前
调整后
占空间字节数
扩展次数
占空间字节数
扩展总数
CNTR_HIST
5,075,107,840
33
3,670,016,000
6
CLIENT_INVOICE
2,421,555,200
35
1,572,864,000
8
TRAF_HIST
1,520,435,200
20
1,153,433,600
7
CARGO_HIST
1,237,319,680
45
1,048,576,000
6
CONTAINER
465,928,192
27
534,773,760
8
STOW_HIST
912,261,120
20
524,288,000
3
BOOK_HIST
578,961,408
34
419,430,400
6
CY_SUMMARY
578,961,408
34
209,715,200
6
YARD_POOL
191,397,888
46
199,229,440
12
LOADLIST_LOG
146,800,640
13
157,286,400
10
小计
13128,728,576 B
307
8441,036,040 B
72
2.1.5 应用系统性能上的改善比较
下表是调整前、后几个关键表的全表扫描所用CPU时间的情况比较。

表名
调整前
调整后
总行数
全表扫描秒数
总行数
全表扫描秒数
CNTR_HIST
16024484
00: 02: 12.20
16024484
00: 01: 79.24
TRAF_HIST
3587947
00: 00: 23.40
3587947
00: 00: 14.30
CARGO_HIST
5293703
00: 00: 29.23
5293703
00: 00: 22.53
STOW_HIST
1626705
00: 00: 32.16
1626705
00: 00: 11.36
CONTAINER
1715838
00: 00: 12.16
1715838
00: 00: 08.20

2.2 天津海关Quick Pass应用系统咨询与服务
QuickPass应用系统是海关总署主推的海关快速通关的业务系统，该应用系统要求在Oracle企业级的数据库系统下运行，应用系统的高可用性要求很高。因此，在正式上该应用系统前要进行规模分析和高可用性分析。以便满足QuickPass应用系统的发展需要。

2.2.1 应用系统需求分析
我们针对QuickPass应用的特点，结合天津的要求，对应用系统所需的服务器配置、磁盘容量、备份系统等进行了分析，给出了Quick Pass应用系统配置建议，包括：

l Quick Pass系统架构建议
l Quick Pass应用系统对环境要求的建议
l Oracle版本选择建议；
l 高可用性软件选择。

2.2.2 应用系统规划与安装服务
我们针对服务器与磁盘空间的实际情况进行规划和设计，给出了QuickPass应用系统规划与设计说明书。包括：
l 服务器子系统的规划与设计说明
l QuickPass系统数据库设计
l Oracle 9i QuickPass安全设计
l Oracle 9i Quick Pass高可用性设计

2.2.3 现场Oracle系统安装服务
我们根据前期的规划与设计，到现场进行了Oracle系统的安装，包括：
l Oracle 9i 系统的安装；
l 数据卫士的配置(Data Guard)；
l 应用系统表空间的创建；
l 应用系统用户的创建与授权；
l Oracle系统基本参数的配置。

2.3 天津汽车研究所应用系统升级服务
天津汽车研究所的应用系统所运行的数据库服务器：SUN SPARC V880小型机；服务器操作系统版本：SunOS V880 5.8 Generic_117350-02 sun4u sparc SUNW,Sun-Fire-880。数据库系统是Oracle R9.2.0.1.0。由于Oracle R9.2.0.1.0 版本存在一些Bug，导致系统的稳当性差，加上原来安装Oracle R9.2.0.1.0时选择了ZHS16CGB231280字符集，使一些冷僻汉字不能正确存储，导致遇到冷僻汉字查询时总是出现“?”符号。用户要求将现在Oracle R9.2.0.1.0升级到 R9.2.0.6.0上，并要求解决冷僻汉字的存储与显示问题。

2.3.1 Oracle系统问题分析与方案
我们针对现有系统的情况进行分析，提出可行的升级方案。主要工作有：
l 现有系统分析初步
l 系统升级方案
2.3.2 Oracle系统升级操作
当对现有的问题进行认真的分析后，得出了解决问题的方法。接着制定一套完整的升级操作方案，在与用户商量和确认后，选择了周末进行升级的时机。升级的主要任务是：
l 下载Oracle 9i 升级包软件；
l 现有系统的数据备份；
l 删除现有的数据库系统；
l 重创建数据库系统；
l 恢复应用系统数据；
l 检查与测试应用的数据的正确性，包括冷僻汉字的存储与显示；
l 升级数据库系统到 R9.2.0.6.0；
l 测试应用系统的可用性。

2.3.3 Oracle系统升级报告
在完成Oracle R9.2.0.1.0升级到 R9.2.0.6.0的升级和应用系统的迁移后，为了帮助用户在以后的升级中能自己进行操作，我们将升级和迁移过程整理成文档。为用户提供详细的升级操作说明书，主要内容涵盖：
l 应用系统备份操作；
l 创建库的创建操作；
l 应用系统的恢复操作；
l 数据库系统的升级操作等。