Alibaba DBA Team

Silverlight技术

vogts — Mon, 06 Oct 2008 17:40:45 +0800

Silverlight是一种全新的web展示方式。

最早的网络，是以静态页面为主，后来有了动态（如ASP,ASP.NET,JAVA,PHP等）。在后期，在动态上做了扩展，就是有了ajax。ajax最大的好处，就是页面无刷新，用户体会不到每个post和fresh。ajax的后台其实是一堆js脚本实现的。

但是想想，现在的网络技术，还是不能做出类似flash那种东西。因此有了Silverlight，它的好处在于程序员能够轻松的写出各种各样的花哨界面。感觉在未来会比较流行。目前Silverlight在国内，应用不多，但是已经有很多国外的demo网站了。

我觉得比较适合51，开心网之类的交友网站。因为他们要“炫”为主！

MySQL Replication(复制)基本原理

sky — Wed, 24 Sep 2008 22:46:48 +0800

1、复制进程
Mysql的复制（replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。

要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。
复制的基本过程如下：
1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的，而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题，主要如下：
首先，一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，性能受到了一定的限制，异步复制的延迟也会比较长。
另外，Slave端从Master端获取bin-log过来之后，需要接着解析日志内容，然后在自身执行。在这个过程中，Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误，那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave 端的压力比较大的时候，这个过程的时间可能会比较长。
所以，后面版本的Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。

2、复制实现级别
Mysql的复制可以是基于一条语句（Statement level），也可以是基于一条记录（Row level），可以在Mysql的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。
Row Level：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。
优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及 trigger的调用和触发无法被正确复制的问题。
缺点：row level下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update语句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，执行之后，日志中记录的不是这条update语句所对应额事件（mysql以事件的形式来记录bin-log日志），而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候，产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动，实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。
Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。
优点：statement level下的优点首先就是解决了row level下的缺点，不需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能。因为他只需要记录在Master上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点：由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于Mysql现在发展比较快，很多的新功能不断的加入，使mysql得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement level下，目前已经发现的就有不少情况会造成mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能真确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化，所以不会出现类似的问题。
从官方文档中看到，之前的Mysql一直都只有基于statement的复制模式，直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始，Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给Mysql的复制又带来了更大的新挑战。另外，看到官方文档说，从5.1.8版本开始，Mysql提供了除Statement Level和Row Level之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在Mixed模式下，Mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样，仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。

3、复制常用架构
Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。
一个Master带多个slave的架构实施非常简单，多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个 slave连上了master端，只要有slave进程通过了连接认证，向他请求binlog信息，他就会按照连接上来的io进程的要求，读取自己的 binlog信息，返回给slave的IO进程。对于slave的配置细节，在Mysql的官方文档上面已经说的很清楚了，甚至介绍了多种实现slave 的配置方法。

Mysql不支持一个Slave instance从属于多个Master的架构。就是说，一个slave instance只能接受一个master的同步源，听说有patch可以改进这样的功能，但没有实践过。Mysql AB之所以不实现这样的功能，主要是考虑到冲突解决的问题。

Mysql也可以搭建成dual master模式，也就是说两个Mysql instance互为对方的Master，也同时为对方的Slave。不过一般这种架构也是只有一端提供服务，避免冲突问题。因为即使在两边执行的修改有先后顺序，由于复制的异步实现机制，同样会导致即使在晚做的修改也可能会被早做的修改所覆盖，就像如下情形：
时间点   Mysql A                        Mysql B
1    更新x表y记录为10
2                                 更新x表y记录为20
3                                 获取到A日志并应用，更新x表的y记录为10（不符合期望）
4    获取B日志更新x表y记录为20（符合期望）
这样，不仅在B库上面的数据不是用户所期望的结果，A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，才能够避免上面的问题。

原文首发： Sky.Jian 朝阳的天空
原文链接：MySQL Replication(复制)基本原理

MySQL单表到底可以多大

sky — Thu, 18 Sep 2008 11:46:07 +0800

前天突然收到Monitor Center发出来的报警：
PROBLEM:CN_DSL_***4/MAXFILE is CRITICAL,SNMP CRITICAL - *These File size is larger than 18932735283: /abc/def/ghi/***/***.MYD

刚看到这个报警的时候，还吓了一跳。数据文件超过最大文件限制？不会吧？好像才18G嘛，怎么会就开始报警了？
于是开始查找报警来源，经过一番查找，总算找到监控脚本。这台机器之前是SA管理维护的，所以相关规范也是按照SA管理的web服务器来设计的。所以他们在监控系统中添加了某些特定的目录下文件大小的限制，防止某些意外出现大文件的情况。最后我只得在监控脚本中过滤掉了MySQL的“.MYD”和 “.MYI”文件。

