基本知识讲解请参考鸟哥的私房菜基础篇第三版，知识很详细，这里就不多说了。

  (1) 创建LVM

       步骤一：再新建5块10MB SCSI的硬盘

               这一步和上一步制作raid的操作是一样的，请参见上一篇

       步骤二：用4块硬盘做raid5+1hostspare

               mdadm --create --auto=yes /dev/md1 --level=5 --raid-devices=4 --spare-device=1 /dev/sdc{5,6,7,8,9}

               注意：这次我们创建raid起名为/dev/md1(上次为/dev/md0)

       步骤三：查看RAID组成情况  

[root@compute-0 mnt]# mdadm --detail /dev/md*

mdadm: /dev/md does not appear to be an md device

/dev/md0:  # 上次RAID实验创建的

        Version : 1.2

  Creation Time : Fri Mar 22 04:41:39 2013

     Raid Level : raid5

     Array Size : 480768 (469.58 MiB 492.31 MB)

  Used Dev Size : 160256 (156.53 MiB 164.10 MB)

   Raid Devices : 4

  Total Devices : 5

    Persistence : Superblock is persistent

    Update Time : Fri Mar 22 05:44:28 2013

          State : clean 

 Active Devices : 4

Working Devices : 5

 Failed Devices : 0

预算，自从美国军方提出以来，在近20年的时间里得到了快速的发展，并且成为各个大中小企业不得不关注的一个问题，在预算的执行和分析过程中，总是会有一些质疑的声音，最常见的一种就是各种无法按时完成合理预算的理由，在此就不一一例举，说出这些理由的人，都抱有一种心态，并且在中国的传统和企业文化下这种心态得到了良好的土壤，从此茁壮成长；中国人的传统，看过程，在乎过程，过程中可能出现各种特殊情况，可能出现各种做不了，最后结果失败，而且在做预算的时候还有一种心态，就是计划都是理想化的，所以达不到有点理所当然，但是所有人都忘记了，这个计划并非理想化，这个计划是合理的，也就是完成这样的计划是必要的，达不到是工作没有做好，请问你尝试了所以方法了吗？

