03月 10th, 2010 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
较大型的系统环境往往因各种原因,将数据库部署到不同平台或者不同版本上。随着系统的后期调整,必然涉及到数据库方面的相关改造(比如平台迁移,版本升级等)。对于这类整改工作,需要考虑的因素比较多,但核心问题无外乎以下几点:
① 风险与可控性
风险与可控不单单指的是迁移升级过程中,更指迁移完毕后的新环境的运行情况(稳定性、性能等)以及对业务系统的支撑情况。
一个良好的迁移工程,需要强有力的迁移控制过程,完善的模拟验证机制以及快速有效的回退方案。
②停机维护窗口
大部分迁移都需要在指定的停机时间内完成,以避免对业务造成更多的中断和影响。对于高可用环境,需要有良好的迁移方案来尽可能压缩停机时间。
本文重点讨论各种常见场景下利用Oracle自身特征的迁移升级手法,不涉及跨字符集转换,不涉及成熟的第三方迁移工具。 【阅读全文】
11月 27th, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
HugePages在linux kernel 2.6被完整引进,其目的是为了提供更大的内存页面以便于更好的支持大内存。
在linux中,默认的内存页面是4096字节,而现行物理设备中,内存动辄几十G,当系统运行内存较大的应用程序(比如数据库)时,过小的内存页面会产生大量的TLB miss和缺页中断,将大大降低程序性能。Hugepages提供了2M到256M的大内存页面(大小取决于内核版本和物理架构)来代替默认的页面大小.
使用Hugepages可以得到更好的性能,因为Hugepages不可交换,可以避免内存的换入换出,对一个Oracle database,可以将使用的SGA作为Hugepages钉住,会整体上提升db的性能。Oracle推荐在64bit Linux上对大内存数据库使用Hugepages.
【阅读全文】
11月 3rd, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
早上某数据库服务器CPU不断报警,应用系统管理员同时反馈应用响应明显变慢。登陆数据库主机查看,应用连接上来的几个进程占用了大量的CPU资源,造成CPU空闲率很低。登陆数据库查询,发现有不少buffer cache chains的等待,初步判断是应用上出现了某些性能糟糕的SQL语句。
通过进程捕获了几条耗资源的SQL语句,发现大部分都是类似同一条语句造成的。手工执行一下,需要2分多钟才能出结果。
捕获到的SQL语句如下:
【阅读全文】
11月 3rd, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
由于系统整体规划需求,需将现有9iR2数据库统一升级到10gR2版本,由于涉及到机房内多套业务系统,因此作为明年的迁移项目,需要做前期迁移方案规划和测试。
情况大致如此
|
|
迁移前
|
迁移后
|
|
OS 版本
|
Linux AS4( 32bit)
|
Linux AS4( 64bit)
|
|
Oracle版本
|
9iR2(9.2.0.6/9.2.0.8)
|
10.2.0.4
|
由于涉及的业务数据库容量动辄几百G,且停机时间有限(不超过4小时),因此迁移方案的核心在于如何用最短的时间和最安全可控的步骤来完成这次迁移。
【阅读全文】
11月 1st, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
本篇主要讲述10gR2 logical standby的性能优化方法.一些日常维护和故障处理要点,请参考
Logical Standby日常维护与性能优化(一)—日常维护与故障排除
Logical Standby较physical standby容易出现性能上的问题。对于一个DML繁重,尤其是大事务比较多的库,SQL APPLY往往会出现性能上的瓶颈。因此导致备库‘hang’住或者无法跟上主库同步速度的情况也并不少见。
下面描述一下逻辑备库在性能排查和诊断方面的一些切入点和方法:
【阅读全文】
10月 23rd, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
本篇主要讲述logical standby日常管理维护中的检查和故障排除要点,不涉及性能问题。性能问题和相关调整将在下篇中单独阐述。
Logical Standby日常维护与性能优化(二)—性能诊断与优化
10gR2大大简化了logical standby的创建步骤,从physical到logical的转换步骤异常简单,不再对搭建过程过多描述。
【阅读全文】
09月 8th, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
高可用是当前IT信息系统架构中的热点方向,越多越多的系统追求更高的数据保护和更低的停机时间。作为支撑后台业务运行的数据库系统,不同的数据库厂家也提供了不同的高可用保护方案。结合自身的维护经验和认知,简单谈谈SQL Server在高可用方面的一些选型举措。
1.Failover Cluster(HA集群)
Failover Cluster是依赖于集群软件的一种故障转移方案,物理架构上需要2台以上的主机+一套共享存储。几乎所有的主流数据库都有相应成熟的集群HA解决方案,可以避免因单台服务器硬件以及操作系统环境的故障而带来的单点隐患。HA方案的核心在于,通过集群软件判断集群中资源的状态,故障时刻能够将服务资源自动切换。在Sql Server中,借助于Windows平台上的MSCS,SQL server也提供了一套failover解决方案。该方案成本较高,但有较高的故障转移能力和较低的停机时间,能提供非存储故障引起的故障保护。
【阅读全文】
08月 20th, 2009 |post by Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
关键词: 谨慎,周全的考虑.
昨晚系统调整,将一套CRM数据库的几个用户迁移到另外一台性能较强的服务器数据库上去。
源库: oracle 9208
目标库: oracle 9206
字符集相同. 操作系统都是linux
这样的环境太好了,几乎一下子就想到了传输表空间,不用忍受exp/imp大量数据带来的痛苦的煎熬与等待。由于之前使用传输表空间做了一些迁移案例,所以驾轻就熟,也没多想,简单列了checklist,然后待停机时间开始做这次迁移。
【阅读全文】