说到文件大小，刚好常有人问我说MySQL是否有单个表的大小限制？限制多大呢？这里做一个简单的介绍吧。

在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从 MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。

而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。

以下是从收集到的一点信息，不一定全部准确：
操作系统                                    大小限制
win32 w/ FAT/FAT32              2GB/4GB
win32 w/ NTFS                      2TB（可能更大）
Linux 2.2-Intel 32-bit            2GB (LFS: 4GB)
Linux 2.4+                            4TB(ext3)
Solaris 9/10                         16TB
NetWare w/NSS filesystem 8TB
MacOS X w/ HFS+               2TB

以下是MySQL文档中的内容：
Windows用户请注意： FAT和VFAT (FAT32)不适合MySQL的生产使用。应使用NTFS。

在默认情况下，MySQL创建的MyISAM表允许的最大尺寸为4GB。你可以使用SHOW TABLE STATUS语句或myisamchk -dv tbl_name检查表的最大尺寸。请参见13.5.4节，“SHOW语法”。

如果需要使用大于4GB的MyISAM表（而且你的操作系统支持大文件），可使用允许AVG_ROW_LENGTH和MAX_ROWS选项的CREATE TABLE语句。创建了表后，也可以使用ALTER TABLE更改这些选项，以增加表的最大允许容量。

原文首发： Sky.Jian 朝阳的天空
原文链接：MySQL单表到底可以多大

自己搞了函数行专列还是可以拼接

xiayulai — Sat, 13 Sep 2008 00:20:01 +0800

今天有个需求，要求把一个表里的根据一列（例如id）分组并且将每行的任意几列的数据挨着拼装在一起中间加特殊字符，
然后分组之后每个id对应的几行合成一条记录，例如：
SQL> select * from test;

P_ID NAME                 VALUE
———- ——————– ——————–
1 AAA                  aaa
2 BBB                  bbb
1 ABC                  abc
3 CCC                  ccc
2 DDD                  ddd

SQL> SELECT P_ID, Mystrcat_n(NAME||chr(01)||value) NAME FROM TEST GROUP BY P_ID;

P_ID
———-
NAME
——————————————————————————–
1
2AAA2aaa2ABC2abc

2
2BBB2bbb2DDD2ddd

3
2CCC2ccc

寻求Sky.Jian（简朝阳）帮助，给我了一个他自己搞的一个函数，结果不满足我的要求，
在他的基础上修改一下，可以满足以上要求，中间是用chr(01)来分隔的，函数体如下：
（执行此函数到底消耗多少资源没有测试过）

create or replace type Mystrcat_new as object
(
str varchar2(4000),

static function ODCIAggregateInitialize(sctx IN OUT Mystrcat_new) return number,
member function ODCIAggregateIterate(self IN OUT Mystrcat_new,value IN varchar2) return number,
member function ODCIAggregateTerminate(self IN Mystrcat_new,returnValue OUT varchar2, flags IN number) return number,
member function ODCIAggregateMerge(self IN OUT Mystrcat_new,ctx2 IN Mystrcat_new) return number
)
/

create or replace type body Mystrcat_new is
static function ODCIAggregateInitialize(sctx IN OUT Mystrcat_new)
return number is
begin
sctx := Mystrcat_new(null);
return ODCIConst.Success;
end;

member function ODCIAggregateIterate(self IN OUT Mystrcat_new, value IN varchar2)
return number is
begin
self.str := self.str||chr(01)||value;
return ODCIConst.Success;
end;

member function ODCIAggregateTerminate(self IN Mystrcat_new, returnValue OUT varchar2, flags IN number) return number is
begin
returnValue := self.str;
return ODCIConst.Success;
end;

member function ODCIAggregateMerge(self IN OUT Mystrcat_new, ctx2 IN Mystrcat_new) return number is
begin
null;
return ODCIConst.Success;
end;
end;
/

CREATE OR REPLACE FUNCTION Mystrcat_n (input varchar2) RETURN varchar2
AGGREGATE USING Mystrcat_new;
/

SELECT P_ID, Mystrcat_n(NAME||chr(01)||value) NAME FROM TEST GROUP BY P_ID;

ASM Lib包务必注意小版本啊

vogts — Fri, 12 Sep 2008 14:24:25 +0800

