分类目录归档：安装和升级

Exadata X5-2数据库服务器上跟换内存条的测试

发表于 2015 年 5 月 8 日 由 Lunar

今天系统组的同事测试了一下Exadata X5-2数据库服务器上的内存能识别的种类 因为目前公司富裕的内存条只有“Hynix Semiconductor” DDR4 16GB的，因此，就测试的这个，结果是可以识别，没有问题。 这个也在情理之中，因为Exadata的cell节点上也用这款内存条： 上面的另一款samsung的就是比较标准的高端内存条了，不过16GB的，网上查了不贵，1k~2k RMB，但是貌似32GB的DDR4 SAMSUNG的很少见…… . 这里我同事把服务器上原有的8跟32GB samsung DDR4 2133内存条换掉，插入了12根Hynix Semiconductor的DDR4 16GB和 4根samsung DDR4 16GB内存条，结果服务器识别没问题： 顺便说一下cell节点的内存设备信息： 存储节点上使用的内存条种类：

发表在 安装和升级 | 标签为 , | 留下评论

Exadata X5-2服务器上扩内存或者更换内存的详细步骤

发表于 2015 年 5 月 8 日 由 Lunar

Exadata X5-2服务器上扩内存或者更换内存的paper研究 Exadata上服务器内存条的使用限制： 1， 服务器支持3种类型的内存条： （1）32-GB quad-rank (QR) Load-Reduced DIMMs (LRDIMMs) （2）8-GB single-rank (SR) 或者16-GB dual-rank (DR) Registered DIMMs (RDIMMs) 2，不能混用前面两种，即要么都是32-GB quad-rank (QR) Load-Reduced DIMMs (LRDIMMs)，要么都是 8-GB single-rank (SR) 或者16-GB dual-rank (DR) Registered DIMMs (RDIMMs) 3，根据文档，更换内存条的过程是：Within a memory channel, DIMMs … 继续阅读 →

发表在 安装和升级 | 标签为 , , | 留下评论

Exadata X5-2服务器上扩内存或者更换内存的paper研究

发表于 2015 年 5 月 8 日 由 Lunar

根据Oracle白皮书的记录，Oracle Sun Server X5-2数据库服务器的配置如下： 注意上面： 256GB DDR4-2133 RAM (8x 32GB DIMMS; Memory Expansion kit provides up to 24x 32GB DIMMS in groups of 8) 也就是每台数据库服务器出厂缺省配置是256GB内存（8个32GB DIMM，具体型号是 DDR4-2133 RAM），可以扩展到最大24*32=768GB LRDIMM是较新一代的内存设备，能够保证即使在单条内存32GB容量甚至更高的情况下，服务器上每个内存通道依然能够布满至3条内存条 这里的8组(P0：CHA,CHB,CHC,CHD P1：CHA,CHB,CHC,CHD)，也就是每组上面可以最多插入3根内存条，因此一共可插入24跟内存条，每个内存条32GB 具体如下图： 在服务器上如何查看当前内存的使用情况呢： 当前已经插入的内存条有8根，每根都是32GB：32*8=256GB 服务器上每个CPU支持的一对内存模块最多内存容量为192GB（6*32GB）： 服务器上每个CPU支持的一对内存模块最多内存插槽为6个： 24*32=768GB，也就是当前系统最大可以插入24根32GB的内存条，也就是最多支持768GB内存： 内存频率是2133： 全部内存信息如下： 具体更换步骤参见 … 继续阅读 →

发表在 安装和升级 | 标签为 , , | 留下评论

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

发表于 2014 年 4 月 2 日 由 Lunar

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

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

为Exadata 服务器创建共享文件系统（DBFS）

发表于 2014 年 3 月 17 日 由 Lunar

DBFS是Oracle 11.2的新特性，他提供了在Linux操作系统中将Oracle的ASM数据库映射成文件系统来使用的功能。操作上的文件在DBFS内部是以SecureFiles LOBs（SecureFiles LOB是11.1的新特性，对比与以前的BasicFiles LOBs，Oracle称SecureFiles LOBs为全新设计的LOBs）的形式存储在数据表中。由于篇幅关系，这里不详细描述SecureFiles LOBs了。 其配置过程非常简单，具体参见MOS: Configuring a Database for DBFS on Oracle Database Machine [ID 1191144.1] List of Critical Patches Required For Oracle 11.2 DBFS and DBFS Client [ID 1150157.1] 在Exadata上数据库节点的本地磁盘空间是有限的，因此，在做数据加载时，我们需要想办法使用更大的空间来存放数据（以便后续加载到exadata上的数据库中），通常，DBFS是一个很好的选择。 如果经常使用的话，写一个shell自己动完成所有过程，测试过，也就是几分钟，O(∩_∩)O哈哈~。 下面详细讲解一下配置的过程： 配置DBFS 文件系统 为Exadata 服务器创建共享文件系统（DBFS） … 继续阅读 →

发表在 FAQ, 安装和升级, 日常运维 | 2 条评论

