在 2017 DTCC – 数据库大会的现场，老朋友盖总的公司发布了『Oracle Database 12.2 体系结构图』，该体系结构图，几乎涵盖了 Oracle 最新的 12.2 的所有技术细节和新的特点。体系结构图中尤其对 Oracle 12cR2中的众多新特性，比如多租户、In-Memory、Sharding，还有Recovery Buddy和LMS等，尽皆涵盖。废话不多说，请赏图！ 最后，大家如果想要下载高清图，可以关注他们微信公众号“数据和云”去获取。 ...继续阅读 (7)

创建MySQL Cloud Service时，会要求提供一个SSH登录密钥，所有的Oracle云服务主机登录用户都是opc，因此在服务创建完毕，收到通知邮件之后，就可以通过ssh登录到服务器上。登录到主机以后，服务器显示了MySQL运行状态和存储使用量的提醒。这里介绍了 Oracle MySQL Cloud Service 提供的安全选件功能，如果我们用MySQL Workbench登录到数据库中，在Server Status页面可以看到：SSL连接，PAM验证，密码校验，数据库审计等多种安全功能全部是开启的。类比,阿里云的 MySQL RDS 并没有开启任何安全选项，或许是为了性能考虑？Oracle对于数据库安全性的看重确实超越了大多数数据库提供商，而这也带来了一些小麻烦。在创建MySQL云服务的时候，需要指定数据库root用户的密码，这个密码有比较强的安全要求，需要有大写、小写英文字母，有数字，同时还需要有特殊字符（比如#）。因此在后续创建Login Path时，在mysql_config_editor命令提示输入密码的时候，需要在密码前后加上双引号（比如”Passw#rd”），否则会一直出现拒绝访问的提示。--opc用户没有办法直接登录MySQL，需要切换到oracle用户 [opc@mysql-cloud-mysql-1 ~]$ mysql -uroot -p Please ...继续阅读 (1)

首先盗用一下盖总这边的一张照片，哈哈！2015年8月 Tom 大师归隐， Oracle RWP 团队几乎就暂停了外部公开亮相。不过，2017年3月28日，RWP 团队再次亮相在了ACOUG和Oracle公司的联合主办的Oracle 性能优化之旅的中国北京站，在北京广播大厦酒店为咱们国内的Oracle 技术人呈现了 6个小时的精彩内容！作为Oracle届的大神级人物，Andrew 和 Graham 领导了 Oracle 公司数据库性能优化领域的顶尖团队。为全球Oracle用户分享了大量的优化方法级经验，包括Oracle Database软件本身，以及Oracle Database软件所运行的硬件环境和网络环境的优化。国内Oracle大神盖总做了简单的开场之后，就是 Andrew和Graham的干货分享啦，第一个主体为OLTP的秘密。从OLTP系的内部机制，以及系统为什么会出现各类性能问题等等，再找到问题的根源，最终解决这些问题。Graham从Oracle 数据库运行硬件环境的CPU的工作原理的角度做了剖析，在OLTP中，CPU繁忙对于系统意味着一切问题的开始，包括数据库响应时间分片等，这些都对于数据库优化有很大的影响。这里饮用盖总的说法：“在RWP团队的优化策略中，他们一直遵循top-down的原则，努力从根源处解决问题，正如我们之前所说，数据库性能的问题绝大部分都可以归结为SQL的 ...继续阅读 (1)

这是 Oracle Sharding 介绍系列文章的最后一篇，前面总攻介绍了4篇：Oracle Sharding 介绍系列I（什么是Oracle Sharding）Oracle Sharding 介绍系列II（特性优势）Oracle Sharding 介绍系列 III（横向对比）Oracle Sharding 介绍系列 IV（技术实现）这里我们再来看看 Oracle 官方文档还给我们介绍了哪些关于 Oracle Sharding 的信息呢？首先看看，Oracle 云服务上支持Oracle Sharding吗？Oracle数据库云服务（PaaS）目前不提供用于部署分片数据库的整体自动化，但可以使用Oracle数据库云服务自动部署Oracle Sharding将会在2017年被列入计划，计划支持混合云和全部云部署模型，以及单数据中心和多数据中心部署。然后，Oracle Sharded数据库可以使用cookbook部署在Oracle Cloud（DBCS实例）上。问：如何为Oracle Cloud（PaaS）授权Oracle Sharding？答：使用DBCS EE和DBCS EE高性能（HP），仅限使用三个主分片。 （待机分片数量没有限制）；使用DBCS EE极端性能（EP）和Exadata云服务（ECS），对主分片或备用分片数量没有限制。真实场景下Oracle Sharding的优势 ...继续阅读 (7)