这件事是我太大意了，前几天装ASM的RPM包，怎么搞都搞不上去。我迷茫了好几天。到configure最后一步总是过不去，还调整了N多的OS参数，还上metalink上去查。报的错误是这样的：

[root@localhost wt]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets (’[]‘). Hitting <ENTER> without typing an
answer will keep that current value. Ctrl-C will abort.

Default user to own the driver interface [oracle]:
Default group to own the driver interface [oracle]: oinstall
Start Oracle ASM library driver on boot (y/n) [y]:
Fix permissions of Oracle ASM disks on boot (y/n) [y]:
Writing Oracle ASM library driver configuration: [ OK ]
Loading module “oracleasm”: Unable to load module “oracleasm”
[FAILED]

查了系统日志，给的信息是：

Sep 11 20:55:55 localhost modprobe: FATAL: Module oracleasm not found.

搞的我一头雾水，看到oracle官方论坛上说，这是一个bug。一开始我也是这么认为了。

今天再仔细看了下，是最最下面的小版本不对，ORACLE官方对小版本分的非常，非常细：

Drivers for kernel 2.6.18-92.el5

今天重新下了一个，小版本都一致的，结果就好了。

看到论坛上，很多兄弟发生的情况，和我差不多。所以我特发此文。

oracle 11g standby query error: ora-08103 and ora-01410

fcp — Wed, 03 Sep 2008 11:55:41 +0800

范鑫做的测试，我转过来。看起来很简单的一件事情，由于具有偶然性，不能每次都重现，所以特地记录下来，一直报的 ORA-08103: object no longer exists 是由于 standby 上的查询进程导致，把standby 激活后查询就正常了

当然这里要交代一下前提，就是在主数据库上有一个job，每天晚上将一个表truncate再插入数据，第二天就发现standby上查询错误，在主数据库上move表之后恢复正常。但是手工做 truncate却取法重现，重新做个job任务偶尔重现，也不是一定得到这个现象。目前正在进一步测试中，但至少发现了 11g的 standby提供适时查询功能是存在缺陷的。当然不truncate就没问题。

测试在一个已经存在问题的standby上进行，先以standby模式open，再open read only，最后激活open：

oracle@ctr_db1:/home/oracle>export ORACLE_SID=testctrdmsb2

oracle@ctr_db1:/home/oracle>sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on Wed Sep 3 10:28:45 2008

@>sqlplus /nolog

SP2-0734: unknown command beginning “sqlplus /n…” - rest of line ignored.

@>conn / as sysdba

Connected.

sys@CTRDM_DB1>

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

select count(*) from mcc.sync_job_status

ERROR at line 1:

ORA-01410: invalid ROWID

sys@CTRDM_DB1>select count(*) from mcc.testd2;

COUNT(*)

———-

1127

sys@CTRDM_DB1>

sys@CTRDM_DB1>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@CTRDM_DB1>startup mount;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE instance started.

Total System Global Area 2004340736 bytes

Fixed Size 2145744 bytes

Variable Size 402653744 bytes

Database Buffers 1593835520 bytes

Redo Buffers 5705728 bytes

Database mounted.

sys@CTRDM_DB1>alter database open ;

Database altered.

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

select count(*) from mcc.sync_job_status

ERROR at line 1:

ORA-08103: object no longer exists

sys@CTRDM_DB1>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@CTRDM_DB1>startup mount;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE instance started.

Total System Global Area 2004340736 bytes

Fixed Size 2145744 bytes

Variable Size 402653744 bytes

Database Buffers 1593835520 bytes

Redo Buffers 5705728 bytes

Database mounted.

sys@CTRDM_DB1>alter database open read only;

Database altered.

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

select count(*) from mcc.sync_job_status

ERROR at line 1:

ORA-08103: object no longer exists

sys@CTRDM_DB1>

sys@CTRDM_DB1>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@CTRDM_DB1>

sys@CTRDM_DB1>startup mount;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE instance started.

Total System Global Area 2004340736 bytes

Fixed Size 2145744 bytes

Variable Size 402653744 bytes

Database Buffers 1593835520 bytes

Redo Buffers 5705728 bytes

Database mounted.

sys@CTRDM_DB1>alter database open;

Database altered.

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

COUNT(*)

———-

sys@CTRDM_DB1>

如何恢复被删除的表空间？

vogts — Tue, 02 Sep 2008 13:19:09 +0800

前几天看到论坛上有人问，看到大家都是纸上谈兵，我做了个example。

下载地址：
删除表空间恢复.pdf