三招助你做好Oracle数据库备份测试

三招助你做好Oracle数据库备份测试,第1张

数据库备份是保障数据库安全的重要手段之一 绝大部分数据库管理员都已经发现对数据库进行备份的重要性 甚至对其具有很大的依赖性 为此数据库管理员必需肯定备份策略确实可靠 一个没有经过测试的备份策略其实比没有进行备份更加糟糕 因为它会给各位数据库管理员一种假的安全感

但是笔者发现不少的数据库管理员在遇到服务器故障时 却不时的会遇到无法顺利利用故障文件恢复数据库或者数据库备份文件不完整等问题 这主要是因为大家只注重数据库的备份策略 但是却忽视了数据库备份文件的测试策略 如果备份文件不完整或者出现错误的话 那么及时备份策略制定的再好 也是竹篮子打水一场空 为此笔者在这里郑重建议大家 数据库备份测试策略与数据库备份策略一样的重要 那么做为Oracle数据库管理员 该如何做好这方面的测试工作呢?对此笔者有一家几个招数 或许能够帮助大家解决这方面的问题

招数一 模拟各种现实中可能出现的问题

很多原因会导致数据库服务器罢工 而这些罢工很有可能造成数据库中现有数据的损坏 为此数据库管理员必需凭借自己的经验列举出现实中可能出现的故障情况 然后针对这些可能发生的故障 去测试现有备份策略能否有效的应对

如笔者给企业部署完Oracle数据库之后 一般都会模拟各种现实中可能出现的问题 然后针对这些问题进行一一测试 如笔者会在一个更新事务处理的过程中 突然关闭电源 然后再重新启动数据库服务器 查看这次断电事故对服务器可能造成哪些影响?能否利用现有的备份文件与日志文件把数据库中的数据恢复到断电的那一个点上?如笔者还会测试用户错误的更新了大量的数据 并且已经递交了事务 此时需要测试看看能否利用重做日至文件来恢复更新之前的数据?如企业如果采用了磁盘阵列的话 那么笔者还需要测试磁盘阵列的有效性 如把某一块硬盘拿掉 添加上一块新的硬盘 看看其数据库服务器能否正常恢复数据 总之一句话 通过模拟各种失败以及从这些失败中进行恢复 看看能否恢复到故障发生时的点 这些测试工作将会给数据库管理员获得书本上没有的无价经验

具体来说 笔者认为数据库管理员在模拟失败时 以下几个失败的原因不能够放过 一是服务器突然断电 这可能导致配置文件的错误导致无法访问或者数据的丢失二是重做日志发生损坏 这可能导致数据库管理员无法把数据恢复到故障发生时的点三是硬盘发生故障而导致数据丢失 这主要是要测试备份文件异地存放的有效性四是数据批量更新的错误处理 这主要是测试数据库管理员在进行批量更新之前是否有先对数据库进行备份的习惯 等等 数据库管理员只有预先模拟现实中各种可能出现的问题 并得到解决方案 只有如此 在真正遇到这些问题的时候 数据库管理员才能够临危不乱 迅速解决故障

当然这些测试最好是能够在另外一台主机上进行测试 在生产服务器上进行这些破坏性测试的话 可不是一个明智的做法

招数二 需要详细记录备份与还原测试的数据

笔者建议数据库管理员 无论你做了哪些测试 测试的工作是否充分 都需要一五一十的记录下相关的备份与还原测试数据 因为这些故障可能随时发生 到那个时候可没有时间让数据库管理员去研究分析该如何处理 那时如果数据库管理员有类似文档的话 那么只要按照相关文档去处理 就可以减少中间思考的时间 可以迅速利用备份文件与日志文档进行数据库恢复作业

具体来说 笔者认为数据库管理员在测试的时候需要记录如下内容

