月归档：2014 年四月

浅谈Oracle非常规恢复

发表于 2014 年 4 月 27 日 由 Lunar

一直以来，类似非归档无备份的数据库损坏，或者备份不可用，或者用备份恢复因为时间太长或者空间限制等等原因制约，非常规恢复一直是我们不能扔掉的救命稻草，在这个方面我并不擅长，但是一直都很喜欢。 记得2001年前后，我第一次有兴趣想要认真学习一下Oracle（以前做开发相关比较多，菜鸟dba），在还没有了解Oracle备份恢复的机制时，忘记为什么首先接触了Oracle 817的Standby，一周内完整的读了一遍文档，动手搭建了两个，并记录在ITPUB和我自己的blog上，很有成就感，而那时，我还没有意识到，其实Standby 的本质就是数据库的备份和恢复的完美结合。 后来有机会作为dba参加一个公司（在当时没觉得公司小，但是只有我一个菜鸟dba，O(∩_∩)O哈哈~）的一个海外项目，是做一个3节点Oracle 817 OPS 克隆数据库的事情，当时我还不熟悉RMAN，使用dd裸设备的方式完成了任务。这个项目之后，我开始迷上Oracle的备份和恢复，并且开始玩rman了。 迄今为止，我还是认为数据库备份恢复是学习Oracle的最佳入口，因为很多时候你可以方便的模拟场景，并研究恢复，在一个个案例中，学习和了解更多internal的原理。当然，任何时候官方文档都是第一步，没有这个基础，很多都如同空中楼阁。 还有一点，一个好的架构设计、备份恢复策略和灾备设计都是最好的选择，这个是毋庸置疑的。 但是中国大量D版客户，尤其是小客户中太多情况下是没有专业的设计，出了问题，非常规恢复的手段就是救命稻草了。 下面的ppt就是去年一个客户在备份不可用的情况下，花“巨资”请人做了非常规恢复后，找我们去做的一次交流，客户要求的主题就是“非常规恢复”： 浅谈Oracle非常规恢复-lunar

发表在 backup&recovery, Internal | 标签为 , , , , , , | 留下评论

Exadata的磁盘自动管理-3-磁盘自动管理的操作规则

发表于 2014 年 4 月 22 日 由 Lunar

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息 Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念 Exadata的磁盘自动管理-3-磁盘自动管理的操作规则 磁盘自动管理的一些条件和限制： 1. Griddisk 的状态改变时（OFFLINE/ONLINE）： 如果一个griddisk的状态变为临时不可用（temporarily unavailable），那么它会在ASM中被自动的变更为OFFLINED。 如果一个griddisk的状态变成可用的（available），那么它会在ASM中被自动的变更为ONLINED 2. Griddisk的DROP磁盘的操作 如果一个物理盘（physicaldisk）失效了，所有在这个物理盘之上的griddisk都会在ASM中自动的以FORCE选项DROP。 如果一个物理盘（physicaldisk）的状态变为’predictive failure’，所有在这个物理盘之上的griddisk都会在ASM中被自动DROP。 ‘predictive failure’的概念参见前面的《Exadata的磁盘自动管理-1-读懂cell alert的磁盘信息》 如果一个flashdisk出现性能降级，相应的griddisk都会在ASM中自动的以FORCE选项DROP。 3. Griddisk的ADD磁盘的操作 如果更换了一个物理盘，该物理盘上对应的celldisk和griddisk都会被重新自动的创建，并且在创建后自动的加入到ASM中。当然，这个是要求换盘之前这个盘是完全自动管理的，也就是之前他是被自动的在ASM中drop的。 如果手工的drop了griddisk（不带force选项），那么就需要手工的将盘加回到ASM中。 如果griddisk是NORMAL状态，并且在ONLINE模式，那么使用FORCE选线drop了磁盘（这个模式通常必须使用FORCE选项），他也会被自动加回到ASM中。 4. 对CELL进行rolling upgrade时，Griddisk 的状态发生改变：OFFLINE/ONLINE Before the upgrade all griddisks will be inactivated on the storage … 继续阅读 →