在上一篇Oracle Sharding 介绍系列 III（横向对比）对 Oracle Sharding 与其他产品进行了横向对比之后，这一篇我们再看看 Oracle Sharding 背后的技术实现1、数据在分片之间如何分配？Oracle Sharding使用水平分区来跨分片（离散物理数据库）分割数据库表，以便每个分片包含具有相同列但行的不同子集的表。跨分片的分区的分布在表空间级别完成。分片表的每个分区驻留在单独的表空间中，每个表空间与特定分片相关联。每个分片上的表分区与非分片Oracle数据库中使用的常规分区没有区别。即使表的分区驻留在多个数据库中，对应用程序开发人员来说，表的外观和行为与单个数据库中的常规分区表完全相同。应用程序发出的SQL语句从不引用分片，也不依赖于分片数及其配置。 Oracle Sharding提供了几种可选的分区方法，可以自动或由用户确定数据的分布，或两者的组合。2、Oracle Sharding支持哪些类型的Sharding方法呢？Oracle Sharding支持三种分片方法：系统管理，用户定义和复合分片。系统管理的分片不要求用户指定数据到分片的映射。使用按照一致性哈希分区，自动在分片中分布数据。分区算法均匀且随机地在分片之间分布数据。这种分布旨在消除热点并在整个碎片上提供均匀的性能。当向SDB添加或从SDB中删除分片时，Oracle Sharding ...继续阅读 (7)

上一片介绍了Oracle Sharding 介绍系列II（特性优势），这里再介绍一下Oracle Sharding与其他产品进行一下横向对比。1、Oracle Sharding与RACOracle RAC和Active Data Guard的组合为OLTP和分析应用程序提供了透明的横向扩展和可用性，并且可以满足99 +％的用例需求。 使用Oracle RAC，所有事务可以对数据库中的任何数据起作用，没有必要分区数据或关注多分片操作的性能，所有RAC实例共享对同一物理数据库的直接访问。Oracle Sharding牺牲了透明性，为定制设计的OLTP应用程序提供了巨大的可扩展性和高可用性。 使用Oracle Sharding，应用程序被设计为使更新事务对单个分片中的数据起作用。 跨越多个分片的事务不会受益于与单分片事务相同的性能和可伸缩性。问：在什么场景下使用Oracle Sharding而不是RAC？答：有以下两种情况：当Oracle Enterprise Architect或客户决定Oracle RAC无法解决当前或未来的可扩展性和可用性要求时，Oracle Sharding会成为首选解决方案；当应用程序被明确地设计用于分片数据库时。注意，分片和Oracle RAC不是互斥的。分片可以使用Oracle RAC或RAC One节点代替复制HA。第一个版本的Oracle Shardin ...继续阅读 (9)

承接上一篇文章Oracle Sharding 介绍系列I（什么是Oracle Sharding）这里再介绍下 Oracle Sharding 更多的特性，为什么会受到如此多的关注Oracle Sharding是响应客户对数据库架构的需求，可以提供线性可扩展性和完全故障隔离的组合，而无需共享存储或损害Oracle数据库的企业质量：严格的一致性，SQL的全部功能，开发人员敏捷性 具有JSON，安全性，高可用性，备份和恢复，生命周期管理等。Oracle Sharding不仅仅将Oracle的企业质量扩展到分片式数据库架构， 并且通过使用自动化来简化生命周期管理，高级分区方法来解决各种各样的场景案例以及数据相关的路由，以实现卓越的运行时性能。与竞争性分片解决方案或定制部署相比，这些功能为客户提供了显着的优势。1、Oracle Sharding在12.2版本中的新特性Oracle 12.2在Sharding方面增加了许多新的优势：具有完全故障隔离的线性可扩展性。用于Oracle分区的OLTP应用程序可以在任何平台上弹性扩展（数据，事务和用户）到任何级别，只需在额外的独立服务器上部署新的分片。由于计划外中断或计划维护而导致的碎片不可用或减速只影响该碎片的用户，但不会影响其他碎片用户的应用程序的可用性或性能。每个分片可以运行不同版本的Oracle数据库，只要应用程序与最早运行的版本向后兼容即可 ...继续阅读 (10)

