HugePages在linux kernel 2.6被完整引进，其目的是为了提供更大的内存页面以便于更好的支持大内存。
在linux中,默认的内存页面是4096字节,而现行物理设备中,内存动辄几十G，当系统运行内存较大的应用程序(比如数据库)时，过小的内存页面会产生大量的TLB miss和缺页中断，将大大降低程序性能。Hugepages提供了2M到256M的大内存页面(大小取决于内核版本和物理架构)来代替默认的页面大小.
使用Hugepages可以得到更好的性能，因为Hugepages不可交换,可以避免内存的换入换出，对一个Oracle database，可以将使用的SGA作为Hugepages钉住，会整体上提升db的性能。Oracle推荐在64bit Linux上对大内存数据库使用Hugepages.
早上某数据库服务器CPU不断报警，应用系统管理员同时反馈应用响应明显变慢。登陆数据库主机查看，应用连接上来的几个进程占用了大量的CPU资源，造成CPU空闲率很低。登陆数据库查询，发现有不少buffer cache chains的等待，初步判断是应用上出现了某些性能糟糕的SQL语句。
通过进程捕获了几条耗资源的SQL语句，发现大部分都是类似同一条语句造成的。手工执行一下，需要2分多钟才能出结果。
捕获到的SQL语句如下：
【阅读全文】
由于系统整体规划需求，需将现有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小时),因此迁移方案的核心在于如何用最短的时间和最安全可控的步骤来完成这次迁移。
【阅读全文】
本篇主要讲述10gR2 logical standby的性能优化方法.一些日常维护和故障处理要点,请参考
Logical Standby较physical standby容易出现性能上的问题。对于一个DML繁重，尤其是大事务比较多的库，SQL APPLY往往会出现性能上的瓶颈。因此导致备库‘hang’住或者无法跟上主库同步速度的情况也并不少见。
下面描述一下逻辑备库在性能排查和诊断方面的一些切入点和方法：
【阅读全文】
本篇主要讲述logical standby日常管理维护中的检查和故障排除要点，不涉及性能问题。性能问题和相关调整将在下篇中单独阐述。
10gR2大大简化了logical standby的创建步骤，从physical到logical的转换步骤异常简单，不再对搭建过程过多描述。
【阅读全文】
高可用是当前IT信息系统架构中的热点方向，越多越多的系统追求更高的数据保护和更低的停机时间。作为支撑后台业务运行的数据库系统，不同的数据库厂家也提供了不同的高可用保护方案。结合自身的维护经验和认知，简单谈谈SQL Server在高可用方面的一些选型举措。
1.Failover Cluster(HA集群)
Failover Cluster是依赖于集群软件的一种故障转移方案，物理架构上需要2台以上的主机+一套共享存储。几乎所有的主流数据库都有相应成熟的集群HA解决方案，可以避免因单台服务器硬件以及操作系统环境的故障而带来的单点隐患。HA方案的核心在于，通过集群软件判断集群中资源的状态，故障时刻能够将服务资源自动切换。在Sql Server中，借助于Windows平台上的MSCS，SQL server也提供了一套failover解决方案。该方案成本较高，但有较高的故障转移能力和较低的停机时间，能提供非存储故障引起的故障保护。
【阅读全文】
关键词: 谨慎，周全的考虑.
昨晚系统调整，将一套CRM数据库的几个用户迁移到另外一台性能较强的服务器数据库上去。
源库： oracle 9208
目标库： oracle 9206
字符集相同. 操作系统都是linux
这样的环境太好了，几乎一下子就想到了传输表空间，不用忍受exp/imp大量数据带来的痛苦的煎熬与等待。由于之前使用传输表空间做了一些迁移案例，所以驾轻就熟，也没多想，简单列了checklist，然后待停机时间开始做这次迁移。
【阅读全文】
oracle在10g版本明确引入time model,直观的作为一种量度指标反映给用户。时间作为一种性能上的量度和反映，一直贯穿在oracle的各个版本中，可以说时间模型并不是10g特有的东西。只不过，这种模型和概念在10g之前并没有明确和加以细化，而且，在oracle各个版本的升级和演化中，也在不断进行调整。
时间作为我们性能优化的一个重要参考，虽然有时候并不能给诊断带来直接的切入点，比如我们常常提到的cpu time、db time甚至是response time，这些指标孤立起来因为负载和系统环境的不同可能并没有横向比较的意义，却可以作为某个系统的状态数据和优化前后的成果参考，有很高的纵比意义。
结合awr/statspack，看一下数据库层面上对优化有指导意义的几个重要的时间概念。
【阅读全文】
