第3章 磁盘实现方法和ASM针对DBAWord文档下载推荐.docx
《第3章 磁盘实现方法和ASM针对DBAWord文档下载推荐.docx》由会员分享,可在线阅读,更多相关《第3章 磁盘实现方法和ASM针对DBAWord文档下载推荐.docx(56页珍藏版)》请在冰豆网上搜索。
使用高级文件系统特性和裸设备以改进性能
了解在系统的计划阶段要考虑的问题
3.1
成为规范的磁盘阵列
使用RAID(冗余独立/廉价磁盘阵列,RedundantArrayofIndependent/InexpensiveDisks)配置磁盘现在已经成为一种规范。
人们已经普遍使用RAID,甚至是购买没有RAID的中等系统都会承受很大的压力。
在本章的后面,您将看到ASM也提供了冗余级别。
即使是在个人计算领域,使用一些基于硬件的冗余磁盘配置也已经变得更为常见。
对于DBA来说,这意味着比以前更多的管理工作,他们必须采取特殊的保护,确保磁盘阵列配置使用增强的I/O,同时也对磁盘故障提供相应保护。
无论RAID配置是基于硬件还是软件,配置工作都应该尽可能地设置正确,以获得最佳的性能,同时保持适当的保护。
3.1.1
使用磁盘阵列改进性能和可用性
通过以如下的方式分组一些磁盘(分组为卷或虚拟磁盘)来创建RAID逻辑单元号(LogicalUnitNumber,LUN):
将单个磁盘作为一个逻辑磁盘使用。
在存储区域网络(StorageAreaNetwork,SAN)出现之前,LUN就是磁盘驱动器地址(编号)。
因此,在正常操作期间,一个逻辑设备可以得益于它背后的多个物理设备。
这意味着更为快速的数据访问(在适当地配置时)和容量远大于单个设备物理限制的存储卷。
如果一个磁盘失败并且这个磁盘上的所有数据都被破坏,此时就可以重建磁盘组,因此数据可以存储在多个位置。
系统并不会因为一个磁盘故障而停止下来(在使用适当的RAID级别时)。
在一个磁盘出现故障时,用户可以继续他的操作,就好像什么也没有发生一样。
系统会警告系统管理员某一个磁盘发生了故障。
然后管理员会取出这块磁盘并插入另一个磁盘。
硬件控制器或操作系统会自动在新的磁盘上写入丢失的信息。
系统会继续操作,就像没有中断一样。
3.1.2
所需的磁盘数量
我知道处于这种情况的硬件供应商会感谢我,但实情就是如此。
关于购买磁盘的经验之谈是:
“不要单凭容量来购买磁盘”。
如果您有一个中等规模的200GB数据库,为什么需要购买具有1TB磁盘容量的磁盘阵列?
原因就在于磁盘主轴。
由于单个磁盘的容量一直保持在146GB左右,合理地分布数据可能非常困难,但是近来我经常看到人们单凭容量购买磁盘,这就给这些人带来了不适当的冗余或较差的性能,或者同时产生这两种情况。
除此之外,在正确地配置1TB的磁盘之后,您可能只有500GB的可用存储空间,其他的300GB容量用来执行各种有用的操作。
至于具体的操作,使用SAN就是应该最先执行的操作。
为什么不投资在可以给多个系统带来益处的硬件上?
本章后面将对此进行介绍。
3.1.3
可用的RAID级别
当前几乎每个中等规模的服务器或企业级的服务器都提供了硬件RAID解决方案,这种解决方案内置在服务器中,或者作为附加的存储设备。
使用各种可用的RAID级别已经变成一个通用标准,而不管购买的是什么类型的阵列。
下文列出了Oracle数据库管理员需注意的一些较为常用的选项:
RAID0(分段集)
这个级别允许自动磁盘分段(striping)。
这意味着Oracle的数据文件可以自动扩展到多个磁盘上。
表空间所对应的数据文件片断可以同时扩展到多个磁盘(而不是一个磁盘)上,并可同时对它们进行访问(节省了大量的磁盘I/O)。
需要注意的是,这不是高可用性或容错的解决方案,因为磁盘组中某个磁盘的丢失意味着需要恢复所有的数据。
RAID1(镜像集)
现在多数系统都支持自动磁盘镜像。
在操作系统里也经常用到这个技术,但用在Oracle数据库中主要是想得到更高的可用性。
相比于数据的数量,使用RAID1级别需要两倍的存储空间。
RAID5(带有奇偶校验的分段集)
这个级别将奇偶检验块放到额外的磁盘上,这主要是为了媒介恢复。
有大量读操作的应用程序都可以从这种磁盘阵列分布中获得最大的性能。
这是一个低成本的解决方案,对于有大量写操作的Oracle应用程序,其效率并不高。
下面的小节中将讨论这个RAID级别的改进方案。
RAID1+0(RAID10,镜像的分段)
先镜像磁盘,然后对其进行分段。
这是最常见的OracleOLTP产品RAID级别,也称为RAIDTEN。
它通过将RAID0的磁盘I/O分段优势融入到RAID1带来的镜像,结合了前两个RAID级别的优点。
在高读/写量的环境(如OLAP)中,由于对数据的小规模访问会很频繁,我们建议使用这个级别的RAID。
RAID0+1(RAID01,分段的镜像)
先分段磁盘,然后对其进行镜像。
该级别通常会与RAID10混淆或者被认为不存在,它通过将RAID0的磁盘I/O分段优势提供给RAID1带来的镜像,结合了前两个RAID级别的优点。
在高读/写量的环境(如OLAP)中,由于对数据的小规模访问会很频繁,使用这个RAID级别也很适合,但是它不如RAID10健壮,并且不能容忍来自不同分段的两个磁盘同时产生故障。
此外,在产生故障之后的重建过程中,阵列中的所有磁盘都必须参与到重建过程中,这一点也不如RAID10令人满意。
RAID1+0+0(RAID100,RAID10的分段)
先镜像磁盘,然后对其进行分段,接下来再次分段(顶层的分段通常使用软件进行操作,称为MetaLun或软分段)。
这种RAID级别的优点主要是改进随机读的性能和消除热点。
3.1.4
更新的RAID5
许多硬件供应商都使用RAID5配置来配置系统,从而充分利用磁盘上的可用空间,并且减少阵列的总体成本。
尽管RAID5对于不昂贵的冗余是个很好的方案,但它对于写入密集型操作的性能来说通常较差。
一般来说,当对RAID5阵列发出一个写入请求时,必须改变磁盘上已修改的块,从磁盘上读取“奇偶校验”块,并且使用已修改的块计算新的奇偶校验块,然后把数据写入到磁盘上。
无论请求写入的数据为多少,这个过程都会限制吞吐量,因为对于每一个写操作,都有至少两个额外的I/O操作。
建议仅在一个文件系统大部分进行的是读取操作或只读操作时使用RAID5。
大多数存储器供应商都了解到这种奇偶校验写操作对性能有一定影响,并且已经提出各种解决方案来减少这种额外操作带来的影响。
最常见的解决方案是在阵列上实现一个内存缓存,从而加速阵列上所有I/O的写性能。
对于周期性的或少量的写活动,这种解决方案可能完全适合于您的系统,但是您需要记住这些写操作最终都需要写入到磁盘。
如果由于执行大量写活动而使该磁盘缓存超载,则可能产生通常所说的“串行化I/O”情况。
在这种情况中,阵列无法足够快速地写入磁盘以清除缓存,这就基本上抵消了缓存带来的优势。
确保检查您的供应商可能实现的其他解决方案,主动询问他们如何处理大量的I/O。
一些期待实现的解决方案如下:
动态缓存管理:
这是阵列用于调整缓存使用方式的功能。
一些供应商简单地将缓存对半划分——如果有1GB的缓存,则将500MB用于读,另外500MB用于写。
因为Oracle缓冲区缓存基本上已经是读缓存,并且能够调整阵列缓存,因此主要通过写缓存提供一些灵活性。
这种解决方案也适用于RAID5之外的其他配置。
绑定的写操作:
一般来说,写操作的最大尺寸大于Oracle块的尺寸。
一些供应商已经在其阵列中实现了智能化,从而这些阵列可以将多个奇偶校验操作分组到一个I/O操作中。
因为需要较少的物理磁盘往返操作,当运行RAID5时,这种解决方案可以极大地改进缓存的性能和有效性。
RAID6是RAID5的另一个变体,您可能已经通过广告看到过这种RAID级别。
RAID6的运行方式类似于RAID5,不同之处在于它利用每组数据块分段对应的奇偶校验块。
虽然这种RAID级别带来了更多容错的额外优势,但是您可能丢失两个磁盘,因此这种RAID级别具有甚至更低的发展潜力。
我仍然会优先选择RAID1+0(镜像和分段)。
RAID1+0一般比RAID5更为快速,或者至少一样快,并且对于多种设备故障自然地具有更多的容错。
您可能处于磁盘具有多个物理外壳的情况,因此使用分段和镜像也可以在外壳之间构建容错。
3.2
安装和维护传统文件系统
使用RAID配置的物理设备和传统文件系统组可以让DBA在执行Oracle数据文件安装和维护时变得更为轻松,这是因为手动均衡磁盘已经不再繁琐。
随着当前的存储系统中采用大容量的磁盘,将文件系统配置划分为4到6个设备已经变成无意义的事情。
除非使用涉及12个或更多物理磁盘的系统,否则将这些磁盘划分为多个逻辑磁盘设备只会带来很少的优势。
即使产生大量使用两个数据文件的情况,这些数据文件在阵列上共享的缓存或主机总线适配器(HostBusAdapter,HBA)也可能是常用的磁盘访问方法。
最后,根据预期的发展情况,您最终可以管理的文件系统数量会使创建的多个逻辑磁盘失去存在的意义。
技巧:
不要把磁盘阵列上的一个逻辑设备分割成两个文件系统。
该操作看起来能够向您提供灵活性,但它也会增加必须管理的数据文件位置的数量。
考虑成本
为了支持镜像数据的磁盘阵列,需要较多(更多)的原始磁盘存储(对于RAID1,您可能需要双倍的磁盘空间)。
尽管这可能增加最初系统的价格,但同时优点也很明显。
由于上述原因,在做出关于如何配置将要购买的新存储系统的决定时,应仔细考虑保持该系统运行的投资回收率(ReturnOnInvestment,ROI)以及改进性能的价值。
这就将我们导向了另一类正在变得较为流行的存储系统。
因为最基本的存储阵列的容量在不断增大,公司正在寻求通过多节点访问技术利用存储空间。
无论采用的实现方法是存储区域网络(StorageAreaNetwork,SAN)还是网络附加存储(Network-AttachedStorage,NAS),您的存储系统能够放入另一个服务器中的初始投资和额外收益通常都值得这样做。
因此,当具有4Gbit/sec传输速度的光纤通道存储阵列(带有4个磁盘)并且感觉没有充分利用该资源时,就可以考虑购买更多的基础设备,这样您的企业就可以进一步发展,并且在所有重要的系统之间共享该资源。
使用磁盘阵列可以提高系统性能,另外在磁盘出现故障时保护您的数据。
使用适当的RAID级别和技术解决方案,这样就可以维持组织所需的可用性。
不要认为已经足够好,这样您就会在临晨两点时因为丢失某个磁盘而感到悔恨。
3.3
在硬件磁盘之间分布关键数据文件
为了更有效地在传统文件系统上操作Oracle数据库,一定要特别注意把关键的数据文件分布到可用的文件系统里。
例如,经常被访问的表应该放置在与相应的索引分开的文件系统上。
另外,如果磁盘配置允许的话,联机重做日志和归档日志都应该与用来恢复的数据文件分开放置。
事实是,在可以获得硬件的大多数情况下,您需要确保不会因为过多地划分磁盘而影响到有效使用磁盘的能力。
除非在这些文件系统下有许多设备,否则就需要做更多的工作。
与如下元素关联的文件应该尽可能分离:
SYSTEM表空间
TEMPORARY表空间
UNDO表空间
联机重做日志文件(最好放在最快的磁盘上)
操作系统磁盘
放在ORACLE_HOME目录下的关键Oracle文件
经常被访问的表的数据文件
经常被访问的索引的数据文件
归档区域(应该总是与将要恢复的数据分离)
下面的示例说明了在UNIX环境下跨11个文件系统的文件分布:
/:
OperatingSystem
/u01:
Oraclesoftware
/u02:
TemporaryTablespace,ControlFile1
/u03:
UndoSegments,ControlFile2
/u04:
RedoLogs,ArchiveLogs,ControlFile4
/u05:
SystemandSYSAUXTablespaces
/u06:
Data1,ControlFile3
/u07:
RedoLogMirror,Index3
/u08:
Data2
/u09:
Index2
/u10:
Data3
/u11:
Index1
3.3.1
分开存储数据和索引文件
通常应该把所连接的表(在一个查询中同时访问的表)的数据和索引表空间分开放置。
下面的示例显示了一个表连接,以及一个管理数据的可行解决方案:
select
COL1,COL2,....
from
CUST_HEADER,CUST_DETAIL
where
...;
下面所示的为数据管理解决方案:
Disk1:
CUST_HEADERTable
Disk5:
CUST_HEADERIndex
Disk8:
CUST_DETAILTable
Disk12:
CUST_DETAILIndex
这个解决方案通过访问4个不同的磁盘和控制器来完成表的连接。
把数据和索引文件分别放置在不同的物理磁盘设备和控制器上;
这样,当表和索引同时被访问时,就不会访问同一个物理设备。
当然还可以扩展到更多的磁盘上。
本章的后面将会介绍到,表和索引分区可以帮助我们更容易地完成这项任务。
把关键的Oracle数据文件分开放置,这样可以避免磁盘争用成为一个“瓶颈”。
通过把经常连接的几个表的表和索引分开放置,可以保证即使是最糟糕的表连接也不会导致磁盘争用。
3.3.2
避免I/O磁盘争用
磁盘争用通常发生在有多个进程试图同时访问一个物理磁盘的情况下。
把磁盘的I/O更平均地分布到多个可用的磁盘上,这样可以有效地减少磁盘竞用,同时也提高了性能。
减少磁盘I/O也可以减少磁盘争用。
要监控磁盘争用,可以查看数据库控制中的数据库文件度量(DatabaseFilesMetrics)。
该度量组包含两组度量:
文件平均读取时间(AverageFileReadTime)和文件平均写入时间(AverageFileWriteTime)度量应用于与数据库关联的所有数据文件。
如果发现一个或两个数据文件看起来具有特别高的值,则可以单击相应的数据文件,然后使用比较对象文件名(CompareObjectFileName)链接以查看收集的这些数据文件之间的统计。
如果这些数据文件同时繁忙,并且位于相同的磁盘上,则出于改进这段时间内的性能的考虑,可以选择将一个数据文件重新放置到另一个文件系统。
也可以选择通过运行如下查询来确定文件I/O问题:
col
PHYRDS
format999,999,999
PHYWRTSformat999,999,999
ttitle
"
DiskBalancingReport"
READTIM
WRITETIM
nameformata40
spool
fio1.out
name,phyrds,phywrts,readtim,writetim
v$filestata,v$datafileb
where
a.file#=b.file#
order
byreadtimdesc
/
spooloff
下面是部分的查询输出:
FriMar24
page1
DiskBalancingReport
NAME
Phyrds
Phywrts
ReadTim
WriteTim
/d01/psindex_1.dbf
48,310
51,798
200,564
903,199
/d02/psindex_02.dbf
34,520
40,224
117,925
611,121
/d03/psdata_01.dbf
35,189
36,904
97,474
401,290
/d04/undotbs01.dbf
1,320
11,725
1,214
39,892
/d05/system01.dbf
1,454
10
956
...
注意:
您也可能有sysaux01.dbf、users01.dbf和example01.dbf。
在磁盘上的物理写入和读取次数上如果出现很大的差别,就表明肯定有哪个磁盘负载过多。
在前面的示例中,文件系统1-3都被经常使用,而文件系统4-5仅被少量使用。
为了获得一个较好的均衡,可以移动一些数据文件。
把数据文件分布在多个磁盘上,或者使用分区,都可以帮助您把对表或索引的访问移动到另外一个磁盘上。
查询V$FILESTAT和V$DATAFILE,以查看到均衡数据文件后的效果。
注意到使用V$TEMPFILE和V$TEMPSTATS监控临时表空间。
3.3.3
通过移动数据文件来均衡文件I/O
可以按照下面的步骤来物理移动一个导致文件争用的数据文件:
(1)使与数据文件有关的表空间脱机:
ALTERTABLESPACEORDERSOFFLINE;
(2)把数据文件复制到磁盘的新位置上:
$cp
/disk1/orders1.dbf
/db2/orders1.dbf
(UNIX的复制命令)
(3)用新数据文件位置为表空间重命名数据文件:
ALTERTABLESPACEORDERS
RENAMEDATAFILE′/disk1/orders1.dbf′TO′/disk2/orders1.dbf′;
(4)使表空间重新联机:
ALTERTABLESPACEORDERSONLINE;
Deletetheolddatafile(whensurethemoveddatafilecanbeaccessed):
$rm/disk1/orders.dbf(UNIXdeletecommand)
通过把数据文件移到不经常被访问的磁盘上,可以有效解决磁盘争用的问题。
通常用于大型的关键文件的另一种方法遵循如下步骤:
(1)将表空间置于READONLY模式,通过查询DBA_TABLESPACES确认该状态。
(2)在OS级别上复制数据文件。
比较复制操作后的文件尺寸以确保具有相同的尺寸。
(3)将表空间改为脱机。
(4)使用ALTERTABLESPACE命令重命名数据文件。
(5)将表空间改回联机。
(6)将表空间改为READWRITE。
(7)通过查询V$DATAFILE确认控制文件是更新的。
(8)在OS级别上删除旧的数据文件。
使用EnterpriseManager中的数据库文件度量可以确定发生在每个数据库文件上的I/O。
将大量使用的数据文件移动到单独的文件系统以分布I/O。
3.4
本地托管的表空间
在Oracle8i之前,所有表空间段上的盘区信息都通过Oracle数据字典来维护。
这样,发生在数据库的段上并关系到盘区分配(extentallocation)的操作,比如扩展或截取一个表,将会导致对数据字典的操作。
这从数据库管理的角度来看代价就显得太高了,这是因为如果有很多带有很多盘区的表被操作时,数据字典将会成为这些操作的瓶颈。
Oracle8i推出了一个新的盘区管理选项,叫作本地托管的盘区。
通过本地托管的盘区,这些盘区管理操作都会被重新分配到数据文件头中的位图块上。
这同时也提高了性能,原因是数据库的每个表空间都只包含自己的盘区信息,可以使用快速散列进程访问该信息,而不是使用较慢的、基于表的查询访问。
使用本地托管的表空间特性时,除了在字典托管表空间中可用的传统“用户”托管盘区定义之外,Oracle还提供了将盘区分配到段中的两个选项,即“自动分配”和“统一”选项。
在自动分配管理模式下,数据库使用一个内部算法,在段大小增长时增加盘区的尺寸。
使用自动分配选项,当表空间中的段增长时,数据库使用一个内部算法来确定适当的下一盘区尺寸,该内部算法以盘区数量和扩展比例作为系数进行计算。
该选项的优点是,如果表已经被定义为具有不适当的较小盘区尺寸,数据库将自动增加表的下一盘区尺寸,并且因此减少表具有的全部盘区数量。
因此,如果正在操作新的应用程序,并且不确定段增长的数量,则使