数据库系统维护申请表
数据库系统维护申请表
数据库日常维护工作
数据库日常维护工作是系统管理员的重要职责。其内容主要包括以下几个部分： 一、备份系统数据 SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。 1、备份数据库 每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。 除了按计划周期卸出数据库之外，还需在每次运行没有日志的操作后卸出数据库。例如：·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）； ·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，或使用了 WRITETEXT 命令。 卸出数据库的命令为： DUMP DATABASE database_name TO dump_device database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得设备的信息。 下面一条命令用来卸出数据库 my_db ： DUMP DATABASE my_db TO db_bk_dev 2、备份事务日志 如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单独备份日志。 备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。 备份事务日志的命令格式为： DUMP TRANsaction database_name [TO dump_device] [WITH TRUNCATE_ONL Y|WITH NO_LOG|WITH NO_TRUNCA TE] 其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH TRUNCA TE_ONL Y 或 WITH NO_LOG 子句时，才可以备份到设备。 注意：如果总是用 DUMP DA TEBASE （备份数据库及其日志），而不用 DUMP TRAN ，事务日志将不会刷新，而变得非常庞大。
数据库日常维护
数据库日常维护(参考) 数据库日常维护工作是系统管理员的重要职责。其内容主要包括以下几个部分： 一、备份系统数据 SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过DUMP 和LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。 1、备份数据库 每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。 除了按计划周期卸出数据库之外，还需在每次运行没有日志的操作后卸出数据库。例如： ·每次强制地运行了DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）； ·每次用sp_dboption 允许select into/bulkcopy 做快速拷贝，或用SELECT INTO 命令创建一个永久性的表，或使用了WRITETEXT 命令。 卸出数据库的命令为： DUMP DATABASE database_name TO dump_device database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程sp_helpdevice 可以获得设备的信息。 下面一条命令用来卸出数据库my_db ： DUMP DATABASE my_db TO db_bk_dev 2、备份事务日志
数据库维护保养管理方案计划规范标准
数据库运维管理规范龙信思源（北京）科技有限公司
一、总则 为规范公司生产系统的数据库管理和配置方法，保障信息系统稳 定安全地运行，特制订本办法。 二、适用范围 本规范中所定义的数据管理内容，特指存放在系统数据库中的数据，对于存放在其他介质的数据管理，参照相关管理办法执行。 三、数据库管理员主要职责 3.1.负责对数据库系统进行合理配置、测试、调整，最大限度地发 挥设备资源优势。负责数据库的安全运行。 3.2.负责定期对所管辖的数据库系统的配置进行可用性，可靠性， 性能以及安全检查。 3.3.负责定期对所管辖的数据库系统的可用性，可靠性，性能以及 安全的配置方法进行修订和完善。
3.4.负责对所管辖的数据库系统运行过程中出现的问题及时处理解决。 3.5.负责对所管辖数据库系统的数据一致性和完整性，并协助应用开发人员、使用操作等相关人员做好相关的配置、检查等工作。 3.6.负责做好数据库系统及数据的备份和恢复工作。 四、数据库的日常管理工作 4.1.数据库管理的每日工作 (1)检查所有的数据库实例状态以及所有与数据库相关的后台进程。 (2)检查数据库网络的连通与否，比如查看监听器（listener）的 状态、网络能否ping通其它的计算机、应用系统的客户端能否连通服 务器等等。 (3)检查磁盘空间的使用情况。如果剩余的空间不足 20% ，需要删除不用的文件以释放空间或申请添加磁盘。 (4)查看告警文件有无异常。 (5)根据数据库系统的特点，检查其它的日志文件中的内容，发现 异常要及时加以处理。 (6)检查cpu、内存及IO等的状态。 (7)检查备份日志文件的监控记录，确定自动备份有无成功完成。 对于数据库的脱机备份，要确信备份是在数据库关闭之后才开始的， 备份内容是否齐全。运行在归档模式下的数据库，既要注意归档日志
数据库维护常见问题解决方法
数据库维护常见问题解决方法 (1)SQL SERVER日志损坏后,不能用sp_atttach_single_file_db 恢复,用如下步骤: 方法一 1、建一个同名的数据库 2、修改服务器设置：允许对系统目录进行直接修改(sp_configure 'allow updates',1) 3、停止SQL Server 4、用原mdf文件覆盖新建库的数据库文件 5、重启SQL Server（这时数据库应该是置疑） 6、将数据库置为紧急状态：update master.dbo.sysdatabases set status = 32768 where name=dbname 7、重建日志：dbcc rebulid_log('dbname', 'logfile') 8、update master.dbo.sysdatabases set status=16 where name = dbname 9. 修改服务器设置：取消允许对系统目录进行直接修改(sp_configure 'allow updates',0) 方法二 1.新建一个同名的数据库 2.再停掉sql server(注意不要分离数据库) 3.用原数据库的数据文件覆盖掉这个新建的数据库 4.再重启sql server 5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句(注意修改其中的数据库名) 6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用 数据库的脚本创建一个新的数据库,并将数据导进去就行了. USE MASTER GO SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE GO UPDATE SYSDA TABASES SET STATUS =32768 WHERE NAME='置疑的数据库名' Go --重起SQL SERVER sp_dboption '置疑的数据库名', 'single user', 'true' Go DBCC CHECKDB('置疑的数据库名') Go update sysdatabases set status=16 where name='置疑的数据库名' Go sp_configure 'allow updates', 0 reconfigure with override Go sp_dboption '置疑的数据库名', 'single user', 'false'
数据库该如何维护
数据库维护报告 08.1班14号王世杰08013110114 维护背景 用户在访问数据库时,发现数据库服务器的响应时间加长,检索数据的速度变慢,远远超过了用户所能容忍的范围,而且在用户登录时经常出现错误提示. 性能诊断与故障诊断 系统的性能和很多因素有关,其中硬件方面,主要涉及到服务器的CPU,内存,磁盘,网络等;软件方面主要涉及到应用程序,操作系统以及数据库.在对系统进行性能诊断时,需要对这些因素逐个进行诊断. 由于系统已经运行了很长时间,在此期间应用程序的代码没有被修改过,而且在应用服务器上只运行Weblogic这个很成熟的软件,故此初步判断可能是数据库服务器性能降低,并且出现了故障,而与中间件服务器没有关系.我们对数据库服务器进行了以下检查： 1.对CPU的利用率进行检查.发现节点tdfmis1和tdfmis2的CPU利用率相当高,几乎达到100%,但是其中将近30%的时间都在等待磁盘I/O.每个节点有4个CPU,处理现有的事务应该绰绰有余 2.对内存的利用率进行检查,发现系统中几乎没有内外存交换的情况,故此判断两个节点的内存是足够使用的. 3.通过对网络流量进行分析,发现没有丢失数据包,数据包冲突等情况,这说明网络的传输质量是没有问题的. 4.在HP-UX操作系统中通过对磁盘I/O进行分析,发现磁盘I/O主要集中在数据库所在的卷组中.由次可以判断:由于数据库的设计或者结构原因,导致数据库性能降低. 5.在对两个节点的数据库实例进行检查时,发现其中一个实例工作正常,另一个实例无法启动.在这种情况下,对数据库的所有访问将集中在工作正常的节点上,另一个节点无法启动实例,所以无法分担工作负载. 6.在对数据库的结构进行检查时,发现数据库中有两个临时表空间.其中表空间TEMP是数据库的默认临时表空间,它的数据文件位于节点tdfmis2的本地硬盘上,而不是位于磁盘阵列上.节点tdfmis1由于找不到这个临时表空间的数据文件,所以无法启动数据库实例.另一个临时表空间TEMP1其实没有任何作用,它的数据文件位于节点tdfmis1的本地硬盘上,而且把根文件系统/的空间写满了,因此在重新启动系统时,集群服务无法启动,整个数据库无法向用户提供访问. 7.由于临时表空间的设计不合理,导致两个节点上有大量的磁盘I/O,性能急剧降低. 8.由于数据库的初始化参数PROCESSES的值太小,限制了数据库中可以启动的进程的数量,导致有些用户无法正常登录. 9.通过对数据库所使用的内存进行检查,发现系统的物理内存为4G,而为数据库分配的内存仅为1G,数据高速缓存的大小仅为200M,系统的内存没有得到充分利用. 10.通过对数据库中的表进行检查,发现表中存在大量的存储碎片,这将导致对表的访问速度降低. 性能调优与故障解决 在找到问题的根源后,解决这些问题就简单了.我们对数据库进行了以下维护措施： 1.重新创建了临时表空间TEMP,把它的数据文件放在共享的磁盘阵列上,这样两个节点上的数据库实例都可以正常启动,而且CPU等待磁盘I/O的时间降低到了3%左右,效果非常明显. 2.删除了临时表空间TEMP1,为节点tdfmis1的/文件系统释放了大量的存储空间,这样在重
Oracle 11gR2数据库系统日常维护操作手册
Oracle 11gR2数据库系统日常维护操 作手册 修订纪录：
目录 一、介绍 (3) 二、维护 (4) 2.1 ASM管理与监控 (4) 2.1.1 磁盘创建(Linux) (4) 2.1.2 查看磁盘(Linux) (4) 2.1.3 删除磁盘 (linux) (5) 2.1.4 创建磁盘组 (5) 2.1.5 磁盘组新增磁盘 (5) 2.1.6 磁盘组删除磁盘 (5) 2.1.7 磁盘组删除 (5) 2.1.8 磁盘组维护 (5) 2.1.9 磁盘组监控 (6) 2.2 OHAS服务管理与监控 (6) 2.2.1 启/禁用服务资源 (6) 2.2.2 启动/停止资源服务 (8) 2.2.3 监控/删除资源服务 (9) 2.3 表空间管理与监控 (10) 2.3.1 表空间管理 (10) 2.3.2 表空间监控 (11) 2.4 重做日志管理 (12) 2.5 日志维护 (13) 2.5.1定制GRID模块的日志保留策略 (13) 2.5.2定制RDBMS模块的日志保留策略 (14) 2.5.3 查看异常日志 (14) 2.5.4 手工清理日志 (15)
Oracle 11g引进了些新的特性，在日常维护方面也带来些变化和改善。日常维护工作中，大体上保持和延续了以前版本的优良友好操作接口，只部分新特性下，增加或改善了操作交互方式。
日常维护工作中，主要有表空间、重做日志、归档、用户帐户、表、索引、簇表等的管理维护；在Oracle 11gR2数据库，我们的系统开始采用Oracle的ASM组件来管理数据库的存储，因而ASM管理存储也成了一项日常维护工作;另外，还采用了Oracle Restart功能来管理ASM、数据库、监听等数据库资源服务，故OHAS服务状态管理也是需要加以关注。 表空间、重做日志、归档的一般管理和以前版本的管理没有太多的差异；只是涉及新增和调整时，涉及文件存储方面，因使用ASM部件，而需要做些操作命令语法上的调整; 用户账户、表、索引、簇表等内部逻辑结构的维护管理没有太多的变化。 2.1 ASM管理与监控 ASM管理涉及存储的管理，主要有磁盘、磁盘组的创建、新增、更新、删除等管理维护方面。 2.1.1 磁盘创建(Linux) ASM磁盘创建，主要是使用ASMLib来管理磁盘的配置，Oracle引进ASMLib在内核级别进行磁盘的管理，便于ASM实例识别到磁盘，方面ASM创建、更新、删除磁盘组或组磁盘成员。 ASMLib管理磁盘，通过在系统级别识别到磁盘路径后，创建一个别名，来配置磁盘。 Redhat linux下通过多路径软件识别磁盘路径后，对磁盘进行分区后，就可以使用ASMLib来创建一个磁盘别名。 示例：Redhat ES 5下，采用DM管理的磁盘 通过多路径软件识别并配置了一个磁盘路径,将在/dev/mapper目录生成一个设备文件，默认是：/dev/mapper/mpath[0~N]命名，但这个识别的设备对应的真实设备可能会随机器启动而发生变化；故可以通过wwwid号在/etc/multipath.conf 文件配置别名，来固化设备与设备文件名对应;如配置一个设备别名为：asm_dsk_01,则在/dev/mapper目录生成一个文件名：/dev/mapper/asm_dsk_01，这样就可以使用fdisk或kpartx来划分分区，然后使用ASMLib来自动管理设备和生成另一个别名，便于Oracle ASMLib 来管理设备的权限，而不随系统启动发生权限信息丢失问题。 创建语句：划分的DM设备文件分区为：/dev/mapper/asm_dsk_01p1 ASMLib创建磁盘别名后，会在/dev/oracleasm/disks目录生成一个赋予ASM实例属主权限的磁盘设备别名文件，如示例则生成一个设备文件： /dev/oracleasm/disks/DISK01,属主将是初始化ASMLib时配置的属主: grid:asmadmin,ASMLib初始化配置，也可以通过配置文件进行调整： /etc/sysconfig/oracleasm 2.1.2 查看磁盘(Linux)
数据库的运行与维护
数据库的运行与维护 1.数据库的运行 要使数据库系统投入并保持正常运行，需要许多人做许多工作。这里主要讨论作为计算机系统的一个组成部分的DBMS及其数据库与其他系统部件的接口关系、系统的工作原理。 1.1运行环境的构成 数据库的运行除了DBMS与数据库外，还需要各种系统部件协同工作。首先必须有各种相应的应用程序，其次各应用程序与DBMS 都需要在操作系统（OS）支持下工作。在有远程通信的情况下，则需要数据通信管理部件的支持。图1-1描绘了一个数据库运行环境的典型部件。其中，DBCS（数据库控制系统）是与各用户程序 APP接 i 口的模块；DBSS（数据库存储系统）操作存储数据库并与OS或DBMS 自己的标准存取方法（AM）接口；各应用程序和DBMS部件都在OS的管理程序（supervisor）的管理下工作。对于一个给定的DBMS，不一定就有名为“DBCS”或“DBSS”的系统，在这里它们是一般性术语，但绝大多数DBMS都有相当的功能部件。在网络或分布式环境下，还需要数据通信管理系统（DCMS）的支持。
图1-1 数据库系统运行环境 通常，系统初启时，应用程序与DBMS都不活动，一旦事务达到系统，OS管理程序就调度用户事务所需要的应用程序运行。当应用程序要求存取数据库时，向DBMS发出请求。DBCS接受应用程序请求，并考察外部模式与概念模式，以确定需要什么概念记录来满足请求，然后调用DBSS存取存数模式，转换概念记录成存储记录，并经OS传递请求给相应的AM，再由AM实现物理数据库的存取和数据I/O。 1.2运行环境的类型 数据库运行环境的组成与用户环境的类型紧密相关。可以用两种不同的用户环境：一种是数据库为一个或少数单个用户的专用而建立；另一种是针对整个组织建立的集成数据库。在前一种环境下，常
浅谈数据库的日常管理与维护
浅谈数据库的日常管理与维护 企业在信息管理过程中，大量的数据存储、共享、访问和修改，都需要通过数据库系统来实现。数据库系统作为信息的聚集体，是计算机信息系统的核心，其性能在很大程度上影响着企业信息化水平的高低。一个公司，不管它是自己开发应用软件，还是购买第三方应用软件，都需要对数据库进行管理和维护。科学有效地管理与维护数据库系统，保证数据的安全性、完整性和有效性，己经成为现代企业信息系统建设过程中的关键环节。 数据库管理中存在的问题 随着信息网络技术的飞速发展，数据库的应用越来越广泛，但也随之产生了一系列数据管理的问题，其中，尤为突出的是数据库安全性问题。 数据库安全性问题一直是困扰数据库管理员的难题。通常数据库面临的威胁主要有：软件和硬件环境出现意外，如磁盘损坏，系统崩溃等；计算机病毒可能造成系统崩溃，进而破坏数据；对数据库的不正确访问，引发数据库死循环，造成前端系统无法使用；未经授权非法访问数据库信息，窃取其中的数据；未经授权非法修改数据库中的数据，使其数据失去真实性；通过网络对数据库进行各种非法存取；通过
网络破坏数据库系统的完整性、可靠性；对网络数据库进行拒绝式服务攻击等。而对于重要部门或敏感领域的数据，则会面临更多威胁。这就需要企业信息部门通过加强对数据库的日常维护和管理，来进一步保障网络数据库的安全。 做好数据库的日常管理与维护 数据库系统在信息化建设中的重要地位和作用告诉我们，数据库的日常管理与维护不容小视。为保证数据库数据的安全，企业应该做到未雨绸缪。 （一）完善管理制度，强化监管力度。数据库系统的安全与企业自身内部的安全机制、内外网络环境、从业人员素质等密切相关。因此，企业应该完善网络系统安全规章制度，防范因制度缺陷带来的风险；企业应该规范操作流程和故障处理流程，减少人为失误与故障，提高故障处理速度，缩短故障处理时间；企业应该通过建立科学合理的责任追究机制，防止出现由于工作态度、工作作风等各种人为因素导致的数据库安全事故。 （二）采取措施，确保数据库数据的安全。保证数据库数据的安全是数据库日常管理与维护工作的首要任务，企业需要采取的安全措施主要有：
2017年数据库维保服务采购内容及技术要求
2017年数据库维保服务采购内容及技术要求 一、采购内容 采购内容：ORACLE数据库维保服务 服务期限：三年 服务标的： 1）核心系统ORACLE 11g RAC数据库。 2）系统开发运行过程中与Oracle数据库使用相关的技术支持。 3）ORACLE数据库灾备中心建设中相关的技术支持。 二、服务提供商资质能力要求 公司资质：注册资金不少于200万元人民币，具备ISO9000、高新技术企业、 ISO20000等资质至少两项 技术实力： 1）投标方至少拥有3个具有OCM认证资质的高级Oracle工程师，至少有1名工程师具备Oracle11g OCM认证资质，需提供相关证书。 2）投标方至少拥有1个ACE认证资质的高级工程师。 3）在近3年以内来，至少有3例ORACLE数据库性能优化案例，需提供相关证明。 4）需有本地服务团队。 三、技术服务要求： （一）第一年的数据库维保服务增项 针对院内某数据库实例进行跨平台数据迁移，并搭建RAC。 （二）每年oracle数据库维护与技术支持服务服务目的与内容要求： 本次服务主要用于下列目的：保障系统稳定运行，保障系统的数据安全可靠，改 善系统运行性能，提升开发人员对数据库的利用能力和水平。为达成上述目的，投标 人应提供7*24小时（即每周7个工作日，每天24小时，2小时内到达现场）全天技 术支持服务，并根据甲方需要提供现场支持服务。具体服务时间由甲方需求决定。服
务内容包括： 1、健康检查。最小频率为两个月一次到用户现场对数据库进行例行健康检查，并提交报告，根据健康检查的内容对数据库进行优化。检查的内容应包括但不限于以下内容： （1）容错检查，检查并分析系统日志及跟踪文件，发现并排除数据库及应用系统的错误隐患； （2）检查数据库及应用系统的配置健康情况； （3）发现并排除数据库系统错误隐患； （4）检查数据库系统是否需要应用最新的补丁集； （5）检查数据库空间的使用情况，协助进行数据库空间的规划管理； （6）检查数据库备份的完整性； （7）监控数据库性能、数据库运行状态、运行效率、是否存在安全隐患； （8）备份方式是否合理、备份数据是否可恢复； （9）提供系统健康检查报告； 2、数据库及应用系统性能调优。数据库及应用系统性能调优应包括但不限于以下内容： （1）利用工具采集系统运行时的各项监控数据； （2）分析系统主要的性能瓶颈； （3）分析系统、网络、应用软件及数据库等各方面资源的使用情况； （4）确定系统性能现状及性能调整的目标； （5）定位系统中出现的性能瓶颈； （6）测试验证针对性能瓶颈进行的改进方案； （7）产生基于ORACLE最佳应用准则的性能调整建议报告； （8）适用于当前商业规则的Oracle 软件配置； （9）为客户提供实施问题的解决方案； （10）为客户进行现场技能讲解传授； （11）ORACLE工程师在现场调优数据库性能和应用性能；
数据库系统繁忙的维护办法
数据库系统繁忙的维护办法 最近mSwitch、IPTV的系统维护中，经常遇到数据库繁忙、各种业务反应极慢的情况。此时查询数据库CPU占用率，IDLE接近于0。 一．检查操作系统 首先登陆主机，执行top命令，一般会发现CPU资源几乎消耗殆尽，存在很多占用CPU很高的进程，而内存和I/O都不高，具体如下： last pid: 26136; load averages: 8.89, 8.91, 8.12 216 processes: 204 sleeping, 8 running, 4 on cpu CPU states: 0% idle, 97.3% user, 1.8% kernel, 0.8% iowait, 0.0% swap Memory: 8192M real, 1166M free, 14M swap in use, 8179M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 25725 oracle 1 50 0 4550M 4508M cpu2 12:23 11.23% oracle 25774 oracle 1 41 0 4550M 4508M run 14:25 10.66% oracle 26016 oracle 1 31 0 4550M 4508M run 5:41 10.37% oracle 26010 oracle 1 41 0 4550M 4508M run 4:40 9.81% oracle 26014 oracle 1 51 0 4550M 4506M cpu6 4:19 9.76% oracle 25873 oracle 1 41 0 4550M 4508M run 12:10 9.45% oracle 25723 oracle 1 50 0 4550M 4508M run 15:09 9.40% oracle 26121 oracle 1 41 0 4550M 4506M cpu0 1:13 9.28% oracle 二．查看数据库的告警日志ALERT文件 我们的数据库告警日志一般在$ORACLE_BASE/admin/ORCL/bdump下，文件名为： alert_ORCL.log。查看文件中是否有’ora-‘,’err’,’not complete’等信息。一般来讲，我们的数据库系统比较健壮，其本身一般不存在问题。
信息系统数据维护和管理规定
医院信息系统数据维护和管理规定 为加强我院计算机信息系统数据库及基础数据维护和管理，保证医院信息系统数据的安全、稳定、准确，制定本规定。 一、数据库管理 1 .系统维护人员必须管理好数据库和数据库服务器的登录用户名和登录密码，以免被他人盗用。 2 .系统维护人员必须经过专业技术培训，具备相应的专业技术水平方可上岗。 3 .医院各部门工作人员按照医院信息管理系统的使用要求和业务 要求开展工作，规范地录入、接收和移交各类档案数据和各类业务数据。医院有关部门要加强数据质量管理，确保入库数据真实、完整、准确。 4 .医院各类计算机数据统一在数据中心管理保存。系统维护人员 做好数据库审核工作，对收集的各类数据进行完整性和质量检查，对不符合要求的数据，应退回形成部门重新处理。 二、基础数据维护 1.凡需要新增或作废的各项数据，如药品、诊疗项目、一次性材 料，需各相关部门负责人员及科主任签字方可进行相关操作，并自行以时间为序建立变更记录以便核对。 2 .基础数据变更应由各职能科室批准并签章方可执行，主要包括 机构设施变更、人员变更、床位设置变更等。 3 .凡需加入信息科的信息资料须由经办科室主任签字，经办科室 需保留原始记录。
4 .院内各科室需修改业务数据时，凭分管领导批示方可到信息科由系统维护人员修改。 5 .信息科及各职能科室人员可根据工作需要使用信息系统进行数据查询。 6 .为保证各类统计数据的完整性、及时性与准确性，统计数据经使用部门复核后方可使用。 7 .禁止超范围与盗用他人账号进行数据查询，不得私自提供统计数据给其他单位与个人，禁止对数据进行篡改、破坏。
Sybase数据库系统维护
第1章 Sybase数据库系统维护 本章描述与网管系统的数据库系统相关的问题及其解决办 法。 1.1 设置Sybase服务自启动的方法 1. 以root用户登录，建立自启动文 件/etc/rc(2)d/S98sybserver： su - sybase -c "/export/home/sybase/install/startserver \ -f /export/home/sybase/install/RUN_sybserver \ -f /export/home/sybase/install/RUN_sybserver_back" sleep 10 2. 修改自启动文件的属性 chmod 0700 /etc/rc(2)d/S98sybserver 3. 进入ISQL环境 $isql -Usa -Pserver1234 4. 查看数据库占用空间大小 1>sp_helpdb 数据库名称 2>go 1.2
安装Sybase时无法创建数据库服务器的处理方法安装Sybase数据库时，创建“Adaptive Server”失败，出现 如下错误提示： Building Adaptive Server 'xxxx': Building master device... Master device complete. Writing entry into directory services... Directory services entry complete. Writing RUN_SERVER file... RUN_SERVER file complete. Starting server... Task failed Unable to boot server 'xxxx'. Server 'xxxx' was not created. 这是因为安装Sybase数据库前要修改操作系统的共享内存 参数，如果没有修改就进行了安装，就会发生上述情况。 修改方法为： (1) 编辑“/etc/system”文件，在最后增加一行，其内容 为： set shmsys:shminfo_shmmax=工作站实际物理内存大小 （单位MB）*1024*1000 (2) 在修改之后保存文件，然后重新启动工作站，使修 改生效，再安装数据库。 1.3
数据库维护工作手册
数据库维护工作手册文档编号：文档名 称： 编写：审 核： 批准:批准日 期：
目录
1概述 数据库的日常监控是使管理员及时了解系统异常的手段。大部分情况下，系统总是正常运行的。只有对正常情况的充分了解，才能通过对比正常情况发现异常情况。对于数据库的日常监控要有记录，文字记录或者电子文档保存。对于数据库异常进行分析，提出解决方案。 日常工作包括监控和维护两个部分。 此文档中关于数据库的运行命令示例主要针对于ORACLE数据库，但对于SYBASE数据库同样有参考价值，只要换用相对应的语句即可。 数据库监控 2数据库监控 数据库监控工作内容 制定和改进监控方案，编写监控脚本。 对于数据库进行日常监测，提交记录。 根据监测结果进行分析、预测，提交相应的系统改进建议方案。 数据库监控工作步骤 2.1.1查看数据库日志 数据库的日志上会有大量对于管理员有用的信息。ORACLE的Alert日志纪录了数据库系统所报的系统级错误信息，以及数据块失效等严重错误信息。错误信息的产生，会产生相应的跟踪文件，通过查看警告日志和跟踪文件可查找错误原
因，对于发现的问题应及时解决和汇报。如： 1.表空间是否满，是否需要进行添加或者扩展。Alert文件中会显示有表块 无法扩展的提示。 2.表的块或者页面是否损坏。（往往这时alert文件中会显示ora-600的错 误。） 3.数据库是否进行了异常操作。（如：drop tablespace等等）。 实用命令： ·报警日志文件（或alrt
数据库的建立和维护
实验二: 数据库的建立和维护 学号：姓名： 实验目的 熟练掌握建立数据库和表，向数据库输入数据、修改数据和删除数据的操作。 实验内容 建立数据库并设计各表，输入多条实际数据，并实现数据的增、删、改操作。 实验步骤： 创建用于学生管理数据库，数据库名为XSGL，包含学生的基本信息，课程信息和选课信息。数据库XSGL包含下列3个表： (l）student：学生基本信息。 (2）course：课程信息表。 (3）sc：学生选课表。 各表的结构分别如表1、表2和表3所示。 一. 数据库的建立： 1．命令方式建立：
（a）在SQL SERVER2005中，在新建查询中使用T-SQL语句建立数据库XSGL：CREATE DATABASE XSGL ON(NAME='XSGL_DATA', FILENAME='D:\XSGL.MDF', SIZE=10MB, MAXSIZE=50MB, FILEGROWTH=5%) LOG ON (NAME='XSGL_Log', FILENAME='D:\XSGL_Log.ldf', SIZE=2MB, MAXSIZE=5MB, FILEGROWTH=1MB) 2．在新建查询中使用T-SQL语句建立数据库XSGL2： CREATE DATABASE XSGL2 3．T-SQL语句删除数据库XSGL2： drop database XSGL2 二. 表的建立： 1．命令方式建立： 在SQL SERVER2005 中的”新建查询”编辑窗口中用下列SQL语句建立三个表student，course，sc: use xsgl create table student (sno char(10)not null primary key, sname varchar(10)not null, ssex char(2)not null check(ssex ='男'or ssex ='女'), sage int, sdept char(2)not null ); go create table course (cno char(3)not null primary key, cname varchar(30)not null, credit int check(credit >=0 and credit <= 10), pcno char(3)references course(cno) ); go create table sc (sno char(10)not null, cno char(3)not null, grade int check(grade >=0 and grade <= 100), primary key(sno, cno),
ORACLE数据库系统的日常维护规程
ORACLE数据库管理员应按如下方式对ORACLE数据库系统做定期监控： (1). 每天对ORACLE数据库的运行状态,日志文件,备份情况,数据 库的空间使用情况,系统资源的使用情况进行检查,发现并解决 问题。 (2). 每周对数据库对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康检查,对数据库对象的状态做检查。 (3). 每月对表和索引等进行Analyze,检查表空间碎片,寻找数据库 性能调整的机会,进行数据库性能调整,提出下一步空间管理 计划。对ORACLE数据库状态进行一次全面检查。 每天的工作 (1).确认所有的INSTANCE状态正常 登陆到所有数据库或例程,检测ORACLE后台进程: $ps –ef|grep ora (2). 检查文件系统的使用（剩余空间）。如果文件系统的剩余空间小于20%，需删除不用的文件以释放空间。 $df –k (3). 检查日志文件和trace文件记录alert和trace文件中的错误。 连接到每个需管理的系统 ? 使用’telnet’ ? 对每个数据库,cd 到bdump目录,通常是$ORACLE_BASE/
检查第三方备份工具的备份日志以确定备份是否成功 对EXPORT备份方式: 检查exp日志文件以确定备份是否成功 对其他备份方式: 检查相应的日志文件 (5). 检查数据文件的状态记录状态不是“online”的数据文件，并做恢复。 Select file_name from dba_data_files where status=’OFFLINE’ (6). 检查表空间的使用情况 SELECT tablespace_name, max_m, count_blocks free_blk_cnt, sum_free_m,to_char(100*sum_free_m/sum_m, '99.99') || '%' AS pct_free FROM ( SELECT tablespace_name,sum(bytes)/1024/1024 AS sum_m FROM dba_data_files GROUP BY tablespace_name), ( SELECT tablespace_name AS fs_ts_name, max(bytes)/1024/1024 AS max_m, count(blocks) AS count_blocks, sum(bytes/1024/1024) AS sum_free_m FROM dba_free_space GROUP BY tablespace_name ) WHERE tablespace_name = fs_ts_name (7). 检查剩余表空间 SELECT tablespace_name, sum ( blocks ) as free_blk , trunc ( sum ( bytes ) /(1024*1024) ) as free_m, max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks FROM dba_free_space GROUP BY tablespace_name; (8). 监控数据库性能 运行bstat/estat生成系统报告 或者使用statspack收集统计数据