一是需要记录遇到故障时还原所需要用到的文件以及基本的 *** 作步骤 如当发生硬盘故障时 此时需要恢复故障硬盘中的数据 需要用到哪些文件(可能需要用到保存在其他硬盘上的备份文件与重做日志文件) 以及一些 *** 作步骤 记录这些内容有利于数据库管理员在遇到问题的时候迅速找到这些文件并且熟练的应用这些文件进行数据库的恢复作业

二是需要记录备份或者恢复过程中遇到的意外事件 虽然只是模拟失败 但是这个故障以及解决故障过程中出现的意外事件 在实际工作中很有可能会出现 而数据库管理员在遇到这些意外事件时能否轻松应对则是考验数据库管理员能力的地方 笔者在日常工作中 对于这些意外事件无论大小都会一一的进行记录 并且对于如何解决这些意外也会做相关的说明 要知道 这些内容可是数据库管理员的无价之宝 因为这些东西在任何教科书上或者讲座上都是学不到的 只要在模拟过程中经历了一次失败 数据库管理员就应该把当时的情况以及如果处理这种意外事件的解决方案加入到你的工作笔记中 必须切记 意外事件往往不会只发生一次 它很有可能在未来的某个时刻再次发生 养成及时更新自己的工作笔记的习惯 有利于数据库管理员提高自身的水平 提高应对意外事件的能力

三是要勤于跟其他这方面的专家进行交流 如笔者经常会逛各种论坛 在论坛上 有些数据库管理员会把自己遇到的问题在上面列出来 有不少就是在备份或者恢复过程中出现的一些意外事件 这些意外事件有些是数据库管理员以前遇到过的 而有些则是由于工作经验限制没有碰见过的 但是很有可能在以后的工作中为碰到 为此数据库管理员需要预先去了解 收集这些别人碰到的问题 并在可能的情况下模拟这些意外事件 并寻求解决方案 因为别人遇到的意外情况 很可能我们自己在下次也可能会遇到 防范与未然 提早想好解决措施 有利于我们在遇到这些问题时 迅速采取有力的措施解决

招数三 测试 测试 再测试

俗话说 熟能生巧 如果数据库管理员了解了意外事件 也知道该如何处理 但是如果因为不熟悉相关的 *** 作 则很可能会因为 *** 作不当而造成新的意外事件或者造成不可挽回的损失 所以数据库管理员在工作比较空的时候 需要对这些解决方案进行测试 一来是看看随着数据库版本的升级 这些解决方案是否仍然有效二是提高自己 *** 作的熟练程度 确保以后在遇到类似故障时能够万无一失的进行 *** 作

为了达到这个目的 笔者对自己提出了如下几个要求

一是当数据库新版本出来之后 需要对工作笔记中记录下的解决方案进行测试 以判断这些解决方案是否过期 没有过期最好 如果过期了的话 则必须解决它 如需要考虑这些意外事件在新版中是否仍然会出现 如果仍然会出现的话 则就要在新版本功能的基础上寻找新的解决方案 有些意外事件则可能会随着数据库版本的升级而被解决掉 故数据库管理需要随着数据库版本的升级而不断的进行测试 以提高相关解决方案的时效性

二是给企业部署完成新的解决方案之后 需要挑选一些重要的内容进行测试 如笔者给企业部署完成Oracle数据库(采用磁盘阵列) 如果要模拟所有的失败情况并测试相关对解决方案是否可行是不现实的 因为这需要花费很长的时间 得不偿失 此时笔者会挑选一些重要的或者经常发生的意外情况 并测试相关的解决方案是否可行 同时 这也是对企业用户的一种培训 以提高他们独立自主解决问题的能力 如对于上面这个案例 笔者会跟数企业用户一起 进行磁盘阵列有效性的测试 如换一块新的硬盘之后看看数据库服务器是否会自动恢复相关的数据 把企业用户培养起来了 那么我们数据库管理员也可以轻松很多

三是对于一些新的解决方案也需要进行测试 如笔者平时比较喜欢逛论坛 在论坛上有人提出一个问题 后面有很多数据库管理员会把相关的方案写出来 这些方案有些可能是数据库管理员已经知道了的有些则是他们还没有想到的 此时数据库管理员需要对新的方案进行测试 因为也许这个新的解决方案能够在更短时间内解决故障

