利用AIX条带化(STRIPE)优化数据库IO

简介:

 一、背景

生产环境IBM P560目前用于Oracle DataGuard 的standby机器。在oracle Apply 归档日志时,查看服务器IO情况,发现Hdisk0、1上的IO有时候能达到到100%。而Hdisk2、3上IO活动很少。
经分析,oracle的数据文件存放目录放在/oradata,该目录建立在hdisk0、1上。故在数据库发生读写数据文件时,只有hdisk0,1有IO。另外2块盘IO活动少。故考虑将数据库文件从rootvg迁移出来,将数据库的归档文件建立在rootvg里,达到平均分布服务器的IO的目的。

二、理论支持
一般以LVM管理的存储,一个vg中可能会有很多pv,同样的,一个lv可能跨越多块pv,为了使硬盘存储速度加快,就会用到条带化的技术,即把连续的数据分成大小相同的数据块,然后依次存储在各个pv上。类似于RAID0,使存储速度加快。但并不会使数据像RAID0一样危险容易丢失,因为在正式使用中,不会像此时做测试一样没有任何保障地将多块硬盘做成一个vg,而是普遍连接的后台存储,在划分LUN之前,已经在物理硬盘上做好RAID5或RAID1,在RAID5或RAID1的基础上再划分出多块LUN,即系统上的pv,即使pv所在硬盘损坏,但有底层的硬RAID冗余,并不会丢失数据。
条带单元大小:即条带化的LV中,每一个条带单元的大小,对应于I/O中数据块的大小。对于Oracle来讲,db_block_size即设定的数据块大小。而db_file_multiblock_read_count就一次读取时最多并行的数据块的个数,db_block_size和db_file_multiblock_read_count相乘即一次总的I/O大小。这个大小不能超过操作系统的最大I/O (max_io_size)值。在ORACLE应用中,lv条带的大小一般设置为两倍或两倍以上的Oracle块大小,因为假如设置成与Oracle数据块相同大小,无法保证Oracle数据块的边界正好与条带单元的边界对应,如果不对应的话,就会出现大量的一个I/O由两个条带单元,来处理的情况。
条带大小的原则:对于高并发并且IO请求小的情况下,一块物理硬盘处理多个I/O请求,低并发但I/O请求较大时,可能需要多块硬盘处理一个I/O请求。原则上的要求是一次I/O请求能被一次性处理完成。
大概的条带化的概念就是这样。

