原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/43989939
【简介】
个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以英文形式代替，不会泄露任何企业机密，纯为技术分享。
创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。
欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。
【前言】
这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。借由此杂记与库友们分享蓝的成长历程。
不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博，痴迷其深邃，痴迷于近在咫尺却又遥不可及。
而又说不清从何时起，注视于oracle的红色耀眼，照亮出眼前的一道光，未知与迷惑在自己的脚下开始初露些许人生的充实与青春的回馈。
在追逐于DBA梦想的道路上步步前行。
___________________________________________________________________
面对自己不懂的知识面，抓住机会，就要“多问多学多看”。
——深蓝
___________________________________________________________________
现象：服务器启动不正常。
开始说之前，想提的是，作为一个想从事数据库方面或是IT领域的人士们，不要认为小概率的事情就不会发生。因为这次发生的就是小概率。
下面记录了一个小操作，源于服务器的一块磁盘损坏，致使服务器在安装操作系统后，启动卡在滚动条界面。开始的时候，不知道这是怎么回事。看到系统厂商的工程师，敲击了下“ESC”，这才云开雾散，因为这时我看到了系统的启动过程，报出了检测一块dev设备(磁盘)时遇错了，而无法继续下去。突然想到这块磁盘在昨天硬盘指示灯确实红灯亮起过，报过故障了。只不过后来恢复正常绿灯了（不知道为什么），想毕应该是这块硬盘仍然存在不确定问题（排除了松动，怀疑存在坏道或控制器损坏等原因）。于是借由硬件厂商联系了服务器厂商（浪潮原厂工程师），一番描述后，联系好第二天会到现场检测。再之后，浪潮来的工程师更换了这块故障磁盘，系统启动恢复正常。因为磁盘做了RAID5，允许一块磁盘损坏。所以操作系统和原磁盘数据并未损坏和丢失。而最终确定，系统无法启动是因为自检这块磁盘时不通过，因为系统不通过检测，系统就会反复的对这块磁盘进行检测，从而出现了卡顿现象。
最后想说的是，这个服务器是跟随项目全新上线的，从系统集成商来装系统，到我方在现场检查硬件情况，前前后后，不出一周时间。而就在没有任何业务压力的情况下，一块磁盘莫名其妙的坏掉了。但遇到这种情况，见得多了就不以为新奇了，任何电子产品都有可能出现不确定问题。这也就是为什么会有容灾方案的原因吧。哈，所以这才意识到，硬件厂商的质保期不是没有用的，因为在出厂的时候，可能厂商就预见到了会有损坏的，这种情况是目前人为所不能控制的。但转念一想，是不是暴漏本身产品的质量缺陷呢？联想到了锤子手机的碎屏险，是不是因为工程师预见了屏幕的破损概率大，于是就做出了一个质保的方案呢（我这里胡思乱想了）。也怀念曾经的“诺基亚”，假设不给质保也不会担心有损坏问题（质量好啊）。但，或许这正是人类科技水平发展的道路上，在探索的过程中必然要经历的，进步是需要付出一定代价的。
至此，想再提一下这个简单的操作：就是在启动LINUX系统时，在进度条界面，如果我们点击ESC就会看到系统启动时进行的操作。如下图：
点击“esc”，可以看到启动过程，如下：
说实话，以前还真不知道。
学到了点皮毛，还是感觉惭愧，这个小操作竟然才知道，诶呀~~~。引以为戒了，不知道大家都知道不，反正我以前不知道，以后就知道了。
来源于主机（PC-server）、小型机连接“光纤交换机”时，再连接“光纤存储”，这样就会形成多条链路，如果在主机上从存储划出一块盘，可能会在主机上映射出很多块盘，会让操作者无法选择应该操作那一块磁盘。为了避免这个繁琐的磁盘链路，就会使用到多路径软件，将多条路径聚合到一起。既起到方便管控磁盘的作用，也起到负载均衡的效果，假设一条链路断掉，其它链路仍然可用，这样不会影响对于磁盘的访问。
几款多路径软件：
（1）、IBM主机和IBM存储：RDAC、MPIO、SDDPCM
（2）、日立的存储：HDLM
（3）、EMC存储：PowerPath
（1）、初探LUN
LUN是SCSI协议中的名词，是SCSI ID的更细一级的地址号，每个SCSI ID（Target ID）下面还可以有更多的LUN ID。对于大型磁盘阵列，可以生产几百甚至几千个虚拟磁盘，为每个虚拟磁盘分配一个SCSI ID是远远不够用的。因为没有SCSI总线最多允许16个设备接入（目前32位SCSI标准最大允许32个设备）。要在一条总线上放置多于16个物理设备也是不可能的，LUN就是这样一个次级寻址ID。磁盘阵列可以在一个SCSI ID下虚拟多个LUN地址，每个LUN地址对应一个虚拟磁盘，这样就可以在一条总线上生成众多虚拟磁盘，以满足需求。
后来，人们把硬件层次生成的虚拟磁盘，统一称为“LUN”，不管是不是在SCSI环境下，虽然LUN最初只是SCSI体系里面的一个概念。而由软件生成的虚拟磁盘，统一称为“卷”，比如各种卷管理软件、软RAID软件等所生成的虚拟磁盘。
--摘自张冬瓜，大话存储2
（2）、SAN
下面展示一个SAN存储架构图（来源于电子书中），如下：
SAN（storage area network）：关于存储区域网络
网络，不仅仅指以太网、TCP/IP网，可以是SCSI网、PCI总线网、USB网等。RAID控制器，就相当于一个路由器，也就是协议转换器。
将磁盘放到了主机外部，存储设备和主机之间，就形成了又一个独立的网络：存储区域网络（Storage Area Network，SAN）。
（摘自，张冬瓜，大话存储2）。
（3）、存储的规划方案
最后，由于方案前期采购出现的错误（因为当时我方还未介入），没有采购光纤交换机，而是采购的华为的S5700S系列，虽然效率上有些失望，但还是把我们应该做的工作做好吧。
完成存储的划分，其中包括存储的RAID部署、存储初始化、RAID分区（划分存储分区方案由我方提出，硬件厂商给予实施）、完成映射（在多服务器系统内需要安装多路径软件）。
面对着12块、6块磁盘存储盘阵，简单阐述下存储方案，如下：
|
存储名称 |
RAID方案 |
物理容量 |
可用容量 |
LUN划分 |
|
数据库存储 |
RAID5+热备盘1块 |
12*3TB |
10*3TB |
（3*20G）+（55*500G） |
|
备份存储 |
RAID5+热备盘1块 |
6*3TB |
4*3TB |
2*5119G |
|
数据库服务器 |
RAID5 |
6*1TB |
5*1TB |
4T+1T |
看一眼实物图：
凌乱的线缆，还没来得及整理的线缆，先体验了一把突然断电的爽快。这是发生的一次意外断电以致使服务器宕机。其实恢复这个很简单，只需要到机房重启即可。而这次，我犯了低等的错误。由于之前有过一次网络部门随意拔掉了我们一次网线的经历，我下意识的把这次认为是“人为事故”，看了一眼数据库服务器的状态，指示灯运行正常的，就跑到了机柜的后部查看电缆，如下图：
而这次我犯了错误。由于自己的粗心大意，直接去了网络部，找到了网络部门的工程师，并表示服务器没有问题，但是网络不通了。而网络工程师倒也没有任何隐瞒说昨天有过一次断电，不知道是否和这有关系。于是去查看了接入局域网的端口线，但是没有发现问题。然后查看了我方交换机的vlan设置，表示说可能断电引起设置冲掉了。截止到此，我们在错误的方向上开始了天方夜谭。为什么这么说，原因有下：
1、路由器断电不能使其配置失效（不知道当时网络工程师是故弄玄虚还是真的这么想的，我差点就信了，诶呀~~，这里我承认，我弱智了，难道还有把配置信息放到内存里的不成，额~~(⊙o⊙)。）
2、断电后直接反应应该确认服务器是否启动，而不是去直接联系网络部（这里我又二了一把，诶呀~~，又弱智一次）。之所以会产生如此低级错误，其实原因很简单。其实我原本查看了服务器，不过只是查看了数据库服务器，因为这两台服务器设置了通电后自动启机了。而没看其它服务器，造成了这次低级错误的发生。
电源的固定，简单的事一拖再拖。跟协调的人有关，但之所以郁闷，本无关的事变的有关了，而后又没处理好，这就郁闷了。
这个说来，本应该负责的部门不负责，也就是机房管理方，而硬件服务商、系统集成商或我们软件开发商都表示不承担这部分的工作。所以客户头也大了，连线缆还没有进行布设（就像上图那样，凌乱呐~~）。由于线缆没有布设，机柜中的线缆凌乱的被塞到了服务器后面，给正常运行造成了安全隐患。
好在，在过了许久之后，终于，客户自行解决了这个问题，我们的硬件设备也总算是稳定下来了。
稍微了解一下PDU,PDU(电源分配单元), Power Distribution Unit也被称为“机柜电源插座”，如下两张图：
原以为神秘又高大上的一体机，没成想，一个不小心，这个价值千万元级别的设备就这样活生生的展现在了我的眼前。
记得之前在一节oracle公开课中，简单了解了一下exadata（oracle一体机），在这里做个简单的回忆，从解决四方面问题入手的一体机。
（1）、如何解决传统数据库部署所带来的性能问题？
传统的数据库部署：
存储层：1、数据量增加IO瓶颈；2、数据分布不均；
网络层：带宽不足
服务器层：过多数据处理
解决思路：减轻负载、加宽带宽、提高并行
1、加宽通道
2、减少数据量传到数据库服务器
3、增加系统并行处理
理念化：
存储横向扩展，实现并行处理能力
存储层：智能化、预处理
服务器端的卸载预处理工作分担到存储层，处理完后返回给数据库服务器。
（2）、解决了资源独立，无法共享的问题？
传统数据库：
分配给不同的主机，不是共享的，分配资源不均，有些资源不足，有些资源过度。生产环境动态变化，无法动态满足负载的目标
设计原则：资源共享、资源控制
解决：
如：1、把存储服务器的资源变成一个存储池，一个存储池给一个或多个数据库使用，服务器都可以用到所有磁盘的能力，满足IO吞吐量；
2、对IO进行控制，根据业务的优先级来处理。
（3）、解决复杂的数据库系统均衡化配置？
传统数据库：
大型的存储系统，EMC存储；
分区；
设备昂贵；
技术维护管理；
总的代价开销非常大；
让一体机实现性能均衡化：
使用exadata，平衡及优化的配置
主机、存储、数据库、应用程序：调优
exadata端到端优化：硬件软件配置好了的
易于上线，不需设计、调优、维护、设置
（4）、如何解决系统的维护和扩容过程复杂
一体机：
简化部署：消除复杂部署；
当天部署完成，获得极限性能。
以上通过理论性、概述式的介绍了一下一体机，其中具体的技术细节并没有涉及到，如果对于exadata的技术真正感兴趣的朋友，不妨去看看官方手册或参考文档，相信会有所收获的。
这里对于一体机的了解我也是刚刚开始，就简单介绍这些吧，毕竟还是菜鸟，O(∩_∩)O~
系列链接：
蓝的成长记——追逐DBA（2）：安装！安装！久违的记忆，引起我对DBA的重新认知
蓝的成长记——追逐DBA（3）：古董上操作，数据导入导出成了问题
蓝的成长记——追逐DBA（4）：追忆少年情愁，再探oracle安装（Linux下10g、11g）
蓝的成长记——追逐DBA（5）：不谈技术谈业务，恼人的应用系统
蓝的成长记——追逐DBA（6）： 做事与做人：小技术，大为人
蓝的成长记——追逐DBA（8）：重拾SP报告，回忆oracle的STATSPACK实验
蓝的成长记—
—追逐DBA（9）：国庆渐去，追逐DBA，新规划，新启程
蓝的成长记——追逐DBA（10）：飞刀防身，熟络而非专长：摆弄中间件Websphere
蓝的成长记——追逐DBA（11）：回家后的安逸，晕晕乎乎醒了过来
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/43989939
蓝的成长记——追逐DBA（13）：协调硬件厂商，六个故事：所见所感的“服务器、存储、交换机”
原文地址：http://blog.csdn.net/huangyanlong/article/details/43989939