这是关于Oracle Sharding 方面系列文章的第一篇，从 Oracle 12.2 开始，不仅有多租户场景，多数据中心架构，还有云部署模型。下面就是关于 Oracle Sharding介绍系列第一篇，大部分内容来自 Oracle 文档。这篇文站首先介绍下什么是 Oracle Sharding。Oracle Sharding是Oracle数据库为在线交易类型的应用程序定制设计的一种可扩展、支持高可用功能的架构，可以在不具有共享硬件或软件的数据库池中分发和复制数据。数据库池作为单个逻辑数据库展现给应用程序，应用程序通过在池中添加额外的数据库（分片），可以在任何平台上弹性扩展（数据，事务和用户）到任何级别， 使用Oracle数据库12.2.0.1的第一个版本支持扩展到1000个分片。1、Oracle Sharding的优点与使用类似的可伸缩性方法的本地部署相比，Oracle Sharding提供了卓越的运行时性能和更简单的生命周期管理；还提供了企业DBMS的优势，包括：关系模式，SQL和其他编程接口，支持复杂数据类型，在线模式更改，多核可扩展性，高级安全性，压缩，高可用性，ACID属性，一致性 阅读，使用JSON的开发人员敏捷性等等。Oracle分片使用水平分区在分片之间分布数据，通过分片分割数据库表，以便每个分片包含具有相同列但行的不同子集的表。从数据库管理员的角度来看，SDB由 ...继续阅读 (5)

到此，关于 MySQL Cloud Service 系列相关文章就全部结束了，最后再回顾一下 MySQL 作为 Oracle 在互联网行业的数据库软件主力兵，Oracle 在其云战略中同样得到了重视，提供了 MySQL 数据库的云服务。作为官方提供的云数据库，无论从软件版本的管控，网络安全的把握以及服务工具的提供，都很好的为“官方出品”正名，确实考虑的非常周到，体验方面也做得还算不错。而我们作为一个实际的使用用户，需要重点关注的是哪些内容呢？相信大多数用户和我一样，就是数据库的创建和维护是否足够简单方便，数据库的管理是否高效便利，所以我这里在最初的几篇文章中就重点介绍了：创建  MySQL Database 的文章：MySQL Cloud Service：创建 MySQL Database以及MySQL 日常维护的内容：MySQL Cloud Service：日常维护然后，数据库作为企业最为核心资产“数据”的存放地，其安全也必定是每一个企业所重点关注的，所以我这里针对 MySQL Cloud Service 数据库的访问控制做了单独介绍：MySQL Cloud Service：网络访问控制管理最后，任何软硬件都有出现故障的时候，任何人都有出现失误的时候，所以每一个 DBA 都知道，备份是一个 DBA 工作的重中之重，任何重大操作之前先备份，任何一个数据库都需要有备份，而在 Orac ...继续阅读 (1)

MySQL Cloud Service 系列文章快捷入口：MySQL Cloud Service 介绍MySQL Cloud Service：创建 MySQL DatabaseMySQL Cloud Service: MySQL服务概览MySQL Cloud Service：MySQL 的起停MySQL Cloud Service：网络访问控制管理MySQL Cloud Service：日常维护MySQL Cloud Service：备份及恢复前面已经通过9篇文章介绍了 Oracle Cloud Service 中的 MySQL Cloud Service 的使用及注意事项，本文最后再介绍以下很多 DBA 所关心的两个问题：补丁管理 和 容量管理我们先看看如何在 MySQL Cloud Service 上来处理补丁的事情。有哪些补丁是可以在 MySQL Cloud Service 上使用的？MySQL Database 相关补丁MySQL 数据库 Instance 层面的补丁是可以正常使用的，当然，补丁过程和我们平常维护本地数据库差不多，同样包含以下几个步骤：检查补丁对应版本检查补丁的前置条件（比如空间是否够，版本是否对等）执行补丁程序确认补丁结果遇到异常回滚补丁OS 相关补丁由于 MySQL Cloud Service 在创建数据库的时候同时给了我们一个独立的 OS 环境用于运行 ...继续阅读 (1)

MySQL Cloud Service 系列文章快捷入口：MySQL Cloud Service 介绍MySQL Cloud Service：创建 MySQL DatabaseMySQL Cloud Service: MySQL服务概览MySQL Cloud Service：MySQL 的起停MySQL Cloud Service：网络访问控制管理MySQL Cloud Service：日常维护本文将延续本系列，介绍 MySQL Cloud Service 上云数据库的备份与恢复操作，比较一下与我们以前维护的MySQL数据库到底会有什么方面的差异。 首先，我们在之前的文章中已经介绍过，当我们创建一个 MySQL Cloud Service 云数据库的时候，系统就会给我们配置一个默认的备份规则。 该备份规则设置了 Oracle MySQL Cloud Service 会通过 MySQL Enterprise Backup 来进行备份，备份集包括数据库所有的数据文件基于某个时间点的完整状态。由于是通过 MySQL Enterprise Backup 工具备份，所以备份集中包含的详细内容可以通过 MySQL Exterprise Backup的官方文档看到所有详细列表，列表如下： ...继续阅读 (1)

