社区
DB2
帖子详情
操作系统崩溃后如何恢复db2数据库,现有数据库表空间等文件
zhouhaijun2
2017-12-09 01:03:03
操作系统崩溃后如何恢复db2数据库,现有数据库表空间等文件,请高手指教,多谢了!
...全文
996
1
打赏
收藏
操作系统崩溃后如何恢复db2数据库,现有数据库表空间等文件
操作系统崩溃后如何恢复db2数据库,现有数据库表空间等文件,请高手指教,多谢了!
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
1 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
HuaXia1985
2018-04-13
打赏
举报
回复
简单来说就将已提交,但数据还没写入到磁盘的数据重做一遍。 在数据库中执行了DDL或者DML操作都会记录在日志中,如果提交了那日志记录就会写入到磁盘中,但实际操作的数据可能还只是在内存的缓冲池中未写入磁盘,在数据库奔溃后这部分的数据会丢失,但是在启动数据库后数据库管理器会从磁盘中读取到这些数据对应的日志,然后根据日志中的记录重新做一遍操作,把这些数据找回来,这个过程一般比较消耗时间。
数据库
灾难性
恢复
(
数据库
技术;灾难性;
恢复
;数据备份)
目录 摘要 3 ABSTRACT 3 1. 灾难类型 4 2.
恢复
类型 4 3.
恢复
的级别 4 4. 需要防止的故障级别 4 4.1 可接受的数据丢失量 5 4.2 允许用于
恢复
的时间量 5 4.3 备份和
恢复
5 5. 灾难
恢复
方案 5 5.1 简单备份 6 5.2 备份和日志保留 7 6. 高级存储备份 8 7.
数据库
恢复
9 摘要 随着
数据库
技术在各个行业和各个领域大量广泛的应用,在对
数据库
应用的过程中,人为误操作、人为恶意破坏、系统的不稳定、存储介质的损坏等等原因,都有可能造成重要数据的丢失。一旦数据出现丢失或者损坏,都将给企业和个人带来巨大的损失。这就需要进行
数据库
恢复
。 关键词:
数据库
技术;灾难性;
恢复
;数据备份 ABSTRACT With the database technology in various industries and a large number of wide application in various fields, in the process of database applications, artificial misuse, human vandalism, system instability, damage to storage media and other reasons may have resulted in important data lost. Once the data appears lost or damaged, both businesses and individuals will give enormous losses. This need for database recovery. Abstract: Database technology; catastrophic; recovery; Data BackupDevice Driver; Data Backup; Logical Block Address;
数据库
灾难性
恢复
1. 灾难类型 为了使
数据库
损失降低到最小程度,需要一个
恢复
策略,确保它起作用,并经常实行策略,一些灾难类型包括: 1. 系统故障。电源故障、硬件故障或软件故障都能够使
数据库
处于不一致状态。 2. 事务故障。用户无意中会用错误数据修改
数据库
,从而毁坏
数据库
。 3. 介质故障。如果磁盘驱动器变得不能使用,那么可能会丢失所有或部分数据。 4. 自然灾难。系统所在的设施可能会遭受火灾、洪水或其它类似灾难的损坏。 2.
恢复
类型
DB2
考虑到了下列
恢复
类型: 1.
崩溃
恢复
。这种类型的
恢复
通过撤销(回滚)未提交的事务来防止
数据库
处于不一致状态。 2. 版本
恢复
。这种类型的
恢复
通过使用从 BACKUP 命令获取的备份映像来
恢复
先前的
数据库
版本。
恢复
的
数据库
将包含在执行 BACKUP 命令时所处状态的信息。如果在执行备份之后针对
数据库
执行进一步操作,那么该信息将丢失。 3. 前滚
恢复
。这种类型的
恢复
通过使用完全
数据库
备份,结合日志
文件
来扩展版本
恢复
。必须先
恢复
备份以用作基线;然后在该备份之上应用日志。该过程会将
数据库
或
表空间
恢复
到某个特定时间点。前滚
恢复
要求启用归档日志记录。 3.
恢复
的级别 建立灾难
恢复
计划对于现代企业至关重要。企业
数据库
中的信息对于进行业务活动是极其重要的。保护该数据以及在灾难之后确保其“生命”是很重要的活动。当构建 DR计划时,有三个关键级别问题。 4. 需要防止的故障级别 要防止的故障级别通常是近似性问题。原始数据与其备份之间在物理上有多紧密?备份数据可以在不同的驱动器上、在独立的机器上、在独立的楼层上或在不同的建筑物里。不可能预测所有可能的灾难。火灾、水灾或甚至用户的恶作剧都可能是企业必须面对的问题。解决方案的设计应该包括公司希望防止最坏情况的方案。 4.1 可接受的数据丢失量 所有企业都不希望在故障之后丢失任何数据。虽然不丢失数据是可能的,但由于可能需要的复杂性和费用(尤其是如果所防止的故障级别非常高),这通常是不实际的。可接受的数据丢失量取决于数据对公司有多重要以及有什么资源可用于确保其生命。 4.2 允许用于
恢复
的时间量
恢复
所需的时间量类似于高可用性的目标。它与高可用性解决方案之间的差异在于所防止的故障类型以及通常认为合理的时间长度。HA 故障转移通常以秒和分钟来衡量,而灾难
恢复
则可能以小时和天来进行衡量。不过并非总是这样,但这个差异区分了对这些解决方案的相对期望。 4.3 备份和
恢复
数据库
备份创建了
数据库
的时间点映象,它是灾难
恢复
解决方案的基本组件。
DB2
提供了几种备份,包括脱机备份、联机备份和增量备份。从备份
恢复
所需的时间取决于
数据库
的大小和可用于执行
恢复
的硬件资源。 由于
数据库
备份只捕获时间点的数据,因此无法通过一个简单
恢复
来
恢复
备份之后发生的任何数据更改。要
恢复
备份之后完成的事务,就需要应用日志
文件
。可以从备份和日志
文件
(通过在日志
文件
中进行“前滚”来应用)来
恢复
数据库
。这允许
恢复
到某个时间点或
恢复
到日志
文件
结束。 因此,如果 DR 解决方案必须
恢复
自上次备份以来的事务,那么保留日志
文件
是非常关键的。有两个提高日志保留的
DB2
特性:双日志记录和用户出口工具,已在关于
数据库
复制 HA 选项的部分中进行了讨论。 5. 灾难
恢复
方案 灾难
恢复
方案可以分成三类:简单备份、备份和日志保留、高级存储备份 。 虽然不是每个解决方案都清晰地被划入这三类中的某一类,但它们确实为您理解灾难
恢复
选项提供了合理的框架。 5.1 简单备份 MySQL表保存为
文件
方式,很容易备份。要想保持备份的一致性,对相关表执行LOCK TABLES操作,然后对表执行FLUSH TABLES。你只需要读锁定;这样当你复制
数据库
目录中的
文件
时,允许其它客户继续查询表。需要FLUSH TABLES语句来确保开始备份前将所有激活的索引页写入硬盘。 备份
数据库
的另一个技术是使用mysqldump程序或mysqlhotcopy脚本。 1. 完全备份
数据库
: 2. shell> mysqldump --tab=/path/to/some/dir --opt db_name 或: shell> mysqlhotcopy db_name /path/to/some/dir 只要服务器不再进行更新,还可以只复制所有表
文件
(*.frm、*.MYD和*.MYI
文件
)。mysqlhotcopy脚本使用该方法。(但请注意如果
数据库
包含InnoDB表,这些方法不工作。InnoDB不将表的内容保存到
数据库
目录中,mysqlhotcopy只适合MyISAM表)。 3. 如果mysqld在运行则停止,然后用--log-bin[=file_name]选项来启动。二进制日志
文件
中提供了 执行mysqldump之后对
数据库
的更改进行复制所需要的信息。 对于InnoDB表,可以进行在线备份,不需要对表进行锁定; MySQL支持增量备份:需要用--log-bin选项来启动服务器以便启用二进制日志;当想要进行增量备份时(包含上一次完全备份或增量备份之后的所有更改),应使用FLUSH LOGS回滚二进制日志。然后,你需要将从最后的完全或增量备份的某个时刻到最后某个点的所有二进制日志复制到备份位置。这些二进制日志为增量备份;
恢复
时,按照下面的解释应用。下次进行完全备份时,还应使用FLUSH LOGS或mysqlhotcopy --flushlogs回滚二进制日志。如果MySQL服务器为从复制服务器,则无论选择什么备份方法,当备份从机数据时,还应备份master.info和relay-log.info
文件
。
恢复
了从机数据后,需要这些
文件
来继续复制。如果从机执行复制LOAD DATA INFILE命令,你应还备份--slave-load-tmpdir选项指定的目录中的SQL_LOAD-*
文件
。(如果未指定,该位置默认为tmpdir变量值)。从机需要这些
文件
来继续复制中断的LOAD DATA INFILE操作。 如果必须
恢复
MyISAM表,先使用REPAIR TABLE或myisamchk -r来
恢复
。99.9%的情况下该方法可以工作。如果myisamchk失败,试试下面的方法。请注意只有用--log-bin选项启动了MySQL从而启用二进制日志它才工作; 1.
恢复
原mysqldump备份,或二进制备份。 2. 执行下面的命令重新更新二进制日志: 3. shell> mysqlbinlog hostname-bin.[0-9]* | mysql 在某些情况下,你可能只想要从某个位置重新运行某些二进制日志。(通常你想要从
恢复
备份的日期重新运行所有二进制日志,查询不正确时例外)。 还可以对具体
文件
进行选择备份: • 要想复制表,使用SELECT * INTO OUTFILE 'file_name' FROM tbl_name。 要想重载表,使用LOAD DATA INFILE 'file_name' REPLACE ...并
恢复
。要避免复制记录,表必须有PRIMARY KEY或一个UNIQUE索引。当新记录复制唯一键值的旧记录时,REPLACE关键字可以将旧记录替换为新记录。 如果备份时遇到服务器性能问题,可以有帮助的一个策略是在从服务器而不是主服务器上建立复制并执行备份。如果使用Veritas
文件
系统,可以这样备份: 1. 从客户端程序执行FLUSH TABLES WITH READ LOCK。 2. 从另一个shell执行mount vxfs snapshot。 3. 从第一个客户端执行UNLOCK TABLES。 4. 从快照复制
文件
。 5. 卸载快照。 只创建
数据库
备份确实创建了一个 DR 解决方案。它也许是非常有限的,这取决于您的环境。通过从“活动”的系统上移走所创建的备份,可以提高保护的级别。增加
数据库
备份的频率也降低了数据丢失的风险。备份软件对于创建和维护
DB2
备份可能非常有帮助。例如,IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了允许在其软件控制的设备上直接备份和维护
DB2
数据库
的解决方案。这些设备可以是磁带库或另一种存储设备。 简单备份适合于只读
数据库
或由能轻松重新创建的批处理作业填充的
数据库
,或者在备份之间不必维护
数据库
更改的情况下。 表 1.简单备份的优缺点 优点: 缺点: 保护级别:
数据库
备份可以转移到外部位置,以提高保护级别 数据丢失的风险: 备份之间的数据更改可能会丢失(运行增量备份来降低风险的影响)
恢复
所需的时间:
数据库
恢复
需要很长时间 5.2 备份和日志保留 保留
数据库
日志
文件
与
数据库
备份一起创建了更完善的 DR 解决方案。日志
文件
允许
恢复
备份之间发生的数据更改。该解决方案的真正复杂性在于保护日志
文件
以确保它们在
恢复
期间的可用性。如果选择实现双日志记录,
DB2
可以将日志
文件
放在不同的位置,如果确保这些位置在不同的存储器阵列上,那么保护级别就会得到提高。但是,日志
文件
仍面临存储子系统故障。如在高可用性的日志传送选项中所提到的,用户出口程序可以提供重定位日志
文件
的替代方法。 用户出口可以将已关闭的日志
文件
移到当前系统可用存储阵列之外的位置,从而提高保护级别。这里的告诫是它只移动已关闭的日志
文件
。即使已实现了双日志记录,包含活动事务的日志
文件
仍面临因阵列丢失或存储设备故障而产生的丢失。该解决方案适合于大多数面向商业事务的环境。 它均衡了最小化数据丢失风险的需要和维护 DR 解决方案所需的成本。 表 2.备份加日志保留的优缺点 优点: 缺点: 保护级别:
数据库
备份可以转移到外部位置,以提高保护级别 数据丢失的风险: 如果使用适当的步骤来维护日志
文件
,会大大降低数据丢失的风险
恢复
所需的时间:
数据库
恢复
需要时间,应用日志
文件
将增加
恢复
时间 6. 高级存储备份 我们在高可用性下的高级存储选项部分中讨论过这个主题,相同的原则在这里也适用。正如在那部分中所见的,STANDBY方法允许当
数据库
副本处于暂挂状态时在辅助系统上执行
数据库
备份。 创建
数据库
副本已经创建了 DR解决方案的一部分。备份副本提高了保护级别。如果用双日志记录和用户出口程序正确实现了这个高级存储备份,那么它就为核心企业
数据库
生成了最好的 DR解决方案。 该解决方案最适合处于企业活动核心的
数据库
系统。示例可能包含了供应链管理和在线代理系统。 表 3.用于灾难
恢复
的高级存储备份优缺点 优点: 缺点: 保护级别: 保护级别本来就很高,而且可以通过耦合存储子系统来提高保护级别。 数据丢失的风险: 如果采用双日志记录和用户出口程序,会大大降低数据丢失的风险
恢复
所需的时间:
恢复
所需的时间非常短。 7.
数据库
恢复
数据库
恢复
中心理解为: (1)当
数据库
出现损伤或由于人员误操作、
操作系统
本身故障所造成的数据看不见、无法读取、丢失。工程师通过技术手段读取将数据都
恢复
为可以读的数据,数据
恢复
不是靠一两种软件就可以完成,往往需要数个工程师靠经验不同的方式才能
恢复
数据,当然
数据库
恢复
还包括各种
操作系统
:除普通的WINDOWS外,还有Unix、Linux、APPLE机,而以UNIX为多。 (2)
数据库
数据已经存在,但是无法正常使用,提示错误,都应归属为数据修复,举例说明:SQL SERVER
文件
打开提示LDF
文件
损坏,或错误823等等。
数据库
恢复
实际上就是利用技术手段把不可见或不可正常运行的数据
文件
恢复
成正常运行的过程。 方法一 如何附加
数据库
(企业管理器) 1、展开服务器组,然后展开服务器。 2、右击"
数据库
",然后选择"所有任务"/"附加
数据库
"。 3、输入要附加的
数据库
的 MDF(master 数据
文件
)名称。如果不确定
文件
位于何处,单击浏览("...")搜索。最多可以指定16个
文件
名。 4、若要确保指定的MDF
文件
正确,请单击"验证"。"原
文件
名"列列出了
数据库
中的所有
文件
(数据
文件
和日志
文件
)。"当前
文件
位置"列列出了
文件
的名称和路径。如果Microsoft? SQL Server? 找不到指定位置的
文件
,则附加操作将失败。可以对"当前
文件
位置"列进行编辑,并且
文件
的当前位置必须在该列中才能使附加操作得以进行。例如,如果在分离操作前改变了
文件
的默认位置,则必须指定当前位置才能使附加操作顺利进行。 5、在"附加为"框内,输入
数据库
的名称。
数据库
名称不能与任何
现有
数据库
名称相匹配 6、指定
数据库
的所有者。 7、单击"确定"按钮。新附加的
数据库
的
数据库
节点即创建在"
数据库
"
文件
夹中。 方法二 sp_attach_db 将
数据库
附加到服务器。 语法 sp_attach_db [ @dbname = ] 'dbname' , [ @filename1 = ] 'filename_n' [ ,...16 ] 参数 [@dbname =] 'dbname' 要附加到服务器的
数据库
的名称。该名称必须是唯一的。dbname 的数据类型为 sysname,默认值为 NULL。 [@filename1 =] 'filename_n'
数据库
文件
的物理名称,包括路径。filename_n 的数据类型为 nvarchar(260),默认值为 NULL。最多可以指定 16 个
文件
名。参数名称以 @filename1 开始,递增到 @filename16。
文件
名列表至少必须包括主
文件
,主
文件
包含指向
数据库
中其它
文件
的系统表。该列表还必须包括
数据库
分离后所有被移动的
文件
。 返回代码值 0(成功)或 1(失败) 结果集 无 注释 只应对以前使用显式 sp_detach_db 操作从
数据库
服务器分离的
数据库
执行 sp_attach_db。如果必须指定多于 16 个
文件
,请使用带有 FOR ATTACH 子句的 CREATE DATABASE。 如果将
数据库
附加到的服务器不是该
数据库
从中分离的服务器,并且启用了分离的
数据库
以进行复制,则应该运行 sp_removedbreplication 从
数据库
删除复制。 权限 只有 sysadmin 和 dbcreator 固定服务器角色的成员才能执行本过程。 示例 下面的示例将 pubs 中的两个
文件
附加到当前服务器。 EXEC sp_attach_db @dbname = N'pubs', @filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf', @filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs_log.ldf' 请参见 CREATE DATABASE sp_attach_single_file_db sp_detach_db sp_helpfile sp_removedbreplication 系统存储过程
Linux环境
数据库
管理员指南
目 录
译者序
前言
第1章 Linux
操作系统
1
1.1 Linux的简要历史介绍 1
1.2 Linux核心 2
1.2.1 Linux的开发特点 2
1.2.2 Linux分发包 3
1.2.3 为什么要为商业Linux
版本付费 3
1.3 Linux与其他
操作系统
之间的差异 3
1.3.1 功能丰富 3
1.3.2 多任务 4
1.4 为什么选择 Linux 6
1.4.1 何时使用 Linux 6
1.4.2 服务器与工作站 6
1.4.3 推荐的硬件 7
1.4.4 移植到 Linux工作站 7
1.5 Linux分发包 8
1.6 升级或移植前的考虑 10
1.6.1 硬件兼容性 11
1.6.2 升级 11
1.6.3 从其他
操作系统
进行移植 12
1.6.4 选择分发包 12
1.7 怎样着手工作 12
1.8 小结 13
1.9 常见问答 13
第2章 Red Hat Linux基本安装 16
2.1 引言 16
2.1.1 物理上独立的机器 16
2.1.2 选择 Linux分发包 16
2.2 初步的安装决定 17
2.2.1 硬件 17
2.2.2 多CPU 17
2.2.3 RAM 17
2.2.4 磁盘 17
2.2.5 RAID 18
2.2.6 网络接口 18
2.2.7 备份问题 19
2.2.8 支持问题 19
2.2.9 安装初步知识 19
2.3 安装 Red Hat 19
2.3.1 快速安装介绍 19
2.3.2 选择安装类型 22
2.4 定制(手工)安装 23
2.4.1 按要求创建分区 23
2.4.2 网络设置 26
2.4.3 时区选择 28
2.4.4 root账号配置 28
2.4.5 验证 29
2.4.6 使用 NIS 或 NIS+ 30
2.4.7 程序包选择 30
2.4.8 X Window 安装 32
2.4.9 程序包安装 34
2.4.10 Linux装载程序与引导盘 35
2.4.11 完成安装 36
2.4.12 配置服务器运行
数据库
36
2.4.13 需要注意的事项 36
2.5 Linux的其他风格 36
2.6 小结 37
2.7 常见问答 38
第3章 在 Linux上安装并运行 Oracle 40
3.1 引言 40
3.2 概念 41
3.2.1 系统全局区域 41
3.2.2 程序全局区域 42
3.2.3
表空间
42
3.2.4 数据
文件
42
3.2.5 区 42
3.2.6 段 42
3.2.7 控制
文件
42
3.2.8 重做日志 42
3.2.9 回退段 42
3.2.10 参数
文件
43
3.2.11 版本标识符 43
3.2.12 PL/SQL 43
3.2.13 模式 43
3.4 安装 43
3.4.1 安装前 44
3.4.2 安装Oracle 8 50
3.4.3 安装Oracle 8i 54
3.4.4 安装后 62
3.5 使用 Oracle 8/8i 65
3.5.1 启动和关闭 66
3.5.2 后台进程 67
3.5.3 创建帐号 68
3.5.4 SQL*Plus 70
3.5.5 数据字典 72
3.5.6 导入/导出 73
3.6 第三方软件 73
3.6.1 Orasoft 73
3.6.2 Orac 75
3.6.3 Perl/DBI 76
3.7 小结 76
3.8 常见问答 76
第4章 在Linux上安装 Informix 78
4.1 引言 78
4.2 安装 81
4.2.1 第一部分:软件的获取
和软件的服务器放置 81
4.2.2 第二部分:安装和标记 83
4.2.3 第三部分:磁盘设置和服务器
运行 85
4.2.4 建立 Informix 的数据
文件
86
4.2.5 关于磁盘 87
4.2.6 磁盘和目录 87
4.3 关于空间的考虑 88
4.4 配置 88
4.4.1 $INFORMIXDIR/etc/
$ONCONFIG 89
4.4.2 $INFORMIXDIR/etc/sqlhosts 100
4.4.3 /etc/services 100
4.4.4 /opt/data/rootdbs 101
4.4.5 利用 oninit 启动引擎 102
4.4.6 终止引擎 106
4.5 最后的配置 107
4.5.1 回顾 107
4.5.2 Physdbs 107
4.5.3 创建 physdbs
文件
108
4.5.4 logsdbs 111
4.5.5 创建 logsdbs 113
4.5.6 创建新的逻辑日志 114
4.5.7 Tempdbs 123
4.5.8 最终的 $ONCONFIG 配置值 125
4.5.9 重新启动引擎 126
4.6 其他工具 129
4.6.1 Dbaccess 132
4.6.2 Onmonitor 132
4.7 资源 133
4.7.1 Informix 技术支持组织 134
4.7.2 Informix Web 站点 134
4.7.3 Usenet 新闻组 comp.database.
informix 134
4.7.4 国际 Informix 用户组(IIUG) 134
4.7.5 Informix出版社 134
4.7.6 Informix 培训 134
4.8 小结 134
4.9 常见问答 135
第5章 在Linux上安装和使用 Sybase 136
5.1 引言 136
5.2 安装 136
5.2.1 安装 SQL Server 11.0.3 137
5.2.2 安装可选的客户机软件 141
5.3 配置 142
5.3.1 配置Sybase Database Server 143
5.3.2 配置Sybase Backup Server 149
5.3.3 配置Sybase Client/Server 库 150
5.3.4 在引导时启动
数据库
服
务器和备份服务器 151
5.3.5 设置系统管理员口令 151
5.3.6 配置
数据库
设备和
数据库
152
5.3.7 建立用户登录和权限 153
5.4 测试
数据库
156
5.5
数据库
设计 159
5.6 问题 161
5.6.1 标识列(自动增加) 161
5.6.2 SQL一致性 163
5.6.3 执行环境 164
5.7 小结 168
5.8 常见问答 169
第6章 在 Red Hat Linux上安装
DB2
Universal Database 6.1 170
6.1 引言 170
6.2 为安装
DB2
准备 Red Hat工作站 171
6.2.1 为
DB2
安装准备 Red Hat 5.2
和 6.0 172
6.2.2 为
DB2
安装准备 Red Hat 6.1 172
6.3 安装
DB2
173
6.3.1 进行安装 174
6.3.2 检验安装 180
6.4 配置Control Center 182
6.5 安装
DB2
客户机 184
6.6 配置
DB2
客户机与
DB2
服务器通信 188
6.7 小结 194
6.8 常见问答 195
第7章 在Linux上安装MySQL 198
7.1 引言 198
7.2 安装 199
7.2.1 命名约定 199
7.2.2 二进制分发包的安装 201
7.2.3 RPM 分发包的安装 202
7.2.4 源代码分发包的安装 202
7.3 配置 204
7.3.1 安全性 204
7.3.2 权限 205
7.3.3 访问控制 208
7.3.4 系统设置 209
7.3.5 性能 210
7.4 问题 212
7.4.1 线程 213
7.4.2 运行环境 213
7.5 故障处理 214
7.6 小结 215
7.7 常见问答 216
第8章 在Linux上安装和管理Progress 218
8.1 引言 218
8.2 安装 218
8.2.1 从介质中安装 219
8.2.2 核心参数 223
8.2.3 环境设置 225
8.3 配置 226
8.3.1 目录结构 227
8.3.2 磁盘空间与 I/O 吞吐量 227
8.3.3 创建新
数据库
229
8.3.4 设置缓冲池尺寸 230
8.4 运行Progress 231
8.5 故障排除 241
8.6 优缺点 242
8.6.1 4GL 243
8.6.2 面向 OLTP 243
8.6.3 可靠的
崩溃
恢复
243
8.6.4 成本 243
8.6.5 词索引 244
8.6.6 国际化 244
8.6.7 24×7运转 244
8.6.8 无二进制大对象 244
8.6.9 无并行查询 245
8.6.10 无分布式锁管理程序 245
8.7 小结 249
8.8 常见问答 249
第9章 Linux上的Postgre SQL 252
9.1 引言 252
9.2 Internet 驱动Postgre SQL 252
9.3 获得Postgre SQL 253
9.4 PostgreSQL 快速安装说明 254
9.5 详细安装 255
9.6 资源分发包的安装 259
9.6.1 准备工作 259
9.6.2 循序渐进的过程 260
9.7 PostgreSQL样例 RPM 264
9.8 测试Tcl/Tk接口 264
9.9 测试Python接口—PyGreSQL 264
9.10 测试Perl接口 265
9.11 测试libpq和libpq++ 接口 265
9.12 测试Java接口 266
9.13 测试ecpg接口 266
9.14 测试ODBC接口 267
9.15 测试MPSQL Motif-Worksheet
接口 267
9.16 测试SQL样例—用户定义
类型和函数 267
9.17 验证PostgreSQL安装 267
9.18 紧急问题处理 268
9.19 怎样才能信赖 PostgreSQL 268
9.20 系统布局 268
9.21 Kerberos 验证 269
9.21.1 可用性 269
9.21.2 安装 269
9.21.3 运行 269
9.22 运行时的环境—从 UNIX/Linux
中使用 Postgres 270
9.22.1 启动 postmaster 270
9.22.2 使用 pg_options 270
9.22.3 认可的选项 271
9.23 安全 273
9.23.1 用户验证 273
9.23.2 基于主机的访问控制 273
9.23.3 验证方法 274
9.23.4 建立用户 275
9.23.5 建立组 275
9.23.6 访问控制 275
9.23.7 函数和规则 275
9.23.8 函数 275
9.23.9 规则 276
9.23.10 说明 276
9.23.11 安全的TCP/IP连接 276
9.23.12 通过ssh运行安全隧道 276
9.24 增加与删除用户 276
9.25 磁盘管理—支持大型
数据库
277
9.26 管理
数据库
278
9.26.1 创建
数据库
278
9.26.2 访问
数据库
278
9.26.3 删除
数据库
279
9.26.4 备份和
恢复
279
9.26.5 大型
数据库
280
9.27 使用 PostgreSQL 的 KVM 开关 280
9.28 故障排除—postmaster
启动故障 281
9.28.1 客户机连接问题 282
9.28.2 调试消息 282
9.28.3 pg_options 283
9.29 技术支持 284
9.30 邮件清单 284
9.30.1 PostgreSQL 的电子邮件账号 284
9.30.2 英文邮件清单 285
9.30.3 邮件清单的归档 285
9.30.4 西班牙邮件清单 285
9.31 PostgreSQL的GUI前台工具 285
9.32 ODBC、JDBC和UDBC驱动程序 286
9.33 Perl 和 DBI 接口 287
9.34 PostgreSQL的教材 289
9.35 PostgreSQL URL 参考 290
9.36 小结 290
9.37 常见问答 291
第10章 开发基于Web的应用程序 295
10.1 引言 295
10.2 Web 应用程序平台 296
10.2.1 Active Server Pages 296
10.2.2 Cold Fusion 296
10.2.3 Java Server Pages 296
10.2.4 Zope 296
10.2.5 Scripting Languages 296
10.2.6 PHP 297
10.2.7 Apache 297
10.3 入门 297
10.4 设计相应的模式 298
10.5 数据流 299
10.5.1 PHP、MySQL 和 Apache:
安装样例应用程序 300
10.5.2 PHP
数据库
连通性:进行连接 300
10.6 小结 302
10.7 常见问答 302
附录A 汽车销售应用程序脚本 304
附录B 汽车销售应用程序转储
文件
327
PostgreSQL
数据库
管理(四)
PostgreSQL是以加州大学伯克利分校计算机系开发的POSTGRES,现在已经更名为PostgreSQL. PostgreSQL支持大部分SQL标准并且提供了许多其它现代特性:复杂查询、外键、触发器、视图、事务完整性等。PostgreSQL 是一个免费的对象-关系
数据库
服务器(
数据库
管理系统),它在灵活的 BSD-风格许可证下发行。它提供了相对其他开放源代码
数据库
系统(比如 MySQL 和 Firebird),和专有系统(比如 Oracle、Sybase、IBM 的
DB2
和 Microsoft SQL Server)之外的另一种选择。事实上, PostgreSQL 的特性覆盖了 SQL-2/SQL-92 和 SQL-3/SQL-99,首先,它包括了可以说是目前世界上最丰富的数据类型的支持,其中有些数据类型可以说连商业
数据库
都不具备, 比如 IP 类型和几何类型等;其次,PostgreSQL 是全功能的自由软件
数据库
,很长时间以来,PostgreSQL 是唯一支持事务、子查询、多版本并行控制系统(MVCC)、数据完整性检查等特性的唯一的一种自由软件的
数据库
管理系统。 Inprise 的 InterBase 以及SAP等厂商将其原先专有软件开放为自由软件之后才打破了这个唯一。最后,PostgreSQL拥有一支非常活跃的开发队伍,而且在许多黑客的努力下,PostgreSQL 的质量日益提高。从技术角度来讲,PostgreSQL 采用的是比较经典的C/S(client/server)结构,也就是一个客户端对应一个服务器端守护进程的模式,这个守护进程分析客户端来的查询请求,生成规划树,进行数据检索并最终把结果格式化输出后返回给客户端。为了便于客户端的程序的编写,由
数据库
服务器提供了统一的客户端 C 接口。而不同的客户端接口都是源自这个 C 接口,比如ODBC,JDBC,Python,Perl,Tcl,C/C++,ESQL等, 同时也要指出的是,PostgreSQL 对接口的支持也是非常丰富的,几乎支持所有类型的
数据库
客户端接口。这一点也可以说是 PostgreSQL 一大优点。本课程作为PostgreSQL
数据库
管理一,主要讲解以下内容: 1. PostgreSQL 存储过程基本知识2. PostgreSQL 用户自定义函数3. PostgreSQL 控制结构4. PostgreSQL 游标和存储过程5. PostgreSQL 索引6. PostgreSQL 视图7. PostgreSQL 触发器8. PostgreSQL 角色、备份和还原9. PostgreSQL
表空间
管理
Atomikos3.9官方包文档以及实例
Atomikos TransactionsEssentials 是一个为Java平台提供增值服务的并且开源类事务管理器,以下是包括在这个开源版本中的一些功能: l 全面
崩溃
/ 重启
恢复
l 兼容标准的SUN公司JTA API l 嵌套事务 l 为XA和非XA提供内置的JDBC适配器 注释:XA:XA协议由Tuxedo首先提出的,并交给X/Open组织,作为资源管理器(
数据库
)与事务管理器的接口标准。目前,Oracle、Informix、
DB2
和Sybase等各大
数据库
厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数,以xa_开头的及以ax_开头的。 以下的函数使事务管理器可以对资源管理器进行的操作: 1)xa_open,xa_close:建立和关闭与资源管理器的连接。 2)xa_start,xa_end:开始和结束一个本地事务。 3)xa_prepare,xa_commit,xa_rollback:预提交、提交和回滚一个本地事务。 4)xa_recover:回滚一个已进行预提交的事务。 5)ax_开头的函数使资源管理器可以动态地在事务管理器中进行注册,并可以对XID(TRANSACTION IDS)进行操作。 6)ax_reg,ax_unreg;允许一个资源管理器在一个TMS(TRANSACTION MANAGER SERVER)中动态注册或撤消注册。 l 内置的JMS适配器XA-capable JMS队列连接器 注释:JMS:jms即Java消息服务(Java Message Service)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。Java消息服务是一个与具体平台无关的API,绝大多数MOM提供商都对JMS提供支持。 l 通过XA API兼容第三方适配器 l 更好的整合您的项目 l 集成Hibernate 如何使用Atomikos TransactionsEssentials Atomikos TransactionsEssentials 是一个可靠的库,可以加入到您的Java应用程序,也就是说为了使用这个产品,您必须添加一些jar
文件
(包括在dist和lib
文件
夹下)到您的应用程序或者应用程序服务器。 请注意:Atomikos TransactionsEssentials是一个非常快速的嵌入式事务管理器,这就意味着,您不需要另外启动一个单独的事务管理器进程(不要查找任何的bin
文件
夹)。相反,您的应用服务器将有它自己的intra-VM事务管理器。 配置需求:至少Java1.5 jdk,并且最少128M的内存 性能优化:尽管这个软件有着很大的优势,但是想要更好的发挥其作用,可以按以下的方法优化: l 更高的内存,意味着更高的吞吐量(每秒的事务数目) l 使连接池尽可能的大 l 一旦你不需要的连接请马上关闭它们。不要把你的应用程序放在缓存里,让内部连接池为你做这些,这将促使更高效的连接使用 l 不要让活动的事务闲置:终止所有情况下的事务,尤其是在异常报错情况下的事务。这将减少
数据库
的锁定时间,并且最大效率的处理启用的使用。 如果想获取这些细节的更多信息,也要参阅文档说明部分。 值得注意的是,在我们所有的压力测试中,Atomikos TransactionsEssentials比J2EE的web容器更高效的吞吐量。这些测量值包括日志记录的高效的事务状态,同样,在我们所有的测量中,包括XA和non-XA,高效的效率是一样的。 在J2SE中使用Atomikos Transactions Essentials,只需要按以下步骤 将idst和lib中的jar包全部放入的项目中 创建或者自定义你应用的transactions.properties(或者jta.properties)
文件
(事务管理器的配置),然后将它放入到classpath中,安装
文件
夹中包涵一个实例
文件
;在properties
文件
中注释(#)后面的是默认值,取消一行并且改变默认值。
DB2
数据库
在正常运行时候,
操作系统
突然
崩溃
,
数据库
恢复
办法
首先,此方法仅适用于Windows,Linux暂时没做测试 有一次项目上服务器
操作系统
突然
崩溃
,然而里边
db2
数据库
没有及时做备份,经过现场测试,发现以下方法可以完美将
数据库
恢复
。
数据库
介绍:
数据库
所有
表空间
都存放于D盘,当时E盘有一部分日志,C盘有一部分系统日志。 操作方法如下: 安装一个和原
数据库
环境完全相同的
db2
数据库
操作系统
环境,用户名,磁盘分区保证要一致 新服务器
db2
环境安装好后将
db2
服务停掉 用PE环境进入
崩溃
的那台
操作系统
拷贝
文件
将原C盘目录的 C:\
DB2
C
DB2
5,889
社区成员
11,654
社区内容
发帖
与我相关
我的任务
DB2
IBM DB2 是美国IBM公司开发的一套关系型数据库管理系统,它主要的运行环境为UNIX(包括IBM自家的AIX)、Linux、IBM i(旧称OS/400)、z/OS,以及Windows服务器版本
复制链接
扫一扫
分享
社区描述
IBM DB2 是美国IBM公司开发的一套关系型数据库管理系统,它主要的运行环境为UNIX(包括IBM自家的AIX)、Linux、IBM i(旧称OS/400)、z/OS,以及Windows服务器版本
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章