月归档：2014 年一月

整理了一下以前老blog中的exadata介绍的link，顺便更新下Exadata X4的内容

发表于 2014 年 1 月 7 日 由 Lunar

最近有些小伙伴问起exadata的一些古老问题，这里总结下，顺便根据白皮书小小的更新一下X4的东东（迄今为止，我还没见过X4的真神，O(∩_∩)O哈哈~），期待年后的第一个X4项目中。。。： 最新的Exadata版本 2008年Oracle推出业界第一个全新架构的设计Exadata V1，以满配为例：内存 256G，64Core，没有flashcache 2009年到2010年年底之前，Exadata硬件是V2系列的多，image版本是11.2.2.x比较多，2011年，image版本11.2.2.4.2多（一般都升级上到这个了，相对稳定），第一次在硬件中增加了Flashcache组件，可以提高OLTP的处理能力,V2的硬件，以满配为例：64G内存，576G，内存，Flash容量5.3T 2011年和2012年的主要的exadata硬件是Exadata X2,image主要版本是11.2.3.1.0和11.2.3.1.1增加了磁盘容量（504T），CPU 96core和内存1T 2012年底推出Exadata X3系列，2013年年初随着Exadata X3系列的推出，image升级为11.2.3.2.0和11.2.3.2.1（这个是目前主流的11.2.3.2.x的版本），最显著的软件特征是WBFC(WriteBack FlashCache)。硬件增加了大幅增加了Flashcache的容量（22.4T），以及CPU 128core和内存2T 2013年底，Oracle推出了Exadata X4系列，现在最新的image版本已经是11.2.3.3.0了，最新的硬件是Exadata X4-2，硬件再次升级以满配为例：flashcahe 44.8T，CPU 192 core，内存4T，同时，IB网络的连接方式从Active-Backup到Active-Active（带宽40G/b 升级到 80Gb/b） 软件的更新（image 11.2.3.3.0）： 1，的在1/4 Rack和1/8 Rack的转换，从以前的好几条命令，封装成1一条命令（alter cell eighthRack=TRUE） 2，带有Automatic Flash compression功能（一条命令而已，相同image下，X3跟X4 硬件，命令稍微有点区别，alter cell flashCompress=TRUE和alter cell FlashCacheCompX3Support= TRUE） 3，在线替换磁盘控制器电源（Disk Controller … 继续阅读 →

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

艰难的修复数据库过程，却发现Oracle 11.2果然强大

发表于 2014 年 1 月 5 日 由 Lunar

具体参见: http://t.askmaclean.com/thread-3790-1-1.html http://www.itpub.net/thread-1839128-1-1.html 纯属自娱自乐，没有实际意义的，顺便说下我的发现和测试中的发现（虽然到现在为止数据库还没有open，我还会继续鼓捣他，毕竟还有些方法还没用上，O(∩_∩)O哈哈~。。。）; 首先就是11.2太强大了，很多时候以往的错误都可以fixed，数据库可以open后，做很多跟损坏先关的check 1， 从11.2开始，控制文件自动备份完成的信息由m000完成，且他还完成很多其余工作，当然，只在别的进程触发的时候，他才会去工作 2，DBA_TABLESPACE和V$TABLESPACE的来源不同，一个来源于控制文件，一个来源于基表ts$ 3，ts$和file$不能跳号 4，DBMS_HM很强大（Health Manager），他会定期检查数据库的很多东西，然后让m000进程写trace 。。。 主要的测试步骤已经不太都记得了，但是主要模拟步骤如下： 我的环境： db 11.2.0.3 OEL 5.8 1，创建2个表空间（其实1个也可以，几个都行，为了看得更加清晰），然后切换日志，然后在OS上讲包括UNDOTBS在内的这些数据文件（普通的数据文件和undo的数据文件就可以） 2，启动数据库的时候，你会发现，报错说文件丢失或者损坏，这时你offline drop掉这个报错的文件，数据库应该就可以打开，当然后台有m000生成的trace，HealthManager会不断的触发m000把所有其余随坏的信息都写入trace 3，想办法清理undo$中的问题回滚段 4，创建新的普通数据的表空间，例如“UNDTBS333”，但是设置UNDO_TABLESPACE=这个普通的表空间（scope=spfile），然后启动数据库————–这时我当时的第一个误操作 5，数据库报错，具体忘记了，怎么解决的也忘记了，印象中无非就是undo的隐含参数等等，然后创建正确的undo表空间（create undo tablespace …）给数据库使用 6，解决后，数据库可以正常open，delete from fs$ where name=‘你曾经误操作的那个普通数据表空间 UNDTBS333’，这么做是因为当时我没有仔细考虑风险，因此，手工清理了 其实如果全部都是手工做的话，也可以的，后面发现了需要手工清理什么，但是当时确实么有想太多，误操作了。。。 7，其实这样数据库也还是可以open的，没有太大问题，我用DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)检查，其实这时数据库只有undo$, ts$ 和file$数据不一致，没有影响其他数据对象（因为测试过程没有添加用户测试数据） … 继续阅读 →

发表在 backup&recovery, Internal, Oracle 11.1 & Oracle11.2 | 标签为 , | 留下评论