三、参数提取

 
  1. P560A:/#lspv 
  2. hdisk0          00c3ee9e3439bc67                    rootvg          active 
  3. hdisk1          00c3ee9e5033384d                    rootvg          active 
  4. hdisk2          00c3ee9eae48cc48                    rootvg          active 
  5. hdisk3          00c3ee9eae48df75                    rootvg          active 
  6.  
  7. P560A:/#lspv -l hdisk0 
  8. hdisk0: 
  9. LV NAME               LPs   PPs   DISTRIBUTION          MOUNT POINT 
  10. hd10opt               8     8     00..00..08..00..00    /opt 
  11. hd3                   40    40    00..00..40..00..00    /tmp 
  12. hd1                   4     4     00..00..04..00..00    /home 
  13. hd2                   16    16    00..00..16..00..00    /usr 
  14. hd9var                4     4     00..00..04..00..00    /var 
  15. hd8                   1     1     00..00..01..00..00    N/A 
  16. hd4                   4     4     00..00..04..00..00    / 
  17. hd5                   1     1     01..00..00..00..00    N/A 
  18. hd6                   32    32    00..00..32..00..00    N/A 
  19. tsmdb                 30    30    20..10..00..00..00    /tsmdb 
  20. oradatalv             278   278   49..11..00..109..109  /oradata 
  21. oraclelv              40    40    40..00..00..00..00    /home/oracle 
  22. weblogiclv            40    40    00..40..00..00..00    /weblogic 
  23. weblogic9lv           40    40    00..40..00..00..00    /weblogic9 
  24. lg_dumplv             8     8     00..08..00..00..00    N/A 
  25.  
  26. P560A:/#lspv -l hdisk1 
  27. hdisk1: 
  28. LV NAME               LPs   PPs   DISTRIBUTION          MOUNT POINT 
  29. hd10opt               8     8     00..00..08..00..00    /opt 
  30. hd3                   40    40    00..00..40..00..00    /tmp 
  31. hd1                   4     4     00..00..04..00..00    /home 
  32. hd2                   16    16    00..00..16..00..00    /usr 
  33. hd9var                4     4     00..00..04..00..00    /var 
  34. hd8                   1     1     00..00..01..00..00    N/A 
  35. hd4                   4     4     00..00..04..00..00    / 
  36. hd5                   1     1     01..00..00..00..00    N/A 
  37. hd6                   32    32    00..00..32..00..00    N/A 
  38. tsmdb                 30    30    20..10..00..00..00    /tsmdb 
  39. oradatalv             324   324   89..17..00..109..109  /oradata 
  40. fwdump                2     2     00..02..00..00..00    /var/adm/ras/platform 
  41. weblogiclv            40    40    00..40..00..00..00    /weblogic 
  42. weblogic9lv           40    40    00..40..00..00..00    /weblogic9 
  43.  
  44. P560A:/#lspv -l hdisk2 
  45. hdisk2: 
  46. LV NAME               LPs   PPs   DISTRIBUTION          MOUNT POINT 
  47. oradatalv             598   598   152..223..223..00..00 /oradata 
  48.  
  49. P560A:/#lspv -l hdisk3 
  50. hdisk3: 
  51. LV NAME               LPs   PPs   DISTRIBUTION          MOUNT POINT 
  52. archlog_lv            400   400   00..223..177..00..00  /archivelog 
  53.  
  54. P560A:/#lslv -l oradatalv 
  55. oradatalv:/oradata 
  56. PV                COPIES        IN BAND       DISTRIBUTION   
  57. hdisk0            278:000:000   3%            049:011:000:109:109  
  58. hdisk1            324:000:000   5%            089:017:000:109:109  
  59. hdisk2            598:000:000   37%           152:223:223:000:000  
  60.  
  61. P560A:/#lslv -l oraclelv 
  62. oraclelv:/home/oracle 
  63. PV                COPIES        IN BAND       DISTRIBUTION   
  64. hdisk0            040:000:000   0%            040:000:000:000:000  
  65.  
  66. P560A:/#lslv -l archlog_lv 
  67. archlog_lv:/archivelog 
  68. PV                COPIES        IN BAND       DISTRIBUTION   
  69. hdisk3            400:000:000   55%           000:223:177:000:000  


四、优化步骤
1、把hdisk2从rootvg中剔除
reducevg –d rootvg hdisk2;
2、将hdisk2、hdisk3做成datavg
smit mkvg 输入VG名字为datavg,选择盘为hdisk2 、hdisk3;
3、smit mklv 新建条带化LV
  LV名字输入:oradata_lv
  LV类型为:JFS2
  LV分布的PV:hdisk2、hdisk3
  strip Size 选择:128K (建议为oracle 的db_block_size *同时读取的块,目前系统最大允许为128K);
  lslv -m oradata_lv 发现LV的物理分区平均分布在hdisk2 和Hdisk3上

4、新建文件系统
  smit jfs2 建立文件系统

五、优化结果
P560A:/backup#lspv
hdisk0          00c3ee9e3439bc67                    rootvg          active
hdisk1          00c3ee9e5033384d                    rootvg          active
hdisk2          00c3ee9eae48cc48                    datavg          active
hdisk3          00c3ee9eb6975c7e                    datavg          active
 

