以下是小编整理的Informix Online 数据库维护技巧数据库，本文共6篇，希望能够帮助到大家。
篇1：Informix Online 数据库维护技巧数据库
一、数据库查询用户的建立 银行Informix_on_line数据库由于存储了储户的大量重要信息，为了数据库的 安全 性必需要对数据的操作有严格的规定，如进入on_line数据库要履行严格的手续，这在某些时候又给查找问题带来不便，因此有必要专门建立一个动态查询用户
一、数据库查询用户的建立
银行Informix_on_line数据库由于存储了储户的大量重要信息，为了数据库的安全性必需要对数据的操作有严格的规定，如进入on_line数据库要履行严格的手续，这在某些时候又给查找问题带来不便，因此有必要专门建立一个动态查询用户，该用户仅有对数据库的可读权限，具体做法是：
1.建立查询用户，该查询用户应具有数据库使用的环境
2.将查询用户与数据库作连接(work用户为例)
ln－s/homel/work/homel/read(将查询用户read与数据库用户作连接)；
3.由work用户使用数据库，将connect权限赋予read用户grant connect to read;
4.对数据库中每一张表放select权给read用户
grant select on abc to read.(将select权限赋给read用户)
这样，以read用户注册，对数据库拥有了可读操作，给查找问题等带来方便。
二、数据库一致性检查
a.以informix登录
b.将数据库状态置为off_line
onmode－ky
用onstat－检查数据库状态为off_line
c.将数据库状态置为单用户模式
onmode －s
用onstat－检查数据库状态为quiesent
d.检查数据库保留页状态
oncheck－cr 1>/tmp/oncheck.cr 2>＆1
e.检查数据库目录页一致性
oncheck－clearcase/“ target=”_blank" >cc1 >/tmp/oncheck.cc 2>＆1
f.检查数据库数据的一致性
oncheck－cD workdb 1>/tmp/oncheck.cd 2>＆1
g.检查数据库索引的一致性
oncheck－cI workdb 1>/tmp/oncheck.ci 2>＆1
h.检查/tmp下oncheck.cr,oncheck.cc,oncheck.cd,oncheck.ci文件，查看有无错误信息，如没有，则数据库状态正常，反之亦然。
i.将数据库状态置为online
onmode－m
用onstat－检查数据库状态为online
三、数据库的备份与恢复
1.dbexport备份与dbexport恢复
dbexport备份是一文体文件备份，该备份将数据库中信息以文本文件方式保存，要注意的是，在备份时必须保证没有对数据库有访问者，否则做dbexport不会成功，dbexport备份的一般格式为(以数据库workdb为例)
dbexport workdb－d －s workdbs /path
2.dbimport恢复是将用dbexport备份的文件恢复到数据库中
a.停止一切数据库操作→删除数据库；
b.＄dbimport workdb－d workdbs －i/path;
c.用工具onmonitor将参数TAPEDEV改为/dev/null；
d.ontap －s －u workdb.
` e.检查workdb是否改为U状态.
f.将TAPEDEV值改回原先的值.
需要指出的是在dbimport恢复过程中，有大量的信息要写在逻辑日志文件中，采用上述方式，可避免写逻辑日志文件，加快dbimport的速度，
3.数据库的零级备份
数据库零级备份是重要的备份手段，日常一般用磁带备份，经常用于做重大操作之前的备份，数据往往需要恢复，而磁带上的零级备份数据由于数据量大，恢复起来花费时间较长，因此，可采用在硬盘上做零级备份的办法。
a.在硬盘上划一个足够大的空间，用于备份文件的存放。
b.用onmonitor将参数TAPEDEV改定指向零级备份文件。
如把/cs在作为零级备份文件oback的存放空间，可将参数改为TAPEDEV=/cs2000/oback，这样可做硬盘零级备份，备份恢复时间只是磁带机的1/6。在恢复过程中应该用tail －f online.log监控。恢复过程，一直到数据库状态变为online..
c.将参数TAPEDEV=/cs2000/oback改为TAREDEV=/dev/rmt/0m;
四、数据库常见故障处理
1 检查
用onstat_－1检查逻辑日志的使用情况，是否中止进程，根据finder col.数据库故障的一般检查，首先要检查数据库状态，经常用onstat_de查找可能出现的错误，同时检查online.log是否报错。
2.数据库表的跟踪
遇到在对数据库表作大规模操作时，有时我们不知道对该表的操作是否得以在继续进行，因为isql进入，操作该表，数据库报“该表已被锁”信息，这时可用查询语句：
首先：set retrieved to drity read
然后：select count(＊)from abc,
通过不断对abc表进入统计，如统计数在不断增加，则对该表的操作仍在进行，否则，以停止了对该表的操作。还有，当批量执行SQL命令，如update,……insert等时如不能成功执行，可采用增加判断条件，缩小范围的方法去执行，往往可以获得成功，遇有些语句涉及的记录在处理过程中被锁定，直到处理过程结束可能超过系统关于同时锁定界限，遇这种错误，可以在开始处理时锁定该表。
3.故障排除举例
故障现象：在银行批量结息向结息数据表插入记录时出现informix sqlcode错误号为－239。
故障检查：经查，从现象看，似乎有重复记录插入表中，但经核查数据，可以肯定数据绝无重复记录，考虑到表文件长期使用，表文件的相关信息受到某种破坏，为此，做以下操作：
a.unload to “/tmp/abc.txt”select＊from abc.卸出abc中全部数据；
b.drop table abc.(删除表文件abc)；
c.create tabk abc
(abc_swo mteger;
abc_ano smallint)
…
)；建立数据库表文件abc.
d.load form“tmp/abc.txt”insert into abc.
(将原数据装入表文件abc中)。
e.重新执行结息操作，新产生的结息数据顺利装入表文件abc中，故障得以排除。
作为计算机技术人员，熟悉数据库的操作，掌握一些操作技巧和方法对于我们解决工作中遇到的问题，查找错误，是十分有帮助的。
原文转自：www.ltesting.net
篇2：WIN技巧：最优化ExchangeServer03数据库维护
Exchange Server 默认在存储级别自动执行定期的数据库维护，但是你仍然可以手动检查 你的Exchange服务器的数据库维护时间表来确认你达到最优化的结果，
以下是数据库维护的11个不同的任务DD一些仅仅适应于Exchange邮件箱存储;其它一些仅用于Exchange公共文件夹存储:清除邮件箱和公共文件夹索引。 在公共文件夹和邮箱执行墓碑(tombstone)维护 为邮箱和公共文件夹从垃圾箱移除过期的消息(expired messages) 从公共文件夹移除过期的消息 移除已删除文件夹中超过180天的信件。 .清除公共文件夹中的消息冲突(message conflicts) 更新服务器版本信息在公共文件夹 在公共文件夹存储中检查并且删除复制站点(duplicate site)文件夹 在邮箱存储中清空已删除文件夹。 检查消息栏的无应答消息(orphaned messages) .执行在线的存储磁盘整理
当数据库维护运行在Exchange服务器存储，它将从上面10条中的第一个开始，并且全部可能进行的任务将在分配时间内完成。如果Exchange数据库维护在所有可用的任务完成之前到时间限制了，Exchange服务器将在下一个晚上从任务中断部分继续进行。
在至少在10个任务中的一个完成之后，Exchange服务器将用其数据库维护中的15分钟来运行一个在线的磁盘碎片整理程序。默认情况下，在线磁盘碎片整理将在数据库维护周期结束之后的一个小时继续进行。
调整Exchange服务器数据库维护周期
尽管Exchange数据库维护周期是完全自动的，让人有一些手动的事情你可以去做，以确信它运行在最理想状态下。像我之前所说的，每个存储运行自己独有的维护周期。
调整Exchange服务器存储维护周期
1.打开Exchange系统管理，右键点击你要调整的存储，并且选择道具。
2.操作数据库tab，你可以通过周期间隔来调整存储周期时间表
因为维护周期能够对资源有很强影响，所以维护周期的时间表最后在大多数用户并未使用服务器的时候进行，
比如，数据库维护在午夜到凌晨4点运行对大多数公司来说比较合适。DD但是你要考虑你的备份时间表。备份一个Exchange数据库不用占用存储的任务执行，但是备份会导致在线磁盘碎片整理的停止，直到备份完成。
同样，如果你的服务器有很多Exchange服务器存储器，你可以设置数据库维护间隔去为每个存储器运行在不同时间(如果有太多的存储器，这样可以不大现实)。例如。你可以在从1点到2点时候，在一个存储器运行Exchange服务器维护，然后在2点到3点又到执行另一个存储器上的维护。
控制在线磁盘碎片整理程序间隔
除了11个基本的Exchange服务器数据库维护任务，另外还有一个比其余重要的任务DD在线磁盘碎片整理。在线磁盘碎片整理可以通过压缩数据库记录来压缩空间。记住在线磁盘碎片整理并不是改变数据库的物理大小，只是让存储空间空余出来。
你可以使用两个注册键值来控制Exchange服务器维护周期的在线磁盘碎片整理的动作。(注意修改注册表可能比较危险，所以当这么做之前要执行整个系统的备份)。
如我之前所说，在线磁盘碎片整理在数据库维护周期结束之后运行15分钟(假定任务已经完成) 。注册键HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISservernamePrivate-GUID(或者公共文件夹存储Public-GUID)能被用来控制在维护周期结束之后在线磁盘碎片整理的总时间。
很简单就可以创建一个名字为旧最小运行时间的REG_DWORD类型键值，并且分配给它一个反映时间的数字值，这个数字的值就是你可以把在线磁盘碎片整理作为维护周期的一部分来运行所用的时间。
同样你也可以控制在线磁盘碎片整理进程在维护周期之后运行的时间。要做这个，找到HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISservernamePrivate-GUID (or Public-GUID for public folder stores)并且创建一个名为旧完成时间的REG_DWORD类型键值。
分配这个键值一个数值，来反映在线磁盘碎片整理进程需要运行多少秒。例如，一个3600的值能够触发进程运行3600秒(也就是1小时)。
在很多例子里，你可能不必非得修改注册表，但是我仍然推荐为每台存储设置维护周期时间间隔是必要的。
篇3：数据库维护工程师求职简历
数据库维护工程师大学生求职中所写的个人简历要怎样来描述自己，简历要如何写才能让自己的求职得到更好的效果以这份数据库维护专员专业简历模板参考，为了让各所有的求职者在写简历时能够将自己的简历特长与技能发辉出来，以下应届毕业生网提供数据库技术专业简历模板阅读。
姓名：本网
一年以上工作经验|男|26岁(1990年9月9日)
居住地：杭州
电 话：135*******(手机)
E-mail：/
最近工作[9个月]
公 司：XX有限公司
行 业：互联网/电子商务
职 位：数据库维护工程师
最高学历
学 历：本科
专 业：计算机信息管理
学 校：浙江大学
求职意向
到岗时间：可随时到岗
工作性质：全职
希望行业：互联网/电子商务
目标地点：杭州
期望月薪：面议/月
目标职能：数据库维护工程师
工作经验
/11 – /9：XX有限公司[9个月]
所属行业：互联网/电子商务
管理部数据库维护工程师
1. 负责数据库的集成安装，测试，升级等，定期对数据库运行状况进行巡检。
2. 制订数据库备份，恢复流程策略，并保证正确实施。
3. 快速处理业务数据库运行中出现的问题，保证业务数据安全、可用。
/9 – 2014/10：XX有限公司[1年1个月]
所属行业：金融/投资/证券
管理部数据库维护工程师
1. 负责数据库的日常维护与监控，迅速处理数据库常见告警。
2. 快速分析数据库性能异常，升级故障处理流程。
3. 根据项目需要，进行数据库结构更改、跟踪、优化等操作。
教育经历
/8— 2013/6 浙江大学计算机信息管理 本科
证书
/12 大学英语四级
语言能力
英语(良好)听说(良好)，读写(良好)
自我评价
我认真负责，积极主动，能吃苦耐劳，较好地完成自己的任务和工作，在工作过程中学到了更多的知识，积累了更多宝贵的'经验。我有高度的责任感，善于与人沟通，有较强的组织协调能力，环境适应力强，有良好稳定的心理素质。
篇4：数据库维护工程师求职简历
简历是一个人求职时的名片，个人简历做得好不好那就要看自己写的内容，对于简历的.风格也是一样，不管是应聘大公司还是应聘小公司个人简历都有几个相同点。
应聘小公司时的个人简历要怎样写重点是写什么呢?以下由本网小编推荐数据库维护专员专业简历模板阅读。
篇5：数据库维护工程师求职简历
最高学历
学 历：本科
专 业：信息管理和信息系统
学 校：南京工业大学
求职意向
到岗时间：一个月之内
工作性质：全职
希望行业：金融/投资/证券
目标地点：南京
期望月薪：面议/月
目标职能：数据库维护工程师
工作经验
/2 — 2015/10：XX有限公司[8个月]
所属行业：金融/投资/证券
管理部数据库维护工程师
1. 负责数据库的日常维护与监控，负责数据库的集成安装，测试，升级等。
2. 制订数据库备份，恢复流程策略，并保证正确实施，定期对数据库运行状况进行巡检。
3. 快速处理业务数据库运行中出现的问题，保证业务数据安全、可用。
/7 — 2014/11：XX有限公司[4个月]
所属行业：金融/投资/证券
管理部数据库维护工程师
1. 根据客户的需求，生成数据库字典，负责数据库的备份与恢复、T-SQL语句的编写等。
2. 快速分析数据库性能异常，升级故障处理流程。
3. 根据项目需要，进行数据库结构更改、跟踪、优化等操作。
教育经历
/9— 2014/6 南京工业大学 信息管理和信息系统 本科
证书
/12 大学英语四级
语言能力
英语(良好)听说(良好)，读写(良好)
自我评价
本人性格随和乐观，积极向上，爱好广泛，喜欢钻研，工作认真负责，拥有较强的组织能力和适应能力，并具有良好的身体素质。乐于沟通，易于融入集体，乐于助人，学习能力较好，注重理论与实践相结合，在工作中不断提高专业知识之余。同时也在不断地提高做人、做事的的能力，争取将工作做得更好，争取做更好的自己!
篇6：Oracle数据库备份技巧
利用下面的列出的技巧来确保你不会在每周一次的数据库备份过程中忘记关键步骤。
每周一次备份主数据库。如果你创建、修改或者停止一个数据库，添加新的sql server消息，添加或者停止连接服务器，或者添加记录设备，那就进行手工备份。
每天备份一次msdb数据库。它一般非常小，但很重要，因为它包含了所有的sql server工作、操作和计划任务。
只有当你修改它时，才有必要备份模型数据库。
用sql server agent来安排你的备份工作的时间表。
如果在你的生产(production)环境中有现成资源，备份生产数据库到本地磁盘或者网络服务器(用同一个开关)。然后，把备份文件/设备拷贝到磁带上。在存在许多硬件故障(特别是在raid系统中)的情况下，磁盘常常是完好的(inact)。如果备份文件是在磁盘上，那么恢复时的速度会提高很多。
备份开发和测试数据库至少要用到simple恢复模型。
除了有计划的定时备份外，在进行未记录的(nonlogged)批操作(如，批拷贝)、创建索引、或者改变恢复模型后要备份用户数据库。
如果你使用的是simple恢复模型，记住在截短(truncate)交易记录之后备份你的数据库。
用文档记录你的恢复步骤。至少要大概记录这些步骤，注意所有的重要文件的位置。
--------------------------------------------------------------------------------
在截短记录之前，也就是所有的已提交(committed)交易从记录中清空之前，所有的这些信息都保存在交易记录中。在simple恢复模型中，记录在一个checkpoint期间内截短(在sql server内存缓冲写道磁盘时)，它是自动发生的，但也可以手动执行。这也就是simple恢复模型不支持时间点(point-in-time)恢复的原因。在full和bulk_logged恢复模型下，当交易记录被备份时，交易记录被截短，除非你明确指出不进行截短。
为了备份交易记录，使用backup log命令。其基本语法与backup命令非常相似:
backup log { database } to
下面是如何把交易记录备份到一个名为logbackupdevice的逻辑设备上的例子:
backup transaction northwind to logbackupdevice
如果你不希望截短交易记录，使用no_truncate选项，如下所示:
backup transaction northwind to logbackupdevice with no_truncate
只是基本知识。
尽管我在本文中仅仅概述了数据库恢复的基本知识，你还是可以通过这些技巧来找到正确的方向。那么，为了避免不必要的(丢失数据造成的)恐慌，你要做到每周备份主数据库，每天备份msdb。
文档为doc格式
