发表者： 谷歌移动小组

没有哪个节日能像春节一样，让数亿中国人踏上洋溢着浓情的返乡路程，也没有哪个时刻能像此刻一样，让小小的手机能够如此派上大用场——巧用谷歌手机服务功能，您可以随时随地得到各种各样的帮助。下面，就和大家一起分享一些谷歌手机服务在春节能够“大显身手”的小贴士吧。

旅行小贴士——票务、资讯、路线，谷歌帮您一网打尽

飞机/火车售票点：无论您在哪个城市，只要打开谷歌手机地图，使用“我的位置”功能对当前位置进行定位，再搜索“飞机票”或“火车票”，就能找到离您最近的航空售票处或火车票代售点。手机地图还可以为您提供售票处的联系方式等信息，让您随时致电售票处进行咨询，甚至能够为您规划前往售票点的驾车、公交或步行线路。





城市天气：不知道目的地的天气情况？谷歌帮您搞定！键入“城市名+天气”，您将在搜索结果中看到该城市当天及未来三天的天气预报。此外，如果您已经为自己设定了当前位置，仅输入“天气”就会立即得到本地的天气情况。





春运资讯：在谷歌资讯（Google News）中键入“城市名+ 春运”或者高速公路名称，例如“沈大高速”或者“惠莞高速”就能得到目的地春运相关的最新资讯，了解某条高速公路的通行状况，根据实时情况，您可以随时调整行车路线，一切都变得简单！





路线规划：只需为您的手机安装免费的谷歌地图，您就能随时随地地轻松规划走亲访友或自驾游的出行线路。





实时路况：开车在路上，最担心的莫过于堵车了吧? 不用再忐忑不安了，谷歌手机地图全面支持北京、上海、南京、深圳、广州、成都、重庆的实时路况信息，轻松辨别哪里畅通，哪里拥堵， 拥有谷歌手机地图，从此出行一路畅通!



卫星地图：返乡途中您是否会想象一下这一年来家乡的变化呢？不用等到抵达目的地，现在就使用谷歌手机地图的“卫星视图”先睹为快、一饱眼福吧！





娱乐贴士——吃喝玩乐，谷歌帮您轻松搞定

拜年短信：春节临近，通过谷歌手机搜索“祝福短信”，各式各样的祝福短信被一网打尽，快去挑选一段独特又喜庆的祝福短信送给您的亲朋好友们吧！选好了吗? 那就直接免费发送到自己的手机吧, 连打字的功夫都省了噢!



餐馆信息：春节长假，约上家人或者三五好友，找个餐馆小聚一番，试试新口味。通过谷歌手机地图，输入餐馆名称，您可以直接搜索餐厅位置和到达路线；或者使用“生活信息-餐馆”功能，查找您周边或特定地点周边的餐馆信息。点击餐馆名称，您就能直接致电订餐啦。之外，您还能够查看人均消费价格、其他食客的推荐菜等信息！





影讯：春节贺岁片谁最火？哪个影院最抢手？使用谷歌手机地图“生活信息-影讯”功能，只需几秒钟，您便可以随时随地查看距离自己最近的影院信息和电影放映时间，赶快试一试吧！





即便没有安装手机地图, 也可以方便的通过登录手机版谷歌搜索来查询电影信息及上映时间噢! 搜索“城市名+电影”, 或者设定当前位置后直接搜索“电影”或影片、影院的名称, 火热大片相关信息立即尽收眼底!





养眼大图：春节来临万象更新，您也许想在过年前换个发型，或者动手插花制造节日气氛，或者在出游前提前欣赏目的地风光，谷歌最新的图片搜索技术可以让搜索结果自适应您的手机屏幕，这样您可以查看每一处细节，获得更多信息，得到更好的浏览体验。

译者注: 本文翻译自Jonathan Lewis的文章Faking Stored Outlines in Oracle 9, 可以从此处下载原文的word版本: Stored Outlines in Oracle 9.
本文与前一篇Oracle 8i/9i中的执行计划稳定性是Jonathan Lewis先生写的关于stored outline具体使用以及其中可能涉及到的风险系列文章,也是我所见到的关于stored outline介绍的最详细的文档了. 关于stored outline还有以下相关资料可以对照阅读下:
Oracle Outlines - aka Plan Stability By Kerry Osborne
Plan stability in 10g - using existing cursors to create Stored Outlines and SQL profiles By Randolf Geist
Stored Outlines and Plan Stability By Tim Hall
Tuning Third-party Vendor Oracle Systems :Tuning when you can’t touch the code By Mark Ault

