月归档：2014 年九月

往使用了17T的DG中添加2个1.5T的LUN,共耗时3小时

发表于 2014 年 9 月 26 日 由 Lunar

当前使用了28块800G的SAS SSD。 昨晚，往使用了17T的DG中添加2个1.5T的LUN，从开始到ASM rebalance完成，总共耗时3小时（以前测试的Exadata 1/4配置，加载纯LOB对象，也是1小时1T，当时也感觉很震撼……），速度很快啊，记录一下，O(∩_∩)O哈哈~：

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

使用ASM的数据库和使用文件系统的数据库在AIO上哪里不同？

发表于 2014 年 9 月 26 日 由 Lunar

昨天客户的一个重要应用切换到新的系统环境上，今天观察，发现部分异常等待： 从OS的CPU负载来看，定期会出现一个峰值，从ASH中可以看出，这个峰值对应的等待事件跟AWR的完全吻合。 因此，主要怀疑两个东西： 1，应用的SQL和对象的属性（比如table或者index的统计信息，并行度等等……） 2，系统的AIO设置 上面的第一条，已经提交给开发相应的SQL和其他信息 第二条，因为系统以前是11.2 RAC，使用了ASM，而现在是单机文件系统. 因此对比了这两种环境下AIO的异同，结论如下： 1，Linux下，ASM数据库和文件系统数据库的AIO设置差别： (1). ASM的AIO属性是不受 FILESYSTEMIO_OPTIONS 参数的影响（因为ASM会绕过文件系统buffer），只跟DISK_ASYNCH_IO有关系 (2). 文件系统的AIO属性跟 FILESYSTEMIO_OPTIONS 和 DISK_ASYNCH_IO 都有关系 2，FILESYSTEMIO_OPTIONS=NONE ： Bug 6733627 – Unaccounted Wait Time on “Direct Path” operations with FILESYSTEM_IO_OPTIONS=NONE (Doc ID 6733627.8) 3， db file … 继续阅读 →

发表在 ASM, FAQ | 标签为 , , , , | 留下评论

更改db_unique_name后，修复磁盘组依赖关系和其他crs中的相关配置

发表于 2014 年 9 月 25 日 由 Lunar

做ADG时，修改了数据库的db_unique_name后，alert中报错如下： 这个错误不影响使用，但是终归是别扭的…… 检查crs中数据库的配置： 这里可以看到，以前的spfile（主库的）位置是：+DATA/lunardb/spfilelunardb.ora 此时，即便是手动修改了参数文件位置为 SPFILE=’+DATA/mynewdb/spfilemynewdb.ora’，重启crs后，启动数据库也会有报错信息： 因为它还是自动修改为crs的db资源中的信息，并把以前我手工修改的信息做了备份： 可以修改crs中db的spfile位置： srvctl modify database -d lunardb -p ‘+DATA/mynewdb/spfilemynewdb.ora’ 再次检查，可以发现spfile位置已经正确了： 这里很显然，除了spfile位置，Database unique name也是不对的，因为crs中保存的db信息是根据db_unique_name来判断的，只能通过remove database，然后再add database，add instance等等： 好了，alert中信息正常了：

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