本文转自zylhsy 51CTO博客,原文链接:http://blog.51cto.com/yunlongzheng/721141,如需转载请自行联系原作者
相关实践学习
基于Hologres轻量实时的高性能OLAP分析
本教程基于GitHub Archive公开数据集,通过DataWorks将GitHub中的项⽬、行为等20多种事件类型数据实时采集至Hologres进行分析,同时使用DataV内置模板,快速搭建实时可视化数据大屏,从开发者、项⽬、编程语⾔等多个维度了解GitHub实时数据变化情况。
阿里云实时数仓实战 - 用户行为数仓搭建
课程简介 1)学习搭建一个数据仓库的过程,理解数据在整个数仓架构的从采集、存储、计算、输出、展示的整个业务流程。 2)整个数仓体系完全搭建在阿里云架构上,理解并学会运用各个服务组件,了解各个组件之间如何配合联动。 3 )前置知识要求:熟练掌握 SQL 语法熟悉 Linux 命令,对 Hadoop 大数据体系有一定的了解   课程大纲 第一章 了解数据仓库概念 初步了解数据仓库是干什么的 第二章 按照企业开发的标准去搭建一个数据仓库 数据仓库的需求是什么 架构 怎么选型怎么购买服务器 第三章 数据生成模块 用户形成数据的一个准备 按照企业的标准,准备了十一张用户行为表 方便使用 第四章 采集模块的搭建 购买阿里云服务器 安装 JDK 安装 Flume 第五章 用户行为数据仓库 严格按照企业的标准开发 第六章 搭建业务数仓理论基础和对表的分类同步 第七章 业务数仓的搭建  业务行为数仓效果图  
相关文章
|
2月前
|
存储 人工智能 NoSQL
AI大模型应用实践 八:如何通过RAG数据库实现大模型的私有化定制与优化
RAG技术通过融合外部知识库与大模型,实现知识动态更新与私有化定制,解决大模型知识固化、幻觉及数据安全难题。本文详解RAG原理、数据库选型(向量库、图库、知识图谱、混合架构)及应用场景,助力企业高效构建安全、可解释的智能系统。
|
6月前
|
关系型数据库 MySQL 数据库连接
Django数据库配置避坑指南:从初始化到生产环境的实战优化
本文介绍了Django数据库配置与初始化实战,涵盖MySQL等主流数据库的配置方法及常见问题处理。内容包括数据库连接设置、驱动安装、配置检查、数据表生成、初始数据导入导出,并提供真实项目部署场景的操作步骤与示例代码,适用于开发、测试及生产环境搭建。
247 1
|
2月前
|
SQL 存储 监控
SQL日志优化策略:提升数据库日志记录效率
通过以上方法结合起来运行调整方案, 可以显著地提升SQL环境下面向各种搜索引擎服务平台所需要满足标准条件下之数据库登记作业流程综合表现; 同时还能确保系统稳健运行并满越用户体验预期目标.
187 6
|
3月前
|
缓存 Java 应用服务中间件
Spring Boot配置优化:Tomcat+数据库+缓存+日志,全场景教程
本文详解Spring Boot十大核心配置优化技巧,涵盖Tomcat连接池、数据库连接池、Jackson时区、日志管理、缓存策略、异步线程池等关键配置,结合代码示例与通俗解释,助你轻松掌握高并发场景下的性能调优方法,适用于实际项目落地。
552 5
|
5月前
|
机器学习/深度学习 SQL 运维
数据库出问题还靠猜?教你一招用机器学习优化运维,稳得一批!
数据库出问题还靠猜?教你一招用机器学习优化运维,稳得一批!
164 4
|
9月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
10月前
|
关系型数据库 数据库 数据安全/隐私保护
云数据库实战:基于阿里云RDS的Python应用开发与优化
在互联网时代,数据驱动的应用已成为企业竞争力的核心。阿里云RDS为开发者提供稳定高效的数据库托管服务,支持多种数据库引擎,具备自动化管理、高可用性和弹性扩展等优势。本文通过Python应用案例,从零开始搭建基于阿里云RDS的数据库应用,详细演示连接、CRUD操作及性能优化与安全管理实践,帮助读者快速上手并提升应用性能。
|
9月前
|
SQL Java 数据库连接
【YashanDB知识库】个别数据库用户无法登录数据库,报错 io fail:IO.EOF
【YashanDB知识库】个别数据库用户无法登录数据库,报错 io fail:IO.EOF
|
11月前
|
缓存 NoSQL JavaScript
Vue.js应用结合Redis数据库:实践与优化
将Vue.js应用与Redis结合,可以实现高效的数据管理和快速响应的用户体验。通过合理的实践步骤和优化策略,可以充分发挥两者的优势,提高应用的性能和可靠性。希望本文能为您在实际开发中提供有价值的参考。
267 11

热门文章

最新文章