月归档：2014 年三月

看图说话——Exadata和Exalogic（或者Exadata）级联-1

发表于 2014 年 3 月 11 日 由 Lunar

上一篇，我们梳理了Exadata的网络架构，今天我们说说Double-E的物理联线。 看图说话——Exadata的网络架构 通常我们说Double-E，这里E可以使Exadata，也可以是Exalogic，Double—E级联的方法都差不多，但是X4以后会有变化，因为X3-2和X3-2以前，从1/2 Rack开始都带有一个Spine switch，也就是你在真机上看到的位于机柜最下层的IB Switch，这个Spine Switch主要作用就是用于机柜间的级联。而中间的两个IB Switch叫做Leaf switch，这个适用于机柜内部节点间通信（db和db通信，db和cell通信等）。 现在我们先说说，在一个机柜的情况： 从这个图，我们很清晰的看到，在一个机柜中，每个Leaf switch都需要跟另一个Leaf switch连接，同时，每个Spine switch还需要和机柜中的所有Leaf switch连接。也就是他们之间至少3根Infiniband连线。 那么如果是两个满配的Exadata如何连接呢？ 可以看到，如果两个满配的机柜级联，那么每个Leaf switch都会有两根线，分别连接到两个机柜的Spine switch，而在每个机柜中的2个Leaf switch之间无需连接了。 其实看这个图，如果数据比较好的同学马上就发现了，一共需要多少根连线？ X3和X3以前，1/2 Rack和Full Rack都出厂自带2个Leaf switch和1个Spine switch。X4没有带了，需要单独购买，连接方式也有变化）。这里，每个机柜中的Spine  switch都需要连接本机柜和其他机柜的所有Leaf switch，那么两个机柜中就有4个Leaf switch，总共2个Spine switch，因此，就需要至少8根连线。 我们可以推算一下，如果有3个柜子级联，那么每个Spine Switch上需要多少根线呢？3个机柜级联，总共需要多少根线呢？ 答： （1）每个Spine switch上有6根线。 （2）每个柜子2个leaf switch，3个柜子共6个leaf switch，因此，每个Spine switch上至少会出来6根线，因此3*6=18根连线 X4开始，每个Leaf … 继续阅读 →

发表在 体系架构 | 标签为 , , | 留下评论

看图说话——Exadata的网络架构

发表于 2014 年 3 月 10 日 由 Lunar

下面两个图是Exadata的Owner Guide中讲解网络链接和部署的。 安装好了Exadata，我们需要熟悉Exadata上都有哪些部件，比如数据库服务器，存储服务器，思科交换机，2个PDU（用于冗余）等等，他们是怎么接到咱们的生成环境的，他们之间是怎么连接的，我们怎么去管理他们。。。 X2-2和X3-2的连接方式： X2-2的图，X3的图跟这个没有太大差别，只是X3以后没有KVM了，X4以后，少了一个Spine Switch（需要单独购买）。 其他没太大区别（X4的IB绑定有变化，后续会详细解释）。Sun的ILOM做的非常好，实际上很多管理功能，都可以通过ILOM来完成。 比如前面讲的使用ILOM来完成ISO image的Reimage功能，重启节点功能，还有收集信息功能，系统启动时troubleshooting等等。   计算节点上的对外服务部分有两种方式： 1，一种是NET0和NET1绑定作为client，接入到客户的核心网络，提供对外的数据库连接服务。 2，一种是不绑定，那么通常NET1连接到核心网络，提供数据库连接服务，NET2和NET3都作为其他用途，比如他们分别俩接到备份和灾备网络等等。 当然，大部分客户是绑定net0和net1作为bondeth0来对外提供数据库服务用。 X4-2的连接方式： 在网连接上，X2-2和X3-2的连接方法基本没有太大区别。 但是从X4开始，IB不在安装时进行绑定了，而是分别连接到IB1和IB2两个IB交换机上，这是因为从X4开始提供Active-Active的方式，带宽从40Gb/s升级为80Gb/s。 但是如果Double-E级联（比如2个Exadata机柜，或者Exadata跟Exalogic级联），就不能使用这种Active-Active的方式。 除此以外，我们看到，其余部分的连接都基本相同。 从上面的图我们可以看到，exadata上的网络主要分为4大块： 第一部分，是位于最下面的绿色区域的Infiniband网络连接，也就是exadata的内网。 内网主要是数据库服务器和存储服务器通过两个Infiniband交换机连接，能够获得高带宽低延迟带来的高性能。   第二部分，就是蓝色部分的管理网络。 Exadata上所有的部件都有一根线连接到思科交换机上。然后从思科交换机上有一根线接入到客户的管理网络，这样就方便客户管理。 其实就像传统小机+存储的架构一样，小机也都要连接到客户的管理网段的交换机，然后远程维护（比如使用crt，xmanager等等字符或者图形的管理工具维护客户的小机） exadata上的所有部件也都要让客户可维护和可管理，就是通过各部件连接到思科交换机，然后思科交换机接入到客户的管理网段。 连接到思科交换机的部件有： （1）在X2上有KVM，因此KVM要连接到思科交换机 （2）然后两个PDU（PDUA , PDUB）分别连接线到思科交换机上，也是为了远程管理。 当然需要管理PDU的时候不多，但是如果安装一些监控软件，比如oracle 的grid control的时候就需要能够连接PDU，因此，我们一般也把PDU接入到思科交换机 （3）在每个数据库服务器和存储服务器上有一个类似于芯片的部件，我们称之为ILOM。 它是一个远程管理的接口，我们通过ILOM可以做所有数据库的维护工作，包括安装，升级，刷机，启动和关闭主机，监控主机启动，关闭过程。。。。。 这个ILOM也要连接到思科交换机，然后客户就通过浏览器的方式管理每一个部件 （4）每一个数据库服务器和存储服务器上的NET0口就是管理口，使用这个端口接入思科交换机 这些部件都通过思科交换机，接入到客户的管理网络，包括客户如果使用EM（即grid … 继续阅读 →

