重庆的公需科目在哪个网站做网站建设与设计教程

当前位置： 首页 > news >正文

重庆的公需科目在哪个网站做,网站建设与设计教程,icp网站备案号查询,多说评论插件对网站优化一 . Oracle RAC 的发展历程

1. Oracle Parallel Server (OPS) 早期阶段#xff1a;Oracle 6 和 7 Oracle Parallel Server#xff08;OPS#xff09;是 Oracle RAC 的前身。 通过多个实例并行访问同一个数据库来提高性能。 共享磁盘架构#xff0c;利用分布式锁管理Oracle 6 和 7 Oracle Parallel ServerOPS是 Oracle RAC 的前身。 通过多个实例并行访问同一个数据库来提高性能。 共享磁盘架构利用分布式锁管理DLM来管理并发访问。 OPS 存在复杂的锁定和同步问题限制了其广泛应用。
   
2. Oracle 8i 和 9i Oracle 8i 引入了对集群数据库的基本支持但 OPS 的并行处理和一致性问题仍然存在。 Oracle 9i (2001) 正式引入 Oracle RAC取代了 OPS。 改进的全局缓存服务GCS和全局锁管理GLM解决了 OPS 的一致性问题。 高可用性和故障转移功能得到显著增强。 通过 Cache Fusion 技术实现节点之间的数据块传输提高了性能和可扩展性。
   
3. Oracle 10g Oracle 10g Release 1 (2003) 引入 Automatic Storage ManagementASM简化存储管理。 改进的集群管理功能包括 Oracle Clusterware。 提供更好的负载均衡和故障检测机制。 Oracle 10g Release 2 增强了 RAC 的稳定性和性能。 引入更高级的负载均衡算法。
   
4. Oracle 11g Oracle 11g Release 1 (2007) 加强了自动化管理功能包括自动内存管理和自动 SQL 调优。 改进了高可用性功能如 Data Guard 与 RAC 的集成。 Oracle 11g Release 2 引入 Oracle Grid Infrastructure整合了 Clusterware 和 ASM。 改进的 Rolling Upgrade 功能减少升级过程中的停机时间。 增强了对虚拟化和云环境的支持。
   
5. Oracle 12c Oracle 12c Release 1 (2013) 引入多租户架构Multitenant Architecture支持容器数据库CDB和可插拔数据库PDB。 改进了集群管理和自动化功能简化了部署和管理。 增强了对云计算和大数据环境的支持。 Oracle 12c Release 2 (2016) 提供更好的性能和可扩展性。 引入新的存储选项和改进的备份恢复功能。
   
6. Oracle 18c 和 19c Oracle 18c (2018) 强调自动化和智能化管理进一步简化数据库管理任务。 引入更多的云服务集成功能。 Oracle 19c (2019) 提供长期支持Long Term Support强调稳定性和性能优化。 增强的自动化诊断和修复功能。
   