系列前序文章：MySQL Cloud Service 介绍MySQL Cloud Service：创建 MySQL DatabaseMySQL Cloud Service: MySQL服务概览MySQL Cloud Service：MySQL 的起停MySQL Cloud Service：网络访问控制管理本文将介绍在日常维护过程中的各项操作，比如存储资源的增删，资源的扩容及减配等SSH 证书的管理首先，SSH 证书在数据库创建之初的时候让用户做了第一次填写在业务运行过程中，可能会因为各种原因导致需要修改或者增加新的证书，那么我们可以通过 Cloud Service 详情页的下拉管理列表中“SSH Access”入口进入SSH管理界面然后我们就可以针对 SSH 进行新增或者删除已有证书的操作。存储资源的维护管理存储资源的维护操作主要是用于随着业务增长而不断增大的数据库需要更多存储空间的时候，我们不得不申请更多的存储资源以用于存放数据。根据 MySQL Cloud Service 的定义，又包含了以下集中类型的存储资源：Usable Database Storage：主要用于存放数据库数据Backup Storage：用于备份数据库文件的存储资源Redolog Storage：用于存放 Innodb的Redo 的存储资源存储资源的扩容路径如下：点击“服务名”进入概览页面 -> 选择 “ ...继续阅读 (1)

前序系列文章导航：MySQL Cloud 服务概览：MySQL Cloud Service 介绍MySQL Cloud Service：创建 MySQL DatabaseMySQL Cloud Service：MySQL 的起停MySQL Cloud Service: MySQL服务概览承接前面4片文章的介绍，本文重点介绍以下 MySQL Cloud Service 在网络管理配置方面的内容。MySQL Cloud Service 在网络管理方面，主要包含以下三个方面：计算节点的OS层面我们都知道，对于 OS 管理一般都通过 SSH 的方式进行远程访问操作，Oracle 同样给我们提供了SSH的方式来访问运行 MySQL Cloud Service 的OS，不过 SSH 的访问认证方式是使用证书验证的方式。认证证书在之前系列文章中的第二篇已经介绍过，在创建 MySQL Database 的时候曾今要求用户输入 SSH 证书公钥，就是在这里用到。当然，如果之前配置的公钥因为各种原因需要更换，我们也可以在后期进行修改。但是，即使我们配置好了正确的证书，也并不代表着我们就能顺利的从公网的任意环境都可以访问到运行 MySQL Cloud Service 的 OS 环境。这里就会涉及到 Oracle Cloud Servie 中关于网络安全配置的内容，需要我们在 Oracle 云服务网络服务 ...继续阅读 (1)

本文针对 MySQL Cloud Service 的常规操作做一些简单的介绍Stop（关停） MySQL Cloud Service 中的一个数据库MySQL Cloud Service中停止一个数据库和平常我们自己服务器上关停一个MySQL 数据库有很大的差异。随着对 MySQL Cloud 上的 Database 作出Stop（关停）指令的发出，Oracle会进行以下操作：关停 MySQL Database Instance释放用于运行该 MySQL Instance 的CPU资源释放用于运行该 MySQL Instance 的 RAM资源释放用于运行该 MySQL Instance 的OS 资源总之，当执行 Stop 指令之后，你将无法像以前在自由服务器上那样登陆服务器上进行操作如访问数据文件等。按照Oracle 官方的说法就是“Stopping a MySQL Server deployment is similar to turning off your personal computer”，就像对电脑执行了断电操作一样，所以我们自然也无法再通过ssh访问这台“电脑”了。那么，有哪些资源不会收到影响呢？存储资源（要不然数据不久丢失啦）网络资源（所以IP地址不用担心会变化）当然，既然关闭的时候释放了CPU和RAM等计算资源，所以关停后该部分资源也不会进行计费。同样，关停过程 ...继续阅读 (1)

