search 2013 adfgs

在 Oracle Cloud Service 体验系列文章中,之前已经介绍了三篇文章,分别对应 Oracle Cloud Service 的 概览,Create Instance 以及 网络配置。 本文将介绍在 Oracle Cloud Service 中的 DBAAS控制台中提供的 Oracle Instance 基本管理功能,比如 Apply Patch。 首先,从我们的 Instance 列表中选择一个需要维护的 Instance,如下图: 上图是 Instance 列表,在截图之前点开了右侧操作选项列表页。 我们从图中可以看到,可以进入 EM 管理页面,也可以进入Express 控制台和 DBAAS 监控台。此外,还有 SSH 访问信息展示页(用于增删ssh key),同时还有到网络配置的快捷入口。 下面我们看看通过点击左侧实例名称后的界面: 这就是点击实例名称之后进入的页面,可以看到主要分为2个部分: 概览信息 包括概要信息(无力配置信息以及资源暂用情况) 节点信息(RAC会有多个节点) 其他基础信息(实例在云服务中的各项信息) 管理信息 补丁信息 通过补丁列表,我们可以非常直观的了解到当前Instance 有哪些重要补丁,同时每个补丁都有具体介绍,以及应用补丁是否需要重启等信息。 每个补丁列表右侧有一个操作按钮,可以打开进行 Precheck 操作 和 Patch […]

,

很久没有直接看 Oracle 相关的内容了,前段时间收到 Oracle 赠送给 Oracle ACED 关于 Oracle Cloud Service 为期1年的的体验邀请,于是决定看看 Oracle 官方提供的数据库云到底如何。 初步体验之后发现与自己预想还是有很大不同,所以还是决定写出来分享一下。由于 Oracle Cloud Service 提供的云环境相对比较复杂,所以可能会以一个系列的方式来展现,这里就以一个使用者的角度,先看看 Oracle Cloud Service 的概貌。 从 Oracle Cloud Service 首页能看出,Oracle 云服务主要分为3部分: 软件即服务(SAAS/DAAS: Software as a Service),主要是 Oracle 旗下各种管理软件的云服务,包含以下多种服务: 平台即服务(PAAS: Platform as a Service),主要包 Oracle 旗下数据库、开发环境及应用容器等服务,主要有以下云服务: 基础设施服务方面,以计算资源为主(IAAS: Infrastructure As a Service) 由于我这里主要关注的是数据库相关云服务,所以下面我主要体验了 Oracle 数据库相关云服务(注:目前 Oracle 云服务上还没有 MySQL 数据库相关服务)。 […]

, ,

今天,Oracle(甲骨文)公司的 Oracle Open World / Java One / Oracle Developer 北京大会今天开幕。 大会从13号到16号,共4天,今天上午主要是大会注册时间。由于参会人员众多,Oracle 安排了半天时间用于参会者注册报道。我较早就到达了现场,看到为排队准备的临时隔离绳早已准备好,还有十多个安检通道。看这阵式,等下的注册场面一定很火爆。 今年的大会上,OTN 组织了一次 Oracle ACE 大聚会(OTN Lounge),并有精彩演讲安排。我在里面也安排了一个主题演讲,安排在 15 号(周三)上午。此外还有 Oracle 数据库方面的很多专家如冯春培,盖国强,楼方鑫,张乐奕等,还包括阿里巴巴公司一位经常与我协作的高级 Java 工程师 贺贤懋。 OTN Lounge 的具体日程安排如下:

, ,

