LVM

LVM基础
设备文件：dev/dsk-块设备文件，dev/rdsk-字符设备文件
物理卷：A.查看可用的磁盘信息
          vgdisplay -v :可以查看所有的vg中包含了哪些PV信息；
          strings /etc/lvmtab：可以查看哪些PV已经包含到vg中；
          sam工具查看所有的磁盘状态信息。
        B.查看PV信息
          pvdisplay /dev/dsk/c22t5d1 ：PE数，PE大小，可计算出磁盘大小
        C.生成PV信息
          对于没有加入LVM的磁盘需要生成PV信息才能进行LVM管理：
          pvcreate -f /dev/rdsk/c0t3d0  后面是字符设备文件。
     逻辑卷组：
            A.创建逻辑卷目录
              mkdir /dev/vg04
            B.建立设备文件
              mknod /dev/vg04/group c 64 0x040000 :说明：这条命令是用来建立设备文件，其中c表明建立的是字符设备，64代表的是设备驱动号，这两项都是不可改变的。0x020000的格式                                                             是，总是0x开头，02对应的是vg02——其实也可以不对应，只是为了以后方便，大部分时候，我们都是做成对应的，最后接0000。
            C.创建逻辑卷组
              vgcreate /dev/vg02 /dev/dsk/c0t3d0 /dev/dsk/c0t4d0
            D.扩展逻辑卷组
              vgextend /dev/vg02 /dev/dsk/c0t4d0
     逻辑卷：
            A.在已经创建的逻辑卷组上创建逻辑卷
              lvcreate -L 100 -n my_lvol1 vg02
     文件系统：
            A.在已经创建的逻辑卷上创建文件系统
              newfs -F vxfs -o largefiles /dev/vg02/rlvol1
     挂接文件系统：
            A.将已经创建的文件系统挂接到目录下
              mount /dev/vg02/lvol1 /vg02_lvol1
---------------------------------------------------------------------------------------------------------------------
       扩展文件系统的目的，是为了扩大某个文件系统的可用空间。一般的，当某个文件系统的使用率超过了90%的时候，我们就应该予以格外的关注，因为使用率继续降低，将可能大大降低系统性能。此时，我们就以通过删除一些临时文件来增大可用空间，当然，也可以用下面将要讲到的扩大文件系统的方法。
   我们仍然跟着上面的例子，比如上面我们在vg02中创建了100M的lvol1文件系统，现在我们来将其扩大到200M：
   1. #lvextend -L 200 /dev/vg02/lvol1
   2. #umount /dev/vg02/lvol1
   3. #extendfs -F vxfs /dev/vg02/lvol1
       说明，用了第一步的逻辑卷扩大以后，一定要记得使用这个扩大文件系统的操作，否则，将来系统是用sam来查看到的文件系统大小，和用bdf命令查看出来的大小，就会不一样，并且，其实扩大的那部分空间，其实是还不能使用的！
   4. #mount -a
       说明：做extendfs之前已经umount了，因此扩了文件系统以后，要记得重新mount上去
   5. #vgcfgbackup vg02
       说明，因为我们对文件系统进行了改动，因此不要忘记备份相关信息文件。
=============================================================================================================================================
系统安装自动生成的LVM信息：
   1.在安装盘上创建vg00
   2.逻辑卷
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol3    2097152  296072 1787072   14% /                  根卷        
/dev/vg00/lvol1    2051553  103455 1742942    6% /stand             存放系统内核 
/dev/vg00/lvol7    10485760 5012520 5431672   48% /var              存放系统日志
/dev/vg00/lvol6    10485760 2962536 7464480   28% /usr              存放系统命令
/dev/vg00/lvol5    5242880 2873984 2350432   55% /tmp               存放临时文件
/dev/vg00/lvol4    15368192 4454392 10828576   29% /opt             存放应用软件
/dev/vg00/lvol8    2097152 1365784  731368   65% /home              存放用户文件
/dev/vg00/Oracle   15728640 5177244 9902425   34% /Oracle           Oracle安装目录（安装在vg00下是否合理？）
/dev/vg00/Netvault  524288  127431  372080   26% /Netvault          数据备份软件Netvault安装目录（安装在vg00下是否合理？）
================================================================================================================================================
条带化处理：
LVM的条带化处理：
传统的方法是使用lvcreate的-i/-I参数。具体的命令如：
#lvcreate –i 2 –I 16 –n lvdata –L 1000 /dev/vgdata
这样就会生成一个LV，名为lvdata,大小1000M. 每隔16K数据就会跳到下一块硬盘，以2块硬盘为一循环。
每一个数据块的大小（stripe size）可以由4K到32MB. 基本上当系统的每一个IO很小时，可以选用较小的stripe size,原则是stripe size不能比单个IO的size小。 在实际使用情况中发现不同的stripe size通常来说影响很小。
用这种方式做了条带化之后，如果还需要扩充这个LV，如上例的情况就要求到少要有2个硬盘都有足够的剩余空间。 比如说将lvdata的容量扩充到2000M，则每个硬盘上要有250M的剩余空间。

