精华内容
下载资源
问答
  • 基于私有云的数据库高可用架构实践 ... ...目前,对互联网行业而言,在数据库应用上大规模使用SQL Server的...这样的背景,业内基于MySqL数据库的应用架构非常活跃,提供了多种选择,而基于SQL Server数据库架构

                                      基于私有云的数据库高可用架构实践

    来源:https://comet-project.gitbooks.io


    背景

    目前,对互联网行业而言,在数据库应用上大规模使用SQL Server的并不多见,更多的企业基于LAMP架构来使用MySQL数据库。在这样的背景下,业内基于MySqL数据库的应用架构非常活跃,提供了多种选择,而基于SQL Server数据库的架构,可供参考的案例则极其有限。

    有别于MySQL在数据库架构设计上的多样性和灵活性,基于SQL Server的高可用架构更多的还是基于SAN存储的集群架构。

    同时,在云计算蓬勃发展的今天,各种公有云、私有云及混合云技术在IT基础架构中都得到很好的发展及应用。基于对这种趋势的判断,未来云计算将成为主流。 对于SQL Server数据库的架构而言,如何能够将虚拟化及私有云技术应用到其中是一个可以值得研究的课题。

    基于以上,我们希望设计一套针对SQL Server的高可用架构,能够充分利用私有云的相关技术,同时在存储架构上能够有别于传统的SAN网络。


    方案设计

    对于私有云,我们最先想到的会是开源的OpenStack技术,这估计是目前被应用得最多的开源云计算技术。

    在方案设计之初,我们也尝试利用OpenStack来支持SQL Server数据库,尝试着去搭建能够满足我们需求的架构,但在进一步的了解与测试之后,发现并不合适。虽然在OpenStack上搭建Windows虚拟机是可行的,但考虑到OpenStack对Windows的有限的支持能力,以及数据库应用对于IO的高吞吐要求,我们会担心在性能上并不能满足对搭建SQL Server数据库的实际需要;同时,在其它方面也存在很大的局限性和不确定性。

    最终我们放弃了开源的技术方案,转而寻找微软技术体系下的可替代方案。

    得益于微软对于Windows Server的不断升级与优化,最终借助于Windows Server 2012 R2中的相关技术,我们可以快速搭建一套在Windows平台下的私有云架构,逻辑结构如下:




    整体架构分为四层:


    • 最上层是我们的应用层,利用 Hyper-V技术来实施虚拟化,能够为具体的业务应用提供满足实际需要的计算资源;同时结合群集服务,我们可以实现虚拟机在不同宿主机之间的动态迁移。


    • 第二层为文件系统层,利用SOFS技术来为上层应用提供高可用的共享存储服务。在应用层计算节点与SOFS文件共享服务之间, 将利用SMB3.0协议来提供高效的数据交互服务。在这种架构下,对于Hyper-V虚拟机,其所有文件(包括虚拟机配置,VHD文件,快照)都将存储在SOFS之上。


    • 第三层为存储空间层,利用Windows Server 2012最新的WSS技术,将底层的硬件存储资源通过虚拟化技术整合为可用的逻辑磁盘,提供给上层的SOFS来使用,是一种可靠的存储池资源;


    • 最下层为物理硬件层,提供了实际的物理空间支持,可支持动态扩展。


    核心技术

    在这套架构中,我们将要用到Windows Server 2012中的推出的以下几个非常实用的技术及功能:

    SMB3.0

    Windows标准文件共享协议3.0版本,是SMB协议最大的一次飞跃,可在客户端和服务端之间提供了一种高效的数据交换通道,能够提供与直连存储(DMA)相当的访问性能。

    SMB3.0协议支持以下新的特性,为我们构建高可用的应用架构提供极大的灵活性:


    • 分布式支持:SMB3.0可以将多台服务器组建成为一个集群,使服务端的所有节点统一起来,共同为客户端节点提供文件访问服务。该集群支持横向扩展,可以动态添加或删除节点。


    • 透明故障切换:在集群模式下,SMB3.0提供了故障转移功能,能够在服务端的一个节点出现故障的情况下,自动的将客户端的请求平滑的转移到另一个服务节点之下,实现0的宕机时间,从而保证应用的高可用性。


    • RDMA支持:借助于符合要求的硬件,SMB3.0协议提供了对远程直接内存访问(RDMA)网络适配器的支持,可以让存储的性能与光纤通道相匹配,从而绕过系统的内核直接在内存中进行读写操作,达到与直连存储一样的远程存储速度。该功能使SMB共享能够获得更高的带宽和更低的延迟,从而有效减轻CPU处理 I/O的负载压力,非常适合Hyper-V或SQL Server等读写密集型的应用。


    • SMB多通道:多通道技术能够充分利用客户端及服务端的多个网卡,提供多路径支持,在一个网卡出现故障时快速的进行自动切换,从而有效避免网络故障对整体稳定性的影响。另外在多网络可用的情况,多通道还可以提供网络带宽聚合功能,充分利用硬件资源来提高吞吐量,从而提高应用整体的性能。


    WSS

    Windows Server 2012下的WSS(Windows Storage Spaces)服务提供了一种针对存储的虚拟化技术,可以对所有由SAS和SATA连接的磁盘进行整合,统一到一个称为存储池的管理单元之中进行分配,通过划分虚拟磁盘来对外提供空间服务,能有效的简化我们对于存储的管理。

    WSS具备以下新的特性:


    • 高可用性支持


    对于从存储池中创建的任何虚拟磁盘,WSS可以提供以下三种类型的高可用性:


    • 单镜像

    • 为了额外保护的2路或3路镜像

    • 奇偶校验 (RAID 5)


    在实际项目中可以根据需要,灵活的来进行配置。


    • 分层管理


    WSS引入了一个全新的,基于策略的自动分层机制,能够有效的利用好不同的存储介质。 比如可以基于使用频率来有效的区分冷、热数据,从而为其分配不同的存储介质。对于经常变更的热数据,将被存储在访问速度更快、价格也相对更高的驱动硬盘之上;而对于不经常变更的冷数据,则会被存储在速度相对较慢,较为廉价的磁盘之上。同时,当冷、热数据的状态发生变化时,WSS可依照预定义的策略来执行数据的自动迁移。


    • 数据去重


    WSS支持数据去重功能,能有效的去掉重复数据的冗余,从而提高存储设备的使用效率,降低总体的成本开销,提高设备的使用周期。

    SOFS

    SOFS(Scale-Out File Server)扩展文件服务是微软在Windows Server 2012中推出的一项全新的技术,可以为前端应用(如Hyper-V或SQL Server)提供一种高可用的、可扩展的共享存储服务。其在性能及可靠性上能够提供与传统SAN存储相当的能力。

    为了保证高可用性,SOFS需以集群的AA模式来部署,群集中所有的节点都处于在线状态,当有节点出现故障时,来自客户端的访问会话会自动被重定向到其它可用的节点之上。

    另外,SOFS服务最终交付给客户端会是一个UNC的网络路径,当不同的客户端访问SOFS时,会根据访问的共享对象,进行负载均衡。可能这一次SMB客户端访问SOFS 的UNC路径是节点1提供的连接,而下一次SMB客户端访问就有可能是节点2来提供连接。

    以上几个技术是我们整个架构的核心。


    私有云实践

    利用以上架构及其所涉及到的相关技术,同时配合一定的硬件资源投入,我们就可以打造一个高可用的私有云架构。

    我们能够做到在整体上不存在单点,同时在各级链路均有冗余。

    对于应用层的计算节点,我们利用Windows Cluster来保证Hyper-V虚拟机的高可用。

    对于文件层的服务节点,我们利用SOFS集群的AA模式及SMB3.0的透明故障转移来保证文件访问的高可用。

    对于存储节点,我们利用虚拟磁盘的奇偶校验 (RAID 5)模式来保证数据的完整性。

    在网络层面,我们利用硬件来保证足够的冗余。

    最终的我们的应用架构如下(部分):




    物理空间我们以JBOD的方式来提供,在实际应用中使用了4个MD1200的盘柜,组成了两个逻辑设备组,每个逻辑设备组都会配置一个使用快盘的MD1200和一个使用慢盘的MD1200(用于支持冷热数据的分层管理)。而JBOD设备则通过HBA卡来直连文件服务器。

    文件服务器利用两台RD720来搭建,以此组成SOFS的双A节点,配置了SSD硬盘,支持CSV Cache功能,为应用提供了更高的性能。

    应用层的宿主机和文件服务器之间使用两台万兆光纤交换机来连接,既保证了网络层面的冗余,同时也能够最大的发挥SMB3.0协议的传输性能。

    应用层投入8台服务器作为宿主机,支持Hyper-V的虚拟化。

    搭建完成之后,我们充分模拟了各种可能出现的故障,经过一系列的测试,在可用性层面,最终的结果令我们非常满意。

    另外,对于整体的性能,由于借助了SMB3.0的多通道及RDMA技术,以及利用到了SSD支持的CSV Cache技术,经测试,对于随机读写可取得一个比较好的IOPS值,完全能够支持SQL Server对于高IO的要求。

    扩展性层面,应用层可以通过扩充计算节点来支持更多的Hyper-V虚拟机,而存储空间则可以通过加入更多的SOFS节点来支持横向扩展。

    在建设成本方面,初期会有一个中等规模的投入,但远期扩展成本会变的非常低廉,相较于SAN架构,性价比非常高且可控性更强。

    整套应用将基于SCOM(System Center Operations Manager)来进行管理,支持高效的配置与调整,易用性较好。


    SQL Server的支持

    我们已经完成了一个高可用的私有云平台的搭建,但我们最终的目标是支持SQL Server数据库的高可用。

    得益于SOFS提供的高性能,我们在私有云架构的基础之上做出一定的调整,就能很快的支持SQL Server数据库的应用。

    具体做法:将SQL Server数据库的计算资源运行在Hyper-V的虚拟机之上,而数据库的文件资源则通过SOFS来调用底层的虚拟化存储资源。

    最终,Hyper-V虚拟机的高可用性加上SOFS文件系统的高可用性保证了SQL Server数据库整体的高可用性。

    在我们的实际项目中,这种架构支持了20多个SQL Server的数据库,共10多TB的数据量,整体运行平稳。


    展望

    在微软最新的Windows Server 2016中,相关技术又得到了进一步的提升,提供了更加强大的功能,提供了类超融合的技术架构,能够更加高效、快捷的搭建基于Windows的私有云及高可用架构。

    如果你的项目中应用到了Windows的相关技术,不妨尝试尝试。


    版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。


    -END-


    展开全文
  • 数据库三层架构

    千次阅读 2009-05-17 22:43:00
    关于 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。 1、表现层(UI):...

    关于

      三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。
      1、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
      2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
      3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。

    概述

      在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层。
      三层结构原理:
      3个层次中,系统主要功能和业务逻辑都在业务逻辑层进行处理。
      所谓三层体系结构,是在客户端与数据库之间加入了一个“中间层”,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。
      三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。
      表示层
      
     位于最外层(最上层),离用户最近。用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。
      业务逻辑层
      
     业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统 所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中,将整个架构分为三个主要的层:表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans,对业务逻辑层作了更细致地划分,细分为应用层与领域层,通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
      业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启 下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在 分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可 抽取、可替换的“抽屉”式架构。正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是 调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任 务。
      数据层
      
     数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问,可以访问数据库系统、二进制文件、文本文档或是XML文档。
      简单的说法就是实现对数据表的Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。

    优缺点

      优点:
      1、开发人员可以只关注整个结构中的其中某一层;
      2、可以很容易的用新的实现来替换原有层次的实现;
      3、可以降低层与层之间的依赖;
      4、有利于标准化;
      5、利于各层逻辑的复用。
      缺点:
      1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
      2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

    规则

      三层结构的程序不是说把项目分成DAL, BLL, WebUI三个模块就叫三层了, 下面几个问题在你的项目里面:
      1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用, 并且这些语句保证不会修改数据?
      2. 如果把UILayer拿掉, 你的项目还能在Interface/API的层次上提供所有功能吗?
      3. 你的DAL可以移植到其他类似环境的项目吗?
      4. 三个模块, 可以分别运行于不同的服务器吗?
      如果不是所有答案都为YES, 那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则:
      1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程
      2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以面向对象的方式
      3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关
      4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群
      所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了, 完全没必要作的这么复杂. 而多层结构, 是用于解决真正复杂的项目需求的。

    与MVC的区别

      MVC(模型Model-视图View-控制器Controller)是一种设计模式,我们可以用它来创建在域对象和UI表示层对象之间的区分。
      同样是架构级别的,相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。
      在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把 业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model,但是三层架构中Model的概念与 MVC中Model的概念是不一样的,“三层”中典型的Model层是已实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。

    展开全文
  • 全面解析 Oracle Database 20c 数据库技术架构

    千次阅读 多人点赞 2020-11-25 17:52:06
    本文详细介绍了 Oracle Database 20c 数据库的最新技术架构,包括数据库服务器整体架构数据库实例中的内存和进程结构、数据库文件的物理结构。

    大家好,我是只谈技术不剪发的 Tony 老师。本文详细介绍了 Oracle Database 20c 数据库的最新技术架构,包括数据库服务器整体架构、数据库实例中的内存和进程结构、数据库文件的物理结构等。

    如果觉得文章有用,欢迎评论📝、点赞👍、推荐🎁

    1、整体架构

    数据库服务器
    一个 Oracle 数据库服务器(database server)至少包含一个数据库实例(instance )和一个数据库(database)。数据库实例包含了内存和进程。多租户容器数据库由物理文件组成,也就是数据文件。 Oracle 数据库服务器在运行期间还会使用一些其他的操作系统文件。

    单实例数据库由一个数据库实例和一个数据库组成,数据库和实例之间是一对一的关系。同一台服务器上可以运行多个单实例数据库,每个数据库拥有单独的数据库实例,这种方式通常用于运行不同版本的 Oracle 数据库。

    Oracle RAC(Real Application Clusters)数据库由多个位于不同服务器上的实例和一个共享的数据库组成。多个服务器集群构成了单一的服务端,终端用户和应用程序构成了客户端。这种方式可以实现高可用、可扩展性以及高性能。

    监听器(listener)是一个服务器进程,负责接收客户端的连接请求并建立实例连接,然后将连接交给服务器进程(server process)。监听器进程可以在数据库服务器本地或者远程运行,通常在 Oracle RAC 环境中使用远程运行方式。

    2、数据库实例

    数据库实例

    一个数据库实例(database instance)包含了一组后台进程(background processes)和相应的内存结构。主要的内存结构包括系统全局区 SGA(System Global Area)以及程序全局区 PGA(Program Global Area)。后台进程负责对数据文件中的数据进行操作,并且通过内存结构实现这些操作。数据库实例只存在于内存中。

    Oracle 数据库还会创建多个服务器进程(server processes)处理数据库连接,它们代表了客户端程序执行操作。例如,解析和运行 SQL 语句、检索和返回查询结果。这类服务器进程也被称为前台进程(foreground processes)。

    📝更多关于 Oracle 数据库实例的信息可以参考官方文档

    2.1、系统全局区

    系统全局区

    系统全局区(SGA)是一个内存区域,包含了数据库实例相关的数据和控制信息。所有的服务器进程和后台进程共享 SGA。当我们启动一个数据库实例时,系统会显示分配给 SGA 的内存大小。SGA 包含了以下数据结构:

    • 共享池(Shared pool):缓存用户共享的各种结构,例如解析后的 SQL 语句、PL/SQL 代码、系统参数以及数据字典信息。几乎所有的数据库操作都会涉及到共享池,例如执行 SQL 语句时需要访问共享池。
    • 闪回缓冲区(Flashback buffer):SGA 中的一个可选组件。如果启用了闪回数据库(Flashback Database)功能,Oracle 会启动一个称为恢复写入器进程 RVWR(Recovery Writer Process)的后台进程。RVWR 定期将数据库缓冲区高速缓存(Database buffer cache)中被修改的数据块复制到闪回缓冲区,然后将闪回数据库的数据从闪回缓冲区写入闪回数据库日志。
    • 数据库缓冲区高速缓存(Database buffer cache):用于存储从数据文件中读取的数据块拷贝的内存区域。缓冲区(buffer)是缓冲区管理器临时缓存当前或最近使用的数据块的内存地址。连接到数据库实例的所有用户共享缓冲区高速缓存。
    • 数据库智能闪存缓存(Database Smart Flash cache):Solaris 或者 Oracle Linux 操作系统上可选的一个缓冲区高速缓存扩展内存。它为数据块提供了一个 2 级缓存,即可以改进读密集型在线事务处理(OLTP)系统的响应时间,也可以提高数据仓库(DW)环境中的即席查询以及批量数据修改操作的整体吞吐量。数据库智能闪存缓存位于一个或者多个闪存磁盘设备之上,也就是闪存的固态存储设备。数据库智能闪存缓存通常比内存更便宜、同时比磁盘驱动器快一个数量级。
    • 重做日志缓存(Redo log buffer):SGA 中的一个循环缓冲区,用于保存数据库修改操作相关的信息。变更信息存储在重做条目(redo entries)中,重做条目包含了重建(重做)DML、DDL 以及内部变更所需的信息,主要用于数据库的恢复。
    • 大池(Large pool):一个可选内存区域,用于分配比共享池更大的内存。大池可以为共享服务器模式中的用户全局区(User Global Area)和并行执行语句的 Oracle XA 接口(用于分布式数据库事务)消息缓冲、buffers for 恢复管理器(RMAN)的 I/O 从属进程缓冲以及延迟插入提供更大的内存分配。
    • IM 内存区(In-Memory Area):一个可选的内存组件,可以实现表、分区以及其他类型对象在内存中的列式存储。这种存储格式使得扫描、连接以及聚合操作比传统的磁盘格式快很多,可以为 OLTP 以及 DW 场景提供更好的报表和 DML 性能。该特性对于只访问少数列(大量行)的分析型应用尤其有用,因为它们不像 OLTP 应用需要访问许多列(少量行)。
    • 内存优化池(Memoptimize Pool):一个可选的组件,可以为基于键值的查询提供高性能与可扩展性。内存优化池包含两个部分:内存优化缓冲区和哈希索引。通过哈希索引实现的快速查找功能可以执行快速的表(启用了 MEMOPTIMIZE FOR READ)数据块访问,这些数据块持久性固定在缓冲池缓存中,避免了磁盘 I/O。内存优化池中的缓冲和数据库缓冲区缓存是完全独立的内存结构。哈希索引在配置了内存优化行存储功能时创建,由 Oracle 数据库自动进行维护。
    • 共享 I/O 池(Shared I/O pool):用于 SecureFile 大对象(LOB)的大型 I/O 操作。LOB 包含了一组用于存储大量数据的数据类型。SecureFile 是一个 LOB 存储参数,支持数据的去重、加密和压缩。
    • 流池(Streams pool):用于 Oracle Streams、Data Pump 以及 GoldenGate 中的数据捕获和应用进程。流池存储了缓存的队列消息,并且为 Oracle Streams捕获进程和应用进程提供内存。除非进行了特定的配置,流池的初始大小为零,并且会随着 Oracle Streams 的需要动态调整。
    • Java 池(Java pool):用于存储 JVM 中与会话相关的 Java 代码和数据。Java 池中的内存可以有不同的使用方式,取决于 Oracle 数据库的运行模式。
    • 固定 SGA(Fixed SGA):一个内部的管理区域,其中包含了有关数据库和实例状态的基本信息,以及进程之间通信的信息。

    📝关于系统全局区的详细介绍,可以参考官方文档

    2.1.1、共享池

    共享池
    共享池(shared pool)是 SGA 中的一个组件,用于缓存各种程序数据,例如解析后的 SQL、PL/SQL 代码、系统参数以及数据字典信息。几乎所有的数据库操作都会涉及到共享池,例如用户执行 SQL 语句时数据库需要访问共享池。

    共享池可以分为以下几个组成部分:

    • 库缓存(Library cache):用于存储可执行的 SQL 和 PL/SQL 代码。库缓存包含共享 SQL 和 PL/SQL 区以及控制结构,例如锁和库缓存句柄。当用户执行一个 SQL 语句时,数据库尝试重用以前执行过的代码;如果某个解析后的 SQL 语句可以共享,数据库直接执行该代码。这种行为被称为软解析(soft parse)或者库缓存命中(library cache hit)。否则,数据库必须重新构建可执行的代码版本,被称为硬解析(hard parse)或者库缓存未命中(library cache miss)。
    • 保留池(Reserved pool):用于分配连续的大块内存。数据库以块(chunk)为单位分配共享池中的内存。分块技术允许将大对象(超过 5 KB)加载到缓存中,而不需要申请连续的内存区域。这种方式减少了由于碎片而耗尽连续内存的可能性。
    • 数据字典缓存(Data dictionary cache):用于存储关于数据库对象的信息(也就是字典数据)。数据字典缓存也称为行缓存(row cache),因为它以行的形式缓存数据,而不是缓冲区。
    • 服务器结果缓存(Server result cache):用于存储查询结果的内存池。服务器结果缓存包含 SQL 查询结果缓存和 PL / SQL 函数结果缓存,它们使用相同的基础结构。SQL 查询结果缓存存储了查询结果和查询片段,大多数应用程序都可以通过这种缓存提高性能。PL / SQL 函数结果缓存存储了函数的执行结果。 函数结果缓存适用于经常被调用的函数,并且它们的结果依赖于相对静态的数据。
    • 其他组件:包括队列(enqueue),锁存器(latch),信息生命周期管理(ILM)位图表,活动会话历史(ASH)缓冲区和其他的内存结构。队列是一种共享的内存结构(锁),可以实现数据库资源的序列化访问。队列可以与一个会话或者事务相关。例如控制文件事务队列、数据文件队列、实例恢复队列、介质恢复队列、事务恢复队列、作业队列等等。锁存器是低级别的序列化控制机制,用于保护 SGA 中共享数据结构的并发访问。例如行缓存对象锁存器、库缓存 pin 锁存器和日志文件并行写锁存器。

    📝关于共享池的更多信息,可以参考官方文档

    2.1.2、大池

    大池

    大池(large pool)是一个可选的内存区域,可以为以下组件分配大型内存空间:

    • 用户全局区( UGA):为共享服务器和 Oracle XA 接口(分布式事务)分配的会话内存。

    • I/O 缓冲区:I/O 服务器进程、并行查询的消息缓冲区、RMAN 的 I/O 从属进程的缓冲区以及高级队列内存表的存储。

    • 延迟插入池(Deferred Inserts Pool):支持 MEMOPTIMIZE FOR WRITE 表的高频单行数据快速插入。快速插入也称为延迟插入。 数据最初在大池中进行缓冲,然后由空间管理协调器进程(SMCO)和 Wxxx从属进程异步写入磁盘。每个对象每个会话缓冲到达 1MB 或者每 60 秒写入一次。延迟插入池中的任何数据(包括已提交的数据)都不能读取,即使是写入会话也一样,直到 SMCO 完成写入操作。

      延迟插入池在第一次插入内存优化表时进行初始化。如果大池的空间足够,分配 2G 空间;如果空间不够,在内部产生一个 ORA-4031 错误并且自动进行清理。然后使用一半大小重新尝试分配;如果大池的空间仍然不够,继续使用 512M 和 256M 尝试分配;在此之后将会禁用该功能直到实例重新启动。一旦成功初始化延迟插入池,大小保持不变,不能增加也不能减少。

    • 空闲内存

    大池和共享池中的保留池不同,保留池和其他组件使用相同的最近最少使用(LRU)列表进行维护。大池没有 LRU 列表,已分配的内存不会被释放,直到不再使用为止。

    用户的一次请求是一个 API 调用,它是用户 SQL 语句的一部分。在专用服务器模式中,一个服务器进程对应处理一个客户端的请求;每个服务器进程都使用系统资源,包括 CPU 周期和内存。在共享服务器模式中的行为如下:

    1. 客户端将请求发送给数据库实例,请求由调度器进程(dispatcher)接收。
    2. 调度器进程将请求放入大池的请求队列中。
    3. 下一个可用的共享服务器进程将会处理该请求。共享服务器进程检查公共请求队列中是否有新的请求,并且以先进先出的方式接收新请求。一个共享服务器进程接收队列中的一个请求。
    4. 共享服务器进程对数据库进行相应的调用以完成请求。首先,共享服务器进程访问共享池中的库缓存以验证请求的对象;例如检查表是否存在,用户是否具有正确的权限等。接下来,共享服务器进程访问缓冲区高速缓冲获取数据。如果没有找到数据,访问磁盘获取数据。每一次数据库调用可以由不同的共享服务器进程处理。因此解析查询、获取第一行、获取下一行以及关闭查询结果集的请求可能分别由不同的服务器进程执行。正因为如此,用户全局区(UGA)必须是一个共享的内存区域,因为 UGA 包含了每个会话相关的信息。或者反过来说,UGA 包含了每个客户端会话的信息,并且必须对所有共享服务器进程都可用,因为任何共享服务器进程都可以处理任何会话的数据库调用。
    5. 完成请求之后,共享服务器进程将结果放入调用请求的调度器进程的响应队列。每个调度器进程拥有自己的响应队列。
    6. 响应队列将结果发送给调度器进程。
    7. 调度器进程将完整的结果发送给客户端。

    📝关于大池的更多信息,可以参考官方文档

    2.1.3、缓冲区高速缓存

    缓冲区高速缓存

    数据库缓冲区高速缓存(database buffer cache),或者简称缓冲区高速缓,是 SGA 中存储数据块拷贝的内存区域。一个缓冲区就是一个数据库块大小的内存块。每个缓冲区包含一个地址,称为数据库缓冲区地址(DBA)。所有连接到数据库实例的用户共享缓冲区高速缓存。缓冲区高速缓存的目标是优化物理 I/O,将经常访问的数据块保留在缓冲区高速缓存中,并且将不经常访问的数据块写入磁盘。

    用户进程第一次需要特定的数据时,数据库将会在缓冲区高速缓存中查找数据;如果发现缓存中已存在的数据(缓存命中),就可以直接从内存中读取数据;如果进程无法在缓存中找到数据(缓存未命中),它就必须在访问数据之前将数据块从磁盘上的数据文件复制到缓存中的缓冲区中。通过缓存命中访问数据比缓存未命中时更快。

    缓冲区的管理通过一个复杂的算法来实现,该算法结合了最近最少使用(LRU)列表和访问计数。LRU 可以确保最近访问最多的数据库倾向于保留在内存中,从而最大程度地减少磁盘访问。

    数据库缓冲区高速缓存包含了以下组件:

    • 默认池(Default pool):数据块默认的缓存区域。默认块的大小为 8 KB。除非手动配置其他缓冲池,默认情况下只创建默认池 。其他可选池的配置不会影响默认池。
    • 保留池(Keep pool):用于缓存经常访问,但是由于默认池缺少空间导致过期的数据块。保留池的作用是在内存中保留指定的对象,从而避免 I/O 操作。
    • 回收池(Recycle pool):用于不频繁访问的数据块。回收池可防止指定的对象对缓存不必要的占用。
    • 非默认缓冲池(Non-default buffer pools):适用于 2 KB,4 KB,16 KB 和 32 KB 非标准块大小的表空间。每个非默认块大小的表空间都有其自己的缓冲池。这些缓冲池的管理和默认池相同。
    • 数据库智能闪存缓存(Database Smart Flash Cache):可以使用闪存设备来增加缓冲区高速缓存的有效大小,而不是增加更多的内存。 闪存缓存可以将数据库缓存中频繁访问的数据存储到闪存中,避免磁盘读取来提高数据库性能。当数据库请求数据时,系统首先在数据库缓冲区高速缓存中进行查找;如果找不到数据,则在数据库智能闪存缓存中查找;如果还找不到数据,才会访问磁盘。对于 Oracle RAC 环境,要么所有的实例都配置闪存缓存,要么都不配置。
    • 最近最少使用列表(LRU):包含指向脏缓冲区和非脏缓冲区的指针。 LRU 列表有一个热端和一个冷端。冷缓冲区是最近未使用过的缓冲区,热缓冲区经常被访问并且最近被使用过。从概念上讲,只有一个 LRU,但是支持数据并发访问,数据库实际上使用了多个 LRU。
    • 检查点队列
    • 闪存缓冲区(Flash Buffer Area):包含一个 DEFAULT 闪存 LRU 链和一个 KEEP 闪存 LRU 链。如果没有数据库智能闪存缓存,当进程尝试访问某个数据块并且该块在缓冲区缓存中不存在时,将会从磁盘读入数据块到内存(物理读取)。当内存中的缓冲区高速缓存已满时,将会基于最近最少使用(LRU)机制将缓冲区从内存中逐出。如果使用了数据库智能闪存缓存,后台的数据库写进程(DBWn)会在逐出干净缓冲区时将其中的内容写入闪存缓存,同时缓冲区的头部信息会保存在 DEFAULT 闪存 LRU 列表或者 KEEP 闪存 LRU 列表中,具体取决于缓存对象的 FLASH_CACHE 属性。KEEP 闪存 LRU 列表用于将缓冲区头部信息保留在单独的列表中,以防止常规缓冲区的头部信息将其替换。因此,具有 KEEP 属性的对象的闪存缓冲区头部信息可以保留更长时间。如果 FLASH_CACHE 对象属性设置为 NONE,
      系统不会在闪存缓存或内存中保留相应的缓冲区。当再次访问已过期的内存缓冲区时,系统将检查闪存缓存;如果找到了缓冲区,将会从闪存缓存中再次读回,这种方式消耗的时间只占磁盘读取的一小部分。RAC环境中闪存缓冲区的一致性维护方式与缓存融合相同。因为闪存缓存是扩展缓存,而直接路径 I/O 完全绕过了缓冲区缓存,所以该功能不支持直接路径 I/O。注意,系统不会将脏缓冲区放入闪存缓存中,因为写入闪存缓存不会计入检查点,必须将缓冲区读取到内存中才能对它们进行检查点。

    📝关于数据库缓冲区高速缓存的更多信息,可以参考官方文档

    2.1.4、In-Memory 内存区

    In-Memory Area
    In-Memory 内存区是一个可选的 SGA 组件,包含了内存列存储(IM column store),使用列存储格式优化了表和分区的快速扫描。IM 列存储使得数据可以在 SGA 中同时使用传统的行格式(缓冲区高速缓存)和列存储格式进行缓存。数据库自动地将在线事务处理(OLTP)查询(例如主键查找)发送到缓冲区高速缓存,并且将分析和报告查询发送到 IM 列存储。获取数据时,Oracle 数据库也可以为同一个查询从两个内存区域中读取数据。双存储格式体系不会导致内存需求加倍。缓冲区高速缓存经过了优化,运行时比数据库的大小小很多。

    IM 列存储中只应该存储最关键的数据。如果要将对象添加到 IM 列存储中,创建或更改对象时指定 INMEMORY 属性;可以在表空间(对该表空间中所有的新表和视图有效)、表、(子)分区、物化视图或对象中的部分列上指定该属性。

    IM 列存储使用优化的存储单元管理数据和元数据,而不是传统的 Oracle 数据块。内存压缩单元(IMCU)是一个压缩的只读单元,用于存储一个或多个列中的数据。快照元数据单元(SMU)包含了对应 IMCU 的元数据和事务数据。每个 IMCU 存在一个单独的 SMU。

    表达式统计存储(ESS)是一个关于表达式求值的统计信息库,同时存储在 SGA 和磁盘中。如果启用了 IM 列存储,数据库可以利用 ESS 实现 IM 表达式功能。内存表达式单元(IMEU)是一个物化 IM 表达式和用户虚拟列的存储容器。ESS 是一个独立于 IM 列存储的结构,是数据库中的一个永久性组件,无法被禁用。

    从概念上讲,IMEU 是其父级 IMCU 的逻辑扩展。就像 IMCU 可以包含多个列一样,IMEU 可以包含多个虚拟列。每个 IMEU 和一个IMCU 一一对应,并且和相同的行集对应。 IMEU 包含对应 IMCU 中数据的表达式结果。数据库填充 IMCU 的同时也会填充关联的 IMEU。

    一个典型的 IM 表达式包含一列或多列(可能包含常量),并且与表中的行一一对应。例如,一个 EMPLOYEES 表的 IMCU 包含Weekly_salary 列的第 1-1000 行。对于该 IMCU 中存储的行,IMEU 计算自动检测到的 IM 表达式 weekly_salary * 52,并将用户定义的虚拟列 Quarterly_salary 定义为 weekly_salary * 12。 IMCU 中的第三行对应到 IMEU 中的第三行。

    In-Memory 内存区被分为两个池:一个 1MB 的列式数据池,用于存储填充到内存(IMCU 和 IMEU)中的实际列格式数据;以及一个 64K 元数据池,用于存储 IM 列存储中对象的元数据。这两个池的相对大小由内部算法确定;IM 区域中的大部分内存都分配给 1MB 池。IM 区域的大小由初始化参数 INMEMORY_SIZE(默认值为 0)控制,并且最小值必须为 100 MB。从 Oracle Database 12.2 开始,可以通过 ALTER SYSTEM 命令将 INMEMORY_SIZE 参数动态增加到至少 128MB,但是无法动态缩小 In-Memory 内存区的大小。

    IM 表在首次访问表数据或数据库启动时在 IM 列存储中分配 IMCU。通过将磁盘上的格式转换为新的内存中列式格式,可以创建表的内存副本。每次实例重新启动时都会完成转换,因为 IM 列存储的副本只保留在内存中。完成转换之后,表的内存版本逐渐可以用于查询;如果对表进行了部分转换,查询仍然能够使用部分内存版本并且通过磁盘执行其余操作,而不必等待整个表完成转换。

    服务器进程在处理查询和数据操作语言(DML)时会扫描列式数据并更新 SMU 元数据。后台进程负责将磁盘中的行数据填充到 IM 列存储中。In-Memory 协调器进程(IMCO)是执行列数据填充和重新填充的后台进程。空间管理协调器进程(SMCO)和空间管理工作进程(Wnnn)是代表 IMCO 进行实际的数据填充和重新填充的后台进程。DML 块变更将会写入缓冲区高速缓存,然后再写入磁盘。随后,后台进程基于元数据无效状态和查询请求将磁盘中的行数据重新填充到 IM 列存储中。

    可以启用 In-Memory 快速启动功能,使用压缩列格式将 IM 列存储中的列数据写回到数据库中的表空间。该功能使得数据库启动更快。不过,快速启动功能不适用于 IMEU,它们总是从 IMCU 进行动态填充。

    📝关于 Oracle In-Memory 技术的更多信息,可以参考官方文档

    2.2、程序全局区

    程序全局区
    程序全局区(PGA)是一个非共享的内存区域,包含了服务器进程或后台进程专用的数据和控制信息。Oracle 数据库创建服务器进程代表客户端程序执行数据库的操作。在专用服务器环境中,每个服务器进程和后台进程拥有一个 PGA。PGA 由堆栈空间、哈希区、位图合并区和用户全局区(UGA)组成。当服务器进程或后台进程终止时,相关的 PGA 也会被释放。

    • 在共享服务器环境中,多个客户端用户共享服务器进程。UGA 被移动到大池中,PGA 中只包含堆栈空间、哈希区、位图合并区。
    • 在专用服务器会话中,PGA 包含了以下组件:
      • SQL 工作区:用于数据排序的内存区,例如 ORDER BY 和 GROUP BY。
      • 会话内存:用于存储用户会话变量,例如登录信息和数据库会话所需的其他信息。OLAP 池用于管理 OLAP 数据页,相当于数据块。
      • 私有 SQL 区:用于存储已解析的 SQL 语句信息和其他用于数据处理的会话信息。当服务器进程执行 SQL 语句或 PL/SQL 代码时,进程使用私有 SQL 区存储绑定变量值、查询执行的状态信息和查询的工作区。同一会话或不同会话中的多个私有 SQL 区可以指向 SGA 中的同一个执行计划。持久区(persistent area)包含了绑定变量的值,运行区(run-time area)包含了查询执行的状态信息。游标(cursor)是私有 SQL 区中指定区域的名称或句柄,客户端可以将游标看作一个指针,服务器可以将游标看作一个状态。因为游标与私有 SQL 区关系紧密,这两个术语有时可以互换使用。
      • 堆栈空间:用于存储会话变量和数组。
      • 哈希区:用于执行表的哈希连接。
      • 位图合并区:用于合并从多个位图索引扫描中检索到的数据。

    📝关于程序全局区的详细介绍,可以参考官方文档

    2.3、后台进程

    后台进程

    后台进程(Background processes)是数据库实例的组成部分,用于完成数据库操作所需的维护任务并且为多用户提供最优性能。每个后台进程执行单独的任务,同时又和其他进程一起合作。Oracle 数据库在实例启动时自动创建后台进程,某些后台进程属于强制性的必要进程、其他的进程取决于使用的数据库功能。

    强制性后台进程在使用最小初始化参数文件启动读/写数据库实例时默认运行,只读数据库实例会关闭某些进程。强制性后台进程包括进程监视器进程(PMON)、进程管理器进程(PMAN)、监听器注册进程(LREG)、系统监控进程(SMON)、数据库写进程(DBWn)、检查点进程(CKPT)、 可管理性监视进程(MMON)、可管理性监视轻量进程(MMNL)、恢复进程(RECO)以及日志写进程(LGWR)。

    大多数可选的后台进程与特定任务或功能相关。一些通用的可选进程包括归档进程(ARCn)、作业队列协调器进程(CJQ0)、恢复写进程(RVWR)、闪回数据归档进程(FBDA)以及空间管理协调器进程(SMCO)。

    从属进程是替代其他进程执行操作的后台进程,例如调度器进程(Dnnn)和从属的共享服务器进程(Snnn)。

    📝Oracle 数据库后台进程的完整列表可以参考官方文档

    2.3.1、PMON

    PMON

    进程监视器进程(Process Monitor Process)PMON 负责定期扫描所有的进程并发现异常终止的进程。PMON 还负责协调进程的清理操作,具体操作由清理主进程(Cleanup Main Process)CLMN 和清理从属进程(Cleanup Slave Process)CLnn 执行。

    PMON 以操作系统进程运行,不支持线程模式。除了数据库实例之外,PMON 也可以在 Oracle 自动存储管理(ASM)实例和 Oracle ASM 代理实例上运行。

    2.3.2、PMAN

    PMAN
    进程管理器进程(Process Manager Process)PMAN 可以根据需要监控、创建以及停止以下进程:

    • 调度器进程和共享服务器进程。
    • 数据库内连接池的连接代理进程和服务器进程。
    • 作业队列进程。
    • 可重启的后台进程。

    PMAN 以操作系统进程运行,不支持线程模式。除了数据库实例之外,PMAN 也可以在 Oracle 自动存储管理(ASM)实例和 Oracle ASM 代理实例上运行。

    2.3.3、LREG

    LREG
    监听器注册进程(Listener Registration Process)LREG) 负责将实例、服务、处理程序和终端的信息通知监听器。

    LREG 可以作为一个操作系统线程或进程运行。除了数据库实例之外,LREG 还可以在 Oracle 自动存储管理(ASM)实例和 Oracle RAC 上运行。

    2.3.4、SMON

    SMON
    系统监控进程(System Monitor Process)SMON 用于执行各种数据库维护任务,包括:

    • 创建和管理临时表空间元数据,回收孤立临时段占用的磁盘空间。
    • 基于撤销空间的使用信息管理撤销表空间,包括联机、离线和收缩空间。
    • 当数据字典处于中间不一致的状态时执行清理操作。
    • 为 Oracle 闪回功能维护系统更改号(SCN)到时间点的映射表。

    SMON 可以阻止后台活动产生的内部或外部错误。SMON 可以作为一个操作系统线程或者进程运行。在 Oracle RAC 数据库中,一个实例中的 SMON 进程可以执行其他实例中失败的实例恢复。

    2.3.5、DBWn

    DBWn
    数据库写进程(Database Writer Process)DBWn 负载将缓冲区高速缓存中的数据块写入磁盘文件。另外,它还会处理检查点、文件打开同步以及数据库写入记录。如果配置了闪存缓存,DBWn 还会写入数据库智能闪存缓存。

    通常 BWn 写入的数据块分散在整个磁盘中,因此这种写入比日志写进程 LGWR 的顺序写入慢很多。DBWn 尽可能地执行多块写入以提高性能。不同操作系统中批量写入的块数量不同。

    初始化参数 DB_WRITER_PROCESSES 设置了数据库写进程的数量,取值可以从 1 到 100。前 36 个数据块写进程的名字为 DBW0-DBW9 和 DBWa-DBWz,第 37 到 100 个数据库写进程的名字为 BW36-BW99。数据库基于 CPU 数量和处理器组设置合适的 DB_WRITER_PROCESSES 默认值,或者调整用户指定的配置。

    2.3.6、CKPT

    CKPT
    检查点进程(Checkpoint Process)CKPT 用于在特定时间点提交检查点请求,通知数据库写进程将脏缓冲区写入数据文件。完成每个检查点请求后,CKPT会更新数据文件头和控制文件以记录最新的检查点。

    CKPT 每隔 3 秒检查一次缓冲区内存使用量是否超过 PGA_AGGREGATE_LIMIT 参数的设置,如果是则执行检查点操作。

    CKPT 可以作为一个操作系统线程或者进程运行。除了在数据库实例中运行之外,它也可以运行在 Oracle ASM 实例中。

    2.3.7、MMON & MMNL

    MMON & MMNL
    可管理性监视进程(Manageability Monitor Process)MMON 以及可管理性监视轻量进程(Manageability Monitor Lite Process)MMNL 用于执行和自动工作负载资料库 AWR 相关的任务。AWR 是一个历史性能数据的存储库,包括系统、会话、每个 SQL 语句、段以及服务的累积统计信息,可以用于问题检测和自动调优。

    MMON 从 SGA 中收集各种内存统计信息,过滤之后每隔 60 分钟在 AWR 中创建一个统计快照。快照频率默认为 60 分钟,也可以修改该设置。MMON 还会执行自动数据库诊断监视(ADDM)分析并且针对超出其阈值的指标发出警报。

    MMNL 收集会话统计信息(例如用户 ID、状态、主机以及正在执行的 SQL)并且存储到活动会话历史(ASH)缓冲区中。具体来说,MMNL 每秒钟对 SGA 中的 V$SESSION 和 V$SESSION_WAIT 视图进行抽样,将数据记录在 V$ACTIVE_SESSION_HISTORY 视图中。非活动的会话不会进行抽样。ASH 是内存中的一个循环缓冲区,因此更早的信息可能被覆盖。当 ASH 缓冲区填满或者 MMON 创建快照时,MMNL 将 ASH 缓冲区刷新(清空)到 AWR 中的 DBA_HIST_ACTIVE_SESS_HISTORY 视图。由于空间有限,只有十分之一的数据会被刷新。另外,MMNL 还会计算各种指标。

    MMON 和 MMNL 都可以作为操作系统线程或者进程运行。除了在数据库实例中运行之外,它们也可以运行在 Oracle ASM 实例中。

    更多相关的信息可以参考以下内容:

    2.3.8、RECO

    RECO
    恢复进程(Recoverer Process)RECO 用于解决由于网络或系统故障而导致挂起的分布式事务。

    RECO 可以作为一个操作系统线程或者进程运行。

    2.3.9、LGWR

    LGWR
    日志写进程(Log Writer Process)LGWR 负责将重做日志项按照顺序写入重做日志文件。重做日志项位于 SGA 的重做日志缓冲区。如果数据库设置了多路复用的重做日志,LGWR 将相同的重做日志项写入重做日志文件组的所有成员文件中。

    LGWR 处理非常快速或必须协调的操作,并且委托日志写工作帮助进程(Log Writer Worker helper processes)LGnn 执行这些操作。多个 LGnn 可以利用并发操作将日志缓冲区中的重做写入重做日志文件,并且在完成写操作后通知给正在等待的前台进程。

    重做传输从属进程(Redo Transport Slave Process)TT00-zz 负责将当前在线或者备用重做日志中的重做项发送到配置了异步(ASYNC)重做传输的远程备用目标。

    LGWR 可以作为一个操作系统线程或者进程运行。除了在数据库实例中运行之外,LGWR 也可以运行在 Oracle ASM 实例中。Oracle RAC 环境中的每个数据库实例都拥有自己的重做日志文件。

    2.3.10、ARCn

    ARCn
    归档进程(Archiver Processes)ARCn 只有当数据库位于 ARCHIVELOG 模式并且启用了自动归档功能时才会创建,负责在线重做日志文件的自动归档。日志写进程 LGWR 只有当在线重做日志文件完成归档后才能重用和覆盖相应的日志文件。

    数据库会根据需要启动多个归档进程,从而确保在线重做日志文件的归档操作不会延迟。数据库可能启用的归档进程包括 ARC0-ARC9 以及 ARCa-ARCt(共计 31 个归档目标)。

    初始化参数 LOG_ARCHIVE_MAX_PROCESSES 指定了数据库默认的最大 ARCn 进程数量。如果你执行了一个需要大量归档的操作,例如批量加载数据,可以增加归档进程的最大数量。归档目标也可以设置多个,推荐至少为每个目标创建一个归档进程。

    ARCn 可以作为一个操作系统线程或者进程运行。

    2.3.11、CJQ0

    CJQ0

    作业队列协调器进程(Job Queue Coordinator Process)CJQ0 负责从数据字典中挑选需要执行的作业任务并创建作业队列从属进程(Job Queue Slave Processes)Jnnn 执行这些任务。CJQ0 随着 Oracle Scheduler 的需要自动启动和停止。初始化参数 JOB_QUEUE_PROCESSES 指定了可以创建的最大作业进程数量。CJQ0 基于需要执行的任务数量和可用资源创建相应数量的作业队列从属进程。

    Jnnn 负责执行 CJQ0 分配的作业。Jnnn 执行作业的过程如下:

    • 收集执行作业所需的元数据,例如程序参数和权限信息。
    • 以作业的拥有者启动一个数据库会话,开始一个事务并执行作业。
    • 执行完成后提交并结束事务。
    • 关闭会话。

    完成作业之外,Jnnn 执行以下操作:

    • 根据需要重新安排作业。
    • 更新作业表的状态,标明作业已经完成还是计划再次执行。
    • 插入一条记录到作业日志表中。
    • 根据需要更新运行次数、失败次数以及重试次数。
    • 执行清理操作。
    • 查看新的作业任务,如果没有则进入睡眠状态。

    CJQ0 和 Jnnn 都可以作为操作系统线程或者进程运行。

    2.3.12、RVWR

    RVWR
    恢复写进程(Recovery Writer Process)RVWR 是一个用于闪回整个数据库或者一个可插拔数据的后台进程。也就是说,它负责从当前数据库状态回滚到过去的某个时间点,只要存在相应的闪回日志。当数据库启用了闪回功能或者创建了保证性还原点,RVWR 会将闪回数据写入快速恢复区中的闪回日志。

    RVWR 可以作为一个操作系统线程或者进程运行。

    2.3.13、FBDA

    FBDA
    闪回数据归档进程(Flashback Data Archiver Process)FBDA 是一个为表在生命周期内提供跟踪和存储事务性变更的后台进程。这个功能可以支持表的闪回查询和时间点恢复。

    当修改表的事务提交时,FBDA 检查新生成的 undo,找出与归档对象相关的信息并将其复制到闪回数据归档表空间中。FBDA 维护了当前数据行的元数据并记录了已经归档的数据量。

    FBDA 还负责自动管理闪回数据归档的空间、组织(分区表空间)和保留策略,以及跟踪事务的归档进度。

    FBDA 可以作为一个操作系统线程或者进程运行。

    2.3.14、SMCO

    SMCO
    空间管理协调器进程(Space Management Coordinator Process)SMCO 是一个用于调度各种空间管理任务的后台进程,职责包括主动的空间分配和空间回收。SMCO 动态创建空间管理从属进程(Space Management Slave Processes)Wnnn 来实现这些任务。注意,In-Memory 协调器进程(In-Memory Coordinator Process)IMCO 是执行列式数据后台填充和重新填充的后台进程。

    Wnnn 从属进程代表空间管理协调器进程和 Oracle In-Memory 选项执行实际的工作。

    Wnnn 进程是由 SMCO 动态创建的从属进程,用于在后台执行空间管理任务。这些任务包括基于空间使用量的增长分析将空间预分配到本地管理的表空间和 SecureFiles 数据段中,以及从删除的段中回收空间;同时还包括快速执行延迟插入。Wnnn 进程在启动后将会作为一个代理自动运行,完成一个任务执行后将会自动从队列中获取另一个任务。如果长时间闲置,Wnnn 进程将会自行终止。

    Wnnn 进程还负责 in-memory 对象的填充和重新填充。In-Memory 协调程序(IMCO)负责列式数据的后台填充和重新填充,IMCO 后台进程和前台进程实际上会利用 Wnnn 从属进程执行填充操作。IMCO 使用 Wnnn 进程对优先级为 LOW、MEDIUM、HIGH、CRITICAL 的 in-memory 对象进行填充和重新填充。 前台进程对于 in-memory 对象的查询和 DML 操作也会引起 Wnnn 从属进程执行的填充和重新填充任务。

    SMCO 和 Wnnn 都可以作为操作系统的线程或进程运行。

    2.3.15、Dnnn & Snnn

    Dnnn & Snnn
    在共享服务器模式下,客户端与调度器进程(Dispatcher Process)Dnnn 进行连接,调度器进程为每个连接创建一个虚拟通道。当客户端向服务器发送数据时,调度器进程通过虚拟通道接收数据并将活动通道放入公共队列中,然后由空闲的共享服务器进程(Shared Server process)Snnn 进行处理。共享服务器进程 Snnn 读取虚拟通道中的数据并执行相应的数据库操作完成客户端请求。当 Snnn 需要返回数据给客户端时,将数据写回相应的虚拟通道,然后 Dnnn 将数据发送给客户端。当 Snnn 完成了客户端的请求,会将虚拟通道释放给 Dnnn,从而可以继续处理其他客户端的请求。

    Snnn 和 Dnnn 都可以作为操作系统的线程或者进程运行。除了在数据库实例中运行之外,Dnnn 还可以在共享的服务器上运行。

    📝关于 Dnnn 和 Snnn 与大池的交互,可以参考上文中的大池部分。

    3、数据库

    3.1、数据文件

    数据文件
    一个多租户容器数据库(CDB)由一组存储用户数据和元数据的物理文件组成。元数据存储了关于数据库服务器的结构、配置以及控制信息。

    一个 CDB 包含一个 CDB 根容器(也成为 root)、一个可插拔的种子数据库(seed PDB)、零个或多个用户创建的可插拔数据库(简称为 PDB)以及零个或多个应用容器(application container)。整个 CDB 被称为系统容器。对于用户和应用程序来说,PDB 在逻辑上是一个独立的数据库。

    CDB 根容器的名称为 CDB$ROOT,包含了多个数据文件、控制文件、重做日志文件、闪回日志文件以及归档重做日志文件。数据文件中存储了 Oracle 提供的元数据和公共用户(每个容器中都通用的用户),这些信息由所有的 PDB 共享。

    种子 PDB 的名称为 PDB$SEED,是一个系统提供的 PDB 模板,包含了用于新建 PDB 的数据文件。

    普通 PDB 包含了存储应用程序(例如人力资源管理)使用的数据和代码的数据文件。用户只需要和 PDB 交互,而不需要使用种子 PDB 或者根容器。一个 CDB 中可以创建多个 PDB,多租户系统结构的目的之一就是为每个应用程序创建一个 PDB。

    应用容器是 CDB 中一组可选的 PDB,用于存储某个应用程序的数据。创建应用容器的目的是获得一个主应用程序定义,一个 CDB 中可以创建多个应用容器。

    表空间(tablespace)是数据库的逻辑存储单元,这些逻辑存储单元共同存储了所有的数据。每个表空间对应一个或多个数据文件。根容器和普通 PDB 拥有 SYSTEM、SYSAUX、USERS、TEMP 以及 UNDO 表空间(普通 PDB 可选)。种子 PDB 拥有 SYSTEM、SYSAUX、TEMP 以及可选的 UNDO 表空间。

    📝关于多租户体系结构的详细介绍,可以参考官方文档

    3.2、系统文件

    系统文件

    Oracle 数据库在运行期间需要使用以下数据库系统文件,它们都位于数据库服务器中。数据文件是属于数据库容器的物理文件,上文已经介绍过,因此没有列出。

    • 控制文件(Control files):用于存储关于数据文件和在线重做日志文件信息(例如文件名和状态)的必要文件。这些信息用于实例打开数据库。控制文件中还包含了数据库未打开时可以访问的元数据。强烈建议在数据库服务器中创建多个控制文件的副本,实现高可用性。
    • 参数文件(Parameter file):配置数据库实例的必要文件,启动实例时需要读取该文件。参数文件可以是一个初始化参数文件(pfile)或者服务器参数文件(spfile)。
    • 在线重做日志文件(Online redo log files):记录数据库变更的必要文件,用于数据恢复。
    • 自动诊断信息库(ADR):ADR 是一个基于文件的资料库,用于记录数据库的诊断数据,例如跟踪文件、转储文件、告警日志、健康监控报告等。ADR 提供了一个支持多产品和多实例的统一目录结构。数据库、Oracle ASM、监听器、Oracle 集群件以及其他 Oracle 产品和组件都可以在 ADR 中存储诊断信息。每个产品的每个实例都在 ADR 中拥有自己的主目录。
    • 备份文件(Backup files):用于恢复数据库的可选文件。当介质故障或用户错误损坏或删除了原始文件时,可以使用备份文件进行还原。
    • 归档重做日志文件(Archived redo log files):包含数据库实例连续历史数据变更的可选文件。使用归档重做日志文件和数据库备份文件可以恢复丢失的数据文件。也就是说,归档日志可以恢复还原后的数据文件。
    • 口令文件(Password file):可选文件,允许用户使用 SYSDBA、SYSOPER、SYSBACKUP、SYSDG、SYSKM、SYSRAC 以及 SYSASM 角色远程连接数据库,执行管理任务。
    • 钱包文件(Wallets):对于应用程序通过密码认证连接数据库的大型部署场景,可以将认证信息存储在客户端的 Oracle wallet 中。
      Oracle wallet 是一个安全的软件容器,用于存储身份验证和签名凭证。可选的钱包包括用于用户凭证的 Oracle wallet、用于透明数据加密(TDE)的加密钱包以及用于数据库云备份模块的 Oracle 公共云(OPC)钱包。虽然钱包文件是一个可选的文件,但是官方网推荐使用。
    • 块变更跟踪文件(Block change tracking file):块变更跟踪技术通过在文件中记录变更的数据块,从而提高增量备份的性能。在增量备份时,RMAN不再需要扫描所有的数据块识别发生过变化的数据块,而是通过该文件识别需要进行备份的数据块。块变更跟踪文件是一个可选的文件。
    • 闪回日志(Flashback logs):闪回数据库的作用类似于普通的时间点恢复,它可以将数据库返回到最近的某个时间点。不同之处在于闪回数据库使用自己的日志记录机制,创建闪回日志并将其存储在快速恢复区中。只有当闪回日志可用时才能使用闪回数据库功能,因此需要先创建闪回日志。闪回日志是可选的文件。

    控制文件、在线重做日志文件以及归档重做日志文件可用配置多路复用,也就是在不同的位置自动维护两份或多份完全相同的文件。

    控制文件、参数文件以及在线重做日志文件是数据库启动时必须使用的文件。

    📝更多详细信息可以参考官方文档

    3.3、应用容器

    应用容器
    应用容器(application container)是一个用户创建的可选的 CDB 组件,用于存储应用 PDB 相关的数据和元数据。一个 CDB 中可以创建零个或多个应用容器。一个应用容器包含一个应用 Root 和一个或多个应用 PDB。应用 root 属于 CDB 根容器,存储了公共元数据和数据。

    一个典型的应用包括一些公共用户、元数据公共对象和数据公共对象。你可以在一个应用容器中创建多个与销售相关的 PDB,这些 PDB 共享一个由一组公共表和表定义组成的应用程序后端。

    应用 root、应用种子 PDB 以及应用 PDB 拥有一个 SYSTEM、SYSAUX、TEMP、USERS 以及可选的 UNDO 表空间。每个表空间对于一个或多个数据文件。

    📝关于应用容器的更多信息,可以参考官方文档

    3.4、自动诊断信息库

    自动诊断信息库
    自动诊断信息库(Automatic Diagnostic Repository)ADR 是一个用于数据库诊断数据存储的系统级别跟踪和记录集中仓库,包含以下内容:

    • 后台进程跟踪文件(Background trace files):每个数据库后台进程都可以写入一个相关的跟踪文件。当进程检测到一个内部错误时,会将错误信息写入它的跟踪文件。跟踪文件中的某些信息可以供数据库管理员参考,另一些信息则用于 Oracle 支持服务。通常来说,后台进程跟踪文件的名称中包含了 Oracle 系统标识符(SID)、后台进程名以及操作系统进程编号信息,例如 mytest_reco_10355.trc 是一个 RECO 进程跟踪文件。
    • 前台进程跟踪文件(Foreground trace files):每个服务器进程都可以写入一个相关的跟踪文件。当服务器进程检测到一个内部错误时,会将错误信息写入它的跟踪文件。服务器进程跟踪文件的名称中包含了 Oracle SID、字符串“ora”以及操作系统进程编号信息,例如 mytest_ora_10304.trc 是一个服务器进程跟踪文件。
    • 诊断转储文件(Dump files):诊断转储文件是一种特殊的跟踪文件,其中包含了某个状态或结构在特定时间点的详细信息。转储文件通常是某个事件的一次性诊断数据,而跟踪文件则是连续的诊断数据。
    • 健康监控报告(Health monitor reports):Oracle 数据库提供了一个称为 Health Monitor 的诊断检查机制。健康检查可以发现文件损坏、物理块或逻辑块损坏、undo 和 redo 损坏、数据字典损坏等。健康检查可以生成有关问题的报告,并且在很多情况下会提供解决问题的建议。
    • 事故包(Incident packages):提供了一个将诊断数据上传到 Oracle Support 的定制方法。用户首先将相关数据收集到一个称为事故包的中间逻辑结构中,其中包含了存储在 ADR 中的元数据集合,以及指向 ADR 内部或外部诊断数据文件和其他文件的元数据集合;然后,往事故包中增加一个或多个问题。支持平台随后自动将问题信息、事故信息以及针对数据(例如跟踪文件和转储文件)添加到事故包中。
    • 事故转储文件(Incident dumps):当事故发生时,数据库会创建一个事故目录并写入一个或多个转储文件。事故转储文件的名称中包含了事故编号。
    • 告警日志文件(Alert log file):数据库告警日志是一个按照时间顺序记录的系统消息和错误信息。Oracle 推荐用户定期查看告警日志文件。

    更多相关信息可以参考官方文档

    3.5、备份文件

    备份文件
    数据库备份可以是物理备份或者逻辑备份。

    • 物理备份就是数据库文件的物理拷贝。物理备份可以使用恢复管理器(RMAN)或者操作系统命令创建。
    • 逻辑备份中包含了表、存储过程以及其他逻辑数据。逻辑备份可以通过 Oracle 数据库实用工具(例如 Data Pump Export)创建并保存为二进制文件。逻辑备份可以作为物理备份的补充。

    RMAN 创建的数据库备份存储为映像副本或者备份集。

    • 映像副本(image copy)是数据文件、控制文件或者归档重做日志文件在磁盘上的按位复制。物理文件的映像副本可以使用操作系统命令或者 RMAN 创建和还原。映像副本对于磁盘备份很有用,因为可以执行增量更新和原地恢复。
    • 备份集(backup set)RMAN 创建的专用格式,包含了一个或多个数据文件、归档重做日志文件、控制文件或者服务器参数文件中的数据。备份集的最小单元是被称为备份片(backup piece)的二进制文件。备份集是 RMAN 可以将备份写入顺序设备(例如磁带机)的唯一格式。备份集的优点之一是 RMAN 可以使用块压缩来节省备份数据文件的空间。只有数据文件中使用了的块才会包含在备份集中。备份集也可以被压缩、加密、发送到磁带并且使用高级空间压缩功能(数据文件副本不支持该功能)。

    RMAN 可以与介质管理库(MML)或磁带系统备份(SBT)软件交互并创建到磁带的备份,也可以与 Oracle 数据库备份云服务或零数据丢失恢复一体机(通常称为恢复一体机)进行交互。

    更多信息可以参考:

    展开全文
  • 1.一个数据库用户可以对应多个架构架构是表容器)。架构里面包含的是数据库表。 2.一个数据库角色有可能涉及多个架构数据库角色对应的是权限。 3.一个用户对应一个数据库角色。 4.登录名与数据库用户服务器...

    1.一个数据库用户可以对应多个架构(架构是表容器)。架构里面包含的是数据库表。

    2.一个数据库角色有可能涉及多个架构。数据库角色对应的是权限。

    3.一个用户对应一个数据库角色。

    4.登录名与数据库用户在服务器级别是一对多的;在数据库级别是一对一的。




    服务器登录名:指有权限登录到某服务器的用户;

    服务器角色:指一组固定的服务器用户,默认有9组;

    • 登录名一定属于某些角色,默认为public
    • 服务器角色不容许更改
    • 登录后也不一定有权限操作数据库

    数据库用户:指有权限能操作数据库的用户;

    数据库角色:指一组固定的有某些权限的数据库角色;

    数据库架构:指数据库对象的容器;

    • 数据库用户对应于服务器登录名以便登录者可以操作数据库
    • 数据库角色可以添加,可以定制不同权限  
    • 数据库架构,类似于数据库对象的命名空间,用户通过架构访问数据库对象

    服务器角色

    sysadmin --在 SQL Server 中进行任何活动。该角色的权限跨越所有其它固定服务器角色。

    serveradmin  --配置服务器范围的设置。

    setupadmin  --添加和删除链接服务器,并执行某些系统存储过程(如 sp_serveroption)。

    securityadmin  --管理服务器登录。

    processadmin  --管理在 SQL Server 实例中运行的进程。

    dbcreator  --创建和改变数据库。

    diskadmin  --管理磁盘文件。

    bulkadmin  --执行 BULK INSERT 语句。


    数据库角色

    public
    --public 角色是一个特殊的数据库角色,每个数据库用户都属于它。public 角色: 
    --捕获数据库中用户的所有默认权限。
    --无法将用户、组或角色指派给它,因为默认情况下它们即属于该角色。
    --含在每个数据库中,包括 master、msdb、tempdb、model 和所有用户数据库。
    --无法除去。

    db_owner 
    --进行所有数据库角色的活动,以及数据库中的其它维护和配置活动。
    --该角色的权限跨越所有其它固定数据库角色。

    db_accessadmin 
    --在数据库中添加或删除 Windows NT 4.0 或 Windows 2000 组和用户以及 SQL Server 用户。

    db_datareader 
    --查看来自数据库中所有用户表的全部数据。

    db_datawriter 
    --添加、更改或删除来自数据库中所有用户表的数据

    db_ddladmin 
    --添加、修改或除去数据库中的对象(运行所有 DDL)

    db_securityadmin 
    --管理 SQL Server 2000 数据库角色的角色和成员,并管理数据库中的语句和对象权限

    db_backupoperator 
    --有备份数据库的权限

    db_denydatareader 
    --拒绝选择数据库数据的权限

    db_denydatawriter
    --拒绝更改数据库数据的权限



    先说sqlserver里面的数据库级别设置:

    服务器级 -> 数据库级 -> 架构级 - > 数据对象级,比如说:Server.DataBase1.dbo.Table1;这里的意思就是Table1这个表属于dbo这个架构

    ,dbo这个架构属于DataBase1这个数据库,DataBase1这个数据库属于Server这个服务器。里面的架构其实就是一个容器,好像就是面向对象里面的

    命名空间,一个用户可以拥有多个架构,但是不能对没有拥有的架构进行操作。一个数据库角色,是对不同架构里面数据对象的权限组织,也有可能涉及到

    多个架构,当某一个用户被转换成一种数据库角色的时候,假如这个用户本身不拥有某一个架构而该数据库角色拥有,那它当它对那个架构进行操作的时候就会出错。

    角色,角色意味着一种身份,在数据库服务器里是对一系列权限的组织。

    服务器登录名,指有权限登录到某服务器的用户,可以在有权限的情况下创建新的登录名,超级管理员的登录名是sa

    服务器角色,指一组固定的服务器用户,默认有9组;

    • 登录名一定属于某些角色,默认为public
    • 服务器角色不容许更改
    • 登录后也不一定有权限操作数据库

    数据库用户,指有权限能操作数据库的用户;

    数据库角色,指一组固定的有某些权限的数据库角色;

    数据库架构,指数据库对象的容器;

    • 数据库用户对应于服务器登录名以便登录者可以操作数据库
    • 数据库角色可以添加,可以定制不同权限  
    • 数据库架构,类似于数据库对象的命名空间,用户通过架构访问数据库对象

    登录名与用户在服务器级是一对多的,而在数据库里是一对一的。比如说Server这个服务器有4个数据库,DB1,DB2,DB3,DB4,每个数据库都有一个用户USER1,USER2,USER3,USER,在创建一个登录名my的时候可以通过用户映射的操作,为这个登录名在每一个具体的数据库中指定用户,比如可以如下指定my在DB1中的用户是USER1,它是在使用数据库的时候是唯一的,my在不能再DB1中切换用户,除非重新指定它对DB1数据库的用户映射。

    用户一般是受权限管理的,在新建一个用户的时候是这样的:



    需要指定它的登录名,这也是映射操作的一部分,同时可以指定它的默认架构,如不指定就是dbo,也可以指定它拥有的其它架构和角色成员,不过没有默认数据库角色。

    下面看看新建一个角色:


    在新建的时候可以指定这个角色拥有那些架构,但是这些结构必须是这个数据库里面的,默认架构为当前用户使用的架构,比如当前用户的架构是dbo,则在角上权限定义时所使用的默认架构就是dbo,当然也可以指定其它的架构。

    展开全文
  • 【摘要】 本文提出了一种通过引入内存数据库层,建立两层多分区分布式数据库架构。此方案用于解决海量高并发系统的数据存储和访问问题,尤其适用于电子商务等数据模型复杂且业务复杂的互联网站。 这些年互联网站...
  • Snowflake数据库调研及架构介绍

    千次阅读 2020-11-03 20:46:07
    简介 ...Snowflake的数据仓库不是建立现有数据库或Hadoop等“大数据”软件平台上的,Snowflake数据仓库使用新的SQL数据库引擎,该引擎具有为云设计的独特架构。对于用户而言,Snowflake与其他企业数
  • MySQL数据库的体系架构

    万次阅读 2013-06-19 15:19:43
    MySQL数据库的体系架构图所示: 从上图中可以看出,MySQL主要分为以下几个组件: 连接池组件管理服务和工具组件SQL接口组件分析器组件优化器组件缓冲组件插件式存储引擎物理文件 表显示...
  • 发布数据库上的架构更改

    千次阅读 2010-11-30 16:55:00
    发布数据库上的架构更改 Microsoft? SQL Server? 2000 支持对现有发布数据库进行一般的架构更改。可以向某个已发布的表中添加列和从中除去列,而无需除去和重新创建引用此表的发布和订阅。 架构更改...
  • 内存数据库的分布式数据库架构

    千次阅读 2012-02-16 11:52:51
    本文提出了一种通过引入内存数据库层,建立两层多分区分布式数据库架构。此方案用于解决海量高并发系统的数据存储和访问问题,尤其适用于电子商务等数据模型复杂且业务复杂的互联网站。   这些年互联网站发展迅猛...
  • 互联网数据库架构设计思路数据库

    千次阅读 2016-12-18 15:08:45
    互联网数据库架构设计思路
  • 数据库架构设计

    万次阅读 2013-06-04 00:30:04
    最近考虑如何能设计好一个数据库架构,下面是个人一点想法,欢迎高人指正   任何系统都不是独立的,是一个生态系统,数据库也是一样的,要使其其生命周期内更好的服务于业务,设计之初就要考虑周全。作为...
  • 数据库架构的一切

    千次阅读 2018-06-27 10:36:46
    二、数据库架构设计思路 (1)可用性 (2)读性能 (3)一致性 (4)扩展性 一、基本概念 概念一“单库” 概念二“分片” 分片解决的是“数据量太大”的问题,也就是通常说的“水平切分”。 一旦...
  • 【转】基于内存数据库的分布式数据库架构 ...这些年互联网站发展迅猛,为应对海量数据的高并发访问,产生了各种分布式架构设计思想,例如Key-Value引擎,数据分区等。而对于电子商务类网站,海量数
  • 本书是微软认证IT专家(MCITP)70-...本书适合数据库管理员,也适合需要设计安全数据库解决方案、定义高可用性解决方案、巩固数据库架构、计划并设计数据库部署、设计备份和恢复策略、或需要优化数据库数据库专家。
  • Ridgepole是用于管理数据库架构的工具。 它使用定义数据库模式,并根据DSL更新数据库模式。 (例如厨师/木偶) 变更日志 >= 0.4.8 activerecord-mysql-unsigned现在是可选的。 如果要使用,请安装 --enable-...
  • 实时数据库 架构

    千次阅读 2016-01-22 09:44:06
    数据服务器、Web服务器、设备驱动、人机界面、实用工具可任意组合,分别运行相同或不同机器上。实时数据,历史数据,过程报警,事件等作为整个系统的共有资源,可为其他客户端和数据库共享。     紫金...
  • 数据库双活技术已成为企业重点关注的对象,社区最近组织了交流活动,以帮助大家更好的明确理解...孔再华 民生银行 数据库架构师 冯帅 点融网 高级DBA 韩成亮 某金融单位 数据库架构师 还有以下会员热心分享: ...
  • 数据库架构概念

    千次阅读 2009-09-29 13:25:00
    SQL Server 2005架构中的一些基本概念模型 操作文件(Operational FIles):用于使软件和服务运行的文件。数据文件(Data Files):系统产生的文件。数据文件分为两种:mdf后缀的数据库数据文件,ldf后缀的日志数据库...
  • 全面介绍了如何设计和管理安全的...本书适合数据库管理员,也适合需要设计安全数据库解决方案、定义高可用性解决方案、巩固数据库架构、计划并设计数据库部署、设计备份和恢复策略、或需要优化数据库数据库专家。
  • 数据库架构在美团点评的演变实践

    千次阅读 2017-11-20 15:06:11
    前言 IT时代的缩影基本被CPU、操作系统、数据库这三大核心领域,支撑了半个世纪...下面分别讲每个时代数据库发展的诉求和过程。 关系型数据库时代 说到关系型数据库,就要从1970年E.F.Codd的《A Relatio
  • 给出表,以MySQL Sakila示例数据库为例: CREATE TABLE film_actor ( actor_id SMALLINT UNSIGNED NOT NULL , film_id SMALLINT UNSIGNED NOT NULL , last_update TIMESTAMP NOT NULL DEFAULT CURRENT_...
  • 批量修改sqlserver数据库表的架构

    千次阅读 2013-09-03 20:56:44
    2013-02-05 有时候折腾sqlserver数据库的用户名,导入导出的时候忘了选所有者了,这时候这个sql就用上了,通过测试 ...cursor --定义一个游标 for select name from sysobjects where xtype = 
  • 数据库实验报告1数据库定义实验

    千次阅读 2020-04-29 11:18:58
    (1)理解和掌握数据库DDL语言,能熟练地使用SQL DDL语句创建、修改和删除数据库、模式和基本表。 (2)掌握SQL语句常见语法错误的调试方法。 二、 实验内容: 教材3.3数据定义中例3.1至例3.11的要求操作,并截取...
  • oracle数据库体系架构详解

    万次阅读 多人点赞 2018-08-31 19:10:41
    学习oracle中,体系结构是重中之重,一开始从宏观上掌握它...你首先应该以图纸的方式把整个大楼的体系架构描述出来。然后一点点的往里面填充东西。下面我们先以一个图解的方式对oracle体系结构有一个基本了解   ...
  • 嵌入式SQLite数据库架构和设计

    千次阅读 2017-05-30 20:19:22
    SQLite既是一个数据库,一个程序库,一个命令行工具,也是一个学习关系型数据库的很好的工具。确实有很多途径可以把它使用到内嵌环境、网站、操作系统服务、脚本语言和应用程序。对于程序员来说,SQLite就像一个数据...
  • 分布式系统数据库系统原理(第三版)中的描述:“我们把分布式数据库定义为一群分布计算机网络上、逻辑上相互关联的数据库。分布式数据库管理系统(分布式DBMS)则是支持管理分布式数据库的软件系统,它使得分布对于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 333,786
精华内容 133,514
关键字:

在数据库下如何定义架构