我们需要的数据分为两个部分：1、预算数，根据业务总计划来，来自计划预算；2、实际数，来自日常的业务的发生，任何业务的发生都会产生预算的实际数。

   最后我们怎么确保数据的准确性？

   在做预算与其他工作不同，预算数据的准确性不仅仅是实际数的准确性，更多的我们需要把握预算数据的准确性，因为只有相对准确的预算数据才能反应出我们最的预算是有用的。实际数的准确性很好保证，实际业务的发生数，下边我们会重点讨论预算数据的准确性。

   既然预算是我们计划即将发生的事情，那么会有很多外力因素影响使其无法避免的发生偏差，但是如何去尽量避免这里出现的偏差就需要业务人员配合财务人员去完成。现在很多企业内部无论是业务还是财务人员在做预算的时候都是根据年度计划简单的除12来得到各个月的预算，但是这样的预算方法在80%以上的预算主体都是不适用的。简单的举个例子，如果在高校开个食堂，那么各项费用或者收入在寒暑假期间将会降到最低，如果这样的预算还是简单的使用12个月来均摊是非常不合时宜的，而且即使是平常上课不同的月份也会出现不同的波动，在节假日期比较多的10月份也将对学生的消费产生影响并且在刚开学和学期结束的月份学生产生的消费也大不相同，这些问题的出现都将导致我们再做预算计划的时候需要对不同时间进行合理的分析拆解。

   做预算本就是一个分、合、分的简单过程，第一步我们把一个时间段的预算分为多个段落，这样方便在不同的是时间段有针对性的做出预算，再根据计划合理合并起所有的预算行成一个整体的预算，在这个预算的执行过程中，我们又需要根据当前的变换随时合理的调整拆分整体预算，使预算既不脱离这个企业的发展步骤，又不会出现画饼情况。

   还有就是在预算计划的过程中对于金融危机等不可抗拒因素对业务计划的影响也需要业务人员有一定的预估性，出现这样问题的时候需要及时调整月度、季度、甚至是年度的业务计划，使决策层能够及时了解，并配合企业领导及时调整计划方向，这个过程是预算重点体现，出现这些特殊因素，如果企业反应的越迅速就越能抓住时间也越能减低风险，这样对预算指导企业的发展将是非常有意义的，这个就充分表现了预算分析对决策对企业的影响，但是如果不调整预算只是简单的改变实际业务，那么这样分析出来的结果往往成为事后诸葛亮，是所有企业都不愿意看到的。

   这里我们简单的总结就是，预算和业务密不可分，当一个因素出现变动时我们需要对另一个因素作出快速的反应，这样才能保证企业都是按照计划在发展的，所有的业务都才具有可控性，当业务脱离的预算的约束将成为脱缰野马，将会越走越远，最多的调整都是事后，无法对损失进行避免和挽回，这样的预算只身下空壳。无法起到其真正的意义。

    BI，一个商业智能体系，也是一个提出和应用不足20年，但是发展很快的技术体系。我们应该如何来完成BI工作，应该如何来使用BI，BI所涉及到的人员是哪些，由此在涉及到的时候我们对这样的概念还是很模糊，甚至不知道它能为企业带来什么，或者为企业中的人员带来什么，带着这些疑问，我们先来看BI能为预算的带来的使用方式和意义。

   预算由两部分组成，一、计划，二、执行；当我们把预算和执行转换成各种数字结果放在一起比较的时候，我们就看到了预算的分析结果，通过这些结果，我们在反馈到执行过程，是什么样的过程导致这样的结果，是预算数大（小）了比切实际，还是执行数小（大）了，那么又是什么导致执行数小（大），是整个宏观市场经济情况还是员工的执行率过低，等等情况的反应后都能够指导改进我们的整体业务计划或者是经营方向。

  BI工具方法在结合预算的过程中我们都要注意到总离不开预算执行过程中的预算数和实际数，而在预算和实际的整个过程当中都是相互交织，当一个数据发生变化时不单单是影响的结果，可能会导致整个过程都发生根本的改变，杜邦分析模型在经营分析中就是很好的例子，当任何一个因素发生改变会导致整个系统中的运行数据发生改变从而才改变结果，可以清楚的看到过程的变化情况。

   但是我们的预算现在还停留在简单的两数对比分析，还没有结合成为一个整体，所有在使用数据分析工具的时候也是一些简单的从预算到实际到分析，从累计到进度等最基本的数据集合。

  在上边简单的预算描述过程中我们知道，预算就是一个 计划→执行→分析→反馈→分析→改进 最后得出结论的过程，一直根据不同的执行周期无限重复的一个过程，那么结果什么时候反馈，我们就在什么进行分析，这样就得出如果结果得到的越及时，我们对整个事件（企业）的掌控能够更加准确，所以如果我们有一种能够及时明了的反馈工具是必不可少的，此时我们引入了BI系统。

  BI能够准确的抓取到我们需要的数据无论是数据库还是excel等等数据源，我们先把预算数据存储在BI的数据仓库中，在根据整个事件的分步执行情况例如：凭证，报销，采供单据，还是项目合同等等一系列能够反映事件进行情况的单据，通过这些单据取数与预算数进行对比后，我们得到了预算执行的结果，并且当我们把预算数作为基数，执行数最为对比数可以进行仪表盘等的设置，这样我们根据整个事件的发生进度，事件进度等情况就可以得出我们的结论，怎么样才能够更加及时准确的掌控事件呢，我们得到的答案是当BI与预算系统合理的整合之后就可以，因为每个事件的发生我们都会在业务系统中有所反应，那么我们通过BI系统提取这些反应的量与总计划的量进行对比，最后得出整个事件的进度和执行情况。

   作为一个数据分析的工具，需要紧密的与业务想结合才能够得到价值的体现，我们在使用BI架构起一个分析平台的时候，简单的数据组合对于这样一个工具来说完全是大材小用，所有其中基础的数据仓库就是我们面前的第一个关口，数据仓库的建立于数据库是两种背离的思想，数据库的建立是支撑业务系统的运行但是一定要按照计算机的思路来完成，也就是我们在建立数据库时候需要满足的范式要求，而数据仓库的建立甚至不要需要过多的去考虑范式要求，而更多的是需要考虑业务中数据的关系建立数据与实际分析的对应关系，所有表可以没有主键但是必须要有外键等特殊情况就出现了，在数据仓库的建立方法与数据库相似，完成建立后使用ETL工具做对应、条件等完成数据的抽取，预算数抽取区间为月度，而执行数根据需要可以是日、周、月来递增完成。

   在完成抽取建立完成数据仓库，需要在语义层建立Univers，即数据间对应关系的建立，关系的建立需要避免闭环出现，可以使用上下文等数据库的方法来进行处理，这一个步骤相对比较简单，不再赘述。

   管理建立完成后需要应用到业务中，以何种方式呈现结果就是现在需要考虑的问题，那么根据实际情况，不同的层级需要的结果是不一样的：