前面两篇对 MySQL Cloud Service 做了基本介绍和创建方式，本文将介绍如何检索自己的所有 MySQL Cloud Service 信息，以及如何区查看自己的这些服务。要查看到自己爹 MySQL Cloud Service ，首先需要进入到 MySQL Cloud Service Console 页面，该页面会展示出你之前所创建的所有Instance列表。然后点击进入某一个Instance，就可以查看到该服务的大部分详情信息了。具体包含以下信息：MySQL Cloud Service 常用操作入口启动/关闭/重启 操作入口升/降配置 操作入口健康状态入口等… …MySQL Cloud Service 详细信息展示基本信息如服务名／状态／配置 等MySQL Instance 信息如 版本／端口／字符集 等总的来说，可以通过 Oracle 官方文档中的这个表格来表告诉我们这里到底能干啥： 除了这些信息之外，我们还能在 Activity 页面分析 MySQL Cloud Service 的操作日志，进行全文搜索。不过这里需要注意的一点是这里的日志不是数据库的日志，而是值 Cloud Service 的操作日志，比如何时对服务进行了启动操作，操作的执行结果（状态），什么时候新建/销毁了某个 MySQL Service 等等。活动页面除了能看日志，还有什 ...继续阅读 (1)

这篇文章主要介绍如何在 Oracle Cloud Service环境上创建 MySQL Database准备阶段命令行终端工具 – 准备 ssh 公私钥证书对用于Oracle在MySQL Instance运行的OS环境的登陆，创建过程中 Oracle 会要求用户提供证书需要有一个 Oracle Cloud Service上的 Storage Cloud Service Container用于在创建过程中所需提供的备份环境的配置，需要该 Container 容器的名字以及对该容器拥有读写权限的用户的用户名和密码。Storage Cloud Service 的配置详见文档：Creating Containers Using Oracle Storage Cloud Service创建操作然后就是具体的创建步骤了进入 Oracle Cloud Service 中 MySQL Cloud Service 控制台http://cloud.oracle.com -> Sign in -> Cloud Account -> My Services，通过导航按钮进入 MyCloud Services 并选择 MySQL Cloud Service通过Create Service按钮进入创建页面页面包含：Service（服务），Detail（详情），Confirm（确认）三个部分组成Se ...继续阅读 (1)

MySQL Database 算是 Oracle Cloud Service 中加入的新成员，这也进一步说明了 Oracle 对 MySQL Database 的重视，同时也大小了一直以来很多人所认为的 Oracle 会放弃 MySQL 而只发展 Oracle Database 的留言。这篇文章主要给大家简要介绍一下 MySQL Cloud Service的概况。在 Oracle 的 MySQL Cloud Service 中，MySQL 是以怎样的一种服务存在的？从 Oracle 官方介绍可以清楚的了解到，MySQL Cloud Service是以一个软件服务提供给我们的，但这个软件服务与目前市面上大量的RDS 云服务存在一个根本性的区别：不仅仅提供了一个独立的 MySQL Database Instance 给我们，同时提供了该 Instance 所运行的 OS 环境权限给我们。这就可以推断出，Oracle 给用户提供的 MySQL Instance 是运行在一个独立的OS Instance 上的，每个 MySQL Cloud Service 客户独享了这个 OS 的资源。当然，如果要使用 MySQL Cloud Service，你光有 MySQL 还不行，还得有配套的计算资源、存储资源以及网络资源。这些资源有些是打包在 MySQL Cloud Service 中，有些是需要单 ...继续阅读 (1)

自增变量一直以来都是MySQL上引以为傲的一个特性。虽然和Oracle的 Sequence相比没有后者灵活，但是使用比Sequence更为简单方便。但是，很多时候的但是总是让人不爽，这里的这个但是也同样会给人带来不爽。当使用InnoDB存储引擎的时候，每次重启都会重新计算出当前表上自增字段实际最大值，并作为下一次分配的起点。这就代表如果大量删除过数据之后，自增值可能被重用。这在很多场景下可能导致问题，包括但不限于：主备切换、历史数据迁移等场景。MySQL 8 将自增值记录进入了redo log，每次重启的时候，通过redo log来恢复上一次的最大值。InnoDB使用一个引擎私有的系统表+特殊redo log的方式，在引擎内部自己解决问题。其大概思路为：当发现索引损坏时，写入一条redo log，但不更新数据词典引入一个innodb引擎私有的系统表，称为DD Buffer Table，每次checkpoint之前会将索引corruption bit存入其中。在崩溃恢复时，同时从redo log和DD Buffer Table中读取索引 corruption bit, 合并结果，并标记内存中的表和索引对象。在该worklog中解决的是corruption bit的持久化问题，但实现的框架也适用于其他目的，例如update_time, auto_inc, count(*)等，因此对代码 ...继续阅读 (7)