发表在 内部机制 | 标签为 , , , , , | 留下评论

Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念

发表于 2014 年 4 月 22 日 由 Lunar

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息 Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念 Exadata的磁盘自动管理-3-磁盘自动管理的操作规则 首先明确一些Cell上各种磁盘相关的概念： 每个cell上有12块Physicaldisk，每个盘的容量相同，目前，X2的可以有600GB, 2TB和3TB（2T盘已经停产了），X3的只能有600GB和3TB，X4可以有1.2T和4T盘。 每块物理盘对应一个LUN（前面的2块盘，分别会划去一部分空间用来管理OS。后面的10块盘分别直接对应一个LUN），每个LUN对应一个CELLDISK。 每个cell上前两块盘的前面42G左右的空间做成软RAID1，后面的557G空间和其他10块盘使用方法一样，都是作为一个独立的celldisk的。 注意，celldisk是一个逻辑盘的概念。 这个信息在cell的配置文件中有明确说明 ： 还可以使用下面的命令查看celldisk的容量： [root@dm01cel11 ~]# cellcli -e list griddisk where celldisk=CD_02_dm01cel11 attributes name,size,offset 每个cell上有16个Flashdisk（每个cell上4个PCI闪存卡，每个卡上集成4块flashdisk），X2是每个24G，X3是每个100G，X4是每个200G。 每一个Flashdisk对应一个Flash LUN，每个Flash LUN对应一个Cell Disk。 普通硬盘，即disktype=HardDisk的盘上创建的Celldisk缺省命名为CD_00_cellname,CD_01_cellname, …CD_11_cellname 基于FlashDisk的盘，即disktype=flashdisk的盘上创建的Celldisk缺省命名为FD_00_cellname, FD_01_cellname … FD_15_cellname. GridDisk是一些创建在一个或者多个celldisk上的逻辑盘。在Exadata的标准安装流程中，Griddisk只是使用基于硬盘创建的celldisk，而不使用基于Flashdisk创建的celldisk。 一般我们使用基于flashdisk创建的celldisk来做flashcache和flashlog。 在Exadata环境中，ASM DISK其实就是一个的griddisk。 在Exadata的标准安装中，一般会创建3个磁盘组，其中DATA DG和RECO … 继续阅读 →

发表在 内部机制 | 标签为 , , | 留下评论

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息