Exadata上的手工创建celldisk，griddisk（比如手工增加一个cell节点）

发表于 2014 年 3 月 12 日 由 Lunar

一个客户，因为现有的一台Exadata要从一个地方搬迁到另一个地方的机房，因此机器中所有部件的IP都需要修改（ILOM，SWITCH，DNS，NTP SERVER，VIP，SCAN，PDU等等）…… 这些都可以修改IP的方式完成，也并不复杂。 但是，考虑到机器上以前部署了很多应用（包括SAP的一些东西），本地空间凌乱且空闲不多。 因此，给客户的解决方案： 1，机器不用重刷，只更改相关IP 2，重装RAC(GI和Database) 3，安装Bundle Patch和SAP需要的patch 清理已经的RAC环境很简单，参考我以前写的一个《Linux下手工卸载11.2 RAC(非MOS的deinstall方法)》 类似这种方法，在11.2以前，是常用的，简单干净，O(∩_∩)O哈哈~ 顺便也提一下，《AIX环境下11.2 rac的快速卸载脚本》 下载环境并重新安装时，发现可用的找不到ASM盘，客户想起来清理环境的时候忘记先删除ASM磁盘了。 这里我们说下，ASM中，如果不指定asm_diskgroups和asm_diskstring（比如现在，我们重新安装），那么ASM在不同平台会按照缺省路径来扫描磁盘。 具体请参考：Default Disk Discovery Path by Platform (Doc ID 1389618.1) 缺省平台的扫描路径： Operating System Default Search String 那么Exadata呢，我猜它的缺省路径是o/cell_ip/* 。 例如，我这里是Exadata的VM，asm_diskgroups和asm_diskstring都为空，ASM启动没有问题，因为他按照缺省路径已经扫描到了需要的磁盘组和磁盘信息：   下面的图，更加清晰，所有盘都不在Candidate Disk中，也就是以前划分的cell上griddisk都不可用： 因为没有清理磁盘头，这些盘被ASMB进程扫描到了，也就是以前我们常说，11.2开始，重装RAC后，ASM和数据库都可以手工保留以前的状态，如果以前数据库和ASM是完好的，那么重装完成后，ASMB进程将信息注册到CSS中，数据库直接识别到ASM磁盘，因此，直接手工启动数据库就可以（如果要crs启动，那么必须使用crsctl命令将asm和db都注册到crs中）：  现在，我们需要手工的删除griddisk，celldisk等等，然后手工创建这些盘…… 我们都知道Exadata上使用onecommand来创建celldisk和griddisk的时候，是按照磁盘效率分布不同的数据的，比如数据库文件需要较高的访问效率，而用来存放归档和备份的磁盘组则需要不那么高的访问效率，这些是通过创建cell的时候指定offsize来实现的。 … 继续阅读 →

发表在 安装和升级, 日常运维 | 标签为 , , , , , | 留下评论

Exadata上本地盘的使用（reclaimdisks.sh）

发表于 2014 年 3 月 12 日 由 Lunar

Exadata出厂时，其计算节点本地有4块盘，两两做RAID 1，安装了双OS，一个是Linux，一个是Solaris X86（不是Sparc，O(∩_∩)O哈哈~） X2是每块本地盘300G，从X3开始，每块本地盘600G。 多出一个没用的OS，这样就浪费了很多空间，因此，安装或者重装后，一般都做Reclaim的操作，将出厂时的双OS改为单独的Linux系统启动，并释放空间。 例如这里： 这里显示当前4块本地盘，做了双启动系统，每两块盘做了RAID 1，没有Hot Spares盘 使用reclaimdisks.sh -free -reclaim可以更改为一个单独的系统，大部分客户会选择使用Linux，例如： reclaim的过程大概2小时左右，完成后的结果类似下面： 这里，我们看到，4块本地盘，一个做了Hot spare disk，其余3块做RAID5，只有一个Linux OS了。 这样就把以前Solaris X86 OS 的空间释放出来了，但是这部分空间缺省并没有自动mount上，你需要手工的mount上，或者自己使用LVM扩充到根目录（/）或者非根目录（比如/u01等等），或者扩到Swap区。 例如： 这里我们看到做完reclaim后，释放出来400G左右的空间，这个是X2，每块本地盘300G。 如果是X3，每块本地盘600G，做完reclaim后释放出来600G左右的空间，就类似下面的样子： 现在你就可以使用lvm lvexten等命令，将这些空间扩到你需要的放了，O(∩_∩)O哈哈~。

发表在 安装和升级, 日常运维 | 标签为 , | 留下评论

Exadata 的4种刷机方法——Reimage

发表于 2014 年 3 月 10 日 由 Lunar

明天又要刷机器了，装机工很久没玩，快忘光了，温习一下，O(∩_∩)O哈哈~ 1，刷机前先检查和保留当前系统关键部件的信息，例如： 2，跟NOTES 888828.1的内容，找到相关的image，download后，解压，例如： unzip ImageMaker.tar.zip tar -pxvf ImageMaker.tar DB的image解tar后，可以发现 dl360 目录 CELL的image解tar后，可以发现 dl180 目录 这是因为，Exadata早先跟HP合作推出的V1，用的都是HP的pcserver系列，计算节点的型号是 dl360，存储节点的型号是 dl180，后来也就一直都没有更改了。 我们有四种方式刷机： 1. 用U盘刷机，也就是 USB flash thumb drive 2. 制作ISO image，使用ILOM指定iso的方式（当然如果刻录成光盘，也可以使用DVD模式） 3. 制作一个紧急启动的iso文件（类似于紧急启动盘），然后把image放在NFS上，进行刷机 4. 使用PXE+NFS 上面的4种方法，对于1/4配置来说，哪个都不复杂，用U盘和ISO Image最简单，也最省心。 对于满配或者大量的reimage工作来说，显然U盘就太不可取了，会累死人的，可以使用PXE+NFS和ISO image。 无论哪种方式，制作Reimage的命令都是一个makeImageMedia.sh，语法如下： Exadata出厂时带有双操作系统，一个是Linux，一个是solaris x86，通常，至少国内的客户绝大部分都会选择使用Linux，因此，在安装完成后，我们需要做reclaim操作。 如果是Reimage，那么我们也可以在制作U盘，image或者使用PXE时带上 … 继续阅读 →

发表在 安装和升级 | 标签为 , , | 2 条评论

如何看待exadata的cell节点出现的writethrough/wirteback模式更换或者控制器充放电信息

发表于 2013 年 11 月 24 日 由 Lunar

Exadata使用的是LSI的disk driver，在定期进行的HC中，如果cell上出现类似下面的信息，需要考虑是否需要更换或者bug： 这个信息意味着disk controller写cache的策略从”write-back” 更改为 “write-through” 了，原因是电池学习周期（battery learn cycle）正在进行。 这个学习周期一年回周期性的执行4次，这个操作主要是每次执行一次控制器电池的充电和放电（discharge and charge）操作。 在Image 11.2.1.3之前，每个月执行一次 从Image 11.2.1.3开始，每3个月执行一次： 每年的1月/4月/7月/10月 的17日凌晨2点 这个缺省的时间(下一次学习的时间)可以使用命令修改，例如： cellcli> alter cell bbuLearnCycleTime=”2013-01-22T02:00:00-08:00″ Oracle推荐所有cell磁盘的电源学习周期是同一个时间。 众所周知，Write-through 的性能比 write-back 差。但是当存储crash或者电源丢失（looses power）发生时，write back有丢数据的风险。 因此，在电池学习周期中，会自动将写策略从写回模式（write-back）修改为写模式（Write-through） 如果在cell 的alert上看到类似下面的信息： 需要连接到cell节点，查看一下电池充电的百分比： 当充电完成后，可以在cell的alert上看到如下信息： 连接到cell节点，查看磁盘的写模式（writethrough/writeback）的状态，可以发现： 同样在 上面信息显示了10月17日凌晨:02:00cell01上有一个逻辑盘开始学习，完成时间是10月17日早上7:33。充电完成后，磁盘驱动器已经改回了writeback模式。 通常电池充电（Learning state）可能需要几个小时，如果充电完成后没有自动改回wirteback模式，可能是控制器电源出现问题，需要联系support … 继续阅读 →

发表在 体系架构, 安装和升级, 硬件配置 | 标签为 , , , | 留下评论

关于Exadata的万兆网的配置初级篇

发表于 2013 年 6 月 29 日 由 Lunar

今天忽然好多人问起来万兆模块的事情，微博上写不下，我放在这里。 首先，万兆模块通常的作用有两个： 1，作为备份和灾备的网络，高效快速。有人问为啥不用Infiniband，那个说来话长，用不用都可以，关键看客户的整体架构，从技术上没啥不行的，直接插一根线到IB switch就行了………… 2，作为public ip，用于client的访问，比如地台eth1和eth0，做绑定，这个有N个文档都说了，比如owner guide，还比如MOS等等，这里不赘述，只是一点稍微嘱咐下，如果是初始配置，那么只要按部就班的用onecommand就搞定，如果是后面更改，除了考虑物理的网络连线，客户的交换机是否有万兆模块或者支持万兆，还要考虑软件本身的因素，其实配置好了以后（如果需要可以做绑定，也可以不绑定，根据客户需要），就是参考mos的文档做更改public ip和vip，scan ip等的设置。 在补充一句，在每个Exadata自带的机器上有document文档，其中owner guide上“Changing from 1 GbE Connections to 10 GbE Connections”是专门的一个章节，写的非常详细。 具体就是如下的配置文件，配置万兆使用命令: ethtool [root@dm01db01 ~]# dcli -l root -g dbs_group “ethtool eth4” dm01db01: Settings for eth4: dm01db01: Supported ports: [ FIBRE ] … 继续阅读 →

发表在 安装和升级, 硬件配置 | 标签为 , | 留下评论