原文为在Oracle 9中伪造存储概要

在Oracle 9中伪造存储概要

在前面的文章中,我讨论到存储概要,并且描述了一种通过滥用系统来生成你所需要存储概要的方法.我同时也指出,在Oracle 9中使用这种方法存在一些风险,因为存储在数据库中的细节信息已经变得非常复杂.在接下来的文章中,我将介绍一种合法的操作存储概要的方法,这种方法可以应用在Oracle 8与Oracle 9中.这篇文章的细节都是基于实验得出的,实验环境是Oracle 8.1.7.0与Oracle 9.2.0.1的默认安装环境.

回顾

当你知道如何通过给一段DML语句添加提示就可以让它运行的快很多,但是你却没有访问源代码并将提示放到适当位置的途径, 你会怎么做?

在上一篇文章中,我展示了你可以如何用存储概要(也被称为执行计划稳定性)来驱使数据库引擎为你做这种工作.
一个存储概要由两个组件组成(宽泛地讲)-一个你希望控制的SQL语句,一组每当Oracle发现这条SQL被优化都将在它上面应用的提示.这两个组件都被保存在一个被称为outln的数据库schema中.

我们可以使用一组如图-1中类似的查询语句来检查保存在其中的SQL语句,以及附着在这条SQL语句上的提示.

select	name, used, sql_text
from	user_outlines
where	category = 'DEFAULT'
;

select	stage, node, hint
from	user_outline_hints
where	name = '{one of the names}'
;

Figure 1 Examining stored outlines.
在前面的文章中,我介绍了这样一种想法来欺骗系统, 使用合法的方法创建一个存储概要, 接着,使用一个文本相似的但已经添加过提示的语句来创建一个存储概要,最后,使用一组SQL语句来交换这两个存储概要的实际结果来修复存储概要.

当时,我曾提到这种方法对Oracle 8来讲或许是安全的,但是由于在新版本中引入的变化, 在Oracle 9中可能会导致问题.
这篇文章将对这些变化进行考查, 介绍一种合法的方法来得到你想要的一组存储到outln中的提示,用来解决你的那些问题语句.

相关变化

如果你登录到outln schema(在Oracle 9中它默认是锁住的)查看可用的表清单,你将发现Oracle 9比Oracle 8多出来一张表. 这些表为:

ol$	SQL语句
ol$hints	提示表
ol$nodes	查询块

第三张表是一张新表,被用来将提示列表与这条SQL语句(一份内部重写的版本)的多个不同查询块.你还将发现,提示列表(ol$hints)也被加强了,其中还包括文本长度与偏移量的细节信息.
图2为这三张表的详细描述,用星号标注了Oracle 9中出现的新字段.

ol$

OL_NAME          VARCHAR2(30)
SQL_TEXT         LONG
TEXTLEN          NUMBER
SIGNATURE        RAW(16)
HASH_VALUE       NUMBER
HASH_VALUE2      NUMBER           ***
CATEGORY         VARCHAR2(30)
VERSION          VARCHAR2(64)
CREATOR          VARCHAR2(30)
TIMESTAMP        DATE
FLAGS            NUMBER
HINTCOUNT        NUMBER
SPARE1           NUMBER           ***
SPARE2           VARCHAR2(1000)   ***

Ol$hints

OL_NAME          VARCHAR2(30)
HINT#            NUMBER
CATEGORY         VARCHAR2(30)
HINT_TYPE        NUMBER
HINT_TEXT        VARCHAR2(512)
STAGE#           NUMBER
NODE#            NUMBER
TABLE_NAME       VARCHAR2(30)
TABLE_TIN        NUMBER
TABLE_POS        NUMBER
REF_ID           NUMBER           ***
USER_TABLE_NAME  VARCHAR2(64)     ***
COST             FLOAT(126)       ***
CARDINALITY      FLOAT(126)       ***
BYTES            FLOAT(126)       ***
HINT_TEXTOFF     NUMBER           ***
HINT_TEXTLEN     NUMBER           ***
JOIN_PRED        VARCHAR2(2000)   ***
SPARE1           NUMBER           ***
SPARE2           NUMBER           ***

ol$nodes  (completely new in 9)

OL_NAME          VARCHAR2(30)
CATEGORY         VARCHAR2(30)
NODE_ID          NUMBER
PARENT_ID        NUMBER
NODE_TYPE        NUMBER
NODE_TEXTLEN     NUMBER
NODE_TEXTOFF     NUMBER