以前在做MySQL DBA 的时候，常遇到这样的场景：在数据库运行状态下动态修改了某些配置，但是忘了修改配置文件，结果后面数据库重启之后，之前的修改丢失了。对于做过 Oracle DBA 的同学来说，就完全可以在数据库运行过程中自行控制修改的参数属否要持久化到配置文件中。MySQL8.0 中对这一方面也做了很好的借鉴，学习 Oracle ，也可以针对参数修改做持久化控制了。用户可以选择性的将配置进行持久化。如果需要启用这个功能，可以通过执行SET PERSIST来设定任意可动态修改的全局变量，例如：mysql>SETPERSISTinnodb_flush_log_at_trx_commit = 1; Query OK,0rows affected (0.00sec) mysql>SETPERSISTsync_binlog = 1; Query OK,0rows affected (0.00sec)z 但是有同学可能会发现，这时候如果检查my.cnf文件，好想并没有找到这个修改。其实MySQL是在数据目录下，多了个和之前MySQL版本不一样的文件：$ls-lhmysqld-auto.cnf-rw-r-----1Sky users81Oct1615:09mysqld-auto.cnf文件是JSON格式的， 可以直接用内置的解析器进行解析$cat mysqld-auto.cnf {" ...继续阅读 (17)

MySQL 的权限管理一只以来都是大家所诟病的主要问题之一，最大的问题在于权限系统太过于简单粗暴，对于稍微复杂一些的权限维护就会很复杂。MySQL 8终于在这一方面做了一点改进，给权限系统增加了 Role（角色），总算可以给咱们的权限管理维护人员减低一些工作量了。所谓Role，简单来说就是一个权限集合，这个集合有一个统一的名字，就是Role名。当我们有多个用户需要相同权限的时候，就可以为多个账户创建以恶搞Role，然后再奖Role授予每个账户。这样，当这些用户需要增加或者调整某个权限的时候，并不需要每个用户单独授权，只需要针对Role调整权限就可以达到目的。这在很大成都上方便了权限的维护和管理。Role可以被创建，修改和删除，并作用到其所属于的账户上。下面是简单的测试用例mysql> create database mysql8role; Query OK,1row affected (0.00sec) mysql> use mysql8role; create table t1 (a int, b int, primarykey(a)); DatabasechangedQuery OK,0rows affected (0.00sec) mysql> insert into t1 values (1,2); Query OK,1row affected (0.00sec) 接 ...继续阅读 (8)

等了这么多年，总算等来了这个DBA的福音特性。MySQL8.0开始支持隐藏索引特性，也就是所谓的invisible index。对于不可见的索引，优化器将直接忽略掉。我们可以通过该特性来影响优化器的行为。另外这也可以视为在drop一个索引之前的缓冲，临时把索引设置为不可见后，再观察应用是否正常或有报错什么的，如果一切OK，再最终删除。对应的8.0.0的release note:MySQL now supports invisible indexes. An invisible index is not used by the optimizer at all, but is otherwise maintained normally. Indexes are visible by default. Invisible indexes make it possible to test the effect of removing an index on query performance, without making a destructive change that must be undone should the index turn out to be required. This feature applies to InnoDB tables, for indexes ...继续阅读 (1)

MySQL 8作为目前正在开发的最新版本，目前已经发布了DMR版本，这篇文章主要介绍 MySQL 8 的新特性之一：InnoDB数据字典。 MySQL的核心架构采用统一Server层+不同的底层引擎插件的架构模式，在Server层为每个表创建了frm文件，以保存与表定义相关的元数据信息。但有些引擎（例如InnoDB）本身也会存储元数据，这样不仅产生了元数据冗余，并且Server层和引擎层分别各自管理，在DDL之类的操作时，无法做到crash-safe，更别说让DDL具备事务性了。 MySQL 8 为了解决这些问题（尤其是DDL无法做到atomic），尝试取消了FRM文件及其他server层的元数据文件(frm, par, trn, trg, isl,db.opt)，所有的元数据都用InnoDB引擎进行存储, 另外一些诸如权限表之类的系统表也改用InnoDB引擎。 下面就针对MySQL 8 的这个特性做一些基本的测试，一探究竟。 先创建个新库，并在库下创建两个表来开启我们的测试mysql> CREATE DATABASE mysql8test; Query OK,1row affected (0.00sec) mysql> USE mysql8test Database changed mysql> CREATE TABLE t1 (a int primary key); Quer ...继续阅读 (5)

大约一两个月之前做过一个小调查，大部分MySQL环境目前仍然还是用的MySQL 5.5，占比第二位的是 MySQL 5.6，再然后是5.1，也有不少爱尝鲜的朋友们开始了尝试5.7版本。之前，通过内部邮件了解到 Oracle 最近计划直接将 MySQL 跳跃升级到 MyQL 8.x 版本。为啥会直接做如此大的跳跃性版本升级呢？5.5-> 5.6-> 5.7->8.0?可能一：猜测是如上面的子版本号的变化，只不过是将版本号做了个规则调整而已。可能二：最新的8.0版本对原有 MySQL一直保留的一些基础结构做了较大调整，如彻底放弃 MyISAM，彻底调整数据字典存放方式，对数据库之核心（查询优化器）做了较大调整等等，所以需要在大版本上做一次较大升级。都只是猜测而已，根本原因官方并未对外宣布所以爷不得而知，当然也并不是我们需要特别关注的地方。MySQL 8.0 的变化非常之大，值得所有 MySQL 从业者深入研究，这里我也真对我重点关注的几个特性做一个简单的记录。Storage Engine 层面的改变：彻底放弃MyISAM这一古老的存储引擎，改用 InnoDB存储引擎存储数据字典信息。InnoDB 方面无论在Range Scan 还是 Full Scan 方面都进行了算法优化，较大的提高了扫描性能（类似 Oracle Full Table Scan的优化）Auto In ...继续阅读 (4)

在Oracle Database 12c中，大量新的后台进程被引入进来，很多新特性的实现都和新的进程有关。如：Oracle 12c实现了多LGWR管理，这就引入了LG00-LG99一系列的后台进程；Oracle 12c扩展了多DBWR支持，BW36~BW99，这一列进程都会提高DBWR的写并行；Oracle 12c的多进程多线程模式 – MPMT，引入SCMN进程作为线程监听进程；下表对这些进程做了一定的梳理和说明，供大家参考。进程名全名简要描述详细描述组件范畴AQPCAQ Process CoordinatorPer instance AQ global coordinatorAQPC is responsible for performing administrative tasks for AQ Master Class Processes including commands like starting, stopping, and other administrative tasks. This process is automatically started on instance startup.Database instances Advanced QueueingARSnASM Recovery Slave Process（进程范围 ARS0-ARS9 ...继续阅读 (1)

在Oracle Database 12c之前，翻页查询需要试用rownum的方式进行SQL嵌套查询编写，这非常复杂，在12c中，新增了Top N查询支持特性，允许试用Offset / Limit 等限定进行Top N查询，原来的ROWNUM方式可以被替代。其语法结构大致如下：OFFSET[ROW | ROWS]FETCH [FIRST | NEXT][|PERCENT] [ROW | ROWS][ONLY | WITH TIES]下图是文档语法结构图：如果仅返回TOP 5%的记录，下图中的对比可以看到新语法和原有的查询语句之间的巨大差异：这个新的功能在内部是通过ROW_NUMBER分析函数来实现的，语法类似如下查询，返回经过排序的TOP 5数据内容：SQL> select object_id,object_name from eygle order by object_id2fetch first 5 rows only;OBJECT_ID OBJECT_NAME———- ————————————————–2 C_OBJ#3 I_OBJ#4 TA ...继续阅读 (6)

之前几篇文章都主要都是 DBAAS部分，也就是主要涉及 Oracle Database Instance层面，但 Oracle 在实现 DBAAS 的时候，实际上同时也提供了 Compute 服务，基础设施服务。 这篇文章就体验一下 Oracle Cloude Service 中的 Compute 到底包含了什么？顾名思义，Compute 自然是提供的计算服务了。而 DBAAS 只是软件服务的一种，软件本身运行就必须要计算服务，所以 Oracle 在给我们提供 DBAAS 的时候，同时也提供了 Compute 服务。而 DBAAS 连带提供的 Compute 服务主要体现在以下几个方面：运行 Oracle 的 OS（一台运行 Oracle Linux 的 VM）控制访问的 Network（一套控制网络访问的网络规则）存放数据的 Storage（几个虚拟磁盘卷）自定义 Images（自定义你镜像）业务流程Orchestrations（还没研究明白怎么用）第一部分 Instance 就不用介绍了，就是基本的 OS 相关属性展示介绍。第二部分 Network 之前在体验3 中已经做过介绍，这里也不详细介绍了。第三部分 Storage 主要是指用于运行 Instance 所使用的存储资源，以及运行Oracle Database 和 存放数据所使用的存储资源。在该部分，除了使用系统默认创建的 ...继续阅读 (1)

在Oracle Database 12c中，Oracle引入了多线程模式，允许在Windows平台之外的Unix、Linux系统使用多线程模式，结合多进程与多线程模式，Oracle可以改进进程管理与性能。 先来看一下多进程与多线程模式下，Oracle后台进程的对比。下图是多进程模式：下图是多线程模式下，Oracle数据库启动的后台进程：Multi-process ,Multi-threaded Model 现在作为两种运行模式被支持。如下在Linux系统，缺省的数据库会启动一系列的后台进程：oracle    1727     1  0 Jul11 ?        00:00:57 ora_pmon_core oracle    1729     1  0 Jul11 ?        00:01:21 ora_psp0_core oracle    1731     1  3 Jul11 ?        02:30:26 ora_vktm_core oracle    1735     1  0 Jul11 ?        00:00:24 ora_gen0_core oracle    1737     1  0 Jul11 ?        00:00:11 ora_mman_core oracle    1741     1  0 Jul11 ?        00: ...继续阅读 (5)

在Oracle Database 12c中，可组装式数据库 – Pluggable Database为云计算而生。在12c以前，Oracle数据库是通过Schema来进行用户模式隔离的，现在，可组装式数据库可以让此前意义上的多个数据库一起共存。Pluggable Database 其体系结构的核心是：由一个容器数据库（CDB）和多个可组装式数据库（PDB）构成，PDB包含独立的系统表空间和SYSAUX表空间等，但是所有PDB共享CDB的控制文件、日志文件和UNDO表空间。各个PDB之间互访需要通过DB Link进行，就仿佛是多个数据库一样。在2012 OOW上，Larry重点介绍了Oracle Database 12c 的这个新特性，并将其归结为：多租户数据库。也就是说，在云平台上，不同租户可以在一个大的CDB数据库中运行，而彼此数据（PDB）与应用又完全隔离。显然这个特性对Oracle推出的数据库云平台必不可少。当然，这个特性面临的最大问题仍然是安全问题，如果某个PDB的用户获得了意外的权限提升，则所有用户的数据都可能被暴露。下图是Pluggable Database的体系结构示意图：感谢老盖 ...继续阅读 (8)

数据库 Sharding 目前已经是数据层架构的家常便饭了，随着越来越多的人不断的通过 Sharding 技术来提升数据层的扩展能力，Sharding 本身所带来的各种弊端也开始不断的显露出来了。最近和朋友聊天的时候针对 Sharding 带来的问题做了一些交流，记录之：急于 Sharding，分区键考虑不充分，影响业务发展Sharding 本身是一个需要慎重对待的事情，尤其是分区键的选择。好的分区键会让整个系统基本上对应用没有影响，但是如果选择了一个不合适的分区键，就可能给应用程序带来巨大的麻烦，甚至让有些功能变得几乎不可实现。因为不合适的分区键可能会让本来需要 分组/排序/连接 的数据被拆分分到不同的物理节点，迫使很多原本在一个 Instance 内部的简单处理都无法完成，不得不让应用程序进行大批量IO运算，反而增大的处理成本。应用程序的开发成本上升了，开发效率下降了，业务发展可能就受阻了。过于 Sharding，单机性能过低，造成节点数量过大，维护成本倍增从与一些 DBA 朋友们的交流中了解到，过度 Sharding 也是现在非常常见的一个问题。由于 MySQL 的免费，大家就觉得节点的增加成本较低，扩充节点的性价比非常高，因为不用像 Oracle 那样需要按照 CPU 个数来付 Licence 费用嘛。但事实真的如此吗？可能并不是这么简单。首先，在很多人的意识中，扩展成本只 ...继续阅读 (1)

在Oracle 12c的12.1.0.2版本中，Oracle正式发布和引入了基于内存和列式计算的In-Memory Option （以下简称IMO），这距离Larry在2013年OOW上发布这一特性已经过去了近10个月。以下是IMO特性的原理图，通过在内存中开辟一块独立的区域，Oracle将指定的表或者分区以列式内存存储，但是在存储上，仍然以一份行式存储，这就需要额外的内存空间。当然，内存对于Oracle来说从来都不是问题，为了配合IMO特性，Oracle此前已经推出了SuperCluster M6-32一体机，该服务器满配可以配置32 TB内存，这是一个内存快速扩展的时代：我们来看一下Oracle广为关注的这一新特性的表现。IMO的缺省的参数有：SQL> select name from v$parameter where name like ‘%inmemory%’;NAME——————————inmemory_sizeinmemory_clause_defaultinmemory_forceinmemory_queryinmemory_max_populate_servers在数据库启动时，可以看到SGA中分配的Inmemory Ar ...继续阅读 (7)