发表于 2014 年 4 月 22 日 由 Lunar

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息 Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念 Exadata的磁盘自动管理-3-磁盘自动管理的操作规则 从11.2.3.2.x开始，系统可以自动识别磁盘性能下降，并自动从当前配置中移除。 出现性能下降的磁盘会影响系统整体的性能表现，因为所有的工作负载是平均的分布到所有的磁盘的。 举个例子，如果一个磁盘有相对于其他的磁盘有30%的性能下降，那么整体的系统IO能力就会下降30%。 当检测到磁盘性能下降时，系统自动从当前配置将该盘移除。Exadata会执行一些列性能测试，如果这个磁盘的问题是临时问题，那么系统会自动将其放回原来的配置中。如果这个磁盘不能通过测试，那么就会被标记为性能不佳（pool performance），并自动开启一个ASR(Automatic Service Request)来请求更换磁盘。 这一特性对于硬盘和flash盘同样有效。 说到Exadata的IO能力和管理，必要要提到众所周知的CELLSRV。 CELLSRV是Exadata上存储服务器的主要组成部件，它是一个多线程服务器，主要针对简单的块请求和智能扫描请求（如投影和筛选的表扫描等）提供服务，另外，CELLSRV也与DBRM协同工作来计量各种数据库和客户组在发送IO时所用IO带宽。 CELLSRV收集与操作相关的大力统计信息。Oracle数据库和ASM进程使用LIBCELL和CELLSRV通信，LIBCELL使用iDB协议将IO请求转换为要发送给CELLSRV的消息。 CELL上跟IO相关的主要进程还有MS和RS。 MS(管理服务器)，MS提供Exadata cell管理和配置的功能。它与命令行界面CELLCLI协同工作，每个CELL有CELLCLI进行单独管理。 CELLCLI是一个本地化的管理工具，也就是说他需要在某个特定CELL中管理该CELL。 不过，在Exadata上，可以用dcli实现远程地对多个CELL运行同一个CELLCLI命令来达到集成管理或者统一管理。dcli是一套集成的工具包，本质是通过SSH进行集成管理，可以单独配置（比如你自己有很多非Exadata的linux环境，可以根据需要配置dcli）。 另外，在CELL上，除了CELLSRV负责收集主要的统计信息外，MS也负责发送警报和收集其它统计信息。 RS（重启服务器），RS用于启动和关闭CELLSRV和MS服务，并监控这些服务进程的状态，在必要时负责重新启动cellsrv和ms。 前面说到CELLSRV会自动检测磁盘的性能，并自动更改配置。当CELLSRV检测到磁盘性能下降时，cell disk的状态就会更改为’normal – confinedOnline’，物理盘的状态更改为’warning – confinedOnline’。 这意味着磁盘已经进入了性能表现不佳的第一个阶段，这个阶段是个过渡阶段，磁盘状态不会停留在这个阶段很长时间。 通常磁盘的常见状态会有4种： HEALTH_BAD_ONLINE HEALTH_BAD_OFFLINE HEALTH_GOOD HEALTH_FAIL 这些检测和状态的变化，会有CELLSRV记录到alert中，例如： 同样的信息，在alerthistroy总也有可以观察到： 我猜测，上述信息是通过类似：下面这样的命令完成的： list griddisk attributes … 继续阅读 →

发表在 内部机制 | 标签为 , , | 留下评论

SAP 产品的发展史

发表于 2014 年 4 月 12 日 由 Lunar

最近发现SAP很有意思，就像多年前发现oracle很有意思一样（oracle产品，其实现在也很有意思，不过有些东西貌似回不去了……比如，OGG又大又胖了，当然，他一定力气更大了吧，O(∩_∩)O哈哈~） 这张图是SAP ERP的架构和大致的发展史。 1992年，SAP发布了SAP R/3 系统，数据库是Oracle 7.0，最初的SAP（SAP R/3 4.6 Core之前）只有两部分内容，即SAP Basis和Application。这时的SAP Basis使用ABAP语言编写的。 从产品结构看，猜测这个是一个嵌入式的架构（具体我也不懂，纯猜测）。 那时ORACLE跟SAP是好兄弟，共同闯荡江湖，在一些领域相依相偎不过分吧，O(∩_∩)O哈哈~…… 我个人感觉ORACLE第一个成熟的RDBMS是1996年发布的ORACLE 7.3（1994年release了ORACLE 7.1,1995年release 7.2），这个版本ORACLE有了Standby，直到今天，这个功能也是我个人认为非常有价值和成熟的功能，也是平时给客户做容灾方案和实施时可能条件下的首选方案。 到了1998年，SAP发布了第一个SAP BW（Business Warehouse），而这前一年，Oracle 8 带着OPS(Oracle Parallel Server，RAC前身)、Partiton table和Partiton index、基于时间点的RMAN恢复等等荣耀发布。 不知道是哪一年，SAP发布了使用ABAP开发的SAP R/3 Enterprise Core 4.7，这时的体系架构，看样子已经是两层结构了，这里的SAP Web Application Server 6.20也就是以前的SAP Basis。 我的理解是，从这时起，应用服务器和应用剥离了。在这个版本上，SAP开发了更多的行业解决方案，他们被部署在Enterprise Extensions之上。 那时候还没有SAP … 继续阅读 →

发表在 SAP | 标签为 | 留下评论

密码保护：Exadata预安装的环境需求-网格规划

发表于 2014 年 4 月 2 日 由 Lunar

无法提供摘要。这是一篇受保护的文章。

发表在 安装和升级 | 标签为 | 要查看留言请输入您的密码。