lishixinzhi/Article/program/Oracle/201311/16673

查询输入:

(1)分别对单条件进行精确查询

(2)输入长度的检验,输入允许的最长值进行查询,是否支持

(3)两个查询条件是否为2选1,来回选择是否出现页面错误

(4)输入字符

(5)输入特殊字符

(6)输入数字

(7)输入汉字

(8)输入关系表达式与、或、异或、非、等于

(9)输入空格

(10)条件中含有空格

(11)输入超长字符

(12)输入全角字符

(13)输入单引号

(14)输入单引号引起来的数据

(15)输入双引号

(16)输入双引号引起来的数据

(17)如果支持模糊查询,输入部分查询条件

(18)输入系统中不存在与之匹配的条件

查询结果检查

(1)查询结果按什么顺利排序

(2)查询结果是否根据字段显示排序功能

(3)查询结果是否有分页,如果有,每页最多包含多少记录

(4)查询结果是否匹配

(5)查询结果是否与数据库一致

(6)查询结果是精确查询还是模糊查询

UI验证

(1)文字显示是否正确

(2)页面是否有错别字

(3)输入框大小、文字大小是否合适

(4)页面是否美观

(5)查询结果字段显示是否与需求一致

性能方面

(1)查询处理时间是否能接受

(2)数据库中存在大数据量数据时,查询时间是否能接受

(3)当多个用户同时查询时,输入相同或不同的查询条件系统响应是否及时...