另外一种方法就是extend based striping。 不同于-i/-I的方式，这种条带化是基于PE的。即数据每写完一个PE后，跳到下一个硬盘。通常情况下一个PE大小为4MB.这种方法在配置过程中稍麻烦一点，需要编辑/etc/lvmpvg文件。建立LV时会将数据分布在lvmpvg中列出的所有PV上。当空间用完之后，再加入两个以上的硬盘，就可以在新加的这几个硬盘上平均分布数据
如果你只能加一个PV，那么disable某个LV的extend base striping属性 （lvchange –D n）,仍然可以扩充这个LV。
Extend based striping支持mirroring,而传统的-i/-I不行。
条带化深入分析：
条带化（Striping）是把连续的数据分割成相同大小的数据块，把每段数据分别写入到阵列中不同磁盘上的方法。此技术非常有用，它比单个磁盘所能提供的读写速度要快的多，当数据从第一个磁盘上传输完后，第二个磁盘就能确定下一段数据。数据条带化正在一些现代数据库和某些RAID硬件设备中得到广泛应用。
条带化的设置
由于现在的存储技术成熟、成本降低，大多数系统都采用条带化来实现系统的IO负载分担。如果操作系统有LVM（Logical Volume Manager逻辑卷管理器）软件或者硬件条带设备，我们就可以利用这些攻击来分布IO负载。当使用LVM或者硬件条带时，决定因素是条带深度（stripe depth）和条带宽度（stripe width）：
条带深度指的是条带的大小，也叫条带单元；
条带宽度指的是条带深度的产量或者一个条带集中的驱动数；
需要根据系统的IO要求来合理的选择这些数据。对于Oracle数据库系统来数，比较合理的条带深度是从256K到1M。下面分析影响条带深度和条带宽度的影响因素。
条带深度
为了提高IO效率，我们要尽量使一次逻辑IO请求由一块磁盘的一次物理IO请求。因而影响条带的一个重要因素就是一次逻辑IO请求的大小。
此外，系统中IO的并发度不同我们对条带的配置要求也不同。例如，在高并发度且IO请求的大小都比较小的情况下，我们希望一块磁盘能同时响应多个IO操作；而在那些存在大IO请求的低并发度系统中，我们可能就需要多块磁盘同时响应一个IO请求。无论是一个磁盘还是多个磁盘响应IO请求，我们的一个原则是让一次逻辑IO能被一次处理完成。
下面先看下影响IO大小的操作系统和Oracle的相关参数：
db_block_size：Oracle中的数据块大小，也决定了Oracle一次单个IO请求中的数据块的大小；
db_file_multiblock_read_count：在多数据块读时，一次读取数据块的数量，它和参数db_block_size一起决定了一次多数据块读的大小，它们的乘积不能大于操作系统的最大IO大小；
操作系统的数据块大小：这个参数决定拉Redo Log和Archive Log操作时的数据块大小，对于大多数Unix系统来说，该值为512K；
最大操作系统IO大小：决定了一次单个的IO操作的IO大小的上限，对于大多数Unix系统来说，由参数max_io_size设置；
sort_area_size：内存中sort area的大小，也决定了并发排序操作时的IO大小；
hash_area_size：内存中hash area的大小，也决定了哈希操作的IO大小。
其中，前面两个是最关键的两个参数。
在OLTP系统中，会存在大量小的并发的IO请求。这时就需要考虑选择比较大的条带深度。使条带深度大于IO大小就称为粗粒度条带（Coarse Grain Striping）。在高并行度系统中，条带深度为（n * db_block_size），其中n为大于1的整数。
通过粗粒度条带能实现最大的IO吞吐量（一次物理IO可以同时响应多个并发的逻辑IO）。大的条带深度能够使像全表扫描那样的多数据块读操作由一个磁盘驱动来响应，并提高多数据块读操作的性能。
在低并发度的DSS系统中，由于IO请求比较序列化，为了避免出现热点磁盘，我们需要避免逻辑IO之由一块磁盘处理。这是，粗粒度条带就不适合了。我们选择小的条带深度，使一个逻辑IO分布到多个磁盘上，从而实现IO的负载均衡。这就叫细粒度条带。条带深度的大小为（n * db_block_size），其中n为小于多数据块读参数（db_file_multiblock_read_count）大小的整数。
另外，IO过程中，你无法保证Oracle数据块的边界能和条带单元的大小对齐。如果条带深度大小和Oracle数据块大小完全相同，而它们的边界没有对齐的话，那么就会存在大量一个单独的IO请求被两块磁盘来完成。
在OLTP系统中，为了避免一个逻辑IO请求被多个物理IO操作完成，条带宽度就需要设置为两倍或者两倍以上于Oracle数据块大小。例如，如果条带深度是IO大小的N倍，对于大量并发IO请求，我们可以保证最少有（N-1）/ N的请求是由一块磁盘来完成。
条带宽度
正如我们前面所述，无论是一个还是多个磁盘响应一个逻辑IO，我们都要求IO能被一次处理。因而在确定了条带深度的基础上，我们需要保证条带宽度 >= IO请求的大小 / 条带深度。
此外，考虑到以后系统容量的扩充，我们也需要规划好条带宽度。
如今大多数LVM都支持在线动态增加磁盘。也就是在磁盘容量不足时，我们可以随时将新磁盘加入到一个已经使用的逻辑卷中。这样的话，我们在设置逻辑卷时就可以简单地将所有磁盘都归入到一个卷中去。
但是，有些LVM可能还不支持动态增加磁盘。这时我们就需要考虑以后的容量扩充对IO均衡的影响了。因为你新增加的磁盘无法加入原有卷，而需要组成一个新的卷。但一般扩充的容量和原有容量比较相对比较小，如果原有卷的条带宽度比较大的话，新增加的卷的条带宽度无法达到其大小，这样就会使新、旧卷之间出现IO失衡。
例如，一个系统的初始配置是一个包含64块磁盘、每块磁盘大小为16G的单一逻辑卷。磁盘总的大小是1T。随着数据库的数据增长，需要增加80G的空间。我们把新增加的5个16G磁盘再组成一个逻辑卷。这样就会导致两个卷上的IO失衡。为了避免这种情况。我们可以将原有磁盘配置成每个条带宽度为8个磁盘的8个逻辑卷，这样在新增加磁盘时可以也增加为8个磁盘的新卷。但必须要保证8个磁盘的条带宽度能够支持系统的每秒IO吞吐量。
如果你的条带宽度设置得比较小，就需要估算出你的各个数据库文件的IO负载，并根据负载量不同将他们分别部署到不同卷上一分担IO负载。
人工条带
如果系统不支持LVM或者硬件条带，IO负载就必须由DBA根据数据库文件的IO负载不同手工将他们分散到各个磁盘上去以保证整个系统的IO负载均衡。
有许多DBA会将哪些使用频率非常高的表和它的索引分开存储。但实际上这种做法并不正确。在一个事务中，索引会先被读取到然后再读取表，它们的IO操作是有前后顺序的，因此索引和表存储在同一个磁盘上是没有冲突的。仅仅因为一个数据文件即包含了索引又包含了数据表而将它分割是不可取的。我们需要根据文件上的IO负载是否已经影响到了数据库的性能来决定是否将数据文件分割。
为了正确分布文件，我们首先必须先了解各个数据库文件的IO负载需求以及IO系统的处理能力。鉴定出每个文件的IO吞吐量。找出哪些文件的IO吞吐率最高而哪些IO量很少，将它们分散分布到所有磁盘上去以平衡IO吞吐率。
如果你不了解或者无法预计文件的IO负载，就只能先估计他们的IO负载来规划文件分布，在系统运行过程中再做调整。