售后服务O数据库服务内容赵.docx
《售后服务O数据库服务内容赵.docx》由会员分享，可在线阅读，更多相关《售后服务O数据库服务内容赵.docx（13页珍藏版）》请在冰豆网上搜索。
售后服务O数据库服务内容赵
（售后服务）O数据库服务内容赵
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天津海关QuickPass应用系统咨询和服务10
2.2.1应用系统需求分析10
2.2.2应用系统规划和安装服务11
2.2.3现场Oracle系统安装服务11
2.3天津汽车研究所应用系统升级服务11
2.3.1Oracle系统问题分析和方案11
2.3.2Oracle系统升级操作12
2.3.3Oracle系统升级方案12
第1章技术支持和服务内容
1.1应用系统前期咨询
对于国内的用户来说，要进行信息化管理，就要上网络系统、服务器、购买相应的软件产品，比如：
要求购置小型机、购买关系数据库系统、网络交换机等。
那么，配置什么样的服务器、磁盘容量多少是壹个关键的问题，这些问题如果没有事先进行严谨的分析，可能会于系统投入使用后不久就立即突显出来，比如：
磁盘容量占满80%之上，性能不断下降等。
归根到底，这是于上应用系统前没有针对应用系统的规模进行分析和估计的结果。
1.1.1应用系统规模分析
我们将和用户壹起对现有系统（无论是手工系统或已经于使用的MIS系统）进行分析、然后提出合理的服务器要求和磁盘空间需要，此外，可根据用户的特点给高可用性的方案。
主要任务有：
●应用系统规模分析；
●服务器需求分析；
●数据容量和磁盘空间分析；
●安全性和高可用性分析。
1.1.2数据库系统选择分析
我们通过对应用系统的规模，特点进行分析后，可提出应用对数据库系统的选择方案，如：
●应用且发用户数量；
●特殊对象数据量要求分析；
●高峰期数据的I/O能力要求；
●选择数据库系统建议。
1.2应用系统环境规划
壹般中大型的应用系统，于实际进行测试和正式使用前，均要进行严谨的分析、规划后，才能进行安装、测试、最后正式系统上线。
如果我们对壹个实际的应用系统不针对性的分析和设计，那么这个应用的性能问题就会于几个月后暴露出许多的问题，比如，经常产生死锁、某些大表壹旦被使用导致所有用户感到速度慢等。
这是于因为实际的应用和我们的测试环境有很大的差别。
因此，我们建议进行下面的工作。
1.2.1服务环境的分析和规划
我们壹般均是根据应用系统的需要来制订购买服务器，比如，各子系统的数据容量、用户的分工和权限、磁盘实际空间的分配等。
根据应用的需要和服务器实际的情况进行合理的规划是壹项非常重要的工作，如果我们不加思考就将系统安装上去，就会导致有的系统资源需求不能满足要求，而有的应用系统则显得很空闲。
为了使用整个系统能发挥整体的性能，我们要于系统正式安装和测试前进行规划，包括：
●各子系统数据容量的分析；
●特殊系统对资源需求分析，如月报统计等；
●磁盘空间的规划和设置；
●各子系统和权限的需求分析；
●Oracle系统的自定义安装方案和建议。
1.2.2数据库系统的安装和环境配置
于完成规划后，给出完整的规划方案，于和用户交流和征求有关人员意见后，可进行具体的实施，包括：
●Oracle系统的自定义安装；
●应用系统的配置（表空间的创建、用户的创建、权限的授予等）；
●资源的分配（如使用CPU的比例等）
●Oracle系统的初始设置（如SGA设置、撤消表、排序区的设置等）
1.3数据库系统维护服务
1.3.1系统健康检查
壹个应用系统投入运行后，希望系统能长期稳定、高性能地运行是每个用户的期望。
可是往往于系统投入运行后不久就出现各种问题，如错误频繁、性能下降等。
即使没有发现问题但可能潜于地存于壹些问题。
那么如何及时或预防性地处理壹些即将发生的问题，采取主动的方式应对呢？
关键就是要定期进行健康检查。
我们提供的健康主要针对中大型应用于投入运行后潜于的问题的及时发现和对系统的趋势分析以预期发现系统的壹些问题。
如空间的增加趋势、撤消空间的需求变化、已经出现问题的分析和解决建议等。
主要包括下面工作：
1.应用系统检查
●用户所有表的约束信息
●用户表的依赖关系信息
●用户表中无效的主键
●用户不被使用的索引
2.应用系统数据库安全检查
●对象及其授予权限信息
●用户及其被授予的系统权限
●用户和被授予对象权限
3.应用系统PL/SQL程序检查
●应用有关的存储过程信息
●应用中触发器代码和状态
●数据库快照
●数据库作业
●实体视图
4.Oracle系统检查
●ORACLE系统用户
●ORACLE系统资源文件
●ORACLE系统参数
5.Oracle系统数据文件和表空间
●ORACLE系统数据文件
●表空间的自由空间信息
●表空间碎片信息
●数据文件的I/O情况
6.Oracle系统日志文件和控制文件检查
●ORACLE系统日志文件组信息
●ORACLE系统日志文件成员大小信息
●ORACLE系统控制文件个数
●ORACLE系统控制文件分布
7.Oracle系统撤消表空间
●撤消表和数据文件
●撤消表空间使用统计
8.Oracle系统排序和临时段
●ORACLE系统排序区参数
●ORACLE系统临时表空间和数据文件
●排序操作情况统计
9.Oracle系统SGA区
●数据缓冲区
●共享池
●重做日志缓冲区
10.Oracle系统竞争
●ORACLE系统竞争检查
●过多的分析SQL语句
●Latch检查
11.Oracle系统警告日志文件
●检查错误为ORA-
●检查警告信息
●是否存于严重错误
1.3.2系统安全分析
由于应用系统的数据的重要性，确保应用数据的安全性壹是项重要的工作。
我们不但从认识上重视，而且从技术上要落实。
那么壹个基于Oracle数据库系统的应用系统，他的安全是否存于漏洞呢？
，我们要对系统进行具体分析。
分析的任务包括：
●数据库安全管理设计和设置
●应用系统精细审计
●重要表操作数据丢失的预防
●系统访问和权限授权分析和调整
1.3.3数据库系统性能问题分析和调整
国外有专家说过，“计算机再快，用户也不会嫌太快”。
而实际情况是：
当应用运行半年后，应用系统的性能下降很快，有些系统到了用户不能忍受的地步。
性能慢的原因可能除了硬件的原因外，更多的情况是于于应用系统的设计和环境的配置等。
也就是说，系统慢不壹定是服务的配置不够造成的。
这就希望我们能找出系统性能不能满足需要的原因。
1.3.3.1数据库系统性能维护
检查系统性能问题的主要任务之壹就是检查Oracle系统的有关项，比如：
●SGA性能监视、分析和调整
●临时段（或回滚段）监测和调整
●排序区运行情况分析和调整
●数据库且发用户检测和运行模式的调整
●数据文件和日志文件等的分布调整
1.3.3.2应用系统设计问题分析和调整
除了检查Oracle系统的配置是否合理外，应用系统的设计是否合理也是导致系统性能的原因之壹，所以我们将根据多年来对应用系统设计和开发的经验，对应用系统的结构等进行分析，找出是否存于明显不合理的设计问题，主要任务是：
●逻辑设计和物理设计存于问题分析和调整
●表结构设计问题检测和调整
●特殊大表设计问题检测和调整
●数据库表存储问题检测和调整
●数据库表壹致性和完整性问题检查和调整
●特殊长时间运行程序的分析和修改
●壹般的SQL优化
1.3.3.3数据库系统故障排除
对数据库发生的故障（如数据库不能正常运行，备份和恢复不能进行，数据文件壹致性破坏等）或错误进行捕获和分析，从而提出解决方法。
●数据库系统错误的自动捕捉和显示
●应用系统固定错误的分析
●错误的解决方法和建议
●现场解决错误
1.4数据库系统升级服务
壹般来说，于下面几种情况下用户希望将系统进行升级，比如：
目前的版本太旧，产品供应尚不能再提供技术支持；当前版本存于壹些BUG，系统升级后可避免；上新的服务器或应用系统升级等。
我们可提供下面的升级服务技术支持。
●旧系统问题分析；
●升级所需要的环境和问题分析；
●升级的实施建议方案；
●现场升级操作或指导。
1.5应用系统数据重组
任何经过严谨的分析、规划、设计的系统，也会存于可优化或可完善的地方。
这是因为前期我们所做的工作是壹种估算或预测，即使我们是壹些很有经验的专家，也不能完全保证应用系统的需要没有变化。
总之，应用系统存于不合理的地方可通过重组来消除或减少等。
我们可提供下面的应用系统重组技术服务：
●应用系统问题分析；
●磁盘空间的平衡分析；
●应用系统关键对象重组方案；
●应用系统数据库结构的重组方案；
●磁盘文件重组方案；
●现场重组操作或指导。
第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,272B
189
2070,937,600B
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,576B
307
8441,036,040B
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天津海关QuickPass应用系统咨询和服务
QuickPass应用系统是海关总署主推的海关快速通关的业务系统，该应用系统要求于Oracle企业级的数据库系统下运行，应用系统的高可用性要求很高。
因此，于正式上该应用系统前要进行规模分析和高可用性分析。
以便满足QuickPass应用系统的发展需要。
2.2.1应用系统需求分析
我们针对QuickPass应用的特点，结合天津的要求，对应用系统所需的服务器配置、磁盘容量、备份系统等进行了分析，给出了QuickPass应用系统配置建议，包括：
●QuickPass系统架构建议
●QuickPass应用系统对环境要求的建议
●Oracle版本选择建议；
●高可用性软件选择。
2.2.2应用系统规划和安装服务
我们针对服务器和磁盘空间的实际情况进行规划和设计，给出了QuickPass应用系统规划和设计说明书。
包括：
●服务器子系统的规划和设计说明
●QuickPass系统数据库设计
●Oracle9iQuickPass安全设计
●Oracle9iQuickPass高可用性设计
2.2.3现场Oracle系统安装服务
我们根据前期的规划和设计，到现场进行了Oracle系统的安装，包括：
●Oracle9i系统的安装；
●数据卫士的配置（DataGuard）；
●应用系统表空间的创建；
●应用系统用户的创建和授权；
●Oracle系统基本参数的配置。
2.3天津汽车研究所应用系统升级服务
天津汽车研究所的应用系统所运行的数据库服务器：
SUNSPARCV880小型机；服务器操作系统版本：
SunOSV8805.8Generic_117350-02sun4usparcSUNW,Sun-Fire-880。
数据库系统是OracleR9.2.0.1.0。
由于OracleR9.2.0.1.0版本存于壹些Bug，导致系统的稳当性差，加上原来安装OracleR9.2.0.1.0时选择了ZHS16CGB231280字符集，使壹些冷僻汉字不能正确存储，导致遇到冷僻汉字查询时总是出现“?
”符号。
用户要求将当下OracleR9.2.0.1.0升级到R9.2.0.6.0上，且要求解决冷僻汉字的存储和显示问题。
2.3.1Oracle系统问题分析和方案
我们针对现有系统的情况进行分析，提出可行的升级方案。
主要工作有：
●现有系统分析初步
●系统升级方案
2.3.2Oracle系统升级操作
当对现有的问题进行认真的分析后，得出了解决问题的方法。
接着制定壹套完整的升级操作方案，于和用户商量和确认后，选择了周末进行升级的时机。
升级的主要任务是：
●下载Oracle9i升级包软件；
●现有系统的数据备份；
●删除现有的数据库系统；
●重创建数据库系统；
●恢复应用系统数据；
●检查和测试应用的数据的正确性，包括冷僻汉字的存储和显示；
●升级数据库系统到R9.2.0.6.0；
●测试应用系统的可用性。
2.3.3Oracle系统升级方案
于完成OracleR9.2.0.1.0升级到R9.2.0.6.0的升级和应用系统的迁移后，为了帮助用户于以后的升级中能自己进行操作，我们将升级和迁移过程整理成文档。
为用户提供详细的升级操作说明书，主要内容涵盖：
●应用系统备份操作；
●创建库的创建操作；
●应用系统的恢复操作；
●数据库系统的升级操作等。
升级会员 