eygle.com   eygle.com
eygle.com  
 
Digest Net: September 2008 Archives

September 2008 Archives

Linux Ext3日志模式对数据库的影响

ext3与ext2最大的区别就是ext3有日志,相信大家也知道ext3的日志模式有三种

◆data=journal日志模式
日志中记录包括所有改变文件系统的数据和元数据。它是三种ext3日志模式中最慢的,也是最安全的一种。每个变化需要写磁盘2次、日志写1次。所有新数据首先被写入日志,然后才被定位。意外发生过后,日志可以被重放,将数据与元数据带回一致状态。

◆data=ordered日志模式
仅记录改变文件系统的元数据,且溢出文件数据要补充到磁盘中。这是缺省的ext3日志模式。文件数据的变化情况并不被记录在日志中,但它们必须做,而且由 ext3的daemon程序在与之相关的文件系统元数据变化前执行,即在记录元数据前要修改文件系统数据,这将稍微降低系统的性能(速度),然而可确保文件系统中的文件数据与相应文件系统的元数据同步。

◆data=writeback日志模式
仅记录改变文件系统的元数据,但根据标准文件系统,写程序仍要将文件数据的变化记录在磁盘上,以保持文件系统一致性。这是速度最快的ext3日志模式。因为它只记录元数据的变化,而不需等待与文件数据相关的更新如文件大小、目录信息等情况,对文件数据的更新与记录元数据变化可以不同步,即ext3是支持异步的日志。缺陷是当系统关闭时,更新的数据因不能被写入磁盘而出现矛盾,这一点目前尚不能很好解决。

ext3文件系统还涉及到如何cache中的数据刷到硬盘上。它是通过kupdate进程来实现定期刷的,默认是5秒检查一次,将超过30秒的脏数据刷到硬盘。在as 3.0中可以通过修改/proc/sys/vm/bdflush来达到目的。

而在as 4.0中可以通过修改/proc/sys/vm/dirty_writeback_centisecs和/proc/sys/vm/dirty_expire_centisecs来达到目的。

由于默认是ordered模式,在这种模式下面,如果一个IO先写数据文件,然后再写日志文件。假如说在写完数据文件之后,写日志文件之前时,系统发生crashed,则这部分数据将会丢失,这在数据库是绝对不允许的,不管是Oracle还是MySQL。所以对数据库的写来说,每一次写操作都会先写到pagecache中,然后通知kernelthread 将这个buffers刷到硬盘,然后再将元数据写日志,最后才返回写成功的操作。这样对数据库来说写操作是明显不如写祼设备快

所以说在采用Ext3跑数据库的情况下,将日志模式设为journal模式,性能反而应该会有所提升(没有测试过,理论上分析应该是这样)。 因为在journal模式下数据库一个写操作,先是直接将数据和文件系统的变化写到日志中(绕开cache直接写,性能较好),然后将数据写到cache中,接着由kupdate进程将数据刷新到硬盘上。 相比之下,对DB来讲,它的性能应该比前面一种要快

另外这里还提一下MySQL中的sync_binlog这个参数。如果将这个参数设为1,也就是说每次写binlog文件将同时刷到硬盘上面去,就像Oracle的写IO一样。如果将这个参数关闭,则它交给OS来管理,也就是每5秒检查一次,发现有30秒以前的老数据则刷到硬盘上。innodb_flush_log_at_trx_commit参数来也涉及到刷硬盘的问题。

原文出处:Logzgh

RAC Process Of LMON & LMD & LMSn

The following processes are unique to a RAC environment:
* Lock monitor (LMON) process: The LMON process monitors all instances in a cluster to detect the failure of an instance. It then facilitates the recovery of the global locks held by the failed instance. It is also responsible for reconfiguring locks and other resources when instances leave or are added to the cluster (as they fail and come back online, or as new instances are added to the cluster in real time).

* Lock manager daemon (LMD) process: The LMD process handles lock manager service requests for the global cache service (keeping the block buffers consistent between instances). It works primarily as a broker sending requests for resources to a queue that is handled by the LMSn processes. The LMD handles global deadlock detection/resolution and monitors for lock timeouts in the global environment.

* Lock manager server (LMSn) process: As noted earlier, in a RAC environment, each instance of Oracle is running on a different machine in a cluster, and they all access, in a read-write fashion, the same exact set of database files. To achieve this, the SGA block buffer caches must be kept consistent with respect to each other. This is one of the main goals of the LMSn process In earlier releases of Oracle Parallel Server (OPS) this was accomplished via a ping. That is, if a node in the cluster needed a read-consistent view of a block that was locked in exclusive mode by another node, the exchange of data was done via a disk flush (the block was pinged). This was a very expensive operation just to read data. Now, with the LMSn, this exchange is done via very fast cache-to-cache exchange over the clusters?? high-speed connection. You may have up to ten LMSn processes per instance.

* Lock (LCK0) process: This process is very similar in functionality to the LMD process described earlier, but it handles requests for all global resources other than database block buffers.

* Diagnosability daemon (DIAG) process: The DIAG process is used exclusively in a RAC environment. It is responsible for monitoring the overall health of the instance, and it captures information needed in the processing of instance failures.

AWR dbms_workload_repository使用

| 1 Comment

Oracle 在10g以前的使用的是 Statspack做性能故障诊断的。Oracle Database 10g 提供了一个显著改进的工具:自动工作负载信息库 (AWR)。AWR 和数据库一起安装。数据库装好后,,快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次(snap)
要查看当前的设置,您可以使用下面的语句:

select snap_interval, retention from dba_hist_wr_control;

SNAP_INTERVAL RETENTION
------------------- -------------------
+00000 01:00:00.0 +00007 00:00:00.0

这些 SQL 语句显示快照每小时采集一次,采集的数据保留 7 天。要修改设置 -- 例如,快照时间间隔为 20 分钟,保留时间为两天 -- 您可以发出以下命令。参数以分钟为单位。

begin dbms_workload_repository.modify_snapshot_settings ( interval => 20, retention => 2*24*60 ); end;

AWR 使用几个表来存储采集的统计数据,所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下,并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息(如检查的数据库和采集的快照),后一种类型保存实际采集的统计历史数据。(H 代表"历史数据 (historical)"而 M 代表"元数据 (metadata)")

在这些表上构建了几种带前缀 DBA_HIST_ 的视图,这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关;例如,视图 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上构建的。 AWR 历史表采集的信息比 Statspack 多许多,这些信息包括表空间使用率、文件系统使用率、甚至操作系统统计数据。这些表的完整的列表可以从数据字典中看到。

手工创建快照可以使用:

exec dbms_workload_repository.create_snapshot;

通过awrrpt脚本可以生成报告:
@?/rdbms/admin/awrrpt
生成报告,html和text格式都可以

Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of entries from September 2008 listed from newest to oldest.

August 2008 is the previous archive.

October 2008 is the next archive.

回到 首页 查看最近文章或者查看所有归档文章.