而现在公司主要选择了水晶易表和Web Intelligence 来进行展现。水晶易表主要是数据转换为图表的动态展示，以数据为基础的图形化交互展示，结果如flash等，而Web Intelligence 主要是报表类型，多数以交叉表展示，根据需要选择项目即可。使用方法类似于excel。至此整个系统应用完成，发布之后可以使用浏览器进行查询使用展示结果。

BI还提供了相关的类似钻取这样的展示操作层功能，我们可以根据反应数据的级别进行向上的逐级汇总和向下的逐级钻取，这样的反馈都是能够得到及时的反应出来，在同一个图表中根据不同的条件得到不同结果，及时的反馈

          很多SAP客户做License审计时，并不知道License可以合并一事，一般USMM测量完结果也不看，直接将License审计结果发给SAP了。当然，对于大公司而言，这也是没问题的，毕竟买了那么多License，不用省着用。但对于很多每年SAP License支持占IT预算比重很大的企业来说，很有必要将License合并工作做好。

           License类型一半分为6类：1. Employee  2. Professional  Limit   3. Profesional  4. Develop   5. Test   6. Multi System/Client .

           这6类中，Employee 和 Develop 一般License数量不会买的很多，就我们公司而言加起来都没超过5个.  License中数量买的最多应属Professional Limit或Professional，这类License也是SAP允许用户投入生产使用的License，因为价格高嘛，大家都懂的。

           下面我说下对于这几类License的分类及使用：

          1. Employee和Develop类型数量较少，因为生产系统不允许开发，而自定义开发也是SAP不太推荐做的事，所以在SAP卖License给企业的时候，会极力将License的大比例划分给Professional 和 Professional Limit，这也是比较赚钱的买卖，09年左右一个License会卖到大约3500欧（视合同类型而定）。

           2.Test 类型的用户是不收钱的，但在生产系统中一旦将用户划分为Test类型，SAP视这类用户是不参与生产或者不使用核心业务功能的用户，在审计时SAP也会着重审计这类类型的用户，审核其是否真的没有参与生产活动，在国外诚信是很宝贵的一笔财富，所以客户不会轻易将诚信贱卖，对于Test用户的划分和使用都很谨慎，因为一旦SAP查到企业用Test用户参与实际生产活动，会发出警告甚至停止对其销售License，没有License就意味着没有售后服务，甚至企业会面临吃官司的风险。国内的话，呵呵...

           3. Multi Client类型的License是很多企业忽视的一种License类型，SAP提供这种类型的License是为了给客户节省License费用，让License分类更为清晰。举个例子，在SAP ECC中有ABC这样一个用户，但在SAP BI中也有同名的一个用户ABC，而且他们确实为同一人使用，这时我们就可以将他们合并。在计算License时，就不会重复计算了。

          另外有一点需要注重说明，如果企业在做License审计时，不去主动将用户类型区分开，SAP会将所有的生产系统用户视作Professional用。所以对于Basis顾问来说，管理好SAP用户License是很有必要的，好比对于买了一批商品，但不知道商品的价格分类，这是一件可悲的事。

           Multi System/Client的分类方法：