发表在 体系架构 | 标签为 , | 6 条评论

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 条评论

研究数据字典和基表，发现处理手工删除fs$或者file$等问题的新思路

发表于 2014 年 3 月 10 日 由 Lunar

在测试环境玩什么东西忘记了，反正是忽然发现有个没用的表空间“UNDOTBS1”删除不掉，以前写过一篇，如何查找某个对象的定义（V$_X$_DBA）， 这里重温一下数据字典和动态性能视图： UNDOTBS1在v$tablespace中可见，但是不能drop，在dba_tablespaces中不可见，说明数据字典和动态性能视图不匹配了（手工删除了基表导致的，忘记是删除了ts$还是file$内容了）： 不得不说Oracle 11.2.0.3以后的版本，对于数据库的一致性校验进行了很人性化的改动，以前这种情况是crash的，现在还open着，带病工作，O(∩_∩)O哈哈~ 类似的带病工作的情况，还涉及到很多数据字典的不一致情况，比如以前的i_dependency1, i_dependency2等等。 从这个研究，也证实了如下结论: V$TABLESPACE的信息是来源于GV$TABLESPACE，GV$TABLESPACE来源于基表 X$KCCTS 而DBA_TABLESPACES是来源于 SYS.TS$ TS 和 SYS.X$KCFISTSA。也就是说，V$TABLESPACE的信息来源于控制文件，而DBA_TABLESPACES的信息是来源于其他基表，手工删除基表信息时，其信息不和控制文件信息同步。 下面有具体看看： 看下创建动态性能视图的语句： 通过上面建库脚本也可以清晰的看到，得到授权的普通用户仍然只能访问V$开头的视图，而不能直接访问V_$开头的视图，因为实际上V$视图是V_$视图的公有同义词（PUBLIC SYNONYM）要想访问V_$必须带上SYS.V_$，例如 而查看普通的DBA_ ALL_ USER_ 等视图，可以查看数据字典 dba_views（这个视图从8i开始引入的） 例如： X$ 是 Oracle 数据库 的核心部分，这些表用于跟踪内部数据库信息，维护数据库的正常运行。 X$ 表是加密的（除了MOS和直接看源代码以外，我不知道还有什么方法可以查看X$视图） Oracle 通过 X$和一些基表（TS$, OBJ$, SEG$等）建立起其他大量视图，提供用户查询和管理数据库。 在9i以前 另外，还可以通过X$KQFTA来查看X$表的相关信息： 类似，就是11.2中新引入的X$表： … 继续阅读 →

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

看图说话——ASM实例和ASMB进程

发表于 2014 年 3 月 9 日 由 Lunar