Figure 2 The outln tables.
你可能很快会注意到多处细节-有大量信息被基于这些表的视图排除在外了.视图user_outline_hints的视图定义完全没有改变,尽管表ol$hints上新增加了10个字段.实际上,这个视图在Oracle 8的时候就极度不足,因为它遗漏了相当有用的hint#字段.
你还会注意到,Oracle 9现在有两个hash_value字段.如果你在Oracle 8与Oracle 9中对同样的SQL语句创建存储概要,你将发现它们拥有同样的hash_value,但是Oracle 9中对应的hash_value可能完全不同.
你可以也会发现,Oracle 9中的signature(签名)字段的值与Oracle 8中的值是不同的. 这是由于Oracle这两个版本之间策略上的最主要的调整就是为了提高存储概要的重复利用.在Oracle 8中,只有在你的SQL语句与存储的SQL语句完全匹配(包含空格符/大小写以及换行符)的时候才可以使用.到Oracle 9之后,这个限制放宽了,只要在去除掉重复的”空字符”并且将文本都转换成同样的大小写之后SQL语句能够匹配就可以使用存储概要了.例如,下面的两条SQL语句将使用同一个存储概要.

select * from t1 where id = 5;

SELECT  *
FROM	T1
WHERE   ID = 5;

策略上的这个调整导致了第一次创建这个执行计划的SQL语句的签名的调整;如果你的数据库从Oracle 8升级到Oracle 9,就必须更新存储概要或者必须确认它们不再被使用.(事实上,别名为dbms_outln包outln_pkg包含一个特别的存储过程update_signatures来处理这个问题.
不过,关于Oracle 9中这些表的最意义重大的事情却是对查询语句中涉及到的文本与对象的极度详细描述.创建图-3中显示的例子,并在继续阅读之前详细查看ol$hints表中的内容.

drop table t1;

create table t1
nologging
as
select
	rownum		id,
	rownum		n1,
	object_name,
	rpad('x',500)	padding
from
	all_objects
where
	rownum <= 100
;

alter table t1
add constraint t1_pk primary key (id);

create index t1_i1 on t1(n1);

analyze table t1 compute statistics;

create or replace outline demo_1 on
select	* from t1
where	id = 5
and	n1 = 10
;

Figure 3 Sample code.
这个例子立足于一个简单的小表,包含两组相近的列,其中一个列为逐渐(从而也创建了索引),另外包含一个简单的非唯一索引.我们为一个典型的查询创建一个存储概要来查看我们可以如何对待它.
如果针对由这个例子创建的存储概要demo_1运行图-1中的示例查询,我们将发现这个查询将附带6个提示.

  STAGE  NODE  HINT
	    3     1  NO_EXPAND
	    3     1  ORDERED
	    3     1  NO_FACT(T1)
	    3     1  INDEX(T1 T1_PK)
	    2     1  NOREWRITE
	    1     1  NOREWRITE

不出意外,其中的第四行显示我们将使用主键索引来访问这张表.如果我们实际上想要Oracle使用这个非唯一索引T1_I1访问表,我们该对存储概要做什么呢?理论上讲,我们可以调整这个存储概要以使得

	    3     1  INDEX(T1 T1_PK)

变成

	    3     1  INDEX(T1 T1_I1)

新特性

我们可以做的第一件事是查看包dbms_outln_edit.这个包在Oracle 9中引入,正如它的名字提示的那样,它的目标是编辑存储概要,这看上去令人充满希望.
然而,查看包的方法列表,检查文档手册,我们发现这个包只包含如下几个”编辑相关”的方法.

	CREATE_EDIT_TABLES
	DROP_EDIT_TABLES
	CHANGE_JOIN_POS

前两个方法允许我们创建或删除outln用户拥有的表的本地拷贝.第三个方法允许我们交换一个存储概要计划中的表连接顺序. 哪怕仅仅是帮助我们修改一个简单的提示的方法也是没有的.目前,这个包看上去实际上一无是处-但是它们注定会越来越完善.
当然B方案就是去侵入它了!如果我们登录到outln用户,并自己诊察ol$hints表(也就是支撑视图user_outline_hints的表)的内容,我们可以尝试下面的这个更新操作:

update ol$hints
set
	hint_text = 'INDEX(T1 T1_I1)'
where
	ol_name = 'demo_1'
and hint# = 4
;

登录回到我们的测试Schema,清空共享池,并且打开存储概要:

connect test_user/test
alter system flush shared_pool;
alter session set use_stored_outlines = true;

实际上,我们将发现侵入的存储概要确实如你所愿了.但是这是一个让人不爽的解决方案,
因为我们一直会给一个关于”更改数据字典表”的严厉的警告.

旧方法(1)

接着,我们的目标就是寻找一种迂回但又看似无害的方法来改变存储概要表的内容,并且不需要直接的侵入存储概要表.
从前(在Oracle 9以前),我们有多种实现办法,它们都是基于这样一个事实,存储概要的效果仅仅取决于进来的SQL语句的文本,而完全不关心对对象类型或者对象的所有者.
将表替换成添加过提示的视图是一种有效的方法.(我相信,这种方法最初是由Tom Kyte在它的《Expert One on One: Oracle》这本书中介绍的).
连接到另外一个拥有表T1的访问权限的Schema，按照下面的定义创建一个添加过提示的视图,视图与表的名称保持一致.

Create or replace view t1 as
Select /*+ index(t1,t1_i1) */
	*
from test_user.t1;

一旦视图创建完成,就在这个schema下使用下面的这个命令”重编译”这个已存在的存储概要.

	alter outline demo_1 rebuild;

注意:必须拥有权限alter any outline才可以执行这个命令.
如果登录回到原来的schema,清空缓存(flush shared pool),并且启用存储概要,我们将会发现原来的查询语句现在如愿以偿的使用上了索引T1_I1.

	    3      1  INDEX(T1 T1_I1)

这样为什么可行?因为存储概要并不属于任何一个schema. 当我们在另外一个schema中重编译这个称为demo_1的存储概要的时候,名称T1应用到了一个本地的包含提示的视图上了,因此Oracle将这个提示包装进了真实的执行计划中,从而也进入了这个存储概要.通过查看视图user_outline_hints,将会发现关键的那一行已经变成了
3 1 INDEX(T1 T1_I1)

很不幸,我们还将注意到它现在包含3行如下形式的提示:

	    2      1  NOREWRITE
	    1      2  NOREWRITE
	    1      1  NOREWRITE

而原来我们只有两行:

	    2     1  NOREWRITE
	    1     1  NOREWRITE

我们引入了一个新的提示,也就是”Stage 1,Node 2″.我不敢说我确切的知道这是什么意思,但是它一定与这样一个事实有关,为了在另外一个Schema解析优化这个查询,Oracle执行了一个额外的步骤来将视图引用转换成基础表的引用.
虽然目前这不会导致存储概要无法正确使用(或者如同它在这个简单的例子中这样),谁又能说Oracle在将来的版本又会有多挑剔呢.

旧方法(2)

因为视图引入了一个可能在将来版本变成错误的异常,我们不得不更加挑剔. 让我们试试下面的这种方法:

Create a new schema.
Create table T1 in that schema.
Create ONLY the index T1_I1.
Rebuild the outline in that schema

如果比较存储概要重建前后user_outline_hints的详细内容(必须重新登录到原来的Schema来做这件事),我们将发现除了我们想要改变的那一行,它们是完全一样的.重新登录回原来的Schema,通过清空共享池以及打开存储概要做一个常规检查,我们将会发现修改后的存储概要已经被使用了.

然而,还有一个潜在的威胁,不过这一次更加隐蔽.再回去看图-2中出现在Oracle 9中的新字段的定义-你认为字段user_table_name中保存的值将会是什么啊?它应该是有限制的表名称,例如:
{User_name}.{table_name}

在我们的例子中,这将告诉Oracle表T1实际上是一个属于新的Schema的表,而不是原来的Schema下面的表.即使Oracle确实在使用这个存储概要,这个表里的信息也充分说明Oracle是在错误的对象上面应用这个存储概要.
另外,它现在现在有效,但是为什么有这个信息在这儿呢-可能是为了将来的版本增强做准备呢.

可靠的赌注

看来,要生成存储概要,而又不面临将来的风险就只有一种方法了,那就是尽可能的真实.

在这个示例中,你需要删除主键索引,生成执行计划,然后替换掉主键.

当然,你可能不想在生产环境做这件事,即使你在生产环境做了,存储概要也有可能选择走全表扫描(而不是走你想要的那个索引).
底线是你必须至少在另一个数据库中有一个这个Schema的空闲拷贝,接着需要非常小心的操作这个拷贝以得到需要的存储概要.一旦得到这个存储概要,你就可以从一个数据库导出它并将其导入另外一个数据库.
例如:在这个空闲的数据库上,删除主键以避免PK唯一扫描就是可行的.如果Oracle并没有自动的采用另外一个索引,你可以对系统说各种谎言,诸如:

• 将optimizer_mode改成first_rows_1
• 构造数据使得列N1上的数据是唯一的.(不过,不要将其改成唯一索引,这样生成出来的存储概要将是unique scan而不是range scan了).
• 使用dbms_stats来使这个索引获得一个难以置信的clustering_factor.
• 调整参数optimiser_index_caching来告诉系统,这个索引已经完全被缓存.
• 调整optimiser_index_cost_adj来告诉系统,多块读要比单块读要慢100倍.
• 使用dbms_stats修改aux_stats$表来达到上一条同样的宣称效果,并且添加这样一个事实,一次多块读的典型大小为2个块.
• 重建这个索引以包含where从句中的所有字段.

给定存储概要表中的内容,假使表的所有者不变,对象类型不变以及不改变索引的唯一度,几乎任何事情都可以做. 如果你可以构造一个数据集与环境来生成一份与生产系统没有内部不一致的存储概要,那么你就可以以任何方式来欺骗系统.

结论
相对于Oracle 8来讲,在Oracle 9中进入存储概要的信息变更更加精细了.之前可以非常容易也很明显无风险的”调整”存储概要的方法,现在还仍然可以工作,但是Oracle 9中收集的巨量的附加信息表明,之前的那种方法现在可能会给将来留下隐患.

虽然Oracle 9中引入了一个编辑存储概要的包,但它当前还只是局限在交换表的连接顺序.除了使用第二套系统来调整索引(通过改变环境参数以及人造的统计信息)外, 看似不存在安全的干预存储概要的方法.

参考文献
Oracle 9i Release 2: Database Performance Tuning Guide and Reference - Chapter 7.
Oracle 9I Release 2: Supplied PL/SQL Packages and Types Reference - Chapters 41 - 42

    一直以来, DataReport都是用表格方式显示多行数据, 当我们查询少量字段数很多的记录时, 就不希望以表格方式显示记录, 而希望以Form格式显示, 如下面显示的员工表的信息.

EMPNO	7782
ENAME	CLARK
JOB	MANAGER
MGR	7839
HIREDATE	1981-06-09 00:00:00.0
SAL	2450
COMM
DEPTNO	10
EMPNO	7839
ENAME	KING
JOB	PRESIDENT
MGR
HIREDATE	1981-11-17 00:00:00.0
SAL	5000
COMM
DEPTNO	10

    实现这个功能, 并没有修改任何一行代码, 只是改了一下控制显示格式的XSL文件, 然后在报表定义文件中加入一行.

WEBCHART.XMLATTR=form="yes"
WEBCHART.QUERY_1=SELECT * FROM EMP WHERE DEPTNO=10

    想要更丰富的格式, 只需要再改进一下XSL文件即可, 不需要修改Java代码, 不过这需要你对XML和XSLT比较熟悉.

Relative Posts:

• 2010/01/20 -- 逻辑连接层与物理连接层 (3)
• 2010/01/08 -- DataReport中的超级表达式 (0)
• 2010/01/08 -- DataReport的重复值合并 (0)
• 2010/01/05 -- DataReport中的FORALL循环 (0)
• 2009/12/29 -- DataReport中的Cache为王 (4)
• 2009/12/28 -- 统一DataReport的Servlet (2)
• 2009/12/02 -- 添加URL/HTML字符转义功能 (1)
• 2009/09/21 -- 多支持了四种业务图 (0)
• 2009/07/28 -- DataReport增加JfreeChart支持 (7)
• 2009/07/25 -- DataReport的图片服务功能 (0)

发表者：Jonathan Simon，网站站长趋势分析员
原文：Request Visitors' Permission before installing software
转载自：谷歌中文网站管理员博客
发表时间：2010年2月3日

站长级别:全部

合法的网站可能需要他们的访问者安装软件。这些网站通常会提供给他们的用户标准的网站浏览器之外的功能，比如说查看某种特定类型的文件。请注意，如果你的网站需要用户安装特定的软件，这种软件的安装的过程是非常重要的。错误的安装过程可能会让你的网站看起来像是在安装恶意软件，从而触发我们的恶意软件检测过滤器，导致你的网站在我们的搜索结果里面被加上了“Google恶意软件提示标签”。

如果浏览你的网站需要安装某种特定的软件，你首先需要告诉你的用户为什么他们需要安装这种软件。这里有关于如何处理这种轻的两个错误做法的例子和一个正确做法的例子。

错误的做法：在没有给用户选择是否安装该软件的情况下就自行安装了软件。

错误的做法：弹出一个确认对话框提示用户同意安装该软件，这时并没有给用户足够的可以选择的信息。(这里包括标准的ActiveX 控制安装对话框， 因为它并没有提供足够有用的信息让用户在知情的情况下做出自己的选择。)

正确的做法：将该访问者重定向到一个提供了完整的信息的页面，该页面上应该对为什么这个特定的软件应该被安装给出详细的解释。 从这个页面上，访问者可以继续这个软件的安装过程如果他们觉得这个软件有用的话。

你的网站是否因为给访问者安装软件方法不当而被加上过恶意软件的标签？解决的方法很简单，更新软件的安装过程从而保证每一个访问者都知道这种软件的安装对于他们而言是非常必要的，同时给他们选择退出安装的权利。如果你按照这种方法更新了你网站上软件的安装过程，你就可以到网站站长工具中申请重新评估恶意软件，从而更快删除你的网站在搜索结果中的恶意软件标签。

p { text-indent:28px; } 在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。 Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。 1. 如何配置Key Cache的大小 #配置文件my.cnf key_buffer_size=50*1024*1024 另外，Key Cache的大小可以动态的改变 2. 给数据表划分单独的Key Cache 例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。 SET GLOBAL hot_cache.key_buffer_size=128*1024; CACHE INDEX t1 IN hot_cache; SET GLOBAL hot_cache.key_buffer_size=0; 3. 预先载入某些数据表的索引 LOAD INDEX INTO CACHE t1, t2 4. 关于Key Cache的使用情况观察 Flush现象 mysql> show status like "key%"; +------------------------+----------+ | Variable_name ...

p { text-indent:28px; } 本文将分为前、中、后三篇，分别介绍MyISAM Key Cache的一般机制、Mid-point strategy、状态、参数和命令。 “Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。 1. MyISAM如何使用Key Cache 当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。 如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。 2. 图解 下图展示了访问Index Block的过程：（黑色部分为磁盘中的Index文件） 3. 并发访问 Key Cache中的index Block是可以被并发访问的（Shared access ），下面是一些规则： 多个没有更新操作的session可以并发同一个block buffer 多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问 多个session如果都需要进行block replacement，是可以并发操作。（从index file中读取block更新到key cache，但是key cache已满，需要删除一些block buffer的操作叫做block replacement）   4. 补充说明 Key cache中的Block大小可能和索引文件中的Index Block大小不同，可能是大于、小于、等于中的任何一种，但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。 （未完待续）

p { text-indent:28px; } 在前篇中介绍了Key Cache的基本机制，并且介绍了Key Cache的LRU算法。作为对LRU算法的改进，MyISAM还提供了另一个缓存算法：“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。 1. 相关参数 该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold 2. 原理介绍 (1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。 (注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值) (2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。 (3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。 (4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。 (5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。 3. 如何使用Midpoint Insertion Strategy 我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。 （未完待续）

最近收到不少应届生朋友的咨询，也有不少心急的简历发到了我的邮箱。今天从HR得到消息，淘宝网2010年校园招聘马上要开始了，招聘网站已经正式对外开放。有意向应聘淘宝网的应届生，可以通过此网站关注招聘的职位等信息。简历也请通过该平台递交即可。 淘宝网2010年校园招聘，点此进入。 同时全国各大学宣讲时间也已经确定，第一场将于9.21从浙江大学开始。具体时间安排如下： 浙江大学 2009-9-21 浙大永谦学生活动中心小剧场 18:00--21:30 西安交通大学 2009-9-25 西交大就业中心一楼大厅 18:00--20:30 西北工业大学 2009-9-26 长安校区教学西楼A100(新校区大报告厅) 9:00--12:00 南京大学 2009-9-25 南大科技馆一楼报告厅 18:00--20:30 东南大学 2009-9-26 教学楼1#楼211或311 9:00--12:00 上海交通大学 2009-10-10 闵行区陈瑞球楼报告厅 18:00--20:30 清华大学 2009-10-10 待定 14:00--17:00 北京邮电大学 2009-10-12 教3楼339 9:00--12:00 中国科技大学 2009-10-13 西区学生活动中心学术报告厅 14:00--17:00 大连理工大学 2009-10-19 研究生教育大楼报告厅 14:00--17:00 四川大学 2009-10-19 老校区-就业中心201 15:00--18:00 电子科技大学 2009-10-20 清水河学生活动中心2楼圆厅 9:00--12:00 东北大学 2009-10-23 学生活动中心大厅 14:00--17:00 华南理工大学 2009-10-26 南校区A4-204报告厅 14:00--17:00 中山大学 2009-10-27 南校区熊德龙2楼报告厅 9:00--12:00 武汉大学 2009-10-26 人文馆主厅 14:00--17:00 华中科技大学 2009-10-27 大学生活动中心305教室 9:00--12:00 哈尔滨工业大学 2009-10-27 待定 14:00--17:00 复旦大学 待定 待定 14:00--17:00 杭州电子科技大学 2009-11-3 待定 待定 浙江工业大学 2009-11-10 待定 待定

SemiSyncReplication是Google提供的一个MySQL patch，作用在于保证至少有一个slave完成了数据同步。 安装的过程很简单，但是要找对路。这里提供一个传送门，看完就会编译安装了： http://www.realzyy.com/?p=178 SemiSyncReplication需要的MySQL源码包为mysql-5.0.37.tar.gz；需要的patch为mysql-5.0.37_semisync.patch。其他的patch可以不打，但是如果选择mysql-5.0.37-patches来打补丁的话，那么记得要再打上http://www.realzyy.com/?p=178最后提到的那个小补丁。 配置也很简单，主要是三个参数： master： rpl_semi_sync_enabled = 1 #configures a master to use semi-sync replication. rpl_semi_sync_timeout = 10000000 #the timeout in milliseconds for the master. slave： rpl_semi_sync_slave_enabled = 1 #configures a slave to use semi-sync replication. The IO thread must be restarted for this to take effect. 要特别注意rpl_semi_sync_timeout这个参数，官网推荐的设置10太短了。我测试了一下，将slave上的replication线程停掉，master上面执行更新操作并不会出现明显的block现象。如果想让master和slave时时刻刻保证一致，那么rpl_semi_sync_timeout就需要设置得很大，至少在DBA能察觉异常之前，不允许master单方面进行更新操作。

在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变化，这个变化在某种程度上影响着当前DBA的角色变化问题。 在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样改变目前的现状。 在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的增长，由于大量采用低端机器，集群中某个机器出问题的概率大增，可能每天都会处理好几次down机的事故;第二，对监控系统的要求增加，对10台数据库的监控与对1000台数据库的监控方法肯定会有许多差异的,我们的监控系统也应该具有分布式的能力,避免单点；第三，系统精细化运维能力需要提升，采用大量低端pc server,在机房的设计上要尽可能的下功夫，可以参考一下google的机房建设的论文，pc server的硬件在不同应用上的定制化以尽量节能，CPU个数是否存在严重过多的情况,pc server上装的linux os是否有优化过，不同版本的os是否存在稳定性问题，os上跑的mysql是否已经足够的优化。 另外一个方面的变化，是来自于我们的分布式数据层的开发人员。他们开发的数据层是前端应用与底层数据库集群的中间纽带,是整个分布式数据库系统最重要的组成部份。而开发分布式数据层的开发人员自然会成为核心的核心，他们对于许多底层技术的理解相当的深入。与他们讨论问题时，倍感知识的匮乏。大部份DBA由于缺乏长期的开发经验的积累，双方沟通时，有时会比较吃力。 从长远的方向来讲，分布式数据库系统将会越来越依重于分布式中间件产品，整个应用系统的健康也会更依赖于开发人员的能力。在某种程度上，分布式数据库时代的DBA的重要性，会低于集中式数据库时代的DBA重要性。但对于公司而言，整个公司的技术实力有了质的飞跃,大大节约了成本,也掌握了未来的主动权。 如何扩大DBA的外延与内涵，来适应这种变化，是我们共同努力的方向.

在这篇文章里，给大家简单介绍一下本人对Oracle索引的理解，如有不妥的地方，请不吝指教。 本文只讲最最平常最最简单的索引，就是以create index ix on tx(a,b,c);形式创建的索引，而不讲位图索引、反向键索引、倒序索引、基于函数的索引等等。其实呢，只要是基于B树的索引，不管是在Oracle, Mysql，还是其它数据库中，原理应当都是一样的。 索引最重要的一个性质应该就是有序，索引中的每一项，是从左到右，从小到大，以严格的顺序排列好的。 下面的讨论都以上面的索引ix(a,b,c)为例。 把这棵索引的叶子节点画到纸上，大概是这样的： a1 a2 a3 ...... an b1 b2 b3 ...... bn c1 c2 c3 ...... cn 上面这个3×n的矩阵，每一列代表了一条记录，同时这一列记录，也对应了表里的唯一一条记录。当然，在Oracle里，对于non-unique索引，需要补上rowid，才是真正唯一的。上面的索引相当于create unique index ix on tx(a,b,c,rowid); 我们把这个细节忽略掉。 把每一列看作一个向量,vi = (ai, bi, ci)， 有序的含义就是： vi < vj iff i ＜ j; vi < vj这么定义： (ai ＜ aj) or (ai = aj and bi ＜ bj) or (ai = aj ...

章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。 讲解的内容就不具体介绍了，在LVS官方网站上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^ 组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。 典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示： 如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示： 目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。 在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩展性。 美中不足的是，NDB Cluster的性能实在太差。即使LVS负载均衡做得很好很强大，NDB Cluster也会成为瓶颈。 根据我的观察发现，LVS的架构非常适用于CPU-bound的应用场景。虽然共享存储的引入使得LVS能够支持有状态的连接，但是LVS并不适用于IO-bound的应用。因为不管负载如何均衡，最终瓶颈在于共享存储之上。而共享存储如何拓展，LVS并不关心。也许只有NDB Cluster提升了IO性能之后，LVS才能真正在MySQL方面应用起来。 非常感谢章博士的分享，NDB Cluster终于让我觉得不那么鸡肋了。

InnoDB在接受MySQL线程调用时，有一个并发线程的检查机制，通过innodb_thread_concurrency参数进行控制。如果参数设置大于0，则表示检查机制开启，允许进入的线程数就是参数的值。等于0则禁用并发检查。 在新的MySQL线程调用Innodb接口前，Innodb会检查已经接受的请求线程数，如已经超过innodb_thread_concurrency设置的限制，则该请求线程会等待innodb_thread_sleep_delay微秒后尝试重新请求，如果第二次请求还是无法获得，则该线程会进入线程队列休眠。重试两次的机制是为了减少CPU的上下文切换的次数，以降低CPU消耗，这和Oracle中latch的spin机制是同样的道理。如果请求被Innodb接受，则会获得一个次数为innodb_concurrency_tickets(默认500次)的通行证，在次数用完之前，该线程重新请求时无须再进行前面所说innodb_thread_concurrency的检查。 上述检查逻辑在源码storage/innobase/srv/srv0srv.c(Innodb很多参数都可以在该文件中找到定义)的srv_conc_enter_innodb函数中，有兴趣的可以仔细阅读一下，代码比较浅显，不难理解。另外，如果是一个已经持有lock的线程，则通过调用srv_conc_force_enter_innodb函数可以无视该检查，这是为了避免线程长时间持有锁影响性能，且可能增加死锁的机率。除此之外，slave线程也是有无视检查直接通行的权限。 简单思考一下上述机制，可以得出一个初步的推论：在数据库并发请求较小的情况下，从性能上来说禁用检查机制应该是更好的，毕竟执行检查机制本身也需要加锁(Mutex)。当并发线程很高的情况下，则开启检查机制对性能更有利。至于具体innodb_thread_concurrency设置为多少，可能就需要在不同的条件下实际的做一下测试了，不同的硬件环境，不同的MySQL版本和Innodb版本，应该都会有一些区别。 源代码中对于innodb_thread_concurrency参数的注释如下： /* The following controls how many threads we let inside InnoDB concurrently: threads waiting for locks are not counted into the number because otherwise we could get a deadlock. MySQL creates a thread for each user session, and semaphore contention and convoy problems can occur withput this restriction. Value 10 should be good if ...

开发DBA周会中，丁原提出的问题： DML语句中where子句中添加rownum alter session set nls_language=american; SQL> create table test as select 1 as id from dba_objects where rownum < 10; n  把表中的数据块dump出来 SQL> select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,   2                  dbms_rowid.rowid_block_number(rowid) as block#   3    from test;        FILE#     BLOCK# ---------- ----------          4        988   SQL> alter system dump datafile 4 block 988; System altered. n  查看trace文件，其中的部分数据如下： Block header dump:  ...