2010-02-10 Wed
Buzz 概念不错,Google 利用庞大的 Gmail 用户群,有望借此一举在微博市场反客为主。不过问题也不少,若不改进,恐怕将来 Buzz FAQ 第一条就是“怎样关掉这玩意儿?”。
1. 切换问题。昨天等了一晚,Buzz 还没进入我的 Gmail 界面。今天早上一看,Gmail 左边栏只剩下一个 More 标签,Inbox、Sent Mail 等标签统统不知所踪。我怀疑 Buzz 标签自动导入时,跟 Labs 冲突了,于是进入 Settings 菜单,找到 https://mail.google.com/mail/?labs=0 这个用于脱离 Labs 的 URL 打开,方才看到 Buzz。
2. 自动 follow。不知 Buzz 依据什么规则,自动 follow 了一堆联系人,有些是工作上的 Email 联系人,不宜 buzz。
3. 时间线混乱。只要有某个 following 的任何一个 follower 顶帖,following 的任何一条 buzz 都有可能随时被顶上来。比如 following 中有个 @hecaitou 这样的热门人物,你的 Buzz 时间线永远是乱的。
4. 同步很慢。我设置了 Twitter 为 Connected Site 之一,至今尚未同步到 Buzz。(看到有人成功了,但是很慢,而且很快被淹没在混乱的时间线中。)
5. 不能反向同步。Buzz 上说的话不能反向同步到 Twitter,也就是说 Buzz 不能作为 Twitter 客户端。(也许可以用 Buzz API 搭一个中间站。)
所以,我认为,Buzz 短期内是不会被墙的,Gmail 更不会。Twitter 是有序的信息轰炸,而 Buzz 是无序的信息轰炸,看着看着人就晕了。可见 Buzz 和墙的终极诉求是完全一致的。
Run-time memory allocation for KVM guests
In a virtualized environment, portions of the host's physical memory are allocated to each guest, with each guest starting a virtual session with a fixed RAM allocation. Run-time memory allocation — referred to as memory ballooning during development — allows for changing this allocation at run time. Part of a particular guest's allocation can be reclaimed by the host and allocated to other guests. As well, guests can request additional memory from the host, re-allocating memory assigned to other guests at run-time. This is done using a so-called 'balloon' driver: changing memory allocations is, in line with this analogy, known as inflating or deflating the driver. With this update, a virtio balloon driver has been added to Red Hat Enterprise Linux 5.5, enabling KVM guests to change the amount of memory allocated to them at run-time. (BZ#522629)PCI passthrough improvements
PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system. KVM and Xen hypervisors both support attaching PCI devices on the host system to virtualized guests.Detecting kernel tasks stuck in the uninterruptible sleep state
In some circumstances, tasks in the kernel may permanently enter the uninterruptible sleep state (D-State), making the system impossible to shut down. With this update, the Detect Hung Task kernel thread has been added, providing the ability to detect tasks permanently stuck in the D-State.CONFIG_DETECT_HUNG_TASK kernel flag. When set to "y" tasks stuck in the D-State are detected; when set to n it is off. The default value for the CONFIG_DETECT_HUNG_TASK flag is y.CONFIG_BOOTPARAM_HUNG_TASK_PANIC flag has been added. When set to y, a kernel panic is triggered when a task stuck in the D-State is detected. The default value for theCONFIG_BOOTPARAM_HUNG_TASK_PANIC flag is n.主要的测试代码以及测试方法都依赖于之前翻译的两篇Jonathan Lewis的关于stored outlines的两篇文章:
Oracle 8i/9i中的执行计划稳定性
在Oracle 9中伪造存储概要
此文的原文为 针对stored outline做得几个测试
1. 测试场景
- os : Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
- Db Version: Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
2. 初始化环境.
sys@test>@tmp sys@test>create user james identified by james default tablespace users temporary tablespace temp; User created. Elapsed: 00:00:00.00 sys@test>grant create session,create table,create procedure,create any outline,alter session to james; Grant succeeded. Elapsed: 00:00:00.01 sys@test>alter user james quota unlimited on users; User altered. Elapsed: 00:00:00.00 sys@test> sys@test>@conn james/james sys@test>SET TERMOUT OFF james@test> james@test>set feedback off james@test>alter session set cursor_sharing = exact 2 / Elapsed: 00:00:00.00 james@test>alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss' 2 / Elapsed: 00:00:00.00 james@test>SET TERMOUT ON james@test>set feedback on james@test>set timing on james@test> james@test>create table so_demo ( 2 n1 number, 3 n2 number, 4 v1 varchar2(10) 5 ); Table created. Elapsed: 00:00:00.05 james@test> james@test>insert into so_demo values (1,1,'One'); 1 row created. Elapsed: 00:00:00.00 james@test> james@test>create index sd_i1 on so_demo(n1); Index created. Elapsed: 00:00:00.01 james@test>create index sd_i2 on so_demo(n2); Index created. Elapsed: 00:00:00.00 james@test> james@test>analyze table so_demo compute statistics; Table analyzed. Elapsed: 00:00:00.01 james@test> james@test>!cat > c_proc.sql <create or replace procedure get_value ( 2 i_n1 in number, 3 i_n2 in number, 4 io_v1 out varchar2 5 ) 6 as 7 begin 8 select v1 9 into io_v1 10 from so_demo 11 where n1 = i_n1 12 and n2 = i_n2 13 ; 14 end; 15 / Procedure created. Elapsed: 00:00:00.02 james@test>_END_ SP2-0042: unknown command "_END_" - rest of line ignored. james@test>!wrap iname=c_proc.sql PL/SQL Wrapper: Release 9.2.0.8.0- 64bit Production on Tue Feb 09 23:29:26 2010 Copyright (c) Oracle Corporation 1993, 2001. All Rights Reserved. Processing c_proc.sql to c_proc.plb james@test>@c_proc.plb james@test>
3. 得到当前此SQL的存储概要.
james@test>var m_value varchar2(10); james@test>alter session set create_stored_outlines = demo; Session altered. Elapsed: 00:00:00.00 james@test>exec get_value(1, 1, :m_value); PL/SQL procedure successfully completed. Elapsed: 00:00:00.03 james@test>alter session set create_stored_outlines = false; Session altered. Elapsed: 00:00:00.00 james@test>col category format a20 james@test>select name, category, used, sql_text from user_outlines where category = 'DEMO'; NAME CATEGORY USED SQL_TEXT ------------------------------ -------------------- --------- -------------------------------------------------------------------------------- SYS_OUTLINE_100209233527397 DEMO UNUSED SELECT V1 FROM SO_DEMO WHERE N1 = :B2 AND N2 = :B1 1 row selected. Elapsed: 00:00:00.01 james@test>col hint format a30 james@test>select name, stage, hint from user_outline_hints where name = 'SYS_OUTLINE_100209233527397'; NAME STAGE HINT ------------------------------ ---------- ------------------------------ SYS_OUTLINE_100209233527397 3 NO_EXPAND SYS_OUTLINE_100209233527397 3 ORDERED SYS_OUTLINE_100209233527397 3 NO_FACT(SO_DEMO) SYS_OUTLINE_100209233527397 3 INDEX(SO_DEMO SD_I1) SYS_OUTLINE_100209233527397 2 NOREWRITE SYS_OUTLINE_100209233527397 1 NOREWRITE 6 rows selected. Elapsed: 00:00:00.00 james@test>
4. 第一种改变存储概要的方法, 也即通过直接修改存储概要表来调整.
4.1 生成新的用来伪造的存储概要
james@test>create or replace outline so_fix
2 for category demo on
3 select /*+ index(so_demo, sd_i2) */ v1
4 from so_demo
5 where n1 = 1
6 and n2 = 2;
Outline created.
Elapsed: 00:00:00.01
james@test>
james@test>select name, category, used, sql_text from user_outlines where name = 'SO_FIX';
NAME CATEGORY USED SQL_TEXT
------------------------------ -------------------- --------- --------------------------------------------------------------------------------
SO_FIX DEMO UNUSED select /*+ index(so_demo, sd_i2) */ v1
from so_demo
where n1 = 1
and n2 = 2
1 row selected.
Elapsed: 00:00:00.00
james@test>select name, stage, hint from user_outline_hints where name = 'SO_FIX';
NAME STAGE HINT
------------------------------ ---------- ------------------------------
SO_FIX 3 NO_EXPAND
SO_FIX 3 ORDERED
SO_FIX 3 NO_FACT(SO_DEMO)
SO_FIX 3 INDEX(SO_DEMO SD_I2)
SO_FIX 2 NOREWRITE
SO_FIX 1 NOREWRITE
6 rows selected.
Elapsed: 00:00:00.01
4.2 进入outln Schema Crack系统的outln相关表, 调换两个存储概要的实际内容.
outln@test>@tmp
outln@test>update outln.ol$hints
2 set ol_name =
3 decode(
4 ol_name,
5 'SO_FIX','SYS_OUTLINE_100209233527397',
6 'SYS_OUTLINE_020503165427311','SO_FIX'
7 )
8 where ol_name in ('SYS_OUTLINE_100209233527397','SO_FIX');
12 rows updated.
Elapsed: 00:00:00.00
outln@test>
outln@test>update outln.ol$ ol1
2 set hintcount = (
3 select hintcount
4 from ol$ ol2
5 where ol2.ol_name in ('SYS_OUTLINE_100209233527397',' SO_FIX')
6 and ol2.ol_name != ol1.ol_name
7 )
8 where
9 ol1.ol_name in ('SYS_OUTLINE_100209233527397','SO_FIX');
2 rows updated.
Elapsed: 00:00:00.00
outln@test>commit;
Commit complete.
Elapsed: 00:00:00.00
outln@test>
4.3 打开使用stored outlines的参数, 测试是否确实使用了存储概要, 并附上10046 Trace得到的信息.
james@test>@tmp james@test>var m_value varchar2(10); james@test>alter session set use_stored_outlines = demo; Session altered. Elapsed: 00:00:00.00 james@test>alter session set events '10046 trace name context forever,level 12'; Session altered. Elapsed: 00:00:00.00 james@test>exec get_value(1, 1, :m_value); PL/SQL procedure successfully completed. Elapsed: 00:00:00.03 james@test>alter session set events '10046 trace name context off'; Session altered. Elapsed: 00:00:00.00 james@test>alter session set use_stored_outlines = false; Session altered. Elapsed: 00:00:00.00 james@test>col spid new_value spid james@test>select spid from v$process where addr = ( 2 select paddr from v$session a,v$mystat b where a.sid = b.sid and rownum
sys@test>@plan
Enter value for hash_value: 3638091068
SQL_TEXT
----------------------------------------------------------------
SELECT V1 FROM SO_DEMO WHERE N1 = :B2 AND N2 = :B1
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | |
|* 1 | TABLE ACCESS BY INDEX ROWID| SO_DEMO | 1 | 7 | 3 (34)|
|* 2 | INDEX RANGE SCAN | SD_I2 | 1 | | 2 (50)|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("SO_DEMO"."N1"=:B2)
2 - access("SO_DEMO"."N2"=:B1)
sys@test>
此时, 可以发现, 调整过后的存储概要已经发生作用了, 没有使用最初的索引SD_I1而是使用了我们指定的索引SD_I2.
5. 使用在另一个Schema创建View的方式来替换存储概要.
5.1 首先清除掉前面测试使用的存储概要, 并重新生成存储概要.
james@test>var m_value varchar2(10); james@test>alter session set create_stored_outlines = demo; Session altered. Elapsed: 00:00:00.01 james@test>exec get_value(1, 1, :m_value); PL/SQL procedure successfully completed. Elapsed: 00:00:00.05 james@test>alter session set create_stored_outlines = false; Session altered. Elapsed: 00:00:00.00 james@test> james@test>col category format a15 james@test>select name, category, used, sql_text from user_outlines where category = 'DEMO'; NAME CATEGORY USED SQL_TEXT ------------------------------ --------------- --------- -------------------------------------------------------------------------------- SYS_OUTLINE_100210003729028 DEMO UNUSED SELECT V1 FROM SO_DEMO WHERE N1 = :B2 AND N2 = :B1 1 row selected. Elapsed: 00:00:00.01 james@test>col hint format a30 james@test>l 1* select name, stage, hint from user_outline_hints where name = 'SYS_OUTLINE_100210003729028' james@test>/ NAME STAGE HINT ------------------------------ ---------- ------------------------------ SYS_OUTLINE_100210003729028 3 NO_EXPAND SYS_OUTLINE_100210003729028 3 ORDERED SYS_OUTLINE_100210003729028 3 NO_FACT(SO_DEMO) SYS_OUTLINE_100210003729028 3 INDEX(SO_DEMO SD_I1) ******************** SYS_OUTLINE_100210003729028 2 NOREWRITE SYS_OUTLINE_100210003729028 1 NOREWRITE 6 rows selected.
5.2 登录一个新的用户, 创建一个View并重新编译这个存储概要.
james2@test>create or replace view so_demo as 2 select /*+ index(so_demo,sd_i2) */ 3 * 4 from james.so_demo; View created. Elapsed: 00:00:00.07 james2@test>alter outline sys_outline_100210003729028 rebuild; Outline altered. Elapsed: 00:00:00.01 james2@test>@conn james/james Elapsed: 00:00:00.00 Elapsed: 00:00:00.00 james@test>col category format a15 james@test>select name, category, used, sql_text from user_outlines where category = 'DEMO'; NAME CATEGORY USED SQL_TEXT ------------------------------ --------------- --------- -------------------------------------------------------------------------------- SYS_OUTLINE_100210003729028 DEMO UNUSED SELECT V1 FROM SO_DEMO WHERE N1 = :B2 AND N2 = :B1 1 row selected. Elapsed: 00:00:00.01 james@test>col hint format a30 james@test>select name, stage, hint from user_outline_hints where name = 'SYS_OUTLINE_100210003729028' 2 / NAME STAGE HINT ------------------------------ ---------- ------------------------------ SYS_OUTLINE_100210003729028 3 NO_EXPAND SYS_OUTLINE_100210003729028 3 ORDERED SYS_OUTLINE_100210003729028 3 NO_FACT(SO_DEMO) SYS_OUTLINE_100210003729028 3 INDEX(SO_DEMO SD_I2) ******************** SYS_OUTLINE_100210003729028 2 NOREWRITE SYS_OUTLINE_100210003729028 1 NOREWRITE SYS_OUTLINE_100210003729028 1 NOREWRITE 7 rows selected. Elapsed: 00:00:00.00
关注使用星号标识的两行, 你将发现存储概要确实已经通过这种方式替换掉了
6. 使用在新Schema中创建一个类似的新表来实现改变存储概要的方法.
6.1. 通过在原Schema重新编译outline使其回到最初状态.
james@test>alter outline SYS_OUTLINE_100210003729028 rebuild; Outline altered. Elapsed: 00:00:00.01 james@test>select name, stage, hint from user_outline_hints where name = 'SYS_OUTLINE_100210003729028'; NAME STAGE HINT ------------------------------ ---------- ------------------------------ SYS_OUTLINE_100210003729028 3 NO_EXPAND SYS_OUTLINE_100210003729028 3 ORDERED SYS_OUTLINE_100210003729028 3 NO_FACT(SO_DEMO) SYS_OUTLINE_100210003729028 3 INDEX(SO_DEMO SD_I1) ***************** SYS_OUTLINE_100210003729028 2 NOREWRITE SYS_OUTLINE_100210003729028 1 NOREWRITE 6 rows selected. Elapsed: 00:00:00.00 james@test>
6.2. 在新的Schema创建对应表,以及索引SD_I2. 并重新编译存储概要.
james2@test>l 1 create table so_demo ( 2 n1 number, 3 n2 number, 4 v1 varchar2(10) 5* ) james2@test>/ Table created. Elapsed: 00:00:00.02 james2@test>create index sd_i2 on so_demo(n2); Index created. Elapsed: 00:00:00.08 james2@test>alter outline sys_outline_100210003729028 rebuild; Outline altered. Elapsed: 00:00:00.00 james@test>col hint format a30 james@test>select name, stage, hint from user_outline_hints where name = 'SYS_OUTLINE_100210003729028'; NAME STAGE HINT ------------------------------ ---------- ------------------------------ SYS_OUTLINE_100210003729028 3 NO_EXPAND SYS_OUTLINE_100210003729028 3 ORDERED SYS_OUTLINE_100210003729028 3 NO_FACT(SO_DEMO) SYS_OUTLINE_100210003729028 3 INDEX(SO_DEMO SD_I2) ********************* SYS_OUTLINE_100210003729028 2 NOREWRITE SYS_OUTLINE_100210003729028 1 NOREWRITE
这个时候, 你将发现存储概要也改成我们最初想要的结果了, 也即用索引SD_I2替换掉了SD_I1.
提起NoSQL这个话题,仿佛不应该是DBA要关注的事,而是架构师应该关心的。但是作为一名DBA,在使用传统的关系型思想建模时,应该有必要了解NoSQL的建模方法。
各种NoSQL数据库有很多,我最关注的还是BigTable类型,因为它是一个高可用可扩展的分布式计算平台,用来处理海量的结构化数据,而数据库同样也是处理结构化数据,所以除了没有SQL,在数据模型方面有相似之处。Cassandra是facebook开源出来的一个版本,可以认为是BigTable的一个开源版本,目前twitter和digg.com在使用。我们尝试从DBA的角度出发去理解Cassandra的数据模型。
NoSQL并不能简单的理解为No SQL,其本质应该是No Relational,也就是说它不是基于关系型的理论基础,而我们所有传统的数据库都是基于这套理论而发展起来的,所以SQL并不是问题的关键所在,比如有些NoSQL数据库可以提供SQL类型的接口,允许你通过类SQL的语法去访问数据。而Friendfeed则是反其道而行之,利用关系型数据库MySQL,采用了去关系化的设计方法,去实现自己的KeyValue存储。所以NoSQL的本质是No Relational.
Cassandra特点:
1.灵活的schema,不需要象数据库一样预先设计schema,增加或者删除字段非常方便(on the fly)。
2.支持range查询:可以对Key进行范围查询。
3.高可用,可扩展:单点故障不影响集群服务,可线性扩展。
Keyspace
Cassandra中的最大组织单元,里面包含了一系列Column family,Keyspace一般是应用程序的名称。你可以把它理解为Oracle里面的一个schema,包含了一系列的对象。
Column family(CF)
CF是某个特定Key的数据集合,每个CF物理上被存放在单独的文件中。从概念上看,CF有点象数据库中的Table.
Key
数据必须通过Key来访问,Cassandra允许范围查询,例如:start => '10050', :finish => '10070'
Column
在Cassandra中字段是最小的数据单元,column和value构成一个对,比如:name:“jacky”,column是name,value是jacky,每个column:value后都有一个时间戳:timestamp。
和数据库不同的是,Cassandra的一行中可以有任意多个column,而且每行的column可以是不同的。从数据库设计的角度,你可以理解为表上有两个字段,第一个是Key,第二个是长文本类型,用来存放很多的column。这也是为什么说Cassandra具备非常灵活schema的原因。
Super column
Super column是一种特殊的column,里面可以存放任意多个普通的column。而且一个CF中同样可以有任意多个Super column,一个CF只能定义使用Column或者Super column,不能混用。下面是Super column的一个例子,homeAddress这个Super column有三个字段:分别是street,city和zip:
homeAddress: {street: "binjiang road",city: "hangzhou",zip: "310052",}
Sorting
不同于数据库可以通过Order by定义排序规则,Cassandra取出的数据顺序是总是一定的,数据保存时已经按照定义的规则存放,所以取出来的顺序已经确定了,这是一个巨大的性能优势。有意思的是,Cassandra按照column name而不是column value来进行排序,它定义了以下几种选项:BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType, 和LongType,用来定义如何按照column name来排序。实际上,就是把column name识别成为不同的类型,以此来达到灵活排序的目的。UTF8Type是把column name转换为UTF8编码来进行排序,LongType转换成为64位long型,TimeUUIDType是按照基于时间的UUID来排序。例如:
Column name按照LongType排序:
{name: 3, value: "jacky"},
{name: 123, value: "hellodba"},
{name: 976, value: "Cassandra"},
{name: 832416, value: "bigtable"}
Column name按照UTF8Type排序:
{name: 123, value: "hellodba"},
{name: 3, value: "jacky"},
{name: 832416, value: "bigtable"}
{name: 976, value: "Cassandra"}
下面我们看twitter的Schema:
<Keyspace Name="Twitter">
<ColumnFamily CompareWith="UTF8Type" Name="Statuses" />
<ColumnFamily CompareWith="UTF8Type" Name="StatusAudits" />
<ColumnFamily CompareWith="UTF8Type" Name="StatusRelationships"
CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" />
<ColumnFamily CompareWith="UTF8Type" Name="Users" />
<ColumnFamily CompareWith="UTF8Type" Name="UserRelationships"
CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" />
</Keyspace>
我们看到一个叫Twitter的keyspace,包含若干个CF,其中StatusRelationships和UserRelationships被定义为包含Super column的CF,CompareWith定义了column的排序规则,CompareSubcolumnsWith定义了subcolumn的排序规则,这里使用了两种:TimeUUIDType和UTF8Type。我们没有看到任何有关column的定义,这意味着column是可以灵活变更的。
为了方便大家理解,我会尝试着用关系型数据库的建模方法去描述Twitter的Schema,但千万不要误解为这就是Cassandra的数据模型,对于Cassandra来说,每一行的colunn都可以是任意的,而不是象数据库一样需要在建表时就创建好。
Users CF记录用户的信息,Statuses CF记录tweets的内容,StatusRelationships CF记录用户看到的tweets,UserRelationships CF记录用户看到的followers。我们注意到排序方式是TimeUUIDType,这个类型是按照时间进行排序的UUID字段,column name是用UUID函数产生(这个函数返回了一个UUID,这个UUID反映了当前的时间,可以根据这个UUID来排序,有点类似于timestamp一样),所以得到结果是按照时间来排序的。使用过twitter的人都知道,你总是可以看到自己最新的tweets或者最新的friends.
存储
Cassandra是基于列存储的(Bigtable也是一样),这个和基于列的数据库是一个道理。
API
下面是数据库,Bigtable和Cassandra API的对比:
Relational SELECT `column` FROM `database`.`table` WHERE `id` = key;
BigTable table.get(key, "column_family:column")
Cassandra: standard model keyspace.get("column_family", key, "column")
Cassandra: super column model keyspace.get("column_family", key, "super_column", "column")
我对Cassandra数据模型的理解:
1.column name存放真正的值,而value是空。因为Cassandra是按照column name排序,而且是按列存储的,所以往往利用column name存放真正的值,而value部分则是空。例如:“jacky”:“null”,“fenng”:”null”
2.Super column可以看作是一个索引,有点象关系型数据库中的外键,利用super column可以实现快速定位,因为它可以返回一堆column,而且是排好序的。
3.排序在定义时就确定了,取出的数据肯定是按照确定的顺序排列的,这是一个巨大的性能优势。
4. 非常灵活的schema,column可以灵活定义。实际上,colume name在很多情况下,就是value(是不是有点绕)。
5.每个column后面的timestamp,我并没有找到明确的说明,我猜测可能是数据多版本,或者是底层清理数据时需要的信息。
最后说说架构,我认为架构的核心就是有所取舍,不管是CAP还是BASE,讲的都是这个原则。架构之美在于没有任何一种架构可以完美的解决各种问题,数据库和NoSQL都有其应用场景,我们要做的就是为自己找到合适的架构。
–EOF–
这篇文章,我参考了up and running with cassandra,除此以外,我还参考了twitter提供的API,它帮助我理解twitter的schema设计。这篇文章,肯定有很多理解不正确的地方,希望朋友们指正。
2010-02-09 Tue
iBATIS是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects(DAO),同时还提供一个利用这个框架开发的JPetStore实例。相对Hibernate和Apache OJB等“一站式”ORM解决方案而言,ibatis 是一种“半自动化”的ORM实现。
其中SQL MAP的体系结构如下:

我自己写了一个利用iBATIS框架的示例:
http://docs.google.com/leaf?id=0B2fM7m4tf74hOTkwMTQwNjEtZTgyMi00NDRhLWE0NDQtZTEwYTdmMzI3MjFj&hl=en
ibatis版本:ibatis-2.3.4.726
oracle jdbc client版本:Oracle 11g 11.2.0.1.0 JDBC_ojdbc6.jar
jdk版本:jdk1.6.0_13
本文翻译自Guy Harrison的blog: Using the Oracle 11GR2 database flash cache, 这是他写的关于Flash Cache系列文章的第一篇, 后面还有两篇, 我也将陆续翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.
使用Oracle 11GR2 数据库Flash Cache
Oracle最近发布了一个补丁程序,使得你可以在Oracle Enterprise Linux中使用数据库Flash Cache,即使你并没有使用Exadata存储.这个补丁的名字有点隐晦:
- 8974084:META BUG FOR FLASH CACHE 11.2PL BUGS TO BACKPORT TO 11.2.0.1 OEL
只要安装好这个补丁,你就可以使用任何已存在的flash 设备作为数据库的Flash Cache.下面是我在一个非常旧的服务器与一个非常便宜的usb flash设备上做的初步尝试.相对于更优质的硬件来讲, 测试结果并不具有代表性,但是我认为,它仍然是很有趣的.
安装与配置
如果你也像我一样想在一个USB flash设备上做试验,那么也必须先挂载这个设备.在我的机器上,我创建了一个目录”/mnt/usbflash”,接着在/etc/fstab文件新增了一个如下的条目:
/dev/sda1 /mnt/usbflash vfat noauto,users,rw,umask=0 0 0
在你的系统中,你可能需要将”/dev/sda1″改成其他的设备,这依赖于你如何配置磁盘.然后就可以通过输入”mount /dev/sda1″来挂载这个闪存盘(flash drive).
一旦挂载完毕,就可以通过设置系统书db_flash_cache_files与db_flash_cache_size来配置flash cache了. 如下是我的相关设置:

注意, 参数DB_FLASH_CACHE_FILE的值必须是一个存储在闪存盘上的文件,而不是这个闪存盘的挂载点本身.
一旦这些参数设置完毕,flash cache就会被激活,并且将充当buffer cache的二级缓存. 当从主缓存移出一个block的时候,它将被移到flash cache中,从而在再次读回这个block的时候不需要产生一次访问磁盘的物理读.
监控
有多种方法来检查是否使用到了flash cache. 首先,v$sysstat视图包含多个新的统计项来展示有多少数据块被添加到flash cache中,以及在flash cache中命中的次数(从这儿下载脚本):

还有一些新的等待事件来显示往flash cache中添加条目以及从flash cache中读取条目引起的等待. 从下图可以看到,’db flash’等待的次数超过’ db file sequential read’的等待次数,虽然从flash cache读取的速度远远快于从磁盘的读取速度(但是从flash cache读取的次数也远远超过从磁盘读取的次数):

那么,请记住,我不能不为这个测试选择了最糟糕的硬件-一个老旧的俩CPU intel主机以及一个便宜的拇指磁盘.即使这样,还是发现了引人注目的问题-相对于整个处理时间来讲写开销非常严重.虽然相对于db file sequential reads来讲从flash cache中读取的速度可以节约很多时间,维护flash cache的开销也可能会非常高,因为大部分基于闪存的SSD(Solid State Disk)都有相对严重的写瓶颈.
所有基于闪存的固态盘(SSD,Solid State Disk)都有写性能方面的问题.然而,便宜的MLC(Multi Level Cell)闪存的写速度差不多相当于更加昂贵的SLC(Single Level Cell)的1/3.在闪存盘比较新时,空闲空间可以以单页(一般为4k)递增的方式来写.然而,当闪存盘越来越旧时,写操作需要先清除一个完整的128页的块,从而就会慢很多了.我的便宜的USB盘是一个旧盘,并且是MLC的,所以它的写性能是非常差的.但是,即使是最好的基于闪存的SSD,它的写速度也比读速度要慢很多,因此,有些时候使用闪存盘反而会导致数据库运行的更慢. 因此监控就显得非常重要了.
下面是几个与此相关的其他v$systat统计项:

可以通过查看V$BH视图来查看cache中的内容. 保存在flash cache中的buffer有诸如’flashcur’一类的状态,使得我们可以统计每个对象有多少buffer在主缓存中,有多少buffer在flash cache中(脚本来自这里):

在这个例子中,TXN_DATA表有85,833个块在flash cache中,有28,753个块在主buffer cache中.
结论
能让flash cache工作,我非常高兴,特别是在如此蹩脚的硬件上. 很高兴Oracle对Non-Exadata硬件开放这项技术.
我将很快在搭建一套更好的环境,从而我可以理解它在相当好的商业SSD闪存盘上是如何工作的.
我坚信, 市场需要的理想的存储体系应该包含至少两层—一层来解决海量存储,另一层解决快速检索. 但是,我们也应该保持谨慎,因为flash的写弊端可能导致我们在RAID5上遇到的类似的性能问题.
由于种种原因,终于交了那封信。
现在的感觉,很轻松,再也不用担心有人半夜给我电话,说系统当机了,或者说系统hang了,也再也不用因为干活之外的事情被骂了。
晚上,终于可以关机了。
不用每个月一个星期的在晚上oncall,每次oncall一个星期,就要休息一个星期才能缓过来。
让我,先享受下,这种没有压力的感觉。
2010-02-08 Mon
我曾经在"利用BBED修改block内数据的一个例子"这篇文章里提到了一个计算block内部offset的base的计算方法,即:
BASE的计算方法为:
对于ASSM:76+(itc-1)*24
对于MSSM:68+(itc-1)*24
有朋友在MSN上问我说:为什么这里ASSM要比MSSM多了8个byte?
正好也有朋友在MSN上问我为啥不写一些关于block存储格式的文章,我这里就一并回答了吧。
首先,我觉得没有必要写block存储格式了,因为用BBED的map和print就可以精准的了解一个block的结构了,除了ASSM的segment header、L1、L2、L3用不了map和print之外,其他的基本上都可以。所以,除了写那些用BBED看不了的block的结构之外,写其他的意义并不大。
接着我们来回答一下第一个朋友的问题,即为什么这里ASSM要比MSSM多了8个byte?
要回答上述问题,我们先来看一下一个data block必然会有的三个component的大小:
SQL> select * from v$type_size where component in ('KCB','KTB');
COMPONENT TYPE DESCRIPTION TYPE_SIZE
--------- -------- -------------------------------- ----------
KCB KCBH BLOCK COMMON HEADER 20
KTB KTBIT TRANSACTION VARIABLE HEADER 24
KTB KTBBH TRANSACTION FIXED HEADER 48
从结果里我们可以看到,一个data block的cache layer的大小是20个byte,其transaction layer的固定部分的大小是48个byte(因为必然会有一个ITL),所以这里对于MSSM而言,其base的计算方法就是:20+48+(itc-1)*24,即上文中提到的68+(itc-1)*24。
那么对于ASSM而言,为什么会多了8个byte呢?我们继续往下看:
我们随便看一个MSSM的block:
BBED> map /v
File: /dras21/astca/system02.dbf (125)
Block: 1426 Dba:0x1f400592
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub1 spare1_kcbh @2
ub1 spare2_kcbh @3
ub4 rdba_kcbh @4
ub4 bas_kcbh @8
ub2 wrp_kcbh @12
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18
struct ktbbh, 96 bytes @20
ub1 ktbbhtyp @20
union ktbbhsid, 4 bytes @24
struct ktbbhcsc, 8 bytes @28
b2 ktbbhict @36
ub1 ktbbhflg @38
ub1 ktbbhfsl @39
ub4 ktbbhfnx @40
struct ktbbhitl[3], 72 bytes @44
struct kdbh, 14 bytes @116
ub1 kdbhflag @116
b1 kdbhntab @117
b2 kdbhnrow @118
sb2 kdbhfrre @120
sb2 kdbhfsbo @122
sb2 kdbhfseo @124
b2 kdbhavsp @126
b2 kdbhtosp @128
struct kdbt[1], 4 bytes @130
b2 kdbtoffs @130
b2 kdbtnrow @132
sb2 kdbr[32] @134
ub1 freespace[4966] @198
ub1 rowdata[3024] @5164
ub4 tailchk @8188
注意看这里kdbh的offset是116。
我们再来看一个ASSM的block:
BBED> map /v
File: /dras21/astca/armshistemptbs_03.dbf (121)
Block: 274445 Dba:0x1e44300d
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub1 spare1_kcbh @2
ub1 spare2_kcbh @3
ub4 rdba_kcbh @4
ub4 bas_kcbh @8
ub2 wrp_kcbh @12
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18
struct ktbbh, 96 bytes @20
ub1 ktbbhtyp @20
union ktbbhsid, 4 bytes @24
struct ktbbhcsc, 8 bytes @28
b2 ktbbhict @36
ub1 ktbbhflg @38
ub1 ktbbhfsl @39
ub4 ktbbhfnx @40
struct ktbbhitl[3], 72 bytes @44
struct kdbh, 14 bytes @124
ub1 kdbhflag @124
b1 kdbhntab @125
b2 kdbhnrow @126
sb2 kdbhfrre @128
sb2 kdbhfsbo @130
sb2 kdbhfseo @132
b2 kdbhavsp @134
b2 kdbhtosp @136
struct kdbt[1], 4 bytes @138
b2 kdbtoffs @138
b2 kdbtnrow @140
sb2 kdbr[32] @142
ub1 freespace[4958] @206
ub1 rowdata[3024] @5164
ub4 tailchk @8188
注意看这里kdbh的offset是124,比MSSM多了8个byte。
所以上述问题的答案就是:在ASSM下,oracle改变了block内部table directory和row directory的位置,oracle把它们顺延了8个byte,所以对于ASSM而言,其base的计算方法就是:20+48+8+(itc-1)*24,即上文中提到的76+(itc-1)*24。
作者:Fenng 发布在 dbanotes.net.
虽说年底是 IT 事故多发的期间,不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号,从上午11:00到下午15:30,故障持续四个多小时,全行系统瘫痪。对外称是"核心系统维护"。
个人之所以比较关注这个事故,是因为新闻标题中的"数据库维护失误"。据说是"由于数据系统进行维护时出现了失误,造成宕机"。开始的时候,大家把关注的焦点放到灾备切换与否的问题上,据说是"没敢切换"。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关,我错过了讨论现场。
也有朋友在 Twitter 上说:民生银行上周的系统宕机事故,源于IT部门某应用系统数据库(应该是 DB2 Informix,数据库版本老旧,且无正常维护服务),一个应该在夜间处理的长任务,运行到银行开门也未结束,该系统正常时的CPU使用率就已经到达70-80%,长任务从夜里一直跑到上午无法停止,把本来就不堪重负的业务系统拖慢到不能忍受,由于数据库版本 EOS (End of Service) ,无厂商实验室的工具支持无奈之下,要求重启相关系统,结果造成业务停止。事件的(后续)处理还在进行中。(via)
上述说法看起来比较可信,也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心,实施方是埃森哲(refer)。不过,"民生银行打造的新核心系统已经开发完毕,目前处于内部运用的阶段,今年上半年将会在全公司上线",估计到时候能稳定点?
另外看到有网友说,2008 年初,民生银行的的小额支付系统也出过严重问题,由于操作失误或是程序内部控制原因,造成了几百万的重帐。
涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看,事故发生后,更多的时间都会花在决策上,而一旦选择错误或者不是做出最优的决定,灾难才刚刚开始。
--EOF--
最近文章|Recent Articles
本站赞助商:豆瓣网
评论数(10)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址:http://www.dbanotes.net/review/cmbc_crash.html
DBA Notes 理念: 用简约的技术取得最大的收益...
2010-02-07 Sun
做DBA要经常为其他人员查询一些数据, 有些记录的字段数很多, 用SQLPLUS直接出结果时, 很难对得整齐, 因此没有什么用户体验, 会被内部人员投诉, 外部用户的体验关系着企业的业绩, 内部员工的体验关系到工作的满意度.
Spool的结果的确很乱, 在Yong Huang提议在AnySQL中加入MySQL按列显示功能后, 就在文本导出工具中也加入了这个功能, 第一版本的ociuldr使用如下参数.
ociuldr form=yes ...
第二版的文本导出工具也有这个功能, 只是SQLULDR2中需要设置三个选项才行.
$sqluldr2 scott/tiger query=emp colsep=0x20:0x20 field=0x0a record=0x0a0x0a file=-
EMPNO : 7369
ENAME : SMITH
JOB : CLERK
MGR : 7902
HIREDATE : 1980-12-17 00:00:00
SAL : 800
COMM :
DEPTNO : 20
EMPNO : 7499
ENAME : ALLEN
JOB : SALESMAN
MGR : 7698
HIREDATE : 1981-02-20 00:00:00
SAL : 1600
COMM : 300
DEPTNO : 30
......
能用SQLULDR2来改善用户体验, 真是当初意想不到的事情.
Relative Posts:
下面提供两个岗位,一个是资深JAVA工程师,另个一个是系统架构师,如果对这两个职位感兴趣,可以发简历给我:danchen@taobao.com , 非常期待您加入淘宝,和我们一起并肩奋斗。
职位名称:资深Java工程师 (或 高级Java工程师)
招聘人数:无限制
部门介绍:
市场产品技术部
工作职责:
负责淘宝主站大型Web产品的设计和开发
职位要求:
精通Java SE和Java EE技术,包括Servlet/JSP、JDBC、EJB、JMS、Web Service等
精通面向对象的分析和设计技术,包括设计模式、UML建模等
精通Internet基本协议(如TCP/IP、HTTP等)内容及相关应用
具有较强的编程能力,能够完成较复杂的交互流程设计和实现,具备良好的编程习惯,能够编写高质量技术文档
大规模高并发访问的Web应用架构设计和开发经验
有很强的分析问题和解决问题的能力
有强烈的上进心和求知欲,善于学习新事物
职业发展方向:
如技术、业务能力卓越,显示出过人才能,可专注于技术方向,提升为系统架构师,如辅导、管理能力出色,可提升为TechLeader。
职位名称:系统架构师 (或 Java系统架构师 或 业务平台架构师)
招聘人数:无限制
部门介绍:
市场产品技术部...
工作职责:
负责淘宝主站大型Web产品的技术架构
全面把关系统级的总体设计和重要技术决策,指导其他工程师的设计工作
根据公司需求,负责各类复杂业务系统、海量数据系统、高性能系统、大型分布式系统等各类服务器端软件的建设工作
职位要求:
精通J2EE技术平台及主要框架
精通面向对象的分析和设计技术,包括设计模式、UML建模等,熟练掌握多线程、网络编程、数据库应用开发技术
有互联网相关领域的大型软件的成功设计经验
大规模高并发访问的Web应用架构设计和开发经验
具有出色的分析能力和攻关能力
广博的业界知识和前沿技术敏感性
职业发展方向:
依据技术、业务能力卓越,显示出过人才能,成为技术专家,把握技术方向,促进核心技术进步和创新。
作者:Fenng 发布在 dbanotes.net.
简要回顾一下 2009 年数据库技术领域。过去的一年,差不多也可以说是过度的一年,数据库技术以及数据存储产品等都都或多或少发生一些方向上的转变。
Oracle 收购 Sun,MySQL 前途未卜
Oracle 收购 Sun 可谓一波三折。在获得美国司法部门的批准后,欧盟委员会又开始调查,Oracle 随后抛出一个"十条保证",眼看着欧盟就要点头,没想到 MySQL 创始人 Michael Widenius(Monty) 则在这个当口不失时机的搞出来一个"拯救 MySQL"的抵制活动,让 Oracle 头疼不已。Monty 这人多少也有点上纲上线,现在已经将 MySQL 的命运和 "Internet Free"这个大话题绑在一起了。
没有人会相信 Oracle 会善待 MySQL,谁会干放虎归山的事情呢? 换了你也会把 MySQL 雪藏起来,毕竟商业公司就要逐利。但是,也很难说一旦收购完成后 ,MySQL 会在短期内消失,基于 MySQL 众多开源分支以及解决方案也都发展的不错,我相信最终决定权还是在用户的手里。就算没有 MySQL,也没准儿会有 YourSQL 出来的...
尽管口水战还在进行,MySQL 的开发者倒是没闲着,在年底发布了 5.5 第二个里程碑版本,原来站点上的 6.0 系列的信息全部撤掉。5.5 更像一个集成版本,将不少第三方贡献的功能改进(比如 Google 的 Patch)融合了进来。
而 Oracle 这一年在产品上的一个标志性事件是推出了 Exadata 存储第二版,与第一个版本不同的是,这一个版本在 OLTP 方面增强了许多。从这个版本开始,Oracle 正式拥有自己的存储硬件(第一版是和 HP 合作的产物)。RDBMS 上,除了发布 11g 第二版之外,也在做功能上的调整,这一次,面向的是数据中心。
NoSQL 的兴起
这是今年数据库领域最有趣的话题。NoSQL 的由来大约是这样的:当时还效力于 Last.FM 的 Johan Oskarsson (现在已经投靠 Twitter 了)组织了一个技术会议,话题是关于"open source, distributed, non relational databases",为了方便一点,想出来一个 "NoSQL" 的术语。然后由 Rackspace 的 Eric Evans 引用,进而流传开来(refer)。NoSQL 在基于 Key-value 的存储解决方案上提倡去 SQL 化,尤其避免表连接,并且通过一些变通的办法提供 RDBMS 的 ACID 功能(如果需要的话)。
NoSQL 的理念能够短时间内被技术圈所接受,离不开基本的理论支撑:最终一致性、BASE 、CAP 这三大基石;一方面是基于 Key-Value 的数据存储解决方案更加成熟,
所谓 NoSQL ,是针对当前对关系型数据库的过度依赖与运用而言,不要将其当成万能药,也没必要过于激进的推行 NoSQL 的模式。在我看来,NoSQL 是针对争夺应用模式上的一种理念上的运用。对多数企业来说,仍属屠龙之技,没必要照搬解决方案。至于传统的 RDBMS 是不是已经走向末路,我认为不尽然。RDBMS 依然尤其广泛的应用场景,而NoSQL如果要有更大的作为也要有来自商业上的更大支持才会有所突破。
SSD 被更多企业接受
Jim Gray 在 2006 年的那句名言:Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King ,现在正在被现实所验证。2009 这一年,用户已经开始进一步试水 SSD 产品,包括 MySpace、Last.FM 等网站已经开始在关键应用上部属 SSD(refer: 1, 2)。而国内也有很多企业对 SSD 进行尝试性的使用,这其中包括阿里巴巴、优酷。
更多的存储厂商已经在高端存储中兼容 SSD ,除了去年的 EMC 尝鲜之外,现在 IBM、HDS 、NetApp 都加入了这一阵营。
。随着 SSD 的价格迅速下降,很多存储厂商已经开始调整硬件架构,现在有个看似可行的趋势是在 Cache 层与磁盘层之间多构建一个 SSD 存储层,在成本与性能之间做一个折衷。
在去年年底的回顾中,我曾大言不惭的说"相信2009 年会是 SSD 爆发的一年",总体来看,2009 年对 SSD 的部属还谈不上"爆发"。中规中矩而已。
Amazon EC2 对 MySQL 企业版的支持
尽管我不愿意谈云计算,不过 Amazon 这一年在云计算方面还是做了很大的突破,Amazon EC2 上面现在已经可以跑 MySQL 企业版了,采取按照增长付费 ('Pay-as-we-Grow') 的模式让初创公司有更多的选择,这比 SimpleDB 可以说是前进了一大步。 这种模式在国内是否可行,考虑到当前内容审查的问题,还有待商榷。
国内 Key-Value 产品
这一年来国内对 Key-Value 产品的研究与运用和国外基本没太大的距离,豆瓣网先作出了不错的表率,发布了 BeansDB 存储系统,这是一个豆瓣风格的 Dynamo 实现,采用类似 Memcached 的去中心化结构。而最近得到的消息说人人网也要将其内部使用的存储系统 Nuclear 开源。相信在新的一年可供参考的 Key-Value 会层出不穷。
其它方面
Hadoop 过去一年中没有太大的变化,上了一点规模的网站都在用,快成了 Web 数据分布式计划的标准组件了。Doug Cutting 出走 Yahoo! 还是带来了一定的影响 ,不知道今后 Yahoo! 在 Hadoop 方面的支持力度会如何。至于面向列的 DB 发展情况,在过去的一年中进展不大。SQL Server 和 DB2 等方面似乎没什么可圈可点的大事,倒是 PostgreSQL 因为 MySQL 的不确定性而取得了不小的增长。
有一点要补充的是,假以时日,Open Data 或许也将成为一个趋势。
当然,这份回顾有浓郁的个人色彩,有不同意见请留言探讨吧。
--EOF--
本文发表在《程序员》杂志,不过这里的有些许更新。本文写作时,Oracle 收购 Sun 还没有尘埃落定,现在看起来,一切都变化太快。
最近文章|Recent Articles
本站赞助商:豆瓣网
评论数(7)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址:http://www.dbanotes.net/database/database_event_2009.html
DBA Notes 理念: 用简约的技术取得最大的收益...
有朋友在itpub上问backupset和backuppiece的区别,我很能理解这位朋友为什么会有这样的疑问,因为我在六年前看9i OCP的培训教材的时候也不明白这两者之间的区别是什么。
我们只需要做如下这样一些测试并配合list backup就可以知道backupset和backuppiece的区别了:
1、多个channel并且指定filesperset:
configure device type disk parallelism 3;
run{
backup incremental level=0
format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database
filesperset 3;
}
2、单个channel且不指定filesperset:
configure device type disk parallelism 1;
run{
backup incremental level=0
format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;
}
3、单个channel且指定maxsetsize:
configure device type disk parallelism 1;
configure maxsetsize to 450M;
run{
backup incremental level=0
format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;
}
4、单个channel且指定maxpiecesize:
configure device type disk parallelism 1;
configure maxsetsize to unlimited;
run{
allocate channel c1 device type disk maxpiecesize 300M;
backup incremental level=0
format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;
release channel c1;
}
5、多个channel且指定filesperset,但请注意filesperset的位置:
configure device type disk parallelism 3;
run{
backup incremental level=0
format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database
plus archivelog
format 'D:\oracle\oradata\testdb\backup\testdb_arc_%t_%s_%p.bak'
delete all input
filesperset 2;
}
6:多个channel且指定filesperset,但请注意filesperset的位置:
configure device type disk parallelism 3;
run{
backup incremental level=0
format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database filesperset 2
plus archivelog
format 'D:\oracle\oradata\testdb\backup\testdb_arc_%t_%s_%p.bak'
delete all input;
}
从结果里我们可以得到如下结论:
1、 backupset由backuppiece组成,每一个backuppiece就是一个单个的物理文件;
2、 如果你在分配channel的时候不指定maxpiecesize,则每个backupset只会包含一个backuppiece;反之一个backupset里会有多个backuppiece(即物理文件);
3、 一次备份中backupset的数量跟分配channel的个数、是否指定filesperset、filesperset的位置、是否指定maxsetsize有关。
filesperset的位置很关键,比如我这里有10个datafile需要备份,那么上述测试5对这10个datafile(不含archivelog)会产生多少个backupset?测试6呢?
答案是测试5产生了3个backupset,测试6产生了6个backupset(这里请正确理解filesperset 的含义)。
2010-02-06 Sat
阿凡达口碑不错,看过的同志都说好。我这个土人也趁着影院打折,赶紧去凑个热闹。
的确挺不错,画面很精彩,植物的3D效果最明显了,感觉就在眼前,影片中有个扔催泪弹的镜头,吓我一跳,还以为是真扔过来了。
看完后,眼睛没啥感觉,但头好晕,晃晃都痛。。。。
这还是我第一次看3D电影,OUT了。回来搜了下3D历史,发现第一部3D电影,在1922年就出来了,叫《爱的力量》:
3D电影年代记:1839–2009
1839年,英国科学家查理-惠斯顿爵士根据“人类两只眼睛的成像是不同的”发明了一种立体眼镜,让人们的左眼和右眼在看同样图像时产生不同效果,这就是今天3D眼镜的原理。
19世纪末,英国威廉姆-弗莱斯-格林发明了世界上第一套放映和观看3D电影的装置,但因繁杂缺乏实用推广性,所以并没有戏院采用。
1900年,弗雷德里克-尤金-艾维斯发明了模仿人眼原理的立体摄像机。
1915年6月10日,埃德温-波特和威廉-瓦德尔在纽约阿斯特戏院试验他们的红绿立体电影,放映了包括田园风光在内的多段测试片段,现场仅一位观众。
1922年9月27日,哈利-费尔奥和摄像师罗伯特-艾尔德制作世界上第一部3D电影《爱的力量》,采用了红绿立体电影模式,在洛杉矶大使饭店戏院放映的,同样只有一名观众,院线没人愿买。
20年代末30年代初,法国路易斯-卢米埃尔把他1895年的《火车进站》制作成了3D电影。
1936年,雅各布-莱温赛尔和约翰-诺林为米高梅公司拍摄了短片《Audioscopiks》系列,入场观众都被发了一副红绿眼镜,效果在当时极其震撼,该片获得了当年奥斯卡最佳短片奖的提名。
转自:http://yule.sohu.com/s2009/0623/s269228614/index.shtml
历史够悠久的。
阿凡达是挺精彩的,不过3D的,如果让我看第二遍,想想还是算了,比起精彩的画面,还是让脑袋轻松点的好
— The End —
2010-02-05 Fri
结果是,昨天有人把网线都插拔了一遍,两台机器都挂了;
今天有台机器的网线又被扯,又断了一台。
客户质疑RAC,我只好一遍一遍解释,这个网络啊、心跳啊、VIP啊,对Oracle是灰常灰常重要的。
当然看看日志也有收获,NIC网卡Down的信息,这没什么好说的:
Feb 6 10:13:21 wg1 kernel: bnx2: eth0 NIC Copper Link is Down确认当时的确是有人动了网线,否则不能排除是否网卡本身不稳定。
Feb 6 10:57:20 wg1 kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
Feb 6 10:57:29 wg1 login(pam_unix)[7424]: session opened for user root by LOGIN(uid=0)
Feb 6 10:57:29 wg1 -- root[7424]: ROOT LOGIN ON tty1
Feb 6 10:58:31 wg1 kernel: bnx2: eth0 NIC Copper Link is Up, 100 Mbps full duplex
又发现有Lost ticks的提示信息:
kernel: warning: many lost ticks.
kernel: If your CPU support 'CPU Frequency scaling',You could ignore this warning
kernel: else your time source seems to be instable or some driver is hogging interupts
kernel: rip __do_softirq+0x4d/0xd0
关于lost ticks找到一些参考信息:
在某些系统上,当首次访问一些 IDE 设备时,可能显示信息warning:many lost ticks(警告:丢失许多嘀嗒信号)。当 IDE 设备没有使用 DMA 进行数据传输时,会显示此信息,因为非 DMA 传输所用的时间比计时器嘀嗒信号间隔长很多(在此期间,处理器无法处理计时器嘀嗒信号中断)。此信息并不表示系统出现故障,也不会导致任何功能问题。如果系统运行的是带 Update 1 或更高版本(含适用于此控制器的更新驱动程序)的 Red Hat Enterprise Linux 4,则连接至 Intel ICH7 IDE控制器的设备不会遇到这种问题。但是,由于其它 IDE 设备无法使用DMA,因此该信息仍然会显示。
在基于 AMD 处理器的系统上,如果启用非一致内存存取 (Non Uniform Memory Access) 功能,则系统在高负载情况下将显示"lost ticks"(丢失嘀嗒信号)信息当运行 Red Hat Enterprise Linux 4(更新 4 之前的版本)的系统处于高负载时,屏幕将显示以下信息:
warning: many lost ticks.(警告:丢失许多嘀嗒信号。)
Your time source seems to be instable or some driver is hogging interrupts
(时间源似乎不稳定或者某些驱动程序干扰中断)
rip __do_softirq+0x4d/0xd0
当在基于 AMD 处理器的系统上使用非一致内存存取 (NUMA) 功能时,将出现此问题。要解决此问题,请将以下参数添加到内核命令行:
console=tty0 numa=off
注:确保 numa=off 为内核命令行中的最后一个选项。如果 numa=off 不是最后一个选项,
将不能识别此参数。
在 Red Hat Enterprise Linux 4 更新 4 中已解决这一问题。
(上面这一篇是DELL的文档上的解释)
您可以安心忽略 RHEL4 U4 丟失滴答計時的訊息(6483062)
在沈重的負載下,RHEL4 訊息檔案與 dmesg 記錄檔可能顯示類似下列的訊息:
Warning many lost ticks
Your time source seems to be unstable or some driver is hogginginterrupts.
此訊息是由不同 IRQ 處理常式之間的爭用所導致,但是對於系統沒有負面影響。
(上面一小段是SUN的文档上的解释)
同时注释一下HPET的全称吧:High Precision Event Timer (HPET)
另外一篇文章则为我解释了CPU Frequency scaling的含义:
CPU Frequency scaling,这一选项允许改变CPU的主频,使CPU在低负荷或使用电池时降低主频,达到省电的目的。
Enable CPUfreq debugging,是否允许调试CPU改变主频的功能,如果要调试,还需要在启动时加上参数。cpufreq.debug=
1:变频技术的内核调试
2:变频技术的驱动调试
4:变频技术的调节器调试
感谢网络,感谢网友们的分享,我要继续不断学习。
-The End-
相关文章|Related Articles
- Redflag Linux安装Oracle 10gR2 RAC记事
- OEL Linux与Oracle Validated Configurations
- Linux下如何查看文件秒级修改及访问时间
- Linux + Oracle 数据库系统启动能有多快?
- 使用Linux下script工具记录Oracle输出
评论数量(0)|Add Comments
本文网址:http://www.eygle.com/archives/2010/02/linux_many_lost_ticks.html
于是我发了这么一条新浪微博:
到底是新浪微博牛逼,还是网易微博牛逼,或者前两者包括腾讯微博都是傻逼,只有 Twitter 最牛逼? 新浪微博管理员能回答一下这个问题吗?
真的很敏感啊:
系统管理员 您在2010-02-06 11:59:43发表的微博“到底是新浪微博牛逼,还是网...”已被管理员删除。给您带来的不便,深表歉意。 (1分钟前)
此外,新浪微博 for iPhone 的 app 也显得不怀好意,每次打开都弹出对话框:
“微博”要使用您当前的位置
答案显然是:“不允许”。
好了,测试结束,不玩了。再见,新浪阉博!