先看一下ASM实例的大体部署： 我们都知道，ASM实例管理着元数据，普通数据库实例通过查询元数据的信息来访问相应的ASM文件。 ASM实例和数据库实例都可以访问一组普通的磁盘，这套磁盘被称为磁盘组。 然后，数据库实例直接访问ASM文件的内容，并在与ASM实例通信时获取有关这些文件的分布信息。 Group Services用于注册数据库实例查找ASM实例时所需要的连接信息： Group Services用于注册数据库实例查找ASM实例所需要的连接信息。 当ASM实例mount一个磁盘组时，它就将磁盘组的信息和连接串注册到Group Services。 数据库实例知道了磁盘组的名称，就可以找到应该连接到哪个ASM实例。 ASM实例有哪些独特地方： 1，INSTANCE_TYPE = ASM 2，startup = startup mount(11.2以后，可以直接对ASM实例 startup，但是本质还是startup mount)，对于ASM实例，mount选项不会去mount数据文件，而是mount在参数文件中ASM_DISKGROUPS指定的磁盘组 3，connect / as sysdba(10g) 和 connect / as sysasm(11.2) ASM的后台进程有很多，具体可以参考reference中的描述，这里只想研究一下数据库和ASM之间负责心跳机制的ASMB进程。 我们知道ASMB进程实际上是提供了一个数据库实例和ASM实例之间通信的桥梁，比如在数据库中创建、删除文件，或者修改文件等等的跟存储物理变化相关的操作。首先，我们观察下，他们在CRS,ASM和数据库启动过程中的启动顺序和先后关系： ASM的alert： DB的alert： ASM和数据库实例的ASMB进程都分别将信息注册到css中，参看ocssd.log: 这里，数据库启动时，ASMB的活动过程： 1，ASM实例的ASMB进程启动(spid: 3637，asm_asmb_+ASM1) 2，ASM实例的ASMB进程启动了一个连接到ASM实例的进程（spid：3641，oracle+ASM1_asmb_+asm1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))） … 继续阅读 →

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

expdp中跟踪每一个步骤的时间——metrics=y

发表于 2014 年 3 月 4 日 由 Lunar

在12c中，我们知道expdp和impdp可以看到每一步的时间，其实这个功能在11.2中就可以了，需要加一个未公开的参数 metrics=y，例如： 看一下各个部分执行所花费的时间：

发表在 expdp/impdp | 标签为 , | 一条评论

对于已经存在的exp导出文件或者expdp的导出文件，如何获取导出文件头的信息呢？

发表于 2014 年 3 月 4 日 由 Lunar

对于已经存在的exp导出文件或者expdp的导出文件，如何获取导出文件头的信息呢？ 我们来测试下，我的expdp导出文件是： 方法1：利用dbms_datapump.get_dumpfile_info我们可以得到dump文件头的信息，具体脚本参考 抽取exp/expdp导出文件头的信息 方法2： 使用string来看： 方法3： impdp lunar/lunar DIRECTORY=lunar_dir DUMPFILE=lunartest.dmp NOLOGFILE=y SQLFILE=lunartest_impdp.sql TABLES=lunar_par_test TRACE=100300 这里TRACE=100300是生成data pump进程trace信息。其他trace信息还有很多，后面陆续会介绍其他的data pump的相关trace。 我们知道data pump进程启动的时候，会有两类进程，即：Datapump Master (DM) 和 Worker (DW) processes 他们生成的trace文件产生在BACKGROUND_DUMP_DEST目录里面，命名格式如下： — Master Process trace file: _dm_.trc — Worker Process trace file: _dw_.trc 我们具体看一下3个文件的内容： … 继续阅读 →

发表在 expdp/impdp, FAQ, Scripts | 标签为 , | 留下评论

抽取exp/expdp导出文件头的信息

发表于 2014 年 3 月 4 日 由 Lunar

抽取exp和expdp的dump文件头信息，同时支持oracle 7.3.4以后的exp导出文件和oracle 10.1以后的expdp导出文件

发表在 expdp/impdp, Scripts | 标签为 , , | 留下评论

快速创建1000用户，每用户1000表，1000索引，1000个trigger

发表于 2014 年 3 月 4 日 由 Lunar

有时候为了方便测试，我们需要制造一些复杂的数据，比如这里，我们快速的创建1000用户，每用户1000表，1000索引，1000个trigger

发表在 POC和性能调整, Scripts | 标签为 , | 一条评论

Exadata上验证ASM磁盘头备份的位置

发表于 2014 年 3 月 3 日 由 Lunar

我们都知道，从Oracle 10.2.0.5开始，ASM磁盘会自动备份磁盘头块，备份块的位置在第2个AU的倒数第2个块上。 通常，缺省情况下，AU SIZE是1M，每个AU可以有256个block（每个block 4k），256*4k()=1M 因此，第2个AU同样存放了256个block（0~255），其备份块的位置为 au=1 blkn=254(au和block都是从0开始计数的) 具体的恢复案例，可以参考： ASM磁盘头被fdisk损坏的修复过程 那么在exadata上，缺省的AU是4M，也就是每个AU可以存储 1024个block，即 block 0 ~ block 1023 那么第二个AU的倒数第二个block就是 au=1 blkn=1022 ( au和block都是从0开始计数的 ) 我们来检测一下是不是这样： 注意： 这里kfed命令中，需要指定ausz=4m，否则kfed缺省按照1M来计算，那么结果就是错误的了： 在kfed中指定ausz=4m，检测结果： 经过检查，我们发现，这个规律在exadata上依然有效，ASM除了缺省4M的AU，其余没什么变化，O(∩_∩)O哈哈~ 顺便介绍一个小方法，快速计算备份块的位置：（该方法根据ASM Support Guy修改而来）

发表在 ASM, 内部机制 | 标签为 , , | 一条评论