比如:数据冗余,功能和性能方面存在的问题已经严重影响应用软件的使用。软件测试人员往往重视对软件功能和编码的测试,而忽略对软件性能,特别是数据库访问并发测试。因为,他们固有的思想中认为数据库设计存在问题对系统性能影响不大,或从根本上忽略了数据库在软件开发中的地位,直到出现了问题,才想到对数据库的测试,但往往也是仅仅通过对编码的测试工作中捎带对数据库进行一定的测试,这远远是不够的。目前,中铁网上订票系统在大用户同时在线订票中系统频频瘫痪,就是最好的佐证。 所以,在应用软件的测试工作中,应该将数据库作为一个独立的部分进行充分的测试,这样才可以得到应用软件所需要的性能优化的数据库。那么,应该对哪些内容进行测试,如何进行测试呢? 2、数据库设计的测试 数据库是应用的基础,其性能直接影响应用软件的性能。为了使数据库具有较好的性能,需要对数据库中的表进行规范化设计。规范化的范式可分为第一范式、第二范式、第三范式、BCNF范式、第四范式和第五范式。一般来说,逻辑数据库设计应满足第三范式的要求,这是因为满足第三范式的表结构容易维护,且基本满足实际应用的要求。因此,实际应用中一般都按照第三范式的标准进行规范化。但是,规范化也有缺点:由于将一个表拆分成为多个表,在查询时需要多表连接,降低了查询速度。故数据库设计的测试包括前期需求分析产生数据库逻辑模型和后期业务系统开发中的测试两部分(这里指的是后者),我在这里称为实体测试。 数据库是由若干的实体组成的,包括(表,视图,存储过程等),数据库最基本的测试就是实体测试,通过对这些实体的测试,可以发现数据库实体设计得是否充分,是否有遗漏,每个实体的内容是否全面,扩展性如何。 实体测试,可以用来发现应用软件在功能上存在的不足,也可以发现数据冗余的问题。经过测试,测试人员对有异议的问题要及时和数据库的设计人员进行沟通解决。 3、数据一致性测试 在进行实体测试后,应进一步检查下面的内容以保障数据的一致性: 3.1 表的主键测试根据应用系统的实际需求,对每个表的主键进行测试,验证是否存在记录不唯一的情况,如果有,则要重新设置主键,使表中记录唯一。 3.2 表之间主外键关系的测试数据库中主外键字段在名称,数据类型,字段长度上的一致性测试。 3.3 级联表,删除主表数据后,相应从报表数据应同时删除的问题例如学生表和学生成绩表,学生数据已经删除,成绩表中相应学生的成绩记录应同时删除。 3.4 存储过程和触发器的测试存储过程可以人工执行,但触发器不能人工处理,所以在对存储过程和触发器执行的过程中针对SQL SERVER2005及以上版本可以使用Microsoft SQL Server Profiler性能测试工具进行测试。 Microsoft SQL Server Profiler 是 SQL 跟踪的图形用户界面,用于监视数据库引擎或 Analysis Services 的实例。测试人员可以捕获有关每个事件的数据并将其保存到文件或表中供以后分析。例如:可以对生产环境进行监视,了解哪些存储过程由于执行速度太慢影响了性能。 4、数据库的容量测试 随着数据库系统的使用,数据量在飞速增长,如何在使用前对数据容量的增长情况进行初步估算,为最终用户提供参考,这在数据库使用和维护过程中,是非常重要的。可以通过对数据库设计中基本表的数据大小,和每天数据表的数据产生量进行初步估算。 记录数据量=各个字段所占字节数的总和表的数据量=记录数据量*记录数数据库大小=各表数据量的总和 当然,数据库的大小不仅仅只是基本表的大小,还有系统表,视图,存储过程等其它实体所占的容量,但最基本的数据是表的数据。另外,数据库的容量还包括数据库日志文件的容量,一般应预留数据库文件的2倍左右。 5、数据库的性能测试 应用软件除了功能外,很重要的一部分就是软件的性能,而对于数据库系统,数据库性能的好坏会直接影响应用软件的性能,这部分的测试,一般手工测试就显得无能为力了,这时就要借助自动化的测试软件,例如:DataFactory,DataFactory是一种强大的数据产生器,它允许开发人员和测试人员很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle、Sybase、SQL Server数据库。这样,就可以模拟出应用软件长期使用后,海量数据存储的数据库的性能状况。从而尽早发现问题,进行数据库性能的优化。 这里要注意,进行性能测试的时候,一定要注意测试环境的一致性,包括: *** 作系统、应用软件的版本以及硬件的配置等,而且在进行数据库方面的测试的时候一定要注意数据库的记录数、配置等要一致,只有在相同条件下进行测试,才可以对结果进行比较。否则无法和用户对软件的性能的观点达成一致。 6、数据库的压力测试 说起测试,我们首先想到的就是软件正确性的测试,即常说的功能测试。软件功能正确仅是软件质量合格指标之一。在实际开发中,还有其它的非功能因素也起着决定性的因素,例如软件的响应速度。影响软件响应速度的因素有很多,有些是因为算法不够高效;还有些可能受用户并发数的影响。 在众多类型的软件测试中,压力测试正是以软件响应速度为测试目标,尤其是针对在较短时间内大量并发用户的访问时,软件的抗压能力。但压力测试往往是手工难以测试的,必须借助自动化测试工具。常用的压力测试有:Web测试、数据库测试等。 数据库在大多数软件项目中是不可缺少的,对于它进行压力测试是为了找出数据库对象是否可以有效地承受来自多个用户的并发访问。这些对象主要是:索引、触发器、存储过程和锁。通过对SQL语句和存储过程的测试,自动化的压力测试工具可以间接的反应数据库对象是否需要优化。 这些自动化的测试工具很多,各有特点,基于Java的项目可以使用JMeter,.Net项目可以采用.Net集成开发环境中提供的测试方案。 7、结束语 总之,在应用系统的测试中,把数据库应当作为独立的系统来测试,这无疑会为应用软件的质量增加可靠的保障,同时还必须结合应用软件进行集成测试,只有二者有机结合起来,才能最大限度的发挥数据库和应用软件的功能。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/sjk/9927801.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-03
下一篇 2023-05-03

发表评论

登录后才能评论

评论列表(0条)

保存