主流数据库体系架构及方案介绍.pptx

主流数据库体系结构及方案介绍 解决方案部2016年01月 ANYTIMEANYQUESTION 本讲内容 1 Oracle数据库基本架构及常见方案2 K DB数据库基本架构及常见方案3 DB2数据库基本架构及常见方案4 Sybase数据库基本架构及常见方案5 MySQL数据库基本架构及常见方案 概述 Oracle数据基本架构 概述 Oracle数据基本架构 内存结构 Oracle数据基本架构 进程 Oracle数据基本架构 实例管理 Oracle数据基本架构 实例管理 Oracle数据基本架构 物理数据库结构 Oracle数据基本架构 OMF OracleManagedFiles OMF 按照数据库对象而不是文件名指定文件操作 Oracle数据基本架构 逻辑和物理数据库结构 Oracle数据基本架构 结构组件汇总 内存结构系统全局区 SGA 数据库缓冲区高速缓存 重做缓冲区以及各种池程序全局区 PGA 进程结构用户进程和服务器进程后台进程 SMON PMON DBWn CKPT LGWR ARCn等存储结构逻辑 数据库 方案 表空间 段 区和Oracle块物理 用于存储数据 参数 重做和操作系统块的文件 Oracle数据库常见方案 OracleRAC OracleRealApplicationServer 真正应用集群 简称OracleRAC 是Oracle的并行集群 位于不同服务器系统的Oracle实例同时访问同一个Oracle数据库 节点之间通过私有网络进行通信 所有的控制文件 联机日志和数据文件存放在共享的设备上 能够被集群中的所有节点同时读写 什么是OracleRAC集群 Oracle数据库常见方案 OracleRAC体系结构 集群的数据库服务器 镜像磁盘子系统 高速交换机和互联 集线器或交换机结构 网络 集中管理控制台 存储区域网 低延迟互联 用户 无单点故障 Oracle数据库常见方案 OracleRAC体系结构 共享磁盘数据库 共享数据模型 Oracle数据库常见方案 OracleRAC体系结构 公用网络 节点1 共享存储 重做日志所有实例 数据库和控制文件 OCR和voting磁盘 oracle home 操作系统 CRS 集群互联 数据库实例1 ASM实例1 集群互联 Oracle数据库常见方案 OracleRAC体系结构 客户端首先访问某个实例 让后再通过集群管理软件访问到数据库的数据 节点之间使用内部连接进行通讯 Oracle数据库常见方案 OracleRAC优势 多节点负载均衡 提供高可用 故障容错和无缝切换功能 将硬件和软件错误造成的影响最小化 Oracle数据库常见方案 OracleRAC优势 通过并行执行技术提高事务响应时间 通常用于数据分析系统 通过横向扩展提高每秒交易数和连接数 通常对于联机事务系统 可扩展性好 可以方便添加删除节点 扩展硬件资源 Oracle数据库常见方案 OracleDataGuard Oracle为Oracle数据提供的灾难恢复解决方案Oracle数据库企业版 EE 的特性自动创建和维护生产数据库 或主数据库 的一个或多个事务一致的副本 备用数据库 如果主数据库 因灾难 维护 不可用 那么可以激活一个备用数据库并使之承担主数据库的角色要求主服务器和备用服务器上的Oracle数据库和操作系统的版本相同 什么是OracleDataGuard Oracle数据库常见方案 OracleDataGuard OracleDataGuard核心 数据故障与站点灾难 此外还解决了人为错误和计划维护的问题 数据保护数据可用性数据恢复 数据是企业的核心资产 Oracle数据库常见方案 OracleDataGuard OracleDataGuard结构 网络 逻辑备用数据库 可用于报表操作 SQL应用 将重做转换成SQL 额外的索引和物化视图 物理备用数据库 备份 重做应用 同步或异步重做传输 最新的物理 逻辑备用数据库 MRP LSP RFS 备用重做日志 ARCH Oracle数据库常见方案 OracleDataGuard 存档的重做日志 存档的重做日志 主数据库 事务 LGWR 联机重做日志 ARCH Oracle网络 实时应用 DataGuard重做应用 物理备用数据库是主数据库的一个块到块的副本使用数据库恢复功能来应用更改可以以只读方式打开 用于生成报表和查询还可用于备份和减轻生产数据库的负载 主数据库 物理备用数据库 重做传输 网络 重做应用 备份 备用重做日志 DataGuardBroker Oracle数据库常见方案 OracleDataGuard Oracle数据库常见方案 OracleDataGuard DataGuardSQL应用 逻辑备用数据库是一个开放 独立和活动的数据库包含与生产数据库相同的逻辑信息 行 物理组织和结构可能大不相同可以托管多种模式当通过SQL来应用日志时 可以查询逻辑备用数据库 以进行报表操作可以创建额外的索引和物化视图 以获得更高的查询性能 额外的索引和物化视图 重做传输 网络 可随时进行报表操作 将重做转换成SQL并应用 DataGuardBroker 主数据库 逻辑备用数据库 备用重做日志 Oracle数据库常见方案 OracleDataGuard DataGuard的优点 网络效率只传输重做数据更适于WAN无需协议转换器 基于标准的TCP IP更好的数据保护保持写顺序的一致性 避免逻辑损坏和物理损坏 功能全面的DR解决方案灵活性底层存储器对供应商没有限制ROI从DR投资中提取价值 与数据库本地集成 Oracle数据库常见方案 OracleDataGuard 灵活的数据保护模式 均衡成本 可用性 性能和事务保护 例如 ALTERDATABASESETSTANDBYTOMAXIMIZEPROTECTION Oracle数据库常见方案 OracleDataGuard DataGuard和RAC DataGuard和真正应用集群是互补的 应一起使用以实现最高可用性结构真正应用集群提供了高可用性能够快速和自动地从节点故障或一个实例崩溃中恢复过来提供了增强的可伸缩性DataGuard提供了灾难保护并防止数据丢失维护主数据库的几个事务一致的副本防止灾难 数据损坏和用户错误无需昂贵且复杂的HW SW镜像 Oracle数据库常见方案 OracleDataGuard Streams和DataGuard是Oracle数据库企业版两个独立的特性 它们基于一些共同的底层技术DataGuard 灾难恢复与数据保护事务一致的备用数据库零数据丢失自动转换 故障切换各种数据保护模式Streams 信息共享 分发细粒化和控制要复制的内容双向复制数据转换异种平台由于业务需要 客户可能选择将Streams用于DR HA 而将DataGuardSQL应用用于信息分发 DataGuard与Streams Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate Oracle数据库常见方案 OracleGoldenGate DB2数据库体系结构 DB2简介 IBMDB2是美国IBM公司开发的一套关系型数据库管理系统 它主要的运行环境为UNIX 包括IBM自家的AIX Linux IBMi 旧称OS 400 z OS 以及Windows服务器版本 DB2主要应用于大型应用系统 具有较好的可伸缩性 可支持从大型机到单用户环境 应用于所有常见的服务器操作系统平台下 DB2提供了高层次的数据利用性 完整性 安全性 可恢复性 以及小规模到大规模应用程序的执行能力 具有与平台无关的基本功能和SQL命令 DB2数据库体系结构 DB2体系结构 DB2数据库体系结构 DB2体系结构 系统DB2体系结构中的最高一层是系统 一个系统表示DB2的一个安装 在由很多机器组成的网络环境中 我们有时也称系统为数据库分区 一个系统可以包含多个DB2实例 每个实例能够管理一个或多个数据库 实例实例也称为数据库管理器 DatabaseManagementApplication 是数据库管理器在内存中的映像 是管理数据的DB2代码 实例相当于Informix的InformixServer 在一台机器上可以有多个相互独立的实例 实例之间彼此独立 同时运行 不会相互影响 每个实例可以管理若干个数据库 一个数据库只属于一个实例 实例可控制对数据执行的操作 并管理分配给实例的系统资源 每个实例都是独立的运行环境 可以编目数据库和设置配置参数 可以在同一物理服务器上创建多个实例 并为每个实例提供唯一的数据库服务器环境 Database关系数据库使用一组表来管理数据 表由在行和列中以逻辑关系排列的数据组成 每个表的数据在逻辑上相关 在表之间能够定义关系 DB2数据库体系结构 DB2体系结构 Database关系数据库使用一组表来管理数据 表由在行和列中以逻辑关系排列的数据组成 每个表的数据在逻辑上相关 在表之间能够定义关系 每个数据库包含一组系统编目表 或称之为数据字典 配置文件和恢复日志 系统编目表用于描述数据的逻辑和物理结构 配置文件包含所有为数据库分配的配置参数值 恢复日志记录正在进行的事务处理和可存档的事务处理 数据库可以是本地的 也可以是远程的 本地数据库物理上位于本地的机器上 当数据库物理上驻留在另一台机器上时 则称为远程的 DB2数据库体系结构 DB2内存结构 DB2数据库体系结构 DB2内存结构 InstanceSharedMemory 实例共享内存 每个DB2实例都有一个实例共享内存 实例共享内存是在数据库管理器启动 db2start 时分配的 并随着数据库管理器的停止 db2stop 而释放 这种内存用于实例级的任务 例如监控 审计和节点间通信 数据库管理器配置 dbmcfg 参数控制着对实例共享内存以及其中个别内存池的限制 实例内存 InstanceMemory 1 监视器堆 mon heap sz 用于监控 2 AuditBuffer audit buf sz 用于db2audit实用程序 3 FastCommunicationsbuffers fcm num buffers 用于分区之间的节点间通信 仅适用于分区的实例 INSTANCE MEMORY参数指定为实例管理预留的内存数量 默认值为AUTOMATIC 这意味着DB2将根据监视器堆 审计缓冲区和FCM缓冲区的大小计算当前配置所需的实例内存数量 此外 DB2还将分配一些额外的内存 作为溢出缓冲区 每当某个堆超出了其配置的大小时 便可以使用溢出缓冲区来满足实例共享内存区内任何堆的峰值需求 在这种情况下 个别堆的设置是软限制的 它们可以在内存使用的峰值期间进一步增长 如果instance memory被设置为某一个数字 则采用instance memory与mon heap sz audit buf sz和fcm num buffers的和之间的较大者 这时 对实例内存就施加了一个硬性的限制 而不是软限制 当达到这个限制时 就会收到内存分配错误 出于这个原因 建议将instance memory的设置保留为AUTOMATIC DB2数据库体系结构 DB2内存结构 DatabaseSharedMemory DB2数据库体系结构 DB2内存结构 DatabaseSharedMemory每个数据库有一个数据库共享内存集 数据库共享内存是在数据库被激活或者第一次被连接上的时候分配的 该内存集将在数据库处于非激活状态时释放 如果数据库先前是处于激活状态 或者最后一个连接被断开的时候释放 这种内存用于数据库级的任务 例如备份 恢复 锁定和SQL的执行 大致由以下几部分组成 有些是一开始就分配好的 有些是在做某些操作时才分配的 MainBufferpoolsHiddenBufferpoolsCatalogCacheLockHeapPackageCacheSharedSortDatabaseHeap includeLogBuffer DB2数据库体系结构 DB2内存结构 DatabaseSharedMemory1 MainBufferpools 数据库缓冲池通常是数据库共享内存中最大的一块内存 DB2在其中操纵所有常规数据和索引数据 一个数据库必须至少有一个缓冲池 并且可以有多个缓冲池 这要视工作负载的特征 数据库中使用的数据库页面大小等因素而定 例如 页面大小为8KB的表空间只能使用页面大小为8KB的缓冲池 2 HiddenBufferpools 当数据库启动时 要分配4个页宽分别为4K 8K 16K和32K的小型缓冲池 这些缓冲池是 隐藏 的 因为在系统编目中看不到它们 通过SELECT FROMSYSCAT BUFFERPOOLS显示不出 如果主缓冲池配置得太大 则可能出现主缓冲池不适合可寻址内存空间的情况 我们在后面会谈到可寻址内存 这意味着DB2无法启动数据库 因为一个数据库至少必须有一个缓冲池 如果数据库没有启动 那么就不能连接到数据库 也就不能更改缓冲池的大小 由于这个原因 DB2预先分配了4个这样的小型缓冲池 这样 一旦主缓冲池无法启动 DB2还可以使用这些小型的缓冲池来启动数据库 在此情况下 用户将收到一条警告 SQLSTATE01626 这时 应该连接到数据库 并减少主缓冲池的大小 3 排序堆的阈值 sheapthres sheapthres shr 1 如果没有索引满足所取的行的要求顺序 或者优化器断定排序的代价低于索引扫描 那么就需要进行排序 DB2中有两种排序 一种是私有排序 一种是共享排序 私有排序发生在代理的私有代理内存 在下一节讨论 中 而共享排序发生在数据库的数据库共享内存中 DB2数据库体系结构 DB2内存结构 DatabaseSharedMemory4 PackageCacheandCatalogCache1 虽然大多数内存池的大小是由它们的配置参数预先确定的 但下面两种内存池的大小在默认情况下却是动态的 a 包缓存 pckcachesz maxappls 8b 编目缓存 catalogcache sz maxappls 4c 活动应用程序的最大数量 maxappls AUTOMATIC2 将maxappls设为AUTOMATIC的效果是 允许任意数量的连接数据库的应用程序 DB2将动态地分配所需资源 以支持新的应用程序 因此 包缓存和编目的大小可以随着maxappls的值而变化 DB2数据库体系结构 DB2进程结构 DB2数据库体系结构 DB2进程结构 上图DB2的进程模型 长方形代表处理进程 椭圆形代表处理线程 DB2的主进程是db2sysc 在这个处理进程下有许多线程 最主要的线程也是叫db2sysc 这个主要的线程派生了其他子线程 当一个远程的应用程序比如采用sqlconnect语句链接服务器时 通讯协议的远程监听器将接收这个请求 并联系db2agent agent是一个代表DB2实现一些小操作的处理程序 当发出请求的应用程序是本地的 也就是和DB2服务器在同一服务器上 如果不在同一个服务器上 那么采用db2tcpcm处理本地请求 如果在一台服务器上采用db2ipccm线程来处理请求 如果发生本地和异地并行的情况 db2agent会生成其他线程的代理db2agntp线程 其他的线程如db2pfchr db2loggr db2dlock它们应用到不同的目的 DB2数据库体系结构 DB2进程结构 db2wdog进程 我们都知道在UNIX Linux上 init进程是所有进程的父进程 同样 在DB2的进程中 db2wdog 进程是所有其他DB2进程的父进程 这个进程是由操作系统的init进程派生的 从上面的命令输出中我们可以看到 db2wdog 的 ppid parentpid 是操作系统的init进程 db2wdog 进程是在UNIX和Linux操作系统上处理异常终止的看守程序 db2wdog 是 db2watchdog 的缩写 是看门狗的意思 这个进程的工作机制如图2 3所示 在UNIX中 db2wdog 看守程序是必需的 因为UNIX中的进程只能跟踪其父进程的标识 如图2 3所示 每次新进程启动时 db2gds 进程就会通知DB2看守程序 如果任何DB2进程接收到CTRL C或其他异常信号 该进程就会向看守程序发送信号 而看守程序会将信号传播给实例中其他所有进程 如果 dbzwdog 进程出现异常 那么整个DB2数据库将无法正常工作 DB2数据库HADR高可用性灾难恢复 DB2forLinux UNIX andWindows高可用性灾难恢复 HighAvailabilityDisasterRecovery HADR 功能是一种数据复制功能 它为部分和全面的站点故障提供了一种高可用性解决方案 HADR通过将称为主要数据库的源数据库中的数据更改复制到称为备用数据库的目标数据库 防止数据丢失 HADR是在DB2V8 2中引入的 在DB2V9 7FixPack1之前 备用服务器只能前滚从主要服务器传来的日志记录 并且对用户而言是离线的 不允许在备用数据库上建立用户连接 从DB2V9 7FixPack1开始 readsonstandby功能 HADRRoS 支持只读应用程序访问备用数据库 这只有在启用了readsonstandby功能时才可行 使用此功能 读 写应用程序可访问HADR主要数据库 只读应用程序可访问主要或备用数据库 这支持您将在主要数据库上运行的一些只读工作负载卸载到备用数据库上 连接备用数据库的应用程序在故障转移时不会影响备用数据库的可用性 DB2数据库HADR高可用性灾难恢复 HighAvailabilityDisasterRecovery HADR 是数据库级别的高可用性数据复制机制 最初被应用于Informix数据库系统中 称为HighAvailabilityDataReplication HDR IBM收购Informix之后 这项技术就应用到了新的DB2发行版中 一个HADR环境需要两台数据库服务器 主数据库服务器 primary 和备用数据库服务器 standby 当主数据库中发生事务操作时 会同时将日志文件通过TCP IP协议传送到备用数据库服务器 然后备用数据库对接受到的日志文件进行重放 Replay 从而保持与主数据库的一致性 当主数据库发生故障时 备用数据库服务器可以接管主数据库服务器的事务处理 此时 备用数据库服务器作为新的主数据库服务器进行数据库的读写操作 而客户端应用程序的数据库连接可以通过自动客户端重新路由 AutomaticClientReroute 机制转移到新的主服务器 当原来的主数据库服务器被修复后 又可以作为新的备用数据库服务器加入HADR 通过这种机制 DB2UDB实现了数据库的灾难恢复和高可用性 最大限度的避免了数据丢失 下图为DB2HADR的工作原理图 DB2数据库HADR高可用性灾难恢复 DB2数据库HADR高可用性灾难恢复 什么是HADR DB2HADR特性采用InformixHDR技术采用日志复制技术 快速切换和灾难恢复 Informix HDR HighAvailabilityDataReplication IBM HADR HighAvailabilityDisasterRecovery DB2数据库HADR高可用性灾难恢复 HADR同步方式DB2HADR支持四种同步模式 同步 近同步 异步和超级异步 四种同步模式对网络的要求和对主数据库的影响依次减小 但是可靠性也依次降低 例如 同步模式对主数据库上的事务影响最大 但是可以保证从数据库上的事务和主数据库是实时一致的 而超级异步模式对主数据库上的事务没有任何影响 但是一旦主数据库出现事故 就可能会发生事务丢失 DB2数据库HADR高可用性灾难恢复 HADR同步方式 SYNC 同步 在同步模式下 当用户在主数据库上提交一个事务时 首先该事务的相关数据库日志会被写到主数据库的本地磁盘上 然后主数据库会将日志发送给备机数据库 并且等待备机数据库的回复 备机数据库在接收到日志 并将其写到自己的磁盘上后 才回复给主数据库 主数据库在接到备机数据库的回复之后 才返回给用户该事务提交成功 由此可见 在该同步模式下 凡是提交成功的事务 日志不仅在主数据库的磁盘上 也在备机数据库的磁盘上 此时如果主数据库发生故障 已提交的数据不会丢失 因此 在同步模式下 HADR能够提供无数据丢失保证 Nodatalossguarantee 但是 在该同步模式下 HADR对主数据库业务的影响也是显而易见的 DB2数据库HADR高可用性灾难恢复 HADR同步方式 近同步模式 NEARSYNC 与同步模式相比 近同步模式下的备机数据库接收到主数据库发来的日志时 并不等待将其写到本地磁盘之后才回复给主数据库 而是立即回复给主数据库 主数据库在接收到备机数据库的回复之后就返回给用户事务提交成功 而此时 该事务的日志可能还在备机数据库的内存中 并未写到本地盘上 如果此时主机发生故障 并不能保证在原主数据库上已提交的数据在备机上必然能找回 虽然该同步模式不能保证零数据丢失 但是相比同步模式 近同步模式下的HADR对于主数据库业务的影响较小 DB2数据库HADR高可用性灾难恢复 HADR同步方式 异步模式 ASYNC 在异步模式下 主数据库发送日志成功后就返回给用户 事务提交成功 而此时 备机数据库有可能还没有收到这些日志 如果此时主数据库发生故障 该已提交事务的数据更改就会丢失 同样的 由于异步模式下的主数据库在返回给用户事务提交成功之前不等待备机数据库的回复 HADR对主数据库上业务的影响比近同步模式更小 这种模式下 因为日志有可能仍然在主机的TCP缓冲区里面 如果这个时候主机出现故障停机 这些数据就会丢失 DB2数据库HADR高可用性灾难恢复 HADR同步方式 超级异步模式 SUPERASYNC 从DB2LUWV9 7 5和V9 5 8开始 HADR引入了一种新的同步模式 即超同步模式 在该同步模式下 主数据库上数据库日志的产生与发送完全分离 二者没有任何依赖 这样HADR对于主数据库业务的影响降到了最低 同时 由于日志的产生与发送分离 可能导致主数据库和备机数据库之间的差距较大 此时如果主机发生故障 会有较多的数据丢失 并且非强制接管 non forceTAKEOVER 可能需要更多时间 以上四种同步模式 同步强度从强到弱 无数据丢失保证从高到低 DB2数据库HADR高可用性灾难恢复 DB2HADR的使用限制1 只有DB2UDBEnterpriseServerEdition ESE 支持HADR 但HADR不能支持分区数据库 DatabasePartitioningFeature DPF 2 主数据库和备用数据库必须运行在相同的操作系统版本上 并且DB2UDB的版本也必须一致 除非短暂的软件升级过程 3 主数据库和备用数据库的位大小必须一致 32位或64位 4 不能在备用数据库上进行备份操作5 备用数据库是不能访问的 客户端程序无法连接备用数据库 6 日志归档操作只能在主数据库上进行 7 带有COPYNO选项的LOAD命令是不支持的8 主数据库和备用数据库必须是一对一的 9 HADR不能使用循环日志10 HADR不复制数据库配置参数 共享库 DLLs UDFs或存储过程 DB2数据库常见方案 InfoSphereCDC IBMInfoSphereChangeDataCapture 简称InfoSphereCDC 作为一款跨数据库复制解决方案 支持不同DB2fori之间 甚至是异构数据库之间的实时数据复制 满足了HA环境下对于数据灾备的需求 DB2数据库常见方案 InfoSphereCDC 什么是InfoSphereCDCIBMInfoSphereChangeDataCapture 以下简称InfoSphereCDC 是一个跨不同数据库的实时数据复制解决方案 支持DB2 Informix Oracle MicrosoftSQLServer Sybase Teradata SolidDB等各种主流数据库 InfoSphereCDC通过读取源数据库的日志获取变化的数据 并经过适当的转换将数据复制到数据目标中 InfoSphereCDC目标端支持数据库 消息队列 以及ETL解决方案 例如InfoSphereDataStage 等 从系统性能角度 通过读取数据库的日志来获取变化的数据 InfoSphereCDC对源数据库造成的影响极低 从系统资源角度 通过仅发送已更改的数据 InfoSphereCDC还可以减少处理开销和网络流量 从用户体验角度 InfoSphereCDC提供一个Eclipse风格的管理控制台 方便用户轻松创建 配置 监控与管理各种数据复制任务 总体而言 InfoSphereCDC主要支持三种数据复制模式 分别为 Refresh Netchange 或称为ScheduledEnd Continuousmirroring DB2数据库常见方案 InfoSphereCDC 表1 三种InfoSphereCDC数据复制模式 DB2数据库常见方案 InfoSphereCDC InfoSphereCDC体系结构图 DB2数据库常见方案 InfoSphereCDC 下面描述了InfoSphereCDC体系结构的关键组件 AccessServer 控制所有以非命令行方式对复制环境进行的访问 当您登录到ManagementConsole时 您就是在连接到AccessServer 可以在客户机工作站上关闭AccessServer 而不会影响源服务器与目标服务器之间活动的数据复制活动 命令行界面 允许您独立于ManagementConsole来管理数据存储器和用户帐户 以及执行管理脚本编制 管理API 作为基于Java的可选编程接口运行 您可以使用此API对操作配置或交互进行脚本编制 应用代理程序 目标上的代理程序 用于处理源所发送的更改 通信层 TCP IP 作为源与目标之间的专用网络连接 DB2数据库常见方案 InfoSphereCDC 下面描述了InfoSphereCDC体系结构的关键组件 源和目标数据存储器 表示数据复制所需的数据文件和InfoSphereCDC实例 每个数据存储器都表示您要连接至的数据库 并且充当表的容器 使其可供复制的表包含在数据存储器中 ManagementConsole 允许您配置 监视和管理各种服务器上的复制 指定复制参数以及从客户机工作站启动刷新和镜像操作 另外 ManagementConsole还允许您监视复制操作 等待时间 事件消息以及源或目标数据存储器所支持的其他统计信息 ManagementConsole中的监控器旨在用于需要持续分析数据移动的时间紧急的工作环境 在设置复制之后 您可以在客户机工作站上关闭ManagementConsole 而不会影响源服务器与目标服务器之间活动的数据复制活动 元数据 表示关于相关表 映射 预订 通知 事件和您设置的数据复制实例的其他细目的信息 DB2数据库常见方案 InfoSphereCDC 下面描述了InfoSphereCDC体系结构的关键组件 镜像 将更改复制到目标表或者积累源表更改并在以后将其复制到目标表 如果您在环境中实现了双向复制 那么可以在源表与目标表之间来回进行镜像 刷新 执行初始同步 以便将表从源数据库同步到目标 这称为刷新阅读器复制引擎 用于发送和接收数据 用于发送复制的数据的进程是源捕获引擎 而用于接收复制的数据的进程是目标引擎 InfoSphereCDC实例可以同时作为源捕获引擎和目标引擎运行 单一提取 仅用于源的日志阅读器和日志解析器组件 它将检查并分析所选数据存储器中的所有预订的源数据库日志 DB2数据库常见方案 InfoSphereCDC 下面描述了InfoSphereCDC体系结构的关键组件 源变换引擎 处理行过滤 关键列 列过滤 编码转换和其他数据以传播到目标数据存储器引擎 源数据库日志 由源数据库维护以用于其自身的恢复 InfoSphereCDC日志阅读器将在镜像过程中检查这些日志 并滤出复制作用域外的表目标变换引擎 处理目标存储器引擎上的数据和值转换 编码转换 用户出口 冲突检测和其他数据共有两类仅用于目标的非数据库复制目的地 JMS消息 作为创建为XML文档的行级别操作的JMS消息目的地 队列或主题 InfoSphereDataStage 处理InfoSphereCDC所传送的可以由InfoSphereDataStage作业使用的更改 DB2数据库常见方案 InfoSphereCDC 下面描述了InfoSphereCDC体系结构的关键组件 源变换引擎 处理行过滤 关键列 列过滤 编码转换和其他数据以传播到目标数据存储器引擎 源数据库日志 由源数据库维护以用于其自身的恢复 InfoSphereCDC日志阅读器将在镜像过程中检查这些日志 并滤出复制作用域外的表目标变换引擎 处理目标存储器引擎上的数据和值转换 编码转换 用户出口 冲突检测和其他数据共有两类仅用于目标的非数据库复制目的地 JMS消息 作为创建为XML文档的行级别操作的JMS消息目的地 队列或主题 InfoSphereDataStage 处理InfoSphereCDC所传送的可以由InfoSphereDataStage作业使用的更改 DB2数据库常见方案 InfoSphereCDC DB2数据库常见方案 InfoSphereCDC 主要功能特点 DB2数据库常见方案 InfoSphereCDC Log BasedChangeDataCapture DB2数据库常见方案 InfoSphereCDC ReplicationModes DB2数据库常见方案 InfoSphereCDC 异构平台支持 DB2数据库常见方案 InfoSphereCDC 架构 数据源 DB2数据库常见方案 InfoSphereCDC 架构 目标端 DB2数据库常见方案 InfoSphereCDC 架构 目标端 DB2数据库常见方案 InfoSphereCDC 架构 目标端 DB2数据库常见方案 InfoSphereCDC 与HADR的区别HADR和CDC 最大的区别是HADR必须是同构的 CDC可以使异构的 HADR做灾备基本是冷备 备机可读 CDC可做到实时同步 两端都可读写 HADR有握手机制 对主机由性能影响 CDC无影响 简明说HADR是数据库的一个特性 CDC是一个数据库同步复制软件 还有就是HADR主备关系是单向的 可以一主多备 CDC可以做双向复制 CDC可以做数据集中 分发等 如分局数据向总局汇总 或者总局想分局分发数据等场景 DB2数据库常见方案 InfoSphereCDC 特点 DB2数据库常见方案 InfoSphereCDC IBMCDCvsORACLEGoldenGate Sybase数据库体系结构 Sybase公司成立于1984年 公司名称 Sybase 取自system和database相结合的含义 Sybase公司的第一个关系型数据库产品是1987年5月推出的SybaseSQLServer1 0 Sybase首先提出了Client Server数据库体系结构的思想 并率先在自己的SybaseSQLServer中实现 Sybase数据库体系结构 ASE的产品构成 ASE称为Sybase适应性服务器 是Sybase提供的主要数据库产品 其产品组件可分为服务器端组件 客户端组件 1 ASE服务器端组件a SQLServer ASE数据库服务器 用于数据库SQL服务的高性能RDBMS软件系统b BackupServer ASE备份服务器 是与SQLServer并发运行的服务器应用软件 用来进行数据库备份转储和备份的再装入操作 一般而言 在运行SQLServer的服务器上一般都要运行BackupServerc BackupServer ASE监控服务器 可用于捕获和显示ASESQLServer性能数据 为ASE的性能调整服务 MonitorServer会从SQLServer的共享内存中捕获性能数据 并以图表的方式进行展现 一般而言 运行SQLServer的服务器上一般都要安装MonitorServer 但是未必运行该服务器d 组件集成服务 ComponentIntegrationServices CIS CIS用于扩展ASE到其他异构数据库的互操作性 允许通过ASE实现到其他数据库的异构访问 进而把数据一致性地展示给客户应用 使各种数据源实现透明访问 通常讲 CIS是一种异构数据库互连的网关 Sybase数据库体系结构 ASE的产品构成 1 ASE服务器端组件e 配置工具 包括服务器配置工具 目录服务配置工具等 例如ServerConfig UNIX上的asecfg工具 工具和SybaseCentral管理工具 通过这些工具 ASE用户即可很容易地对ASE进行配置和管理 2 ASE客户端组件SybaseASE的客户端程序一般称为OpenClient OpenClient包含客户应用与ASE的接口API 一般而言 客户应用程序都需要安装OpenClient的库函数来与ASE通信 OpenClient主要包括了如下的若干库 CS Library CT Library DB Library和Net Library ASE在客户端主要有如下的关键组件 以SybaseASEClientForWindows32Bit为例 a Connectivityb LanguageModulesc jConnectforJDBCd Sharede ASEAdministrationTools Sybase数据库体系结构 ASE的产品构成 2 ASE客户端组件SybaseASE的客户端管理程序一般有四个 SybaseCentral 是用来管理SybaseASE数据库的图形化应用 该工具运行在桌面环境下 Windows或UNIXCDE环境 用来简化数据库管理 isql 传统的Sybase交互查询处理器 它允许把命令发送给RDBMS 并接收ASE返回结果 dsedit 用于设定ASE客户端配置文件 测试并实现ASE客户端到服务器的连接 InteractiveSQL SQLAdvantage 用于执行SQL T SQL的图形界面工具 Sybase数据库体系结构 ASE的产品构成 3 ASEWorkspaceSybaseWorkSpace是Sybase公司提供的一个工具包产品 是一个集设计和开发于一身的平台工具 该产品组件基于Eclipse框架 使得广大熟悉Eclipse框架的数据库管理者 程序员可以很快地接手WorkSpace WorkSpace产品提供了如下的管理和开发要点 针对Sybase系列服务器 ASE ASE EAS 的单一开发环境 其开发环境可定制 这对提高生产率大有益处 Sybase数据库体系结构 ASE的内部结构 1 ASE内核组成SybaseASE数据库服务器产品主要由ASE内核 语法分析器 优化器和编译器模块构成 其中 内核是最重要的模块部分 Sybase数据库体系结构 ASE的内部结构 1 ASE内核组成ASE内核管理着全局资源 语法分析器 优化器 编译器 缓冲区 磁盘高速缓冲 事务和锁等 这些对于ASE系统的所有用户都是透明的 其中的优化器 语法分析器和编译器这三部分用来处理数据库接收到的SQL请求 其工作过程如图 Sybase数据库体系结构 ASE的内部结构 2 ASE进程模型ASE数据库系统与其他数据库 如Oracle 在进程结构上略显不同 ASE采用了单进程多线索结构 也就是说 不管有多少个用户连接ASE 对于操作系统来说 ASE仅是一个运行于CPU的进程 因此 ASE可以管理大量用户的载荷 而不给操作系统带来过大的负担 下面的命令显示了运行在UNIX上Oracle10g的进程结构 Sybase数据库体系结构 ASE的内部结构 2 ASE进程模型因此 站在操作系统的角度 ASE的服务进程与其他操作系统进程共享CPU时间片 如图1 14所示的操作系统执行队列中分别运行着若干进程 PIDn 其中只能有某个进程获得CPU执行时间片处于运行状态 如PID3进程 其他进程则处于排队等待CPU时间片的位置 在所有这些进程中 可能就有ASE进程 如PID4进程 这个所谓的ASE进程 PID4 也称为ASE引擎 ASE引擎可以不仅是一个 对于多CPU的SMP类型服务器 ASE可以支持若干引擎同时提供服务 Sybase数据库体系结构 ASE的内部结构 2 ASE进程模型在UNIX中 这种线程关系更加容易获得 在下面基于Linux RHEL5 3 环境的示例中 我们查看了ASE服务器的线程结构 可以看到进程树结构如下所示 PPID1 PID5603 启动ASE服务器PPID5603 PID5604 启动ASE引擎PID5604 LWP 5605 5610 LWP 轻量级的进程 即线程 Sybase数据库体系结构 ASE的内部结构 2 ASE进程模型ASE启动后 操作系统与ASE之间是纯粹的 OS 进程 关系 存在有限的交互 但从用户角度来看 则根本不存在这样的交互 ASE对用户来说是透明的 ASE服务器可以接受成百上千个用户连接 如isql客户端 C CT Lib客户端程序 Java组件等 对于这些应用产生的任何一个连接来说 ASE服务器结构中有专门的一个堆栈结构 来追踪每个线程的状态 并用自旋锁 spinlock 一种系统资源锁 类似于Oracle中的栓 来确保众多线程的并发操作 任意一个时刻仅有一个线程使用一个公共资源 例如缓存 线程也可以称为子进程 或 轻量级的进程 因为线程只占用进程中的一部分资源 在UNIX上 其他一些数据库管理系统采用了 用户 进程 的结构 如Oracle数据库系统 采用这种结构 则除了操作系统本身的工作之外 在数据库用户进程之间进行任务切换时 切换过程需要涉及页面交换 上下文切换等 这会部分浪费系统资源 同时 当数据库用户数增长时 系统性能将会明显下降 系统性能极大地依赖于硬件投资 例如 Oracle9i的安装最低系统要求512MB内存 Oracle10g要求1GB内存 Oracle11g则需要2GB内存 Sybase数据库体系结构 ASE的内部结构 3 ASESMP支持ASE支持SMP环境下 不同版本的ASE支持不同的引擎数 从ASE11 9开始 ASE已经支持高达32个引擎 版本越高 支持的引擎数也就越多 同时 ASE仍然保持了多进程多线索结构 在镜像多处理器的环境中 多CPU协同工作 系统处理能力由于CPU的增多而提高 ASE可以因多引擎配置而提高运行效率 在ASE中 所有引擎都是等同的 每个引擎都可以执行完备的数据库功能 各引擎间通过共享内存来进行通信 Sybase数据库体系结构 ASE的内部结构 3 ASESMP支持在如图1 19所示的服务器中共有n个CPU 当前共有若干个操作系统进程 OS任务 运行于其上 这些任务中 一些任务是ASE引擎任务 另外一些则是纯粹的非ASE的操作系统任务 这里要注意 操作系统对于ASE的引擎和其他操作系统任务是同等对待的 所有非ASE进程 ASE进程优先级相同 因此 一般的工程规律是 在运行数据库的服务器上要避免非数据库操作 减少其他OS进程与数据库引擎之间对CPU时间的争用 Sybase数据库体系结构 ASE的内部结构 3 ASESMP支持所以 ASE引擎与CPU关系是进程排队等待CPU 而在ASE引擎内 ASE动态地把客户任务从运行队列中分配给当前空闲的引擎 ASE操作系统进程 其结构如图1 20所示 Sybase数据库体系结构 ASE的内部结构 4 ASE引擎通信在服务器多CPU配置情况下 若干ASE引擎共同工作 通过共享内存方式进行通信 采用自旋锁 spinlock 方式调度系统资源 图1 21显示了在一个SMP系统中 操作系统 CPU 磁盘存储 ASE引擎 ASE内核结构 共享内存资源的关系 以及在共享内存资源中 过程缓存 数据缓存 任务队列 网络和磁盘I O队列的关系 Sybase数据库体系结构 ASE的内部结构 5 ASE内存使用当ASE启动时 ASE可执行应用向操作系统申请所需的静态内存结构 并放置了ASE的内核程序和各种数据库结构 同时 ASE将申请一个 相当大 的内存区域 这部分内存结构分为数据高速缓存和过程高速缓存 站在服务器角度 服务器内存的分配如图1 22所示 以AIXUNIX为例 其他平台完全类似 Sybase数据库体系结构 ASE的内部结构 5 ASE内存使用ASE配置的高速缓存部分 其中有放置SQL T SQL的过程高速缓存 还有对系统整体效率至关重要的 存放数据库数据的数据高速缓存 数据高速缓存对ASE用户是最重要的一块内存结构 用于缓存数据库数据 其作用如图1 23所示 Sybase数据库体系结构 ASE集群系统 Sybase推出的AdaptiveServerEnterprise ASE ClusterEdition就是用来提供不间断数据库服务能力的数据库产品 该集群版本采用了虚拟化资源管理 VRM 技术 在基于共享存储的服务器集群环境下 可以部署这种高可用的数据库应用系统 其结构如图1 24所示 Sybase数据库体系结构 ASE集群系统 在ASEClusterEdition环境下 我们可以建立多节点的网格环境 如果某个节点出现问题 则出现问题的节点上所承担的用户访问会自动迁移到集群中的其他节点上 这就给我们提供了两种操作可能 人为的宕机实现 ASEClusterEdition允许节点中的一个宕机 而不会影响到整个应用系统的运行 该功能将宕机节点的所有用户连接转移到联机节点 使数据库系统提供了不间断运行 失败下的应用转移 这是ASEClusterEdition的特定功能之一 在节点发生失败后 客户应用被迁移到集群剩余可用节点 用户实现了无缝切换 MySQL数据库体系结构 介绍 定义 MySQL是一款优秀的开源小型关系型数据库系统历史 1979年 始于一款报表工具 数据引擎 1996年 发布MySQL1 0版本 2000年 成立MySQLAB公司 2008年 Sun以10亿美元收购了MySQLAB公司 2009年 Oracle以76亿美元收购实例Sun公司 特点 从DB产品对比角度 1 开源 基于通用公共许可证协议 GPL 可以免费使用修改 2 引擎 采用开放式存储引擎架构 有多种免费或付费引擎可选择 3 高可用度 通过优秀的架构设计及相关手段实现企业高可用 高扩展性 4 免费 有效降低企业投资运营成本 5 趋