7. Oracle 21c 和 23c Oracle 21c (2021) 支持容器数据库CDB架构。 提供更多的自动化管理和 AI 驱动的功能。 增强对混合云和多云环境的支持。
   Oracle RAC 从9i正式引入至今已经发展了20多年如果说是关系型数据库中最成功最稳定的高可用架构应该没有异议不过从11g之后Oracle RAC就没有太多革命性的创新所以基本的理论概念基本没有变化下面简单一下 Oracle Rac的一些基本概念知识基于ORACLE 10G不过基本没差别 二.RAC相关理论知识 2.1 并发控制 在 集群环境中 关键数据通常是共享存放的比如放在共享磁盘上。而各个节点的对数据有相同的访问权限 这时就必须有某种机制能够控制节点对数据的访 问。Oracle RAC是利用DLM(Distribute Lock Management) 机制来进行多个实例间的并发控制。 2.2 健忘症(Amnesia) 集群环境配置文件不是集中存放的而是每个节点都有一个本地副本在集群正常运行时用户可以在任何节点更改集群的配置并且这种更改会自动同步到其他节点。 有一种特殊情况节点A 正常关闭 在节点B上修改配置 关闭节点B启动节点A。这种情况下修改的配置文件是丢失的 就是所谓的健忘症。 2.3 脑裂(Split Brain) 在 集群中节点间通过某种机制(心跳)了解彼此的健康状态以确保各节点协调工作。假设只有心跳出现问题 各个节点还在正常运行 这时每个节点 都认为其他的节点宕机了 自己是整个集群环境中的唯一建在者自己应该获得整个集群的控制权。在集群环境中存储设备都是共享的 这就意味 着数据灾难 这种情况就是脑裂 解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下 集 群中各个节点需要心跳机制来通报彼此的健康状态假设每收到一个节点的通报代表一票。对于三个节点的集群正常运行时每个节点都会有3票。当节点A心跳出现故障但节点A还在运行这时整个集群就会分裂成2个小的partition。节点A是一个剩下的2个是一个。这是必须剔除一个 partition才能保障集群的健康运行。 对于有3个节点的集群 A 心跳出现问题后 B 和 C 是一个partion有2票 A只有1票。按照投票算法 B 和C 组成的集群获得控制权 A 被剔除。 如 果只有2个节点投票算法就失效了。因为每个节点上都只有1票。这时就需要引入第三个设 备Quorum Device. Quorum Device 通常采用是共享磁盘这个磁盘也叫作Quorum disk。这个 Quorum Disk 也代表一票。当2个节点的心跳出现问题时 2个节点同时去争取Quorum Disk 这一票 最早到达的请求被最先满 足。故最先获得Quorum Disk的节点就获得2票。另一个节点就会被剔除。 2.4 IO 隔离(Fencing) 当集群系统出现脑裂问题的时候我们可以通过投票算法来解决谁获得集群控制权的问题。但是这样是不够的我们还必须保证被赶出去的节点不能操作共享数据。 这就是IO Fencing 要解决的问题。 IO Fencing实现有硬件和软件2种方式 软 件方式对于支持SCSI Reserve/Release 命令的存储设备 可以用SG命令来实现。正常的节点使用SCSI Reserve命令 锁住存储设备 故障节点发现存储设备被锁住后就知道自己被赶出了集群也就是说自己出现了异常情况 就要自己进行重启以恢复到正常状态。这个 机制也叫做 Sicide(自杀). Sun 和Veritas 使用的就是这种机制。 硬 件方式STONITH(Shoot The Other Node in the Head) 这种方式直接操作电源开关当一个节点发生故障时另 一个节点如果能侦测到就会通过串口发出命令控制故障节点的电源开关通过暂时断电再上电的方式使故障节点被重启动 这种方式需要硬件支持。 三 RAC 集群 3.1 Clusterware 在单机环境下Oracle是运行在OS Kernel 之上的。OS Kernel负责管理硬件设备并提供硬件访问接口。Oracle 不会直接操作硬件而是由OS Kernel代替它来完成对硬件的调用请求。 在 集群环境下 存储设备是共享的。OS Kernel 的设计都是针对单机的只能控制单机上多个进程间的访问。如果还依赖OS Kernel的服务 就无法保证多个主机间的协调工作。这时就需要引入额外的控制机制在RAC中这个机制就是位于Oracle 和 OS Kernel 之间的 Clusterware它会在OS Kernel之前截获请求然后和其他结点上的Clusterware协商最终完成上层的请求。 在 Oracle10G之前RAC 所需要的集群件依赖于硬件厂商比如SUN,HP,Veritas. 从Oracle 10.1版本 中Oracle 推出了自己的集群产品. Cluster Ready Service(CRS),从此RAC 不再依赖于任何厂商的集群软件。在 Oracle 10.2版本中这个产品改名为Oracle Clusterware。 所以我们可以看出 在整个RAC 集群中实际上有2个集群环境的存在一个是由Clusterware 软件组成的集群另一个是由Database 组成的集群。 3.2 Clusterware 组成 Oracle Cluster 是一个单独的安装包安装后在每个节点上的Oracle Clusterware 会自动启动。 Oracle Clusterware的运行环境由2个磁盘文件(OCR,Voting Disk)若干进程和网络元素组成。 3.2.1 磁盘文件: Clusterware 在 运行期间需要两个文件OCR和Voting Disk. 这2个文件必须存放在共享存储上。 OCR 用于解决健忘问题Voting Disk 用于 解决脑裂问题。 Oracle 建议使用裸设备来存放这2个文件每个文件创建一个裸设备每个裸设备分配100M左右的空间就够了。 3.2.1.1 OCR 健忘问题是由于每个节点都有配置信息的拷贝修改节点的配置信息不同步引起的。 Oracle 采用的解决方法就是把这个配置文件放在共享的存储上 这个文件就是OCR Disk。 OCR 中 保存整个集群的配置信息配置信息以Key-Value 的形式保存其中。在Oracle10g以前 这个文件叫作 Server Manageability Repository(SRVM). 在Oracle10g 这部分内容被重新设计并重名为OCR.在 Oracle Clusterware 安装的过程中 安装程序会提示用户指定OCR位置。并且用户指定的这个位置会被记录在/etc/oracle /ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)文件中。而在 Oracle 9i RAC中对等的是srvConfig.Loc文件。 Oracle Clusterware在启动时会根据这里面的内容从指定位置 读入OCR 内容。 1). OCR key 整个OCR 的信息是树形结构有3个大分支。分别是SYSTEM,DATABASE 和CRS。每个分支下面又有许多小分支。这些记录的信息只能由root用户修改。 2)OCR process Oracle Clusterware 在OCR中存放集群配置信息故OCR 的内容非常的重要所有对OCR的操作必须确保OCR 内容完整性所以在ORACLE Clusterware运行过程中并不是所有结点都能操作OCR Disk. 在 每个节点的内存中都有一份OCR内容的拷贝这份拷贝叫做OCR Cache。每个结点都有一个OCR Process 来读写OCR Cache但 只有一个节点的OCR process能读写OCR Disk中的内容这个节点叫作OCR Master结点。这个节点的OCR process 负 责更新本地和其他节点的OCR Cache内容。 所有需要OCR内容的其他进程比如OCSSD,EVM等都叫作Client Process 这些进程不会直接访问OCR Cache而是OCR Process发送请求借助OCR Process获得内容如果想要修改OCR 内容也要由该节点的OCR Process像 Master node 的OCR process提交申请由Master OCR Process完成物理读写并同步所有节点OCR Cache 中的内容。 3.2.1.2   Voting Disk Voting Disk 这 个文件主要用于记录节点成员状态在出现脑裂时决定哪个Partion获得控制权其他的Partion必须从集群中剔除。在安装 Clusterware时也会提示指定这个位置。安装完成后可以通过如下命令来查看Voting Disk位置。 \(crsctl query css votedisk## STATE File Universal Id File Name Disk group-- ----- ----------------- --------- --------- 1. ONLINE ac0d65877b454fxxxxxxcx1c936ef316 (/dev/mapper/crs1) [CRS] 2. ONLINE   37e617cd5c254f5xxxxxxcff5b2c381b (/dev/mapper/crs2) [CRS] 3. ONLINE 5140d0509b764fxxxxxxc37ea369e6b7 (/dev/mapper/crs3) [CRS]Located 3 voting disk(s). 3.2.2 Clusterware 后台进程 Clusterware 由 若干进程组成其中最重要的3个是CRSD,CSSD,EVMD.在安装clusterware的最后阶段会要求在每个节点执行root.sh 脚 本 这个脚本会在/etc/inittab 文件的最后把这3个进程加入启动项这样以后每次系统启动时Clusterware 也会自动启动其中 EVMD和CRSD 两个进程如果出现异常则系统会自动重启这两个进程如果是CSSD 进程异常系统会立即重启。 1). OCSSD OCSSD 这 个进程是Clusterware最关键的进程如果这个进程出现异常会导致系统重启这个进程提供 CSS(Cluster Synchronization Service)服务。CSS 服务通过多种心跳机制实时监控集群状态提供脑裂保护等基础 集群服务功能。 CSS 服务有2种心跳机制一种是通过私有网络的Network Heartbeat另一种是通过Voting Disk的Disk Heartbeat. 这 2种心跳都有最大延时对于Disk Heartbeat 这个延时叫作IOT (I/O Timeout);对于 Network Heartbeat, 这个延时叫MC(Misscount)。这2个参数都以秒为单位缺省时IOT大于MC在默认情况下这2个 参数是Oracle 自动判定的并且不建议调整。可以通过如下命令来查看参数值 crsctl get css disktimeoutCRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services.crsctl get css misscountCRS-4678: Successful get misscount 30 for Cluster Synchronization Services. 注除了Clusterware 需要这个进程在单节点环境中如果使用了ASM也需要这个进程这个进程用于支持ASM Instance 和 RDBMS Instance之间的通信。如果在使用了ASM的节点上安装RAC会遇到一个问题RAC节点要求只有一个OCSSD进程并且应该是 运行\)CRS_HOME目录下的这时就需要先停止ASM并通过\(ORACLE_HOME/bin/localcfig.Sh delete 删除之前 的inittab 条目。之前安装ASM时也使用这个脚本来启动OCSSD \)ORACLE_HOME/bin /localconfig.Sh add. 2). CRSD CRSD是实现高可用性(HA)的主要进程它提供的服务叫做CRS(Cluster Ready Service) 服务。 Oracle Clusterware是位于集群层的组件它要为应用层资源(CRS Resource) 提供高可用所以Oracle Clusterware 必须监控这些资源并在这些资源运行异常时进行干预包括关闭重启进程或者转移服务。CRSD进程提供的就是这些服务。 所有需要 高可用性 的组件都会在安装配置的时候以CRS Resource的形式登记到OCR中而CRSD进程就是根据OCR中的内容决定监控哪些进程如何监控出现问题时又如何解决。也就是说CRSD 进程负责监控CRS Resource 的运行状态并要启动停止监控Failover这些资源。默认情况下CRS 会自动尝试重启资源5次如果还是失败则放弃尝试。 CRS Resource 包括GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance 和 Service. 这些资源被分成2类 GSDONS,VIP 和 Listener 属于Noteapps类 DatabaseInstance 和Service 属于 Database-Related Resource 类。 我 们可以这样理解 Nodeapps 就是说每个节点只需要一个就够了比如每个节点只有一个Listener而Database- Related Resource 就是说这些资源和数据库有关不受节点的限制比如一个节点可以有多个实例每个实例可以有多个Service。 GSDONS,VIP 这3个服务是在安装Clusterware的最后执行VIPCA 时创建并登记到OCR中的。而Database Listener Instance 和Service 是在各自的配置过程中自动或者手动登记到OCR中的。 3). EVMD EVMD 这 个进程负责发布CRS 产生的各种事件(Event). 这些Event可以通过2种方式发布给客户ONS和 Callout Script. 用户 可以自定义回调脚本放在特定的目录下这样当有某些事件发生时EVMD会自动扫描该目录并调用用户的脚本这种调用是通过racgevt进程来完成 的。 EVMD 进程除了复杂发布事件之外它还是CRSD 和CSSD 两个进程之间的桥梁。 CRS 和CSS 两个服务之前的通信就是通过EVMD 进程完成的。 4). RACGIMON RACGIMON 这个进程负责检查数据库健康状态负责Service的启动停止故障转移(Failover)。这个进程会建立到数据库的持久连接定期检查SGA中的特定信息该信息由PMON 进程定时更新。 5). OPROCD OPROCD 这 个进程也叫做 Process Monitor Daemon. 如果在非Linux 平台上并且没有使用第三方的集群软件时就会看到这个进程。这 个进程用来检查节点的Processor Hang(CPU 挂起), 如果调度时间超过1.5秒 就会认为CPU 工作异常会重启节点。也就是说 这个进程提供 IO 隔离 的功能。从其在Windows 平台上的服务名 OraFnceService 也可以看出它的功能。而在 Linux 平台上 是利用Hangcheck-timer 模块来实现IO 隔离的。 3.3 VIP 原理和特点 Oracle 的TAF 就是建立在VIP 技术之上的。 IP 和VIP 区别在于 IP 是利用TCP层超时 VIP 利用的是应用层的立即响应。VIP 它是浮动的IP. 当一个节点出现问题时会自动转到另一个节点上。 假设有一个2个节点的RAC正常运行时每个节点上都有一个VIP。 VIP1 和VIP2. 当节点2发生故障比如异常关机。RAC 会做如下操作 1). CRS 在检测到rac2节点异常后会触发Clusterware 重构最后把rac2节点剔除集群由节点1组成新的集群。 2). RAC的Failover 机制会把节点2的VIP转移到节点1上这时节点1的PUBLIC 网卡上就有3个IP 地址 VIP1,VIP2, PUBLIC IP1. 3). 用户对VIP2的连接请求会被IP层路由转到节点1 4). 因为在节点1上有VIP2的地址所有数据包会顺利通过路由层网络层传输层。 5). 但是节点1上只监听VIP1和public IP1的两个IP地址。并没有监听VIP2故应用层没有对应的程序接收这个数据包这个错误立即被捕获。 6). 客户段能够立即接收到这个错误然后客户段会重新发起向VIP1的连接请求。 VIP 特点 1). VIP 是通过VIPCA脚本创建的 2). VIP 作为Nodeapps类型的CRS Resource 注册到OCR中并由CRS 维护状态。 3). VIP 会绑定到节点的public 网卡上故public 网卡有2个地址。 4). 当某个节点发生故障时CRS 会把故障节点的VIP 转移到其他节点上。 5). 每个节点的Listener 会同时监听public 网卡上的 public ip 和VIP 6). 客户端的tnsnames.Ora 一般会配置指向节点的VIP. 3.4 Clusterware 的日志体系 Oracle Clusterware的辅助诊断只能从log 和trace 进行。而且它的日志体系比较复杂。 alert.log: \(ORA_CRS_HOME\log\hostname\alert.Log, 这是首选的查看文件。 Clusterware后台进程日志 crsd.Log: \)ORA_CRS_HOME\log\hostname\crsd\crsd.Log ocssd.Log: \(ORA_CRS_HOME\log\hostname\cssd\ocsd.Log evmd.Log: \)ORA_CRS_HOME\log\hostname\evmd\evmd.Log Nodeapp日志位置 \(ORA_CRS_HOME\log\hostname\racg\ 这里面放的是nodeapp的日志包括ONS和VIP比如ora.Rac1.ons.Log 工具执行日志 \)ORA_CRS_HOME\log\hostname\client\ Clusterware 提供了许多命令行工具 比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 这些工具产生的日志就放在这个目录下 还有\(ORACLE_HOME\log\hostname\client\ 和 \)ORACLE_HOME\log\hostname\racg 也有相关的日志。