作者：文平
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
AIX UNIX系统管理、维护与高可用集群建设试读：
前言
为什么要写这本书在所有的操作系统中，UNIX可能是最受争议的了！
认为其“不错”的有之：UNIX的开放性、运行稳定性、性能稳定性，以及多用户多处理的能力都证明其是可信赖的系统！
认为其“不好”的有之：UNIX有着40余载的历史，被微软视窗系统所“压迫”，被Linux系统所“替代”，被很多人误认为不易部署、难于学习！
无论你是否喜欢UNIX，一个基本的事实都摆在这里：当前的主流服务器系统都定位于UNIX系列平台，如IBM AIX、HP-UX、Solaris，等等。
作为一个传统的DBA和SA，我一直致力于UNIX平台上数据库系统的构建工作，工作目标不外乎两个：
构建可靠的服务器系统。可能出现崩溃，但一定能恢复。
构建可用的服务器系统。在资源使用上达到平衡，在效率上满足用户的性能要求。
作为应用系统的中心节点，服务器系统的可靠性和可用性将决定整个应用系统的服务状态，服务器的节点效率将制约整体应用的效率。但我在多年的工作实践中发现一个普遍存在的问题：绝大多数用户都在“头痛医头、脚痛医脚”，而不是系统地看待上述问题。实际上，系统构建和运行维护是一个系统工程，会涉及方方面面：
操作系统的运行效率和资源使用。
存储系统的运行效率和性能设计。
网络系统的运行效率和带宽使用。
数据库系统的运行效率和实例性能。
数据库应用的运行效率和代码优化。
数据库后台结构与后台设计优化。
在构建服务器系统这个系统工程中，操作系统是其中的最基本环节。稳定的配置、合理的操作、精心的应用部署和迭代化的运行调优等都是服务器运行的基本面。
让读者掌握操作系统的运行特征和管理方法并实现上述操作理念就是我写作本书的目的。如果要更深入地了解应用数据库系统方面的问题，请参考我的另外两本书《Oracle大型数据库在AIX/UNIX上的实战详解》和《Sybase数据库在UNIX、Windows上的实施和管理》，这两本书描述了数据库系统的问题、应用系统的问题和部署优化的问题。
这本书并没有写什么深不可测的技术，也没有去炒一些比较流行的概念，没有“人云亦云”。本书前半部分讲述的是AIX的基本概念和使用，后半部分则探讨了AIX应用的部署和运行、性能的分析和优化、高可用环境的设计和构建等。这些都是日常使用AIX UNIX会涉及的基本内容。
虽然本书致力于阐述细节，但是站在作者角度，我还真不希望读者沉浸在细节中！从细节中找到规律，从细节中归纳出概要，是我对大家的期望！本书的读者对象
本书定位于AIX UNIX的广大用户和学习者。写这本书的目的是帮助读者获得关于AIX UNIX的工程实践能力，本书来源于实践，也应用于实践。这一点，作为本书的作者，我是有相当的自信的！
但是，如果你选择这本书的目的是为了获得某个IT证书，那恐怕你会失望了！在当下这个有些浮躁的年代，为了让自己看上去是有能力的，于是出现了考证热。但是，拥有相关的资格证书并不意味着具备高能力。本书旨在帮助有志于从事AIX UNIX相关工作的朋友提高实践能力。
我希望每一个愿意学习的人，包括我自己，都能够放正姿态，学习一些本质的东西，学习一些在工作中能用的东西。真的假不了，假的真不了！如何阅读本书
本书以AIX UNIX为核心，从工程部署、系统管理、优化实践、高可用建设的角度，细粒度讨论了AIX UNIX的系统结构和组成，以及运维和管理的方法和过程。
全书共13章，第1章讨论了系统建设中的系统工程观点。第2章则面向AIX系统，综合介绍了AIX系统的技术要素和系统结构，“巡游”AIX，帮助读者建立对AIX的宏观认识。第3章讲述的是AIX系统的安装、网络的设置和管理，以及用户和权限的设置，“搭建AIX系统”是本章的目的。第4章则面向AIX系统设备，讲述了AIX中关于设备的管理、错误的查看和定位等问题。第5章从AIX使用的角度讲述了AIX的引导过程和模式、服务的管理和设置、任务计划的部署、运维中日志的查看等问题。第6章主要描述了AIX存储管理的层次结构，系统阐述了AIX中存储的各层次、相互调用关系、存储结构的工程实现等内容。第7章则在第6章的基础上，讨论了AIX中文件系统的创建、设置和管理。第8章讨论了AIX系统的备份和恢复，这是所有UNIX系统中最重要的管理话题之一。
从第9章开始，内容偏向于AIX系统的应用和工程实践。第9章讨论的是AIX上的平台服务建设问题，并以AIX上最常见的Oracle、DB2、Sybase系统为例，描述了将AIX部署为数据服务器的工程过程和指导方法。这里没有孤立地看待UNIX问题和数据库问题，而是把它们融为一体，系统地阐述了其环境设置和系统管理等问题。第10章面向AIX应用服务的效率问题，着重讨论了AIX系统的优化，包括系统优化中的指标分析、问题定位、调优策略等问题，目的在于帮助读者构建一个整体优化的计算机系统。
第11～13章讨论了AIX中集群设计和集群建设的问题，详细讨论了AIX中使用的PowerHA（HACMP）集群和GPFS集群这两种构架，分析了集群中的存储问题、拓扑结构问题、高可用资源定义和集群共享文件系统等问题。这3章的目的只有一个：帮助读者构建具有高可用性的集群系统！勘误和支持
感谢你对这本书的信任！
由于我大多数的时间都花在了系统优化、用户培训和方案评审等方面，剩下的时间少得可怜，因此本书历经三年才完成。很多时候是白天处理完某个技术问题，晚上再抽时间把相关的内容写出来，我称之为“写了一个段落”。
其间，低落的时候有之，亢奋的时候有之，思如泉涌的时候有之，反复重写的时侯亦有之！
在我的坚持和努力下，这本书终于完成了。
作为一个技术工作者，我深知自己对技术的理解不一定透彻。虽然我力争仔细论证，以使其100%正确，但是疏漏之处在所难免。
这让我想起美国前国防部长拉姆斯菲尔德的著名演讲"as we know"：
The Unknown As we know，
There are known knowns.
There are things we know we know，
We also know There are known unknowns，
That is to say We know there are some things We do not know，
But there are also unknown unknowns，
The ones we don't know We don't know.
上述这段著名的饶舌体是我深为信服的，我且做一个简单翻译，如下所示：
据我们所知，
我们已经知道一些，
我们知道我们已经知道一些，
我们还知道，
我们有些并不知道，
也就是说，
我们知道有些事情我们还不知道，
但是，还有一些，
我们并不知道我们不知道，
这些我们不知道的，
我们不知道。
书中可能有什么错误，可我并不知道！所以，如果有什么错误，请你谅解我，强烈希望你能告诉我。本书的相关支持网站为www.usedb.cn，我的邮箱为wenping@usedb.cn，欢迎你多提宝贵意见。致谢
我前面多次强调了本书主要讲解的是IT系统构建中的系统工程问题。其实，本书的出版又何尝不是一个系统工程呢？
本书的立项和推动离不开业界的两大策划编辑的鼎力支持——来自电子工业出版社的胡辛征老师和来自机械工业出版社的杨福川老师。二位编辑在本书的创意和内容上提供了广泛建议，在我写作本书时又不忘适时推动和鼓励。作为本书的作者，我要感谢他们；作为朋友，我以此为豪！
作为本书的作者，我必须坦率地承认，凭一己之力，是很难完成这样一本技术专著的。在撰写本书的过程中，我幸运地与陈晓丽女士成为同事。几年中，她已从一个青涩的IT女孩成长为数据库领域颇具权威的技术专家。她是一个质朴的人，每天带着浅浅的微笑上班，从容淡定地工作，为用户提供着完善的服务，为团队提供着坚实的支撑！与小陈合作是件愉快的事，她为本书的成稿提供了大量的实践经验和编写意见。感谢小陈，并祝她生活幸福、事业有成！
近几年来，我出于兴趣，陆续出版了若干本技术专著，范围涉及数据库开发和优化、Oracle系统管理与优化、Sybase系统管理与优化、UNIX部署和管理等。细想起来，在这些书的致谢中，从来没有对家人的感谢！实际上我深深地知道，她们的支持和毫不吝啬的鼓励，才是我放开手脚做自己喜欢的事情的核心动力。感谢我的妻子和女儿！另外，我也想给惧怕写作文的女儿做个榜样：写作文没什么难的，你只要朴素地把想法表述出来就可以了！
最后，请允许我向本书的编辑杨绣国和姜影女士表示敬意，她们的文字功底和技术修养令人赞叹，她们的工作态度令人敬佩！谢谢你们在本书内容上的锱铢必较，使本书的内容更加完美！文平2011年7月于北京第1章 面向系统架构的系统工程
本章内容
架构是系统工程
服务器选型原则
服务器存储部署
数据库物理布局
服务器的内存使用
数据库结构设计
从系统工程看架构编者按
2011年初夏，中国数据库技术大会在北京隆重召开。在这次面向数据库及商业智能技术专业人群的技术盛会上，各路DBA、数据库开发工程师，以及商业智能领域的专业人士齐聚一堂，互相分享和交流各自在数据库技术领域和商业智能领域的研究体会和最佳实践。
在IBM DB2数据库应用实践专场中，本书作者文平老师做了题为“数据库架构设计与面向DB2的工程实践”的演讲。演讲以DB2数据库架构为主线，综合阐述了主机系统、存储系统、网络系统、应用系统、数据库系统之间存在的关联性和因果关系，提出了要以系统工程的方式方法来解决系统构架问题，以保证综合系统的可用性、可靠性和性能。
在进行系统选型时，用户选择的AIX、HP-UX等大型系统是做什么用的？
不会用于Web应用发布和邮件服务，因为有性价比更高的Linux网络服务器和Windows网络服务器。
很少用作中间件服务器，因为Linux和Windows低端集群可以更好地均衡化部署。
AIX、HP-UX等大型系统在大多数情况下会作为数据库、数据仓库类应用的承载平台，这似乎已经成为惯例。在AIX等系统上部署数据库应用系统似乎是理所当然的，而且部署的大多是DB2、Sybase、Oracle等一类的数据库应用系统！
AIX的部署要为上层的应用服务，这点毫无疑问！在考虑AIX的架构时，必须要为上层应用考虑其存储规划、进程调度、内存使用、优先级、用户安全、使用效率等问题，而且这些问题需要站在操作系统、应用系统（数据库）之上来综合考虑。
文平老师的这次演讲所关注的问题就是：从系统角度出发，从整体上考虑和设置操作系统与数据库应用系统，实现对系统的优化，从而使之更可靠！
这里将演讲内容（节选）作为本书的开篇，意在为读者提供一个全面的思维框架，以系统的观点看待问题，从而避免学习上的片面性！
谢谢文平老师的经验分享！演讲主题与概要（1）演讲主题
数据库架构设计与面向DB2的工程实践（2）演讲概要
在应用系统中，系统的架构设计对系统的综合性能表现、数据可靠性保证、业务连续可用性起着决定性作用。良好的系统架构有着各自的特质，而劣质的系统却有着相似的问题。
这次演讲希望与大家分享数据库架构设计的重要性、设计过程中需要考虑的若干要素，以及如何避免具有共性的若干设计问题。
本次演讲以DB2数据库系统为实践案例，主要内容如下：
研究数据库系统与宿主平台的关系
影响性能表现的诸因素
针对UNIX系统的数据库部署与优化
系统资源针对数据库的分配
应用架构设计中的数据库设计问题
数据库高可用和可恢复性部署
以下是文平老师本次演讲中的部分具体内容，希望对大家有所帮助。1.1 架构是系统工程
本次演讲的内容关注的是数据库服务器这个领域，虽然我们在试图将组件和功能模块化，但系统各组件间的确存在着不可割断的关系。在服务器平台领域存在着如下的调用层次关系：
主机提供内存资源和CPU资源来运行应用系统和数据库系统。
应用系统以进程和进程组的方式运行，并与其他进程共享计算能力。
数据库以表和索引等为基本数据结构，逻辑化存储数据。
数据最终以块和页的形式存储在磁盘设备上，通过系统I/O机制对其进行访问。
数据的I/O访问方式、访问总量、访问路径决定着系统的效率。
数据的I/O访问方式就是随机读写、连续读写、条带化读写、镜像读写。
数据的I/O总量就是数据操作中原结果集、中间结果集、最终结果集的大小。
数据的I/O路径就是SQL语句执行时的数据扫描过程和先后顺序。
数据库优化器模块会使用CPU资源来编译和执行SQL语句，确定数据的访问方法。
数据库优化器在决定SQL语句执行路径时，与数据库的E-R结构关系密切。
SQL语句在执行中会通过CPU来执行确定计划、函数计算、排序等操作。
SQL语句在执行中可通过恰当的缓存机制来优化系统磁盘在I/O操作上的滞后性。
其他相关的各种细节和关联关系。
正因为有如上这些关系，所以说数据库系统是一个典型的整体系统。数据库为用户提供的服务不只是数据库的贡献，而是操作系统、数据库系统、存储系统、应用系统、网络系统的共同成就。
虽然我们力争将问题简化，但是，以系统工程的观点来看待数据库构架是一个基本的要求。虽然我们在具体的产品形态上可以采取不同的产品或技术，如主机采用AIX，数据库采用Oracle，或者主机采用Linux，数据库选择DB2，但是平台可以换，各个子系统间的关联关系却不能视而不见！
就DB2而言，上述的系统性关联关系不仅存在，而且可以通过恰当设置达到最优化的目的！1.2 服务器选型原则
做技术选型时，用户首先要清楚地了解应用的类型和特点，然后才能选择合适的平台。
由于技术在不断发展，IBM的Power系列服务器上可以运行AIX、Linux等多种操作系统。如果考虑到Power VM虚拟化，它甚至可以运行x86应用。因此，应用的负载类型是用户需要考虑的最关键要素。
负载可以总结为两大方面：高吞吐量计算类型、大规模并发计算类型。
数据库应用属于典型的高吞吐量计算类型。这种应用需要在很短时间内快速从存储位置访问数据，并快速返回计算结果。这要求服务器有高的吞吐量、高的CPU主频，而不能简单地增加CPU数量。高主频是数据库服务器的首选，例如IBM Power系列的CPU，其主频可高达5GHz，远高于通常的2GHz到3GHz的主频。正因为如此，IBM Power系列的服务器非常适合于DB2等数据库应用。
数据库应用同样也属于高度并发的应用类型——多用户并行访问！多用户访问使服务器产生多会话，这需要服务器有良好的进程和线程处理能力。如果内核数量多、线程处理能力强，则服务器同时处理的用户数量也就越大。如果采用IBM的Power 7 CPU，使超高的主频设计、内置8核与并发32线程的处理能力，使运行效率非常“可观”！
我个人认为，服务器选型时需要了解一个问题：即是否需要“过度消费”？毫无疑问，我们很难、或者说无法计算出一个业务系统究竟需要多大的“计算能力”，这是一个几乎让所有用户头痛的问题。但很明确的一点是：总体拥有成本将包括硬件采购、软件采购、运维支出、管理支出等综合费用。既然很难精确算出“计算能力”，那我们不妨采用“过度消费”的方式，原因很简单，也许“过度消费”能降低总体拥有成本。“过度消费”这样的做法不是没有道理的！系统性能是所有系统的重要指标，而性能则依赖于应用代码、SQL代码、数据库结构、应用访问结构、数据库服务器处理能力、网络处理能力等众多因素。作为一个数据库应用优化顾问，我发现绝大多数应用系统的性能问题都集中在结构设计和代码层面，相信各位同行也会有同样的感受。因此，在实践中，数据库系统的优化被演绎为数据库结构优化、SQL代码优化、应用程序编码优化等。这类工作需要大量的高级技术人员长时间投入，从而增加了应用系统的总体拥有成本，其支出可能会远高于服务器选型中的“过度消费”。
毕竟，人的成本是最贵的！
很多时候用户喜欢讨论这样的问题：CPU数量和CPU主频哪个更重要？我认为CPU主频更重要一些。除了技术层面的问题，在支出上，DB2、Oracle等数据库系统都是按照CPU的核数收取License费用的，因此选择CPU内核数少、但主频高的服务器可以节省购买软件的费用，何乐而不为？
对于“过度消费”这样的情况，如果我们采用一些虚拟化技术，如动态分区，可以使机器的利用率大幅度提高。1.3 服务器存储部署
对于中小型系统而言，DB2和Oracle等数据库服务器无论怎样部署都没有太大的问题，重点是把握好可恢复性。对于性能敏感、数据量巨大的系统来说，例如TB级的系统，其所使用的服务器硬件一般都功能强大，而且是经过恰当部署和设计的，对系统的后期性能表现具有直接的影响，尤其是那些有着海量磁盘和内存的大型服务器。
近些年来，CPU的发展速度可以用摩尔定律来描述，内存技术的发展也是一日千里，存储技术的发展又如何呢？在存储领域，存储技术还是围绕着机械转子带动多个磁盘硅片，人工存储数据信息。
磁盘的I/O速度取决于转速。转速增加，结合磁盘上的缓冲控制，会使数据的读写效率有所提高。但与CPU的速度相比，磁盘的速度相对来说越来越慢了。这个速度差异导致单磁盘根本无法与CPU的速度匹配。鉴于物理磁盘的物理特征和能力，解决磁盘速度问题的唯一方法是存储虚拟化，这就需要磁盘阵列设备的参与。同理，若干年前我们常做的存储分布指南——表和索引的存放守则、磁盘使用区域的位置指定，在今天的虚拟存储环境中基本都没有什么意义了。
我们在设计和使用磁盘阵列时，除了计算所需的存储容量外，还需要考虑存储系统的性能指标：支持的访问次数（单位时间的I/O操作次数，IOPS值）和数据传输率（每秒传输的数据量，TPS值）。
磁盘阵列支持的I/O访问次数和I/O数据传输率与阵列的RAID设计算法相关，也与组成RAID的物理磁盘数目相关。一般的规则是，写类型操作适用于RAID 10型的算法，读类型操作适用于RAID 5算法。鉴于这种性能影响，我们建议部署数据库事务日志到RAID10磁盘组上，因为作为数据库的可恢复性保证的数据库事务日志，是写操作频繁的数据库组件。所以，DB2的日志文件、Oracle的日志文件、Sybase的日志设备等放在RAID 10设备上为宜。
数据库是一种典型的多用户并发类型的服务器系统，这就导致多个用户进程同时访问一个磁盘设备时可能出现磁盘冲突问题。所谓磁盘冲突，就是存储子系统访问超过IOPS和TPS限制后，后续进程需要等待。
避免磁盘冲突是存储部署设计的一个重要目标，其最有效的手段是将I/O最大限度地平衡到多块磁盘上去，也就是I/O负载均衡。我们前面所采用的RAID10、RAID5等条带化技术就是一种可以自动将I/O均衡负载到多物理磁盘上的技术，也就是将一次逻辑I/O操作分离为多个小部分，每个小部分分别存储到不同磁盘上，这样多个进程就可以同时访问数据的不同部分，降低了磁盘冲突的可能性。同时，在对数据进行顺序访问时可获得最大程度的I/O并行能力，提高I/O性能。
条带化是当前存储系统的不二选择。现代操作系统、现代磁盘阵列、各种第三方软件都支持条带化技术。例如AIX、HP-UX等都在LVM上支持条带化，Oracle通过ASM支持条带化，DB2通过自动存储表空间模式来有限支持条带化。
既然存储技术指标中的I/O访问次数、I/O数据传输率与阵列的RAID物理磁盘数目相关，那么通常的公式或经验值也许值得借鉴。在IBM Power系列服务器中，CPU处理的高速度，要与一个拥有足够物理磁盘的RAID逻辑磁盘的I/O速度匹配。一个经验性的标准是，每CPU争取可以对应15到20块物理磁盘，甚至更多。1.4 数据库物理布局
在对数据库进行物理布局设计时，简单性是我们一定要达成的一个目标。也就是说，越简单越好！这往往需要权衡：一方是我们为数据库的某个表和索引设置的某种最优的I/O路径，另一方是管理员为了维护这个更加复杂的存储结构而投入的时间。实现高性能、追求简单明了，都是我们的目标！
下面的几个要点是我们一定要遵守的。这些要点并不复杂，甚至比你想的还简单！（1）将数据库日志和数据分开存储
从系统可恢复性和性能方面来讲，事务日志要和DB2、Oracle等数据库系统的数据分区域存储。为每个DB2分区上的事务日志配置专门的磁盘或LUN，用于存放日志的磁盘数目和数据的磁盘数目，其数目对比应参照系统的典型工作载荷。对联机系统而言，日志和数据的磁盘数目比可以为1:5。（2）可以考虑使用特定的文件系统来替代裸设备
对于AIX等现代操作系统而言，其文件系统对直接I/O模式和并发I/O模式有很好的支持。在典型的数据库类应用中，启用并发I/O模式的系统的I/O性能已经接近甚至达到裸设备的性能了。但由于文件系统提供了简单性，比裸设备方式具有更好的可管理性，因此，使用并发I/O来替代裸设备是一个非常好的选择，尤其是对DB2系统来说，我们可以把一个I/O模式挂载的文件系统交给DB2，使其作为一个容器被DB2表空间使用。
在创建DB2的表空间时，我们可以指定NO FILE SYSTEM CACHING命令来启用直接I/O或并发I/O，目的是让DB2在文件系统上的I/O操作具有接近裸设备的性能。（3）设置DB2的DB2_PARALLEL_IO注册变量
如果DB2数据存储在一个并行的RAID设备上，这时我们可以设置DB2的DB2_PARALLEL_IO注册变量，告知DB2其对应存储设备上的表空间和数据容器的I/O并行度，即每个容器所依托的磁盘数目。
如果我们用9块盘做成了RAID5，则可以设置DB2_PARALLEL_IO为8，即：
db2set DB2_PARALLEL_IO=*:8（4）磁盘阵列逻辑盘条带尺寸与DB2的对应
当磁盘阵列创建逻辑盘时，我们需要指定“条带化”参数。在磁盘阵列的一个RAID逻辑盘中，其成员磁盘上连续分布的数据片段的大小被称为“条带尺寸”，这些分布在所有组成磁盘上对应位置处的片段被称为“条带”。
在DB2数据库中，表空间的扩展数据块尺寸（EXTENTSIZE参数）应设置为RAID条带的对应大小或整数倍。
一般可选的RAID条带大小为128KB、256KB、512KB等。如果在一个512KB条带尺寸的系统上，DB2使用了8KB数据页，则EXTENTSIZE参数可设置为64。（5）可以使用DB2自动存储机制来简化和优化存储
DB2支持自动存储管理，类似于Oracle的OMF（Oracle管理的文件）和ASM（自动存储管理）。在自动存储管理模式下，我们只需要为DB2提供若干个文件系统存储区域即可。
自动存储管理为DB2数据库系统的存储管理提供了一个简单又实用的条带化方法，我们只要能够提供一样大小的存储路径或文件系统，而且这些存储路径拥有一样的I/O能力，它们在并行操作下性能一致，其空间大小也是相同的，即可防止一个存储路径被过早填满，导致其他存储路径不可用。
实际上，上述原则对Oracle系统和Sybase系统也都是基本适用的。例如，Oracle的ASM技术和ACFS技术就与DB2的自动存储管理在思路上很相似。1.5 服务器的内存使用
由于服务器的CPU和I/O设备之间存在着速度差异，用足够的内存作为“速度差”的弥补也就显得非常必要了。目前，数个GB内存的个人计算机已经很普遍了，配置了64GB、128GB内存的数据库服务器也相当常见。一般而言，大的内存总量可支持高的数据库运行效率，极端的情况是数据库共享内存结构已经大到可以把整个数据库装进去运行。
在这里我要提醒大家的是，在为数据库分配内存时，绝对不能让数据库系统所消耗的内存量接近物理内存量，因为操作系统需要物理内存来运行，否则会导致操作系统虚拟内存管理器引发换页操作。
究竟分配多少合适？没有固定的比例，约束倒是有一个，那就是我们要时刻关注系统的换页操作情况。在系统存在“稳定的”换页操作的情况下，适当降低数据库内存的使用是必要的，毕竟数据库要依赖操作系统来运行。1.6 数据库结构设计
一个系统应用的整体性能，不仅取决于服务器硬件的表现，更取决于应用系统的设计和开发，也就是设计水平和编码水平。
在对数据库类应用进行优化的过程中我们了解到一个原则，即思想上要从结构设计抓起，按照下面的顺序：
1）数据库逻辑结构设计和物理设计。
2）数据库对象部署和SQL代码编写。
3）数据库实例性能调整和优化。
4）操作系统性能调整和优化。
5）存储系统性能调整和优化。
6）网络系统性能调整和优化。
上述顺序表述的是这样一种思想，即以设计为源头，会从根本上决定一个系统的总体性能特征。数据库和操作系统层面的调整对性能的贡献会很有限。
但在实践中，上述做法可能并不可行：对于已经上线的系统来说，设计调整是天方夜谭，代码调整是痴人说梦。优化顾问、高级DBA所能做的，仅仅是对数据库局部对象的分析和调整，例如对索引结构的分析和调整。
不能忽略的一点是，索引结构的调整可能意味着极其高昂的成本，主要的因素有两个：
其一，需要专业素质相当好的DBA或程序员；
其二，调整索引有两种可能的结果，好的或坏的。
经验告诉我一点，这是一件投入极大的事情，首先要找到数据库的瓶颈表和SQL，然后找到表上执行过的大多数具有代表性的SQL，并分析其路径，找出可以调整的索引结构，再判断调整后的索引对前面提到的SQL的作用，最后才能确定是好是坏。
我们看到很多文章和著作在讨论SQL优化时都喜欢这么写（包括我自己）：对于会导致瓶颈的SQL，可以通过索引调整进行优化！可以这么说，但是如果真这么做就可能会出错：把导致瓶颈的SQL调整好了，同时又把好的SQL调整坏了！
我知道这么看这个问题有些悲观，但有一个问题确实需要我们注意——优化SQL和索引对象往往是十分耕耘一分收获！从设计和原始开发的角度来解决性能和优化问题，才是我们进行性能调整的关键！
在设计数据库模型结构时，我认为必须遵守以下几点：
1）在范式问题上，将数据库设计为第三范式（3NF）是有道理的，因为在第三范式下，数据实体和属性将被精确表述，冗余数据将不再存在。
2）必须站在开发未来程序的高度上看，考虑利于开发和运行效率的非规范化问题，通过垂直分割来减小表的规模，通过垂直分割来分离冷热数据，通过数据冗余来减少连接和计算。
3）应该区分数据面向业务中的特征，如区分核心表和外围表、事实表和维度表、代码表和数据表，争取设计出具有数据生命周期特征的字段。
4）考虑部署中的分区问题，无论是节点间分区还是节点上分区，分区的大小尽量均衡。
5）考虑表中数据的变化趋势，将数据表区分为恒数表和变数表。考虑对恒数表设计大量的索引，而对变数表要谨慎使用索引。
6）创建索引时选择那些选择性高的列，并谨慎使用复合索引。要时刻注意具有关联关系的表上分区和索引定义是否合适。
7）数据类型定义一定要合理，要严格避免数据类型不匹配所造成的SQL数据隐式类型转换问题。
数据库设计可能更倾向于艺术，而非技术！1.7 从系统工程看架构
在前面的架构相关性论述中，我并没有加入关于应用开发的论述，这不等于开发不重要，而是因为我的演讲时间有限。我与机械工业出版社合作的下一本书《Oracle数据库系统性能优化的艺术》中将对应用开发问题进行重点讨论。
我的演讲就到这里，有关操作系统架构的技术细节请阅读本书，有关数据库系统在UNIX上部署的内容请阅读我以前写的两本书《Oracle大型数据库系统在AIX/UNIX上的实战详解》、《Sybase数据库在UNIX、Windows上的实施和管理》。很高兴今天可以与大家分享数据库服务器架构设计的重要性、设计过程中需要考虑的若干要素，以及如何避免具有共性的若干设计问题等。
谢谢大家！文平2011年4月15日第2章 AIX UNIX的系统结构
本章内容
UNIX代表作：AIX
AIX UNIX的构成要素
了解AIX UNIX
AIX UNIX的系统结构
AIX UNIX手册的使用
熟悉Linux的用户掌握AIX的快捷通道本章导读
在很久以前的一次技术培训活动中，我作为技术顾问向大家介绍AIX UNIX系统和Sybase数据库系统，在日程已过大半后的某个时刻，一位学员向我提了一些问题。
学员：文工，咱们现在学习的是AIX还是Sybase？
我：我们正在学AIX，目前已经学习了系统安装、用户管理、存储管理、网络管理、Shell和命令、备份恢复，正在学习Sybase系统的部署和管理，以及Sybase如何使用AIX逻辑卷作为裸设备……
学员：那AIX究竟都包含哪些东西，都涉及哪些范围，在系统中提供什么服务？
我：我们已经学过绝大多数AIX组成部件了，我们学了……
崩溃！失败！
在学员缺乏整体概念的情况下，过早进入AIX细节，这对掌握系统是没有好处的！AIX系统太过庞大，其技术细节往往吸引了大家太多的注意力，从而使大家忽略了在结构层面对AIX的理解，也就是只见树木，不见森林，这会给大家带来学习上的困惑！
本章的写作目的是试图带领大家“巡游”AIX UNIX，从一个整体和宏观的角度来介绍整个AIX UNIX系统，了解其体系结构和工作原理，综合掌握以下要点：
运行在RS6000服务器上的AIX UNIX环境和运行状态。
AIX的构造模块、数据存储结构、应用进程结构和服务子系统的组成。
AIX系统管理的常用操作、命令使用和管理方法。2.1 UNIX代表作：AIX
AIX全名为Advanced Interactive Executive，它是IBM公司主要用在RS6000系列服务器上的UNIX操作系统。从主机硬件、网络、存储到虚拟性设置，AIX整个系统的设计都完全遵守开放的原则。
AIX是目前应用最广泛的操作系统之一，主要用于应用系统中关键数据的计算和处理，如运行Oracle、Sybase ASE、DB2 UDB等大型数据库系统，以及Oracle iAS、WebLogic等中间件系统。AIX包含诸多大型机的特征，如系统完整性、可管理性、可用性、组件化等，这些功能让关键业务用户称赞不已。国内大多数的银行系统、电信系统等高要求的IT应用都采用AIX，这用事实说明了——群众的眼睛是雪亮的！
AIX UNIX是一种运行在RISC技术下的拥有先进内核技术和最好开放性的系统。从RS6000服务器商业化到今天，在短短的十几年里，AIX在IBM p系列服务器上已经被广泛运用。依托IBM在计算机体系结构和操作系统技术上的数十年经验，AIX最大限度地使用了RISC技术，并成为顶尖的UNIX操作系统之一。
AIX在遵循主流UNIX标准的同时，还开发了极具个性的独特技术分支——可以随时动2.2 AIX UNIX的构成要素2.2.1 内核、Shell与文件系统
登录AIX时，就已经启动了一个服务于这个用户的Shell，该Shell会把用户执行的命令解释成一组系统调用（System Call），或者说解释成内核可以理解和执行的命令。所有的这些系统调用都是众多函数的集合，不能由用户直接使用，且更不能用于交互式运行。
通过系统调用对这个抽象层的封装，AIX系统既实现了模块化的结构，又防止了用户对内核的直接访问，从而避免了对系统造成破坏。
因此我们可以这样总结：Shell就是命令解释器。当我们发出UNIX命令时，Shell会将其解释为某种系统动作。例如，如果用户要运行DB2数据库，Shell会告诉内核，通过I/O子系统从硬盘中找到DB2二进制文件，读取这些DB2二进制文件并将其装入内存。同时在物理内存中申请缓存区域（内存结构），调度CPU时间片段派生出DB2后台进程（db2sync等）。然后，DB2数据库系统开始运行，并接管用户的数据库请求。
但是，不能只将Shell看做一个命令解释器。Shell本身也提供了完整的编程语言环境。我们可以使用这个编程环境编写Shell程序。通常这些Shell程序被称为命令脚本，它由多条Shell命令和程序控制结构组成，并作为一个程序单元在Shell中运行。
随着UNIX产品和技术的不断成熟，在目前常用的工程环境下有若干种各具特色的Shell系统，这些不同的Shell彼此有一定程度的关联和区别。最普通的Shell也许就是Bourne Shell了，它在系统中称为bsh，具有相当大的灵活性和强大的功能。另外两种流行的Shell分别是Korn Shell（ksh）和zShell（zsh）。这些Shell在语法上非常相似，ksh和zsh都是对Bourne Shell进行改进后的版本，AIX中默认的Shell为ksh。
在AIX（或者说UNIX）中，文件是操作系统中极为重要的一部分。从Shell的角度来看，计算机系统中的任何一部分都是文件——程序是文件，目录是文件，硬件也是文件！由于Shell把所有内容都看做文件，因此一个有效管理的文件系统也就成了AIX中不可缺少的组成部分。
内核、Shell、文件系统构成了AIX系统的主体。但仅有这些是不够的，必须还要有能提供业务服务的应用系统，否则要操作系统做什么！AIX作为一个良好的服务器平台，可以运行各种应用系统，如DB2等数据库系统、SAP等ERP系统、Kingdee等财务系统等。本书将讨论如何部署和管理AIX系统、部署和管理高可用系统，以及部署和优化应用系统等。2.2.2 逻辑卷管理器（LVM）
在传统的UNIX系统中，使用磁盘前，首先要根据预期的文件系统大小在磁盘上创建对应大小的磁盘分区，然后将文件系统建立在该分区上。
利用传统的磁盘管理技术，我们需要首先创建磁盘分区，再通过分区来部署文件系统。由于在创建分区时必须占用磁盘内的连续物理空间，即从一个柱面到另外一个柱面，因此一个分区最大不能超过其物理磁盘的容量限制。
随着磁盘链接技术的出现，不同的物理磁盘可以链接在一起，形成了逻辑磁盘。这样，所创建的分区就可以跨越多个物理磁盘。这种方法不仅提高了磁盘的容量，系统I/O性能也因此获益，因为多磁头同时进行硬盘访问可以有效提高磁盘存取速度。在具体的产品层面，这通常被称为RAID存储方式。
目前，在稍具规模且对高可用略有要求的数据库系统中，RAID磁盘存储设备是不可或缺的！这种存储方式也存在问题：如果生产系统中的存储容量需要扩展（如扩大文件系统），则系统必须停止运行，然后通过重构分区的手段来进行分区扩容和文件系统扩容。一般采用的方法是先备份该文件系统并删除分区，然后重构更大的分区，再重构文件系统，最后将数据装载回来。在此期间，所有应用系统的服务必须停止，这会给支撑关键业务的数据库系统的维护造成很大的困难。
但是，AIX系统完美地解决了这个问题。通过AIX LVM（Logical Volume Manager，逻辑卷管理器）——一个介于应用与硬件之间的存储管理软件层，文件系统不再需要直接建立在磁盘分区上，而是可以建立在逻辑卷（Logical Volume）对象上。由于逻辑卷是一个指向若干物理分区（Physical Partition）的集合，因此它是一个可以跨越多个物理磁盘的存储机制，这点甚至有点类似“云存储”！
从逻辑卷的角度上看，其数据块是连续的，但是从物理磁盘角度来看，一个逻辑卷所包含的物理分区却是离散的。只要有空余的物理分区并将其添加到逻辑卷这个“集合”中，逻辑卷的空间就得到了扩充，如图2-2所示。图 2-2 物理磁盘到逻辑分区的映射关系
另外，应用程序不会直接对逻辑卷执行物理存储操作，只执行独立于物理设备的逻辑分区存储操作。逻辑分区的存储操作将由LVM来完成，然后LVM将逻辑上的存取操作提交给内核来执行对应的物理磁盘操作。至于其内部如何操作，这就是LVM的事情了，或者说这属于AIX的知识版权，我们不必管它。
因此，通过AIX逻辑卷管理器的存储管理，传统UNIX在存储方面的诸多问题都得以解决：
逻辑卷可以使用不连续的物理空间，并且可以动态调整其容量。
通过镜像技术，逻辑卷改善了数据访问的性能，提供了关键数据的高可靠性。
通过损坏数据块的映像重构，逻辑卷具有了自发检测和修复的能力。
由于它支持SMIT工作环境，LVM的磁盘管理简单而快捷。2.2.3 日志文件系统（JFS/JFS2）
作为一种主流的UNIX系统，AIX同样提供了文件系统的功能。在AIX中，创建在逻辑卷上的文件系统挂载在目录树上，用户可以通过这个目录树方便、快捷地管理文件并使用磁盘空间。这个目录树是按照分层结构来组织的，形成了一棵倒置的树。各种不同的程序模块在该文件树中按目录分组，形成了与其他UNIX系统类似的文件系统结构，如图2-3所示。图 2-3 AIX的文件系统结构
从图2-3中可以看出，AIX文件系统的最高层是以“/”表示的，它被称为根目录。其下的所有目录都被看成是“/”下的子目录。子目录中既可以放置文件，也可以创建下一级的目录结构。系统启动后，文件系统的挂载情况如图2-4所示。图 2-4 AIX中文件系统的挂载状态
注意上面文件系统的类型（vfs列）。在AIX中，一般可以使用5种类型的文件系统：
日志文件系统（增强型）（Enhanced Journaled File System,JFS2），AIX本机支持的一种文件系统。
日志文件系统（Journaled File System,JFS），AIX本机支持的一种文件系统。
网络文件系统（Network File System,NFS），指通过RPC（远程过程调用）允许文件保存在远程NFS服务器上。
CD-ROM文件系统（CDRFS），允许CD-ROM的内容通过通用文件系统界面进行访问。
集群文件系统（General Parallel File System,CPFS），一种在集群环境下可多节点共享的文件系统。
传统的UNIX系统并不能保证在系统故障后不损失文件，尤其是当文件处于“动态”的变化中时。AIX集成了数据库日志技术，如果文件发生更改，首先会在一个日志中记载文件结构信息的变化，然后再相应地调整文件内容。
这个用于记录文件系统的结构信息（元数据）变化的日志就是JFS log。文件系统发生崩溃等事故后（如数据不一致等错误），AIX将通过这个日志来恢复文件系统。在AIX安装之初，系统默认创建的日志设备（JFS Log）是逻辑卷/dev/hd8。管理员后期创建新的文件系统时，也可以创建其他的日志设备。
被日志化的文件系统借鉴了数据库保护数据的日志技术，日志文件系统以日志形式记录了文件的变化历史，确保了系统在任何时候都能够维护数据的可恢复性，这就是AIX的JFS。JFS2是JFS的增强版，JFS2使AIX中的文件系统可以具有更大的容量和动态可管理性。2.2.4 系统管理界面工具
对于熟悉AIX的用户来说，AIX能让他们过目不忘的可能是SMIT（SMITTY）这个简单的工具了！SMIT（SMITTY），全称为System Management Interface Tool，是AIX系统用于系统管理的工具环境。它以功能菜单的方式为用户提供一个管理接口，从而完成相应的系统管理功能。
SMIT工具有两种工作环境：ASCII字符终端界面和AIX图形终端界面。使用ASCII字符终端时，在#命令行环境下执行smit命令或smitty命令都可以进入SMITTY工具的主菜单。如果是图形终端，则调用smit命令进入图形界面的SMITTY主菜单项，它支持鼠标操作。
SMIT工具简单易用，但包含系统管理的绝大多数功能。如图2-5所示的SMITTY菜单工具，它几乎涵盖了AIX的所有备份功能。图 2-5 AIX中的Smitty菜单工具示例
SMITTY不仅提供了直截了当、简单易用的系统管理环境，还通过两个日志文件（smit.log和smit.script）记载了用户所执行的所有smit操作。
这就给了我们一个生成命令和脚本的捷径——利用Smitty脚本文件生成我们自己的脚本文件。何其方便！2.3 了解AIX UNIX
目前已经有几十种UNIX系统，AIX是其中之一。但是，无论是AIX，还是HP-UX，或者是中小型系统Linux，它们都有着非常多的共性，同时也具有各自的特征。这一节我们来看一看AIX与其他UNIX的共性，以及属于它自己的个性。2.3.1 登录AIX系统
一般而言，AIX系统有两种类型的用户界面：AIX通用桌面环境（Common Desktop Environment,CDE）图形用户界面和基于终端的命令行界面。AIX CDE以X窗口系统为基础（UNIX中的X窗口系统，简称X，是一种网络窗口系统），允许用户通过图形方式来存取网络设备和工具，用户只要简单地拖放鼠标并单击对象，无须知道它们的具体位置。AIX CDE的功能类似于Windows系统的桌面。
但是很显然，此桌面非彼桌面。与Windows相比，AIX CDE则显得初级、简陋和生涩。但是，作为一个服务器平台，漂亮的桌面不是最重要的，计算能力才是真正的能力！为此，很多AIX用户甚至放弃了桌面环境的使用，以节省资源，便于关键业务的运行。
CDE通过如图2-6所示的界面登录系统，输入用户名和口令后，即可进入AIX CDE环境。
在验证了用户名和口令后，AIX就会进入AIX CDE环境，如图2-7所示。图 2-6 AIX系统的CDE登录界面图 2-7 AIX系统的CDE工作环境
命令行界面是字符界面，即基于命令行管理的方式，单击图2-7中的Terminal菜单项，即可以进入如图2-8所示的命令行终端界面。图 2-8 命令行终端界面
在这个界面的控制台命令行下，我们便可以完成所有的AIX管理任务和维护任务，包括命令的输入和执行，以及Smitty的使用等。2.3.2 RS6000的硬件结构
下面先来熟悉一下这台服务器的物理结构、设备构成和操作系统的特征。在命令行终端界面中，使用AIX的一个专用命令prtconf来输出这台AIX服务器的物理构造信息，命令如下所示：
#prtconf
在返回结果中，我们首先可以看到AIX服务器的总体信息，比如服务器的型号、软件安装版本、机器特征等。例如，在下面的返回结果中，我们可以看到一台IBM p750服务器的安装特征：
System Model:IBM,8233-E8B
Machine Serial Number:064EC9P(服务器序列号)
Processor Type:PowerPC_POWER7(CPU类型为Power7)
Processor Implementation Mode:POWER 7
Processor Version:PV_7_Compat
Number Of Processors:16(CPU数目为16)
Processor Clock Speed:3000 MHz(CPU主频)
CPU Type:64-bit(CPU为64位)
Kernel Type:64-bit(AIX安装为64位)
LPAR Info:1 06-4EC9P(LPAR逻辑分区信息)
Memory Size:128000 MB(服务器内存)
Good Memory Size:128000 MB
试读结束[说明：试读内容隐藏了图片]