而这次我犯了错误。由于自己的粗心大意，直接去了网络部，找到了网络部门的工程师，并表示服务器没有问题，但是网络不通了。而网络工程师倒也没有任何隐瞒说昨天有过一次断电，不知道是否和这有关系。于是去查看了接入局域网的端口线，但是没有发现问题。然后查看了我方交换机的vlan设置，表示说可能断电引起设置冲掉了。截止到此，我们在错误的方向上开始了天方夜谭。为什么这么说，原因有下：
1、路由器断电不能使其配置失效（不知道当时网络工程师是故弄玄虚还是真的这么想的，我差点就信了，诶呀~~，这里我承认，我弱智了，难道还有把配置信息放到内存里的不成，额~~(⊙o⊙)。）
2、断电后直接反应应该确认服务器是否启动，而不是去直接联系网络部（这里我又二了一把，诶呀~~，又弱智一次）。之所以会产生如此低级错误，其实原因很简单。其实我原本查看了服务器，不过只是查看了数据库服务器，因为这两台服务器设置了通电后自动启机了。而没看其它服务器，造成了这次低级错误的发生。
第五个故事：让人郁闷的PDU
电源的固定，简单的事一拖再拖。跟协调的人有关，但之所以郁闷，本无关的事变的有关了，而后又没处理好，这就郁闷了。
这个说来，本应该负责的部门不负责，也就是机房管理方，而硬件服务商、系统集成商或我们软件开发商都表示不承担这部分的工作。所以客户头也大了，连线缆还没有进行布设（就像上图那样，凌乱呐~~）。由于线缆没有布设，机柜中的线缆凌乱的被塞到了服务器后面，给正常运行造成了安全隐患。
好在，在过了许久之后，终于，客户自行解决了这个问题，我们的硬件设备也总算是稳定下来了。
稍微了解一下PDU,PDU(电源分配单元), Power Distribution Unit也被称为“机柜电源插座”，如下两张图：
第六个故事：开阔视野——直面传说中的“oracle一体机”
原以为神秘又高大上的一体机，没成想，一个不小心，这个价值千万元级别的设备就这样活生生的展现在了我的眼前。
记得之前在一节oracle公开课中，简单了解了一下exadata（oracle一体机），在这里做个简单的回忆，从解决四方面问题入手的一体机。
（1）、如何解决传统数据库部署所带来的性能问题？
传统的数据库部署：
存储层：1、数据量增加IO瓶颈；2、数据分布不均；
网络层：带宽不足
服务器层：过多数据处理
?
解决思路：减轻负载、加宽带宽、提高并行
1、加宽通道
2、减少数据量传到数据库服务器
3、增加系统并行处理
?
理念化：
存储横向扩展，实现并行处理能力
存储层：智能化、预处理
服务器端的卸载预处理工作分担到存储层，处理完后返回给数据库服务器。
?
（2）、解决了资源独立，无法共享的问题？
传统数据库：
分配给不同的主机，不是共享的，分配资源不均，有些资源不足，有些资源过度。生产环境动态变化，无法动态满足负载的目标
?
设计原则：资源共享、资源控制
?
解决：
如：1、把存储服务器的资源变成一个存储池，一个存储池给一个或多个数据库使用，服务器都可以用到所有磁盘的能力，满足IO吞吐量；
2、对IO进行控制，根据业务的优先级来处理。
?
（3）、解决复杂的数据库系统均衡化配置？
传统数据库：
大型的存储系统，EMC存储；
分区；
设备昂贵；
技术维护管理；
总的代价开销非常大；
?
让一体机实现性能均衡化：
使用exadata，平衡及优化的配置
主机、存储、数据库、应用程序：调优
exadata端到端优化：硬件软件配置好了的
易于上线，不需设计、调优、维护、设置
?
（4）、如何解决系统的维护和扩容过程复杂
一体机：
简化部署：消除复杂部署；
当天部署完成，获得极限性能。
?
以上通过理论性、概述式的介绍了一下一体机，其中具体的技术细节并没有涉及到，如果对于exadata的技术真正感兴趣的朋友，不妨去看看官方手册或参考文档，相信会有所收获的。
这里对于一体机的了解我也是刚刚开始，就简单介绍这些吧，毕竟还是菜鸟，O(∩_∩)O~
?