为了对核心技术拥有更多的自主控制能力,为了解决数据库的线性扩展问题,为了尽量减少对商业软件的依赖,为了摆脱对高端硬件的依赖,为了… 基于以上多种原因,2年前,我们计划将公司某核心应用平台进行大手术:数据库平台从软件到硬件全部重构。当然,这其中应用架构的改造也不可避免的进行了大换血。 这个项目无论是从技术角度还是是业务角度来说,都对我们有着非常大的价值,也必定会带来非常深远的影响。项目历时2年多,分4个阶段才完成: 应用接口统一 这一阶段主要是为了后面真正迁移的时候做准备工作,将该核心应用系统的所有数据访问入口统一到一起,全部以服务化的接口方式呈现给其他有需要的系统,一来方便后续变更的控制,二来也推进了服务化的进程。 Oracle数据库中拆分(1拆16) 这个阶段本不是必要的,但是由于项目启动稍微晚了点,数据出现了爆发性增长,导致该系统的数据表太大(单表不带索引过500GB),原 Oracle 数据库已经快撑不住了。为了安全起见,先在 Oracle 中从一个主表以会员ID进行 hash 运算后再进行水平拆分,从1个表分拆成了16个。附表由于访问量稍小,而且全部是根据主键访问,暂时保留原样。 当然,这样的水平拆分,必然会带来数据访问路由以及数据合并的问题。我们专门为此开发了具有分布式数据库路由/数据合并,数据库读写分离,数据库链接管理等功能的数据访问中间层,专门解决拆分后给应用服务器带来的影响,使得应用服务器完全感受不到后端数据库的变化。 这个数据访问中间层,对前端应用服务器来说,就是一个完整的数据库,所有数据请求都从这里实现,以协议的方式和前端应用服务器的jdbc驱动进行交互,以便让数据库对应用服务器彻底透明。 Oracle迁移至 MySQL(16拆128) 这个阶段是整个阶段中历时最长,复杂度最高,风险系数最高的,未知因素也最多的一个阶段。虽然 MySQL 数据库已经在互联网行业占据了大片江山,但是对于阿里巴巴来说,却仍然是一个新鲜玩意儿,因为之前我们一直都用 Oracle 来提供所有的业务系统的数据库服务。 在此之前,我们从来没有在如此核心业务系统的数据库上使用过 PC Server 和本地硬盘来承载数据库,一直是使用 IBM 小型机和中高端存储设备来解决高性能和高可靠的问题。在更换成 PC Server 和本地硬盘来承载数据库之后,我们就必须面对 PC Server 本身硬件可能存在的不可靠性所带来的 Crash,所以我们必须有一套完善的 HA 切换机制,要比小型机厂商所提供的商业 HA 管理软件更加高效更加自动化更加可控,才能我们降低了设备本身可靠性之后达到原有的可用性要求。 对于一个需要满足 365 * 24 * 7 的核心业务系统来说,肯定是不可能给我们太多时间来进行数据迁移的,所以我们不得不设计出一个对现有系统影响尽可能小的迁移方案,这势必会造成方案的高度复杂化,带来更多的风险。最后的迁移方案要经历如下4个阶段: 1. Oracle 读/写;;MySQL 初始化并增量写 2. Oracle 读/写; MySQL 写 […]

, , ,

在 IT 行业很多工程师(尤其是很多 DBA)的心目中,都把小型机视为解决性能问题的终极武器,认为小型机的处理能力要远大于 PC Server。在几年前,可能也确实是这样。但随着近几年 X86 架构芯片技术的飞速发展,PC Server 的处理能力已经越来越强悍,不断的给我们带来惊喜。 最近几年的小型机市场,基本上被 IBM 吃掉了大部分。虽然可能并不完全是因为其 Power 芯片处理能力与其他厂商的芯片相比有优势,但其处理能力方面的优异表现确实是一个很重要的因素。所以最近几年我们一直关注着 IBM 小型机与其他主机的处理能力比较,当然比较是基于 Oracle 数据库所做的一些测试。 测试基本模型如下: 在待测主机上安装好 Oracle 数据库,配置足够装载下所有数据的 SGA,将 Oracle 的 Redo 日志放在内存文件系统上。然后在我们技术能力范围内对 Oracle 进行相应的调优。 使用我们真实的线上数据抽样(约10GB),Import 进入待测试主机上的 Oracle 数据库中。 通过 PL/SQL 编写出模拟我们在线业务中最为典型的事务逻辑,然后使用C++编写多线程程序作为压力测试客户端。 通过多台主机运行压力测试程序,平缓的给待测主机增加压力,待测主机的 CPU 利用率基本用完为止。 测试数据的收集主要通过恒定时间段的 Oracle 数据库自身性能数据采样(statspack),然后分析 statspak 中的每秒事务数。以往经验显示,基本上当客户端压力线程到达一定数量之后,处理量就比较稳定甚至下降。然后我们从中取出每秒事务数的最大值,做为该机器的处理能力分值。 这个测试模型主要消耗的资源是主机的 CPU + RAM 的能力,而且当初也得到了 IBM 实验室的人认可。 通过这几年对几种主机处理能力跟踪测试情况来看,IBM Power 芯片的优势已经越来越不明显了,甚至其 […]

, , , , ,