分类目录归档：Database

使用VBox 安装 Oracle Database 12c Flex Cluster for OEL 5.8—第2部分 前期准备工作

发表于 2013 年 8 月 28 日 由 Lunar

关于OS，文档有如下介绍： Oracle Linux 6: Oracle Linux 5 or Oracle Linux 4: You should see output indicating that you have subscribed to the Oracle Linux channel, and that packages are being installed. For example: Check the RPM log file to review … 继续阅读 →

发表在 Installation and Deinstall, ORACLE 12C, RAC | 标签为 , , | 留下评论

使用VBox 安装 Oracle Database 12c Flex Cluster for OEL 5.8—第1部分 环境介绍

发表于 2013 年 8 月 28 日 由 Lunar

由于Oracle Database 12c的 Flex Cluster需要使用DNS来解析GNS，因此必须配置DNS server。然后需要使用GNS动态分配SCAN和VIP，因此需要配置DHCP server。 Flex Cluster内置Flex ASM，因此，需要配置共享存储。 好了，我们需要的大致工作如下： 1，安装（或者复制）2个VBox虚拟机，建议使用 OEL 6.3以上版本，具体参见文档（参考支持版本的说明，OEL 5，OEL6都可以） 2，配置共享盘，配置yum安装需要的package 3，配置DHCP SERVER, DNS SERVER, GNS 4，规划网络，确定具体IP。12c只需要在host中指定Public和Private IP即可，至于VIP和SCAN都是由GNS来分配的，而GNS需要在DNS中解析。 5，安装GI 6，调整asm的sga，建议每个asm的sga256M足以，然后重启crs 7，安装DB（推荐DBCA建库，注意建库时指定sga的分配采用全手工方式，既非AMM亦非ASMM，这样经过测试一个db只需要230M到300M就可以跑的很好了，没办法，穷人，你懂的…………） 具体见:使用VBox 安装 Oracle Database 12c Flex Cluster for OEL 5.8—第1部分 环境介绍

发表在 Installation and Deinstall, ORACLE 12C, RAC | 标签为 , , | 留下评论

Linux误删除文件并且数据库crash后恢复

发表于 2013 年 8 月 21 日 由 Lunar

我们都知道误删除文件后，如果没有其他操作，且数据库没有crash（句柄还在），那么是可以通过fd找到文件进行数据库恢复的，具体可以参考以前的文章：linux 误删除文件恢复 那么，如果句柄已经释放（比如数据库crash了），且客户重启了数据库，并执行了一些“恢复”尝试，然后怎么办？ 我们测试下，这里我们要借助一个小工具：ext3grep 该工具可以在下面的网址下载最新版： http://code.google.com/p/ext3grep/downloads/list 系统必须要有e2fsprogs-libs，否则安装ext3grep的时可能会有问题。 如果你下载了rpm包，那么安装so easy: 如果你下载了src的源码，那么可以如下方式安装： 我们看下他的帮助，还是很强大的： 模拟数据库文件被误删除，且数据库crash： 数据库启动报错，丢失了文件 ‘/oradata/orcl/users01.dbf’。 现在使用ext3grep进行扫描和恢复： ext3grep是针对ext3文件系统的（ext2单有自己的扫描恢复工具），确认丢失的文件是ext3文件体系: 这里，我的数据文件都在/oradata，是设备 /dev/sdc1 ： 注意这里，我的数据库目录的inode是 4358145 ，下面我们开始从这个inode继续查找： 文件的inode已经被覆盖了 这里根据两个两个信息进行恢复文件的操作： （1）数据库报错告诉我们需要恢复的文件名称：/oradata/orcl/users01.dbf （2）ext3grep的提示信息告诉我们了从哪里开始写文件： Inode 4358145 is directory “orcl”. 恢复过程如下： 从上面提示我们看到了文件已经恢复出来了，放在 orcl/RESTORED_FILES 下面： 完了不行了，被覆盖了。。。否则这一步就会在当前执行ext3grep的目录下找到一个RESTORED_FILES目录，里面就是我们的user01.dbf文件，再之后，你懂的。。 把他copy到/oradata/orcl/users01.dbf，然后执行recover datafile ‘/oradata/orcl/users01.dbf’，在open，就ok了。。。 我们再测试另一个工具extundelete（感觉原理跟ext3grep一样），看看他是不是强大一些，o(∩_∩)o … 继续阅读 →

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

ASM磁盘头被fdisk损坏的修复过程

发表于 2013 年 6 月 16 日 由 Lunar

一大早起来折腾昨天的12c（我装的是standalone），发现使用文件虚拟成设备的方法，磁盘IO效率很低（我猜是这个原因），于是铲掉打算重新安装 铲掉12c RAC跟铲掉11.2 RAC没啥区别，参考前面的文章 5分钟内搞定。 安装完grid，感觉磁盘不够用，于是把vm停了，加一块新的盘，然后启动后，fdisk /dev/sde 悲剧了，刚弄完就想起来，这个是ASM的DATADG…………于是，你懂的…… 查看日志,ora.DATA.dg 资源状态异常： 使用kfed可以清晰的看到，盘头损坏了： 在ASM中也可以看到，/dev/sdb原本是DATA DG的设备（HEADER_STATU应为 MEMBER），现在确变成“CANDIDATE”： 我们知道，每个ASM磁盘的UNIT 1，块254（Allocation unit# 1, Block# 254）是盘头的备份，因此查看下，这个块是否是好的： 手工把ASM磁盘组DATA挂载上： 好了，可以安装db软件，然后建库了…………

发表在 ASM, backup&recovery | 标签为 , | 一条评论

Linux下手工卸载11.2 RAC(非MOS的deinstall方法)

发表于 2013 年 6 月 13 日 由 Lunar

用了下11.2的deinstall卸载慢的很，熬人，自创了一个，感觉很好，5分钟内搞定，可以稍微改改，写成脚本，o(∩_∩)o 哈哈 思路来自于经典的《How to Proceed From a Failed 10g or 11.1 Oracle Clusterware (CRS) Installation (Doc ID 239998.1)》 补充了一些11.2特有的内容。 下载11.2 RAC的官方方法： How to Proceed from Failed 11gR2 Grid Infrastructure (CRS) Installation (Doc ID 942166.1) 本次没有采用这个方法，其主要是执行deintall脚本，但是我的环境中，执行时间很久，不喜欢……………… 以下是一个节点的，2个节点也一样： 最好先执行这个： 当然，按照我下面的，不执行也没有问题…… 检查是否还有 d.bin … 继续阅读 →

发表在 Installation and Deinstall, RAC, Scripts | 标签为 , , , | 2 条评论

linux 误删除文件恢复

发表于 2013 年 6 月 3 日 由 Lunar

创建测试表空间 创建表插入数据 删除datafile 数据还在，因为从buffer cache中读到的 执行flush buffer cache 可以看见，再次查询，报错文件状态不对了（找不到了） 检查dbwr进程的spid 找到dbwr的句柄 进入dbwr进程的File Descriptor number目录中 恢复过程 检查下，文件已经恢复完成，大小为10m 将数据文件offline 恢复datafile 将数据文件online 好了，完成恢复了

发表在 backup&recovery | 标签为 , , | 2 条评论