Oracle高可用迁移升级场景与实战(二)

        本文重点讨论跨操作系统平台场景下利用Oracle自身特征的迁移升级手法，不涉及跨字符集转换，不涉及成熟的第三方迁移

工具，同平台请参考

Oracle高可用迁移升级场景与实战(一)

         一般来说，跨平台迁移相对于同平台迁移在停机时间和可控性上有着更严格的要求。核心的方法也无外乎快速的一致迁移

和增量同步等几种方法。

  【阅读全文】

Oracle高可用迁移升级场景与实战(一)

       较大型的系统环境往往因各种原因，将数据库部署到不同平台或者不同版本上。随着系统的后期调整，必然涉及到数据库方面的相关改造（比如平台迁移，版本升级等）。对于这类整改工作，需要考虑的因素比较多，但核心问题无外乎以下几点：

① 风险与可控性

    风险与可控不单单指的是迁移升级过程中，更指迁移完毕后的新环境的运行情况(稳定性、性能等)以及对业务系统的支撑情况。

    一个良好的迁移工程，需要强有力的迁移控制过程，完善的模拟验证机制以及快速有效的回退方案。

②停机维护窗口

      大部分迁移都需要在指定的停机时间内完成，以避免对业务造成更多的中断和影响。对于高可用环境，需要有良好的迁移方案来尽可能压缩停机时间。

       本文重点讨论各种常见场景下利用Oracle自身特征的迁移升级手法，不涉及跨字符集转换，不涉及成熟的第三方迁移工具。 【阅读全文】

Hugepages On Linux

       HugePages在linux kernel 2.6被完整引进，其目的是为了提供更大的内存页面以便于更好的支持大内存。

       在linux中,默认的内存页面是4096字节,而现行物理设备中,内存动辄几十G，当系统运行内存较大的应用程序(比如数据库)时，过小的内存页面会产生大量的TLB miss和缺页中断，将大大降低程序性能。Hugepages提供了2M到256M的大内存页面(大小取决于内核版本和物理架构)来代替默认的页面大小.

       使用Hugepages可以得到更好的性能，因为Hugepages不可交换,可以避免内存的换入换出，对一个Oracle database，可以将使用的SGA作为Hugepages钉住，会整体上提升db的性能。Oracle推荐在64bit Linux上对大内存数据库使用Hugepages.

【阅读全文】

一次改变PUSHED PREDICATE方式进行SQL调优的案例

     早上某数据库服务器CPU不断报警，应用系统管理员同时反馈应用响应明显变慢。登陆数据库主机查看，应用连接上来的几个进程占用了大量的CPU资源，造成CPU空闲率很低。登陆数据库查询，发现有不少buffer cache chains的等待，初步判断是应用上出现了某些性能糟糕的SQL语句。

     通过进程捕获了几条耗资源的SQL语句，发现大部分都是类似同一条语句造成的。手工执行一下，需要2分多钟才能出结果。

    捕获到的SQL语句如下：
【阅读全文】

记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit

    由于系统整体规划需求，需将现有9iR2数据库统一升级到10gR2版本，由于涉及到机房内多套业务系统，因此作为明年的迁移项目，需要做前期迁移方案规划和测试。

    情况大致如此

    由于涉及的业务数据库容量动辄几百G，且停机时间有限(不超过4小时),因此迁移方案的核心在于如何用最短的时间和最安全可控的步骤来完成这次迁移。
【阅读全文】

Logical Standby日常维护与性能优化(二)—性能诊断与优化

    本篇主要讲述10gR2 logical standby的性能优化方法.一些日常维护和故障处理要点,请参考

Logical Standby日常维护与性能优化(一)—日常维护与故障排除

    Logical Standby较physical standby容易出现性能上的问题。对于一个DML繁重，尤其是大事务比较多的库，SQL APPLY往往会出现性能上的瓶颈。因此导致备库‘hang’住或者无法跟上主库同步速度的情况也并不少见。
    下面描述一下逻辑备库在性能排查和诊断方面的一些切入点和方法：
【阅读全文】

Logical Standby日常维护与性能优化(一)—日常维护与故障排除

     本篇主要讲述logical standby日常管理维护中的检查和故障排除要点，不涉及性能问题。性能问题和相关调整将在下篇中单独阐述。

Logical Standby日常维护与性能优化(二)—性能诊断与优化

     10gR2大大简化了logical standby的创建步骤，从physical到logical的转换步骤异常简单，不再对搭建过程过多描述。
【阅读全文】

构建SQL Server高可用

    高可用是当前IT信息系统架构中的热点方向，越多越多的系统追求更高的数据保护和更低的停机时间。作为支撑后台业务运行的数据库系统，不同的数据库厂家也提供了不同的高可用保护方案。结合自身的维护经验和认知，简单谈谈SQL Server在高可用方面的一些选型举措。

1.Failover Cluster(HA集群)

    Failover Cluster是依赖于集群软件的一种故障转移方案，物理架构上需要2台以上的主机+一套共享存储。几乎所有的主流数据库都有相应成熟的集群HA解决方案，可以避免因单台服务器硬件以及操作系统环境的故障而带来的单点隐患。HA方案的核心在于，通过集群软件判断集群中资源的状态，故障时刻能够将服务资源自动切换。在Sql Server中，借助于Windows平台上的MSCS，SQL server也提供了一套failover解决方案。该方案成本较高，但有较高的故障转移能力和较低的停机时间，能提供非存储故障引起的故障保护。
【阅读全文】