在做manage console时，由于存在后台和ui两方面修改树数据，存在并发问题。而此树实现又存在递归。

myisam方式是不行的，它需要锁住所有涉及到的表，这样的话，根本达不到只锁一个表的目的。myisam也不支持事务，但它支持表锁，但是他的锁需要手动释放，事务提交时是没有自动解锁的。innodb支持事务，但只支持行级锁。在事务提交时会自动解锁。

可使用单独表来实现并发互斥，此表只有一行记录，在进行操作事务时将此行用hibernate LOCKMODE.Read锁
代码:getSession().load(Lock.class, 0, LockMode.READ);
则达到互斥效果。

Continue reading mysql 锁 事务 并发

自我介绍
技术题
web容器用过哪些，优缺点
margin 方向顺序
经验
1:你最喜欢的编程语言是什么，为什么喜欢它，如果你喜欢的是java的话，你觉得它与javascript有什么区别吗？如果不是，你觉得你喜欢的语言与java又有什么区别？能谈谈你对javascript的看法吗？   
2:能谈谈过去18个月中java平台发生了什么事情吗？
2009

Oracle收购Sun

除了Oracle和Sun的故事，SpringSource的一系列举动在Groovy社区表现得也很活跃：收购Groovy和Grails技术的 幕后公司G2One，收购系统管理软件厂商Hyperic，随后SpringSource又被VMWare收购，在虚拟市场取得立足点。

另外，Terracotta收购了Quartz和ehCache开源框架。

Java开发领域2011年度热点回顾与展望 http://tech.it168.com/a2011/1216/1289/000001289885_1.shtml

3:如果你想学一种新的编程语言，你对那个比较感兴趣，为什么？
4:你非常喜欢的web应用有哪些，为什么喜欢他们？
5:你喜欢UI开发吗?你自己是否写过web UI组件，如果是，请介绍一下这些组件并谈谈你的体会。
6:你觉得开发web应用最糟糕的事情和最好的情况分别是什么，你觉得使用web应用最糟糕的事情和最好的情况又分别是什么？
7:能谈谈你对html5的看法吗？
8:如果你有一年的时间做些事情，你打算做什么，为什么要这样做？
9:你能谈谈你最有话要说的你参与过的项目吗？
10:你参与过开源项目吗？如果有，请介绍一下这个项目并谈谈你的体会？
你认为你有什么优缺点？

Continue reading 我出的web,java面试题

上传后使用http://localhost:10080/diz7/install/index.php安装
依据提示来
php默认配置mysql.dll,mysql pdo mysqli三个扩展都没启用，且extension_dir = "ext"也注释了，都要启用
安装数据库时我使用localhost不行，127.0.0.1倒是可以

Continue reading discuz7安装

swing 开发 assist 功能问题：
关键点获得输入光标的位置。
Point p = textArea.getCaret().getMagicCaretPosition();
mask 一定要在dot之前
setdot后再movedot这时应该是向后，看jdk源码就知道了。
swing 点击window的title栏时，不会触发window的click事件，即使使用Toolkit.getDefaultToolkit().addAWTEventListener的方式也不行
requestFocusInWindow如果不起作用，那要检查顶级窗体是否获得焦点，topWin.setVisible(true);即可
event.consume方法是可以取消事件的，但是对于textarea来说，要禁止输入最好在
keypress->keytyped->keyrealease三个里面都consume,不然还是会输入字符。
swing的事件不是像html dom那样冒泡，它会从最底层控件的事件监听器找起，没有才会向上冒泡。而且getSource是没什么用的(往往是添加监听器本身的控件)。

Continue reading swing 开发 assist 功能问题

一、JavaScript变量作用域(scope)
首先需要明白的几个要点：
1.JavaScript的变量作用域是基于其特有的作用域链的。
2.JavaScript没有块级作用域。
3.函数中声明的变量在整个函数中都有定义。（就后面第三点的说明）
4 .所有在最外层定义（非函数体内定义）的变量都拥有全局作用域
5. 所有末定义直接赋值的变量，系统会自动声明为拥有全局作用域的变量
6. 所有window对象的属性拥有全局作用域
（下面作者还提到全局变量都可以通过window.*来访问，明白这一点很重要，但是否准确？此外目前存在的疑问还有：
    即使可以以这中方式来访问全局变量那是否能认为全局对象由window来统一管理，还是window只是保存了一个拷贝而已?）

这是正确的，例：

<script type="text/javascript">
    	var s = '1';
    	
    	alert(window.s);
    </script>

结果是1

1.JavaScript的作用域链

首先看一个很简单的例子，下面的代码中，定义一个全局变量n，n的作用域是全局的。

<script language="javascript" type="text/javascript">

var n=1;

function show(){

  var m=2;

  alert(n);  //显示结果为1

}

show();

</script>

运行代码后，结果为1。原理就是JavaScript作用域是层层包含的，外层的作用域在内层有效，执行的时候，从内层向外层查找。当函数show执行的时候，首先在函数show内部查找变量n，没有找到，再向外层查找，找到了全局变量n，alert显示结果为1。

2.局部变量优先级高于全局变量

<script language="javascript" type="text/javascript">

var n=1;

function show(){

  var m=2;

  var n=3;

  alert(n);  //显示结果为3

}

show();

</script>

这个不难理解，根据上面变量作用域链的原理，函数执行时，会先从内层向外层查找，如果在内层中找到变量，查找就会停止。所以内层的作用域会优先于外层，局部优先于全局。

稍改一下：

<script language="javascript" type="text/javascript">

var n=1;

function show(){

  var m=2;

  var n=3;

  alert(window.n);  //显示结果为1

}

show();

</script>

为什么会是1，而不是3呢，只是另外一个问题：全局变量都是window对象的属性，任何的全局变量都是window对象的属性，都可以用window.*来引用。(*代表一个变量)

3.在函数内部使用var声明的变量，不论在何处声明，该变量都拥有整个函数的作用域。

<script language="javascript" type="text/javascript">

var n=1;

function show(){

  alert(n);  //undefined

  alert(this.n); //显示为1

  var n=3;  //声明局部变量n

  alert(n);  //显示为3

}

show();

</script>

第一个问什么会显示undefined呢，这个问题的原因就是在函数后面声明了局部变量n=3，在函数show执行的时候，会先从内层查找变量n，结果找到了，但在第一个alert的时候，n还没有赋值，故结果为undefined。

4.JavaScript没有块级作用域

<script language="javascript" type="text/javascript">

var n=1;

function show(){

for(var i=0;i<3;i++){

   var n=6;

   alert(i);  //显示结果为0,1,2

}

alert("for循环外："+i); //显示结果为：“for循环外：3”

alert("n="+n);  //显示结果为：n=6

}

//alert(i);  外部引用一个未声明变量会提示出错

show();

</script>

变量i虽然是在for循环内定义的，但for循环块外部仍然可以引用，i的作用域是整个函数show。如果在show函数外部引用i变量，会出现JavaScript报错。

5.没有使用var声明的变量属于全局变量

<script language="javascript" type="text/javascript">

var n=1;

function show(){

  m=9;  //声明变量m

  var s=6;

}

show();  //不可少，alert之前需要先执行m=9，否则m未声明

alert(m);  //显示9

alert(window.m);  //显示9

alert(s);  //报错"s is not defined"

</script>

函数show执行的过程中，引用了变量m，但未使用var声明，m就变成了全局变量。

二、JavaScript匿名函数

所谓匿名函数就是没有命名的函数，看起来有点难以理解，其实很常见，下面举一个小例子。

window.onload=function(){ alert("加载完毕！");}

这样就创建了一个匿名函数，这个function没有函数名，但可以被调用和执行，当网页加载完毕时，会执行alert()。

<script language="javascript" type="text/javascript">

(function(x,y){alert(x+y)})(2,3);  //显示结果为5

</script>

上面的方法仍然是创建了一个匿名函数，并使用()优先表达式强制执行函数。

三、JavaScript闭包(closure)

闭包其实就是利用了函数作用域和匿名函数的知识，当函数A执行结束时，一部分变量变量被B引用，被引用的变量不能释放，形成了所谓的闭包。这里有篇很好的文章，可以参考一下。

下面看一个小例子：

<script language="javascript" type="text/javascript">

function show(){

   var n=3;

   setTimeout(function(){alert("first:"+n);},3000); //3秒后显示first:3

   alert("second:"+n); //显示second:3

}

show();

function show2(){alert("第一个函数执行结束");}

show2();

</script>

运行上面的函数后，首先alert显示"second:3"，然后显示"第一个函数执行结束"，3秒后显示“first:3”。

仔 细看一下，函数show执行结束的时候，变量n应该被释放了，内存里也就不存在了，怎么过了3秒还能显示出"first:3"呢？闭包恰恰就在此产生了， 当函数show执行结束的时候，想要释放内存里的n，但发现变量n还在被一个匿名函数引用，要在3秒后调用，根据JavaScript闭包原理，内存里的 n被保留了下来，于是在三秒以后仍然可以调用n。

下面看几种写法的区别：

function show2(content){

alert(content);  //3秒后alert显示"test"

}

function show(content,delay_time){

   setTimeout("show2('"+content+"')",delay_time);

}

show("test",3000);

仔细看一下上面这种写法不是闭包，只是普通的函数调用而已。

function show(content,delay_time){

   setTimeout(function(){alert(content)},delay_time); //3秒后alert显示"test"

}

show("test",3000);

这种写法就是闭包，虽然结果是一样的，但原理不一样。

function show(content){

   function show2(){alert(content);}

   return show2;

}

var newshow=show("test");

setTimeout(newshow,3000);  //3秒后alert显示"test"

上面这种写法也是闭包，虽然结果都是一样的，但原理却不一样。这里面看到了函数也可以当作对象也传递，函数show执行后return show2，把函数show2赋值给newshow，然后3秒后，调用newshow对象，执行函数show2。

仔细比较上面3种写法，如果能悟出一些道理就好，闭包有些时候的确难理解。

稍复杂一点的例子：

<script language="javascript" type="text/javascript">

var show=null;

(function(){

var n=1;

var show2=function(){

     alert(n++);

}

show=show2;

})();

show();  //显示1

show();  //显示2

show();  //显示3

</script>

上面代码中，又一次用了函数作为对象传递，n是匿名函数里的局部变量，外部是访问不到的。show是一个全局变量，应该访问不了变量n，但在函数 show执行前，首先把函数匿名函数内部show2赋值给show，当后面函数show运行的时候，会调用show2的代码，而show2是可以访问n 的，故结果显示为1、2、3。

另外一点值得注意的，也是很经典的一个例子。

CSS代码：

ul{ width:600px; margin:0px auto;}

ul li{ margin:1px 0px; background-color:#999999;}

HTML代码：

<ul>

<li>1</li>

<li>2</li>

<li>3</li>

<li>4</li>

</ul>

JavaScript代码：

<script language="javascript" type="text/javascript">

var li=document.getElementsByTagName("li");

for(var i=0;i<li.length;i++){

  li[i].onclick=function(){alert(i);}

}

</script>

运行后，不论点击哪一个li，都是alert提示“4”。这就是一个需要注意的地方：闭包允许内层函数引用父函数中的变量，但是该变量是最终值。闭包引用的变量i，是循环结束后的值，其实这是一个很常见的问题，解决方法也有很多。

比较常见的就是给li[i]添加属性值，比如li[i].n=i；还有就是用闭包方法解决，这个函数本身就是闭包，所谓用闭包来解决闭包的问题。代码如下：

<script language="javascript" type="text/javascript">

var li=document.getElementsByTagName("li");

for(var i=0;i<li.length;i++){

  (function(index){

  li[index].onclick=function(){alert(index);}

  })(i);

}

</script>

Continue reading 【转】JavaScript变量作用域

1. 前言

随着计算机技术的飞速发展，数据库的应用十分广泛，深入到各个领域，但随之而来产生了数据的安全问题。各种应用系统的数据库中大量数据的安全问题、敏 感数据的防窃取和防篡改问题，越来越引起人们的高度重视。数据库系统作为信息的聚集体，是计算机信息系统的核心部件，其安全性至关重要，关系到企业兴衰、 国家安全。因此，如何有效地保证数据库系统的安全，实现数据的保密性、完整性和有效性，已经成为业界人士探索研究的重要课题之一，本文就安全防入侵技术做 简要的讨论。

数据库系统的安全除依赖自身内部的安全机制外，还与外部网络环境、应用环境、从业人员素质等因素息息相关，因此，从广义上讲，数据库系统的安全框架可以划分为三个层次：

⑴ 网络系统层次；

⑵ 宿主操作系统层次；

⑶ 数据库管理系统层次。

这三个层次构筑成数据库系统的安全体系，与数据安全的关系是逐步紧密的，防范的重要性也逐层加强，从外到内、由表及里保证数据的安全。下面就安全框架的三个层次展开论述。

2. 网络系统层次安全技术

从广义上讲，数据库的安全首先倚赖于网络系统。随着Internet的发展普及，越来越多的公司将其核心业务向互联网转移，各种基于网络的数据库应用 系统如雨后春笋般涌现出来，面向网络用户提供各种信息服务。可以说网络系统是数据库应用的外部环境和基础，数据库系统要发挥其强大作用离不开网络系统的支 持，数据库系统的用户（如异地用户、分布式用户）也要通过网络才能访问数据库的数据。网络系统的安全是数据库安全的第一道屏障，外部入侵首先就是从入侵网 络系统开始的。网络入侵试图破坏信息系统的完整性、机密性或可信任的任何网络活动的集合，具有以下特点：

a）没有地域和时间的限制，跨越国界的攻击就如同在现场一样方便；

b）通过网络的攻击往往混杂在大量正常的网络活动之中，隐蔽性强；

c）入侵手段更加隐蔽和复杂。

计算机网络系统开放式环境面临的威胁主要有以下几种类型：a)欺骗（Masquerade）；b)重发(Replay)；c)报文修改 (Modification of message)；d)拒绝服务(Deny of service)；e)陷阱门(Trapdoor)；f)特洛伊木马(Trojan horse)；g)攻击如透纳攻击（Tunneling Attack）、应用软件攻击等。这些安全威胁是无时、无处不在的，因此必须采取有效的措施来保障系统的安全。

从技术角度讲，网络系统层次的安全防范技术有很多种，大致可以分为防火墙、入侵检测、协作式入侵检测技术等。

⑴防火墙。防火墙是应用最广的一种防范技术。作为系统的第一道防线，其主要作用是监控可信任网络和不可信任网络之间的访问通道，可在内部与外部网络之 间形成一道防护屏障，拦截来自外部的非法访问并阻止内部信息的外泄，但它无法阻拦来自网络内部的非法操作。它根据事先设定的规则来确定是否拦截信息流的进 出，但无法动态识别或自适应地调整规则，因而其智能化程度很有限。防火墙技术主要有三种：数据包过滤器(packet filter)、代理(proxy)和状态分析(stateful inspection)。现代防火墙产品通常混合使用这几种技术。

⑵入侵检测。入侵检测(IDS-- Instrusion Detection System)是近年来发展起来的一种防范技术，综合采用了统计技术、规则方法、网络通信技术、人工智能、密码学、推理等技术和方法，其作用是监控网络和 计算机系统是否出现被入侵或滥用的征兆。1987年，Derothy Denning首次提出了一种检测入侵的思想，经过不断发展和完善，作为监控和识别攻击的标准解决方案，IDS系统已经成为安全防御系统的重要组成部分。

入侵检测采用的分析技术可分为三大类：签名、统计和数据完整性分析法。

①签名分析法。主要用来监测对系统的已知弱点进行攻击的行为。人们从攻击模式中归纳出它的签名，编写到IDS系统的代码里。签名分析实际上是一种模板匹配操作。

②统计分析法。以统计学为理论基础，以系统正常使用情况下观察到的动作模式为依据来判别某个动作是否偏离了正常轨道。

③数据完整性分析法。以密码学为理论基础，可以查证文件或者对象是否被别人修改过。

IDS的种类包括基于网络和基于主机的入侵监测系统、基于特征的和基于非正常的入侵监测系统、实时和非实时的入侵监测系统等。

⑶协作式入侵监测技术

独立的入侵监测系统不能够对广泛发生的各种入侵活动都做出有效的监测和反应，为了弥补独立运作的不足，人们提出了协作式入侵监测系统的想法。在协作式 入侵监测系统中，IDS基于一种统一的规范，入侵监测组件之间自动地交换信息，并且通过信息的交换得到了对入侵的有效监测，可以应用于不同的网络环境。

3. 宿主操作系统层次安全技术

操作系统是大型数据库系统的运行平台，为数据库系统提供一定程度的安全保护。目前操作系统平台大多数集中在Windows NT 和Unix，安全级别通常为C1、C2级。主要安全技术有操作系统安全策略、安全管理策略、数据安全等方面。

操作系统安全策略用于配置本地计算机的安全设置，包括密码策略、账户锁定策略、审核策略、IP安全策略、用户权利指派、加密数据的恢复代理以及其它安全选项[7]。具体可以体现在用户账户、口令、访问权限、审计等方面。

用户账户：用户访问系统的"身份证"，只有合法用户才有账户。

口令：用户的口令为用户访问系统提供一道验证。

访问权限：规定用户的权限。

审计：对用户的行为进行跟踪和记录，便于系统管理员分析系统的访问情况以及事后的追查使用。

安全管理策略是指网络管理员对系统实施安全管理所采取的方法及策略。针对不同的操作系统、网络环境需要采取的安全管理策略一般也不尽相同，其核心是保证服务器的安全和分配好各类用户的权限。

数据安全主要体现在以下几个方面：数据加密技术、数据备份、数据存储的安全性、数据传输的安全性等。可以采用的技术很多，主要有Kerberos认证、IPSec、SSL、TLS、VPN（PPTP、L2TP）等技术。

4. 数据库管理系统层次安全技术

数据库系统的安全性很大程度上依赖于数据库管理系统。如果数据库管理系统安全机制非常强大，则数据库系统的安全性能就较好。目前市场上流行的是关系式数据库管理系统，其安全性功能很弱，这就导致数据库系统的安全性存在一定的威胁。

由于数据库系统在操作系统下都是以文件形式进行管理的，因此入侵者可以直接利用操作系统的漏洞窃取数据库文件，或者直接利用OS工具来非法伪造、篡改数据库文件内容。这种隐患一般数据库用户难以察觉，分析和堵塞这种漏洞被认为是B2级的安全技术措施。

数据库管理系统层次安全技术主要是用来解决这一问题，即当前面两个层次已经被突破的情况下仍能保障数据库数据的安全，这就要求数据库管理系统必须有一 套强有力的安全机制。解决这一问题的有效方法之一是数据库管理系统对数据库文件进行加密处理，使得即使数据不幸泄露或者丢失，也难以被人破译和阅读。

我们可以考虑在三个不同层次实现对数据库数据的加密，这三个层次分别是OS层、DBMS内核层和DBMS外层。

⑴在OS层加密。在OS层无法辨认数据库文件中的数据关系，从而无法产生合理的密钥，对密钥合理的管理和使用也很难。所以，对大型数据库来说，在OS层对数据库文件进行加密很难实现。

⑵在DBMS内核层实现加密。这种加密是指数据在物理存取之前完成加/脱密工作。这种加密方式的优点是加密功能强，并且加密功能几乎不会影响DBMS 的功能，可以实现加密功能与数据库管理系统之间的无缝耦合。其缺点是加密运算在服务器端进行，加重了服务器的负载，而且DBMS和加密器之间的接口需要 DBMS开发商的支持。

定义加密要求工具

DBMS

数据库应用系统

加密器

（软件或硬件）

⑶在DBMS外层实现加密。比较实际的做法是将数据库加密系统做成DBMS的一个外层工具，根据加密要求自动完成对数据库数据的加/脱密处理：

定义加密要求工具加密器

（软件或硬件）

DBMS

数据库应用系统

采用这种加密方式进行加密，加/脱密运算可在客户端进行，它的优点是不会加重数据库服务器的负载并且可以实现网上传输的加密，缺点是加密功能会受到一些限制，与数据库管理系统之间的耦合性稍差。

下面我们进一步解释在DBMS外层实现加密功能的原理：

数据库加密系统分成两个功能独立的主要部件：一个是加密字典管理程序，另一个是数据库加/脱密引擎。数据库加密系统将用户对数据库信息具体的加密要求 以及基础信息保存在加密字典中，通过调用数据加/脱密引擎实现对数据库表的加密、脱密及数据转换等功能。数据库信息的加/脱密处理是在后台完成的，对数据 库服务器是透明的。

加密字典管理程序

加密系统

应用程序

数据库加脱密引擎

数据库服务器

加密字典

用户数据

按以上方式实现的数据库加密系统具有很多优点：首先，系统对数据库的最终用户是完全透明的，管理员可以根据需要进行明文和密文的转换工作；其次，加密 系统完全独立于数据库应用系统，无须改动数据库应用系统就能实现数据加密功能；第三，加解密处理在客户端进行，不会影响数据库服务器的效率。

数据库加/脱密引擎是数据库加密系统的核心部件，它位于应用程序与数据库服务器之间，负责在后台完成数据库信息的加/脱密处理，对应用开发人员和操作 人员来说是透明的。数据加/脱密引擎没有操作界面，在需要时由操作系统自动加载并驻留在内存中，通过内部接口与加密字典管理程序和用户应用程序通讯。数据 库加/脱密引擎由三大模块组成：加/脱密处理模块、用户接口模块和数据库接口模块，如图4所示。其中，"数据库接口模块"的主要工作是接受用户的操作请 求，并传递给"加/脱密处理模块"，此外还要代替"加/脱密处理模块"去访问数据库服务器，并完成外部接口参数与加/脱密引擎内部数据结构之间的转换。" 加/脱密处理模块"完成数据库加/脱密引擎的初始化、内部专用命令的处理、加密字典信息的检索、加密字典缓冲区的管理、SQL命令的加密变换、查询结果的 脱密处理以及加脱密算法实现等功能，另外还包括一些公用的辅助函数。

数据加/脱密处理的主要流程如下：

1） 对SQL命令进行语法分析，如果语法正确，转下一步；如不正确，则转6），直接将SQL命令交数据库服务器处理。

2） 是否为数据库加/脱密引擎的内部控制命令？如果是，则处理内部控制命令，然后转7）；如果不是则转下一步。

3） 检查数据库加/脱密引擎是否处于关闭状态或SQL命令是否只需要编译？如果是则转6），否则转下一步。

4） 检索加密字典，根据加密定义对SQL命令进行加脱密语义分析。

5） SQL命令是否需要加密处理？如果是，则将SQL命令进行加密变换，替换原SQL命令，然后转下一步；否则直接转下一步。

6） 将SQL命令转送数据库服务器处理。

7） SQL命令执行完毕，清除SQL命令缓冲区。

以上以一个例子说明了在DBMS外层实现加密功能的原理。

5. 结束语

本文对数据库系统安全防入侵技术进行综述，提出了数据库系统的安全体系三个层次框架，并对三个层次的技术手段展开描述。文中还以在DBMS外层实现加密功能的原理为例，详细说明了如何应用数据库管理系统层次的安全技术。

数据库系统安全框架的三个层次是相辅相承的，各层次的防范重点和所采取的技术手段也不尽相同，一个好的安全系统必须综合考虑核运用这些技术，以保证数据的安全。

----------------------------------------------------------------------------------------------------------------------------

数据库安全分析

三大安全风险

数据库是任何商业和公共安全中最具有战略性的资产，通常都保存着重要的商业伙伴和客户信息，这些信息需要被保护起来，以防止竞争者和其他非法者获 取。互联网的急速发展使得企业数据库信息的价值及可访问性得到了提升，同时，也致使数据库信息资产面临严峻的挑战，概括起来主要表现在以下三个层面：

管理层面：主要表现为人员的职责、流程有待完善，内部员工的日常操作有待规范，第三方维护人员的操作监控失效等等，致使安全事件发生时，无法追溯并定位真实的操作者。

技术层面：现有的数据库内部操作不明，无法通过外部的任何安全工具（比如：防火墙、IDS、IPS等）来阻止内部用户的恶意操作、滥用资源和泄露企业机密信息等行为。

审计层面：现有的依赖于数据库日志文件的审计方法，存在诸多的弊端,比如:数据库审计功能的开启会影响数据库本身的性能、数据库日志文件本身存在被篡改的风险，难于体现审计信息的真实性。

伴随着数据库信息价值以及可访问性提升，使得数据库面对来自内部和外部的安全风险大大增加，如违规越权操作、恶意入侵导致机密信息窃取泄漏，但事后却无法有效追溯和审计。

传统数据库安全方案缺陷

传统的审计方案，或多或少存在一些缺陷，主要表现在以下两个方面。

传统网络安全方案：依靠传统的网络防火墙及入侵保护系统(IPS)，在网络中检查并实施数据库访问控制策略。但 是网络防火墙只能实现对IP地址、端口及协议的访问控制，无法识别特定用户的具体数据库活动(比如：某个用户使用数据库客户端删除某张数据库表);而 IPS虽然可以依赖特征库有限阻止数据库软件已知漏洞的攻击，但他同样无法判别具体的数据库用户活动，更谈不上细粒度的审计。因此，无论是防火墙，还是 IPS都不能解决数据库特权滥用等问题。

基于日志收集方案：需要数据库软件本身开启审计功能，通过采集数据库系统日志信息的方法形成审计报告，这样的审计方案受限于数据库的审计日志功能和 访问控制功能，在审计深度、审计响应的实时性方面都难以获得很好的审计效果。同时，开启数据库审计功能，一方面会增加数据库服务器的资源消耗，严重影响数 据库性能;另一方面审计信息的真实性、完整性也无法保证。

其他诸如应用程序修改、数据源触发器、统一认证系统授权等等方式，均只能记录有限的信息，更加无法提供细料度的数据库操作审计。

--------------------------------------------------------------------------------------------------------------------------

安全审计

一、数据库安全审计系统主要功能包括：

· 实时监测并智能地分析、还原各种数据库操作。

· 根据规则设定及时阻断违规操作，保护重要的数据库表和视图。

· 实现对数据库系统漏洞、登录帐号、登录工具和数据操作过程的跟踪，发现对数据库系统的异常使用。

· 支持对登录用户、数据库表名、字段名及关键字等内容进行多种条件组合的规则设定，形成灵活的审计策略。

· 提供包括记录、报警、中断和向网管系统报警等多种响应措施。

· 具备强大的查询统计功能，可生成专业化的报表。

二、数据库安全审计系统主要特点

· 采用旁路技术，不影响被保护数据库的性能。

· 使用简单，不需要对被保护数据库进行任何设置。

· 支持SQL-92标准，适用面广，可以支持Oracle、MS SQL Server、Sybase、Informix等多类数据库。

· 审计精细度高，可审计并还原SQL操作语句。

· 采用分布式监控与集中式管理的结构，易于扩展。

· 完备的"三权分立"管理体系，适应对敏感内容审计的管理要求。

----------------------------------------------------------------------------------------------------------------------

安全审计技术分类

常见的安全审计技术主要有四类，分别是：基于日志的审计技术、基于代理的审计技术、基于网络监听的审计技术、基于网关的审计技术。

1.基于日志的审计技术：该技术通常是通过数据库自身功能实现，Oracle、DB2等主流数据库，均具备自身审计功能，通过配置数据库的自审计功能，即可实现对数据库的审计，其典型部署示意图如图2所示：

图2 日志审计技术部署示意

该技术能够对网络操作及本地操作数据库的行为进行审计，由于依托于现有数据库管理系统，因此兼容性很好。

但这种审计技术的缺点也比较明显。首先，在数据库系统上开启自身日志审计对数据库系统的性能就有影响，特别是在大流量情况下，损耗较大；其 次，日志审计记录的细粒度上差，缺少一些关键信息，比如源IP、SQL语句等等，审计溯源效果不好，最后就是日志审计需要到每一台被审计主机上进行配置和 查看，较难进行统一的审计策略配置和日志分析。

2.基于代理的审计技术：该技术是通过在数据库系统上安装相应的审计Agent，在Agent上实现审计策略的配置和日志的采集，常见的产品 如Oracle公司的Oracle Audit Vault、IBM公司的DB2 Audit Management Expert Tool以及第三方安全公司提供的产品，其典型部署示意图如图3所示：

图3 代理审计技术部署示意

该技术与日志审计技术比较类似，最大的不同是需要在被审计主机上安装代理程序。代理审计技术从审计粒度上要优于日志审计技术，但是性能上的损 耗是要大于日志审计技术，因为数据库系统厂商未公开细节，由数据库厂商提供的代理审计类产品对自有数据库系统的兼容性较好，但是在跨数据库系统的支持上， 比如要同时审计Oracle和DB2时，存在一定的兼容性风险。同时由于在引入代理审计后，原数据库系统的稳定性、可靠性、性能或多或少都会有一些影响， 实际的应用面较窄。

3.基于网络监听的审计技术：该技术是通过将对数据库系统的访问流镜像到交换机某一个端口，然后通过专用硬件设备对该端口流量进行分析和还原，从而实现对数据库访问的审计。其典型部署示意图如图4所示：

图4 网络监听审计技术部署示意

该技术最大的优点就是与现有数据库系统无关，部署过程不会给数据库系统带来性能上的负担，即使是出现故障也不会影响数据库系统的正常运行，具备易部署、无 风险的特点；但是，其部署的实现原理决定了网络监听技术在针对加密协议时，只能实现到会话级别审计（即可以审计到时间、源IP、源端口、目的IP、目的端 口等信息），而没法对内容进行审计。不过在绝大多数业务环境下，因为数据库系统对业务性能的要求是远高于对数据传输加密的要求，很少有采用加密通讯方式访 问数据库服务端口的情况，故网络监听审计技术在实际的数据库审计项目中应用非常广泛。

4.基于网关的审计技术：该技术是通过在数据库系统前部署网关设备，通过在线截获并转发到数据库的流量而实现审计，其典型部署示意图如图5所示：

图5 网关审计技术部署示意

该技术是起源于安全审计在互联网审计中的应用，在互联网环境中，审计过程除了记录以外，还需要关注控制，而网络监听方式无法实现很好的控制效 果，故多数互联网审计厂商选择通过串行的方式来实现控制。在应用过程中，这种技术实现方式开始在数据库环境中使用，不过由于数据库环境存在流量大、业务连 续性要求高、可靠性要求高的特点，与互联网环境大相径庭，故这种网关审计技术往往主要运用在对数据库运维审计的情况下，不能完全覆盖所有对数据库访问行为 的审计。

Continue reading 数据库系统安全技术框架综述

最近发现论坛上关于数据库远程复制和异地容灾等问题的帖子比较多，现在把我知道的一些解决方案进行一下分析，能力有限，还希望大家多多补充、纠正！
目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：
（1）基于存储层的容灾复制方案
这 种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大 数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。
目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。
（2）基于逻辑卷的容灾复制方案
这 种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择 同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为 这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。
我一直有一个困惑，存储级的 复制，假如是同步的，能保证 数据库所有文件一致吗 ？或者说是保证在 异常发生的那一刻有足够的缓冲来保障？
也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？
上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案
我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧……
我 觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文 件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失， 也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启 动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了 存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而 且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。
所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。
不知道我的理解对不对，也不知道是不是回答了你的问题，呵呵。欢迎指正！
应该说部分地回答了我的问题，呵呵
因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的，存储设备一定是做过重整的，那 不管同步或者异步的拷贝都 有可能 存在问题的。
所以我一直对这个方案的可靠性不敢完全相信，这样一来，倒不如 data guard 可靠了
因为很明显，存储设备拷贝过去的数据文件 不一致是有很大的概率的
你 的意思是说即使不考虑目标端，仅在源端的情况下，存储设备的写入顺序也是和Oracle不一致的？这应该是一个原因。我觉得还有一种可能性就是在忽略存储 设备的这种情况下，在主系统当机，发生切换的时候，主系统存储上的数据文件也不一定能保证一致，就算目标系统保持了完全的同步，也一样不能保正目标端数据 可可以启动。
不太理解，为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿
如果说仅在源端情况下，存储设备的写入顺序也是和Oracle进程不一致，那么不考虑异地冗灾，那么是不是意味着即使本地服务器crash，也无法启动存储上的数据文件？
我也有这个疑问，以前一直觉得仅考虑主系统的情况下，存储设备的写入顺序应该是和数据库的写入顺序一致的， 但我觉得biti_rainy的理解也是有道理的，存储设备毕竟和一般的磁盘不一样，很可能再写入的时候会作重新的组合，不过不知道具体的证据是什么啊？
按 照这种理解，再写入的某一瞬间，数据库的写入顺序和存储的写入顺序可能是不一致的，但既然存储写入的结果跟oracle的写入结果肯定是一致的，那么我们 可以把一个比较长的写入过程分成若干个时间段，在每个时间段的结尾，oracle和存储设备的写入结果都是完全一致的，那么这个时间段的大小是多少呢？
呵呵，说得我自己都快晕了，也不知道大家明白我的意思没有……
o
biti_rainy能不能给我们解释一下啊？或者论坛里有没有对存储设备比较了解的兄弟啊？
系统上通常不一致没关系是因为还有 logfile 的存在，而日志文件通常是被写入了磁盘的，oracle本身是顺序写的，还不需要读，应该是被重整的几率比较小
还有存储设备上，比如掉电没关系，是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘，这个如果不能保证那一掉电基本都要出问题的
但是在复制的那端，我就不清楚是怎么处理的，比如我要停掉复制，开始用起这数据来，或者说设备掉电了，这个时候是怎么处理的
在复制的那端，我感觉是没有经过特殊处理的，因为存储设备完全是物理上的同步，在你停掉 复制的时候，他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的，但他绝对不会去校验或保证oracle的数据 文件在逻辑上是否一致，所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下，停止存储的复制，然后启动 目标端数据库，但还是有1/3的几率无法启动，如果是在原系统发生故障或断电的情况下，估计就更不好说了。
我还是比较佩服那个客户的勇气，一个省级移动运营商的数据中心，数据库连归档都没有，一旦系统崩溃，至少要损失当天的数据，同时容灾端的数据库能不能起来还是个问题……
还好目前还没有出问题，要是出了问题，不知道他们会怎么办……
上次做存储设备的来公司，谈到这个问题的时候说： 很多客户就是这么做的
我就说： 很多人这么做的并不能说就没问题，因为很多 人没有出现事故，是因为隐藏的问题没有机会暴露出来。我需要：
1：机制上的可靠保障，这个可能只有非常理解 原理的人能回答
2：实际系统的测试，要经过在我们自己提供的数据场景下反复测试
通过这两点之后我们才敢放心使用
同意，确实很多人都是这么用的，也确实都很可能出现问题，所以我一直以为基于存储的数据 库容灾方案是有问题的，但在有些环境中好像还只能这么做，例如我们的一个客户，也是一个省级的移动运营商，其数据库每天的日志量达到100G以上，在这种 条件下，好像只有这种解决方案比较可行，其他的都会有一些问题，至少那些使用软件实现的逻辑复制方案是不行的，我感觉oracle自己的standby好 像也负担不了吧？不过他们的数据库至少还是归档的，还有一点保证。呵呵。
从ORACLE的角度来衡量基于存储的容灾肯定是有问题的，不可能做到100%可用。
即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失（当前日志组的数据）。
换个思路了，使用基于应用的同步方案吧。
（3）基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……
目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
这类产品的原理基本相同，其工作过程可以分为以下几个流程：
使 用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档 日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的 复制（主要在oracle9i环境中）。
这种技术的技术特点和优势主要有以下几点：
目标端数据库一直是一个可以访问的数据库；
能保证两端数据库的事务一致性；
因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；
基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；
因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。
这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。
由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。
基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：
数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；
实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；
复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。
不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。
您说的备中心1/3机会不可用，是同步复制还是异步复制的情况？
是指同步复制的情况。
这个数字我不敢保证它的准确性，因为我没有做过实际的实验来验证，但从我在客户那里看到的实际情况来说，基本属实。
您能告诉我你的客户用的那一家的产品吗？
不 管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧 因为数据库写文件是由操作系统来最终完成的，而操作系统本身又有cache，在通过逻辑复制把数据异步或同步复制到其他存储设备上，中间无论哪个环节有问 题，远程存储设备的数据都不能同现有数据保持一致，所以我认为 biti的怀疑是很有道理的。到10g oracle可以使用assm，直接同存储设备对话，这样是否能够好一些，不太确定
存储是通过快照来记录状态，然后再进行复制进行备份的。
其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句
这就是oracle stream 和quest shareplex实现的功能
利用oracle 9i的高级复制，加上第三方的管理工具就可以了
我对oracle 的高级复制研究较多，觉得这是最好的方法，能够完全保证数据的一致性。
但管理起来比较麻烦，需要利用第三方的管理工具就可以了。我用的是 深圳华尔东城公司的管理工具，能够自动进行简单故障处理，目前设置的10分钟增量同步，最大表有4000多万条记录，目前还只同步了一部分表，数据量达到了50G。
容灾实际例子，不知道是不是有帮助
曾 经评估了几个这方面的方案，一是利用存储本身提供的功能，在两端距离比较远（几百几千公里）的时候，只能用异步的方式，同步的话对网络的带宽要求很高，除 非两端能够用光纤直接连接。异步的方式根据厂商的解释是这样的，远端存储上的写是无序的，不会根据生产端的次序写入，对用户来说是透明的，没有办法干预， 也就是说对oracle来说是不同步的，如果没有人为的干预进行一次同步的话，数据库也没有办法启动。但是如果要同步的话就会对生产数据库产生影响，处于 suspend状态。至于停电等各种极端情况我们在同城同步做过测试，没有问题，存储能够保证数据的一致和可用。异地异步没有测试过，不知有哪位兄弟做过 这个试验，能告诉结果。
看了大家的帖子，我也想说点东西，一直以来做的就是容灾和备份的事情。
目前的所谓的容灾可能包含两种方式：
1.真正的容灾，目的就是为了防止在灾难发生的时候能减少下线时间。这个过程没有一个能做到零下线的。
2.”假“容灾，即所谓的ods，数据复制。出来的数据不单单能达到容灾的目的，而且目的端数据可以实时被使用。
第一种方式可能是鸡肋，因为花那么大的投资使用当前的硬件容灾方式去达到一个可能领导在任期间都不能发生的灾难，实在让人觉得不太值得，除非厂商给了这个领导很大一笔钱，不过当前许多电信行业都说要建容灾中心。
第二种方式确实是一种很诱人的方式，也是我现在做的产品。这种方式主要采用两种方式实现：
a.使用我们现在的同步工作实现首次同步（逻辑上的导出，也是一种鬼才写出了这个东西，当然他是我们老总），然后直接转入监控online redolog进行日志监控分析转化，然后传送到目标端装载。
b.使用类似于bcv/ca/flashcopy这些快照类软件在磁盘存储级做成首次同步，然后使用我现在的产品做日志监控，加载到目的端。
这个产品作了1年多，应该说比quest的shareplex强大的多了，但是我并非在此宣传产品，所以我要说的是公平话。
通 过oracle内部方式去达到实时同步可能本身就是一个错误，类似于oracle本身的advance replication以及data guard也是日志分析方式的，他的主要缺点在于效率上存在问题，就是装载数据量很大的时候，根本不能应付，这也是shareplex的毛病。因此我现在 的产品在这个上面是克服了这些缺点，效率绝对的高。我和oracle的stream，quest的shareplex，以及非用于容灾方式的data guard等对比过，大家互有长短。
关键就是，采用基于这种精确分析的复制方式，如何保证数据是完全准确的：
1.没有有效的检验方式，检查数据是否一致，有类似于select minus select的方式，但是对于超过100M的表，除非你有足够的耐心，我经常见到表最大是92G，没有分区，很变态。
2.就算你知道了丢失数据，如何把这个数据补回来。现在的类似于我们的软件，都采用了rowidmap的方式去做精确定位，所以如果丢失了，你如何补回来。我知道quest 是重新同步，我们是把整个表重新同步，因为我们的逻辑到处快。
这些都是基于oracle精确复制需要解决的最大的问题。
呵呵，当然了关于这个里面处理很多oracle的特殊操作的时候还有很多需要做的事情，quest做了8年多了吧，到5年后才支持chained row，不能不说这是一个悲剧。还有许多的操作类型怎么办：ddl
,truncate,rollback savepoint,nologging等等，当然日志了没有的时候，你如何做。
我个人的观点，基于oracle的精确分析复制方式，除了oracle以后能做好，其他人不要轻易尝试。
不知道能否把产品名字透露一下啊？
如果没有猜错应该是DSG的了？
DGS和shareplex的比较让市场来说话吧。
每个人都会说自己的产品好，但是希望在itpub这个地方
还是要说出一些更多技术上的东西。
samchj说“此我现在的产品在这个上面是克服了这些缺点，效率绝对的高”，并且也提到你们的产品也是通过监控redo的变化，提取SQL，那么为什么你们的效率会绝对的高？
希望能从机制上说明一下这个问题。
首先我澄清一下，我没有宣传产品的意思。
我必须让事实说话，而不是市场说话，市场存在很多人为因素。
在 效率上，对于处理chained row这种在数据库中经常出现的东西，不能采用sql statment执行的方法。而shareplex是使用的这种方法。曾经我在测试的时候就对比过这个东西。因为chained row 包括migrate row &chain row 两种。而mr在oracle中只有一个rowid，而cr却不止。因此如果你采用的是rowmap方式精确定位两边的表，那么在处理chain row的时候，除非你能很好的处理，否则最简单和准确的方式就是直接在源端找到这个行，然后通过sql statment的方式装到目的端。这样在速度上是很慢的。
效率的提高主要从分析速度和装载速度上讲的。
我不知道shareplex日志分析是如何进行的，这当然也是这类型软件的kernel了，这是算法问题，我想起基本原理和logminer都差不多，在算法上优化分析速度是很重要的。
在 装载问题上，其实shareplex也曾经使用过direct path的装载方式，但是因为direct path本身就存在很多bug，因此干脆就放弃了这种方式，因为据我所接触的通过direct path装载的bug就很多，例如索引不能使用等。所以只能通过conventional path来装载。这就是规规矩矩的转换成sql statment，然后交给oracle通过解释成binary 后在装载
了，这是很浪费时间的，而且对于qmi（基本由creat table as select引起的oracle特殊插入处理）来说，这是很不合理的，因此在这里应该做些事情，当然细节不便于说。
另外对于首次同步的导出和装载，现在的oracle10g也许就是使用的这种方式了，你可以看看oracle10g的export为什么如此快。
我还是说，不论是否市场怎么样，使用基于oracle精确分析装载的软件要慎重使用，因为他的问题是很多的。
楼上的你们产品是什么啊
关于这类产品的一些特别情况的处理我一直很关心
另： 10G 使用的 *expdp* 和 *impdp* 应该是由 DUL + SQLLDR direct 思想的结合吧
我们现在用的是Oracle 9i ，想用复制软件VERITAS Storage Replicator 3.0使两台服务器上的数据库同步，应该复制Oracle下的那些数据文件，表空间？还有复制后应该怎么做？
服务器硬件说明：
两台服务器为了节约成本，没有使用双机热备，没用磁盘阵列，每台服务器用4块SCSI硬盘做成Raid 5，两台服务器操作系统，数据库安装路径，设置都一致，有没有解决办法啊?
使用SQL Server 2000数据库把数据文件复制到另外一台服务器，数据库可以实现同步，但是Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。
对于samchj 一直说：然后通过sql statment的方式装到目的端。这样在速度上是很慢的，然后交给oracle通过解释成binary 后在装载了，这是很浪费时间的 ？
－－－－－－－－－－－－－－－－－－－－－－－－
能否举出实际的例子？拿出具体的数据来说话， 你所谓的慢是什么程度？
澄清一下，shareplex 不是使用你所谓的direct path 方式。
dx6340老兄，我不是在宣传产品，我再澄清一次。如果有人对我现在做的产品感兴趣，可以给我写邮件，但是我们只谈技术，不谈市场，但是在itpub上或者任何其它场合，我不会说我的产品是如何的好，虽然我的和shareplex做的对比测试很多。他们各有各的优缺点。
shareplex 确实不使用direct path装载，这个我也说过“其实shareplex也曾经使用过direct path的装载方式”，我是说曾经，从研发上讲。你可以用shareplex或者oracle的data guard等做实验，当大数据量的时候，你可以看看他是否能分析过来和装载过来，延迟时间多少。一秒钟能支持的update有多少，insert有多少， 如果做ddl是否需要先停止复制。这些还只是很基本的处理。logminer尚且对日志的分析很慢（不过可以用多进程来弥补，如果你有很多的系统资源）。
wbo 兄弟的“Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。”，我的理解是，如果你使用基于存储级的复制产品，你同步的应该是整个设置的卷或者卷组， 他没有什么oracle的逻辑结构复制方法吧，要么就是把这个表空间创建在一个卷组上，然后设定复制这个卷组。如果你硬是要复制一个表空间过去，我觉得你 应该先通过oracle的TRANSPORT_TABLESPACE来，但是好像很没有必要。使用存储级的复制不能实时打开，打开必须断开。
对于基于复制中的特殊方式处理，主要有这些：
1.采用何种装载方式
2.如何准确快速执行delete和update，因为这两个操作需要rowid，有人采用在数据库本身创建很多的表来维护rowid。
3.对chain row的处理
4.对各种ddl的处理(truncate,create,drop,alter)
5.对于未提交的事务的处理
等等,因为我确实还没有来总结这些资料,这里先列各提纲,我一个一个来总结.
1.装载方式:
在 oracle中装载数据库不外乎两种方式:direct path和conventinal path装载,其中类似direct path装载就是例如sqlload等工具使用的装载方式,因为它省去了sql语句的编译\绑定(kk/kx),直接转换成绑定后的格式对extent进 行操作.而conventinal path装载方式确实普通的装载方式,即类似于标准的sql语句的装载.后者比前者在同等条件下要慢5倍.当然两种方式的装载速度还和表本身的结构和大小 有关.我测试的速度最大有12倍的差距.
在装载上,你还要考虑更多内容,你不能单单调用oracle sqlloader,因为在oracle中有很多的oracle特殊处理的东西,例如:qmi,qmd.oracle在这里对于这些操作有在redo中有 特殊的标志,如果你采用create table as select来创建表,你会觉得它比现创建然后用sql语句插入要快的多,在日志中他也只有很少的记录.因此,在处理这些的时候,你要采用特殊的算法,所 以调用oracle的现成工具是不理想的,曾经在oracle7之前oracle并没有将upi (好像是这个名字)封掉,但是在oracle8i后,oracle不再开放该接口,因此很多的程序员对于这个层面了解很少.当然现在你很难找到.oci只 是封装后更高级的接口而已.
因此装载程序的设计,对于基于oracle精确分析方式的复制有很大的决定作用,这里面还有更多的处理,我也不能一一列出了.
呵呵，楼上的这个工具就是你自己开发的吗？
如果你老板能找到一个肯研究 OCI --> UPI --->OPI 的手下 并一直坚持对oracle的研究，在国内简直是太不容易了。
没其他意思,如果不是你开发的，除了对这一部分外，对oracle的整体问题你有过研究吗？
呵 呵，我不知道oracle的整体问题是什么意思，oracle太大了，我涉及的有关于oracle的备份恢复（包括非归档物理热备份，各种恢复方式，以及 你们都已经在讨论的热备到底在做什么，那都是我很早前学的，反正备份的东西夸大点就是知道原理的东西多些，不过不敢在任何地方卖弄，因为技术这个东西很难 说，嘻嘻）。
搞我们这个容灾产品也有很久了，基本涉及的有联机日志分析，各种特殊操作的原理等等，不能详细罗列，但是在装载上说实话，我只是知道 经过哪些层次，并没有开发，而是帮助开发作单元测试，所以知道比较详细些而已，知道对于我上面写的东西如何处理。同时对比过诸 如：shareplex，stream，data guard等软件产品性能和基本的一些原理，也和存储级复制软件结合，做过组合测试而已。
对于oracle的调优工作，我还是不如大家的，不过我看eygle老兄的东西都很接近我学的东西，因为确实我曾经站在了“巨人”的肩膀上，嘻嘻，还要向大家多学习，学习。
要说深入oracle，也只是在看大家写的东西的同时，自己总结在这些年学习的东西，和大家分享，因为我觉得，我在网络上学了些，当然我也想将我学到的东西给大家分享，呵呵。
明天继续对于这种产品存在的各种瓶颈作分析，也希望大家指正，我申明一点，我不做产品宣传，只是在我都测试过的基础上总结，绝不胡说
其实也没什么,整体方面是说oracle的文件、内存、进程等比较全面的东西，
对于 oracle internal 比较有兴趣一些，如 oracle 内存、文件管理、进程间通信
宏观方面 备份恢复、tuning、体系结构 ，这些都是在前面internal基础上的具体应用，了解了internal后在管理方面就不局限于固定的模式了。
比如喜欢这样的探讨：
呵呵，当然，我关注的也是这些。
我努力想成为一个像我们老板一样的高手，他能将这些东西转换成程序，呵呵。
但是我不能把他拉到itpub上来，否则，中国的oracle研究者有福了。不过我愿意将我在他那里学的东西共享给大家，和大家一起研究。也请多指教。
你们老板……当初是从哪里学来的呢
因为如果原来不是oracle的人的话，我仅仅知道国外这样的人有一些，国内的同时精通oracle+os + 开发 的人，很罕见的 。我只是听闻国内有oracle的人出去做这类产品去了，但具体名字不清楚，不知道是不是你们老板。
这 个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个 IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.
但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质.
同步如果是从主机下来的IO直接复制，这样频繁的小IO将造成网络的大量问题，这对网络的要求太高了。 以前都是听人说同步是从 存储的cache 来的，拷贝的时候封锁cache不允许写……
我觉得这个和同步I/O和异步I/O没有关系，对于存储级的复制，他们都有一个队列来保证I/O的次序，这是类似于ca/emc等厂商的这些存储级（varitas文件系统级）复制的一个共同点。至少我知道veritas声称的原理是这样的。
如果不能保证I/O的次序，存储级复制没有任何意义。而且像ca这样的软件，他并不是实时改变多少就穿多少，我觉得他记录在磁盘头的tab应该隔多少时间加一次锁，然后新的插入写cache，所以如果这个时间源端off的话，cache中的数据应该是丢失的（磁盘坏）。
软件级的复制也一样，你总有一个队列来处理ops/rac的事务顺序，这个队列有放在磁盘上用文件来排队的，也有直接在内存中排队的，这些也是关键的东西。当然像软件复制这样的软件可以通过重新分析日志的方式来弥补，如果磁盘没有坏的话。
同步绝对就是那样，每个在SOURCE端写入的东西必须被远端的存储设备写入成功（不一定是写入磁盘）才返回主机写入成功，基本可以认为就是一个距离很远的RAID1。一致性的问题不用担心，但是带宽要求等等都是很高的。
异步的方法，在之前很多是不能保证一致的，呵呵。最近据说多了很多能保证一致的方法，就知道HDS会吧所有写记录到本地一个日志卷，EMC和IBM的方法还没有弄的很清楚。
看看我们的实际应用
现在介绍我们数据库同步的成功案例，你们提到的问题都可以解决。
现在我们的数据同步已经投入了实际运行，采用逐步增加表的方式。目前已经同步了149个表，其中包括详单表，统计基表等。最大的6000多万记录，有16个超过1000万记录，采用10分钟异步复制。主要有以下特点：
1、关键业务数据（排出了很多垃圾数据），数据量最小
2、对生产机影响较小，目前一般只用到300M 空间
3、目标端数据不可以修改，完全保证数据一致
4、初始同步快捷、方便，不需要停止生产系统应用。影响小，只相当如一个select。
5、管理方便、灵活：能够看到各表上次同步时间；上次同步后又有多少条新数据；上次各表同步耗费多长时间等。
目前每天进行一次count(*) 检查，没有发现有问题。
我们一前也试用过dsj和shareplex的产品，从名气上来说，应该还不错。具体不是我亲自试用的，但最后没有能够成功，我想与我们的系统复杂、数据库本身不是很稳定、要求太高有关。
1、这是一个24小时运行的系统，停止应用程序来进行初始同步比较麻烦。
2、需要在每天早晨从同步的数据中产生关键的数据和报表，要求不能耽误。
3、要求管理维护简单、灵活：要求运行稳定，同步中断后能够简单快速处理完。
现在我们用的oracle机制，加上第三方数据同步管理软件，只用了1个晚上就将主体数据同步好，一周就正式投入使用。然后逐步完善增加同步的表，目前已经同步了149张表，还对同步数据进行了分区处理等优化，从目前的近一个月的情况来看效果理想。
经过一年半还多的时间试用了2家产品没有能够成功，用一周时间就解决了问题（主要报表实际上第二天就正式使用了），心里是多么的欣慰、兴奋和富有成就感。
所以写了这么多东西。
就是用了ORACLE物化视图技术+一个图形界面配置，还以为是啥东东哦。
还有谁为建立报表机和容灾的数据同步而烦恼吗？
oracle的功能确实很强大，这需要大家一起去挖掘，才会有基于oracle的更多更好的应用软件产生。
samchj 兄，你是DSG的吧？海龟从ORACLE,IBM出来，而且专攻容灾的公司，我想不出第二家。你们的技术很牛，对底层很清楚，但让人担心对ORACLE后 续版本的支持。虽然所宣称的产品功能实现很吸引人，在测试中有不少问题，亟待完善。VP忙着改BUG，应该是没有什么时间来这灌水。
关于BITI担心的存储同步问题，楼上的已经解释很清楚了。之所以存储厂商要求主节点、容灾节点更换成他们的存储设备，就是要解决I/O,CACHE的问题，从而保证同步端能够做到完全镜像。
容灾端只有停掉同步，才能打开数据库，然后下一次再重做同步。而且他们还提供SNAPSHOT的功能，建立一个快照数据库，对于一个大数据库，需要的存储很可观。
我个人认为，存储厂商的最大优势在于维护量少，有保障。DATA GUARD配置灵活，不依赖于底层，但需要人为监控。
声明：我们这用的不是DATA GUARD
是一个第三方软件，目前报表机同步底层用的是 实例化视图。
如果建立应用级的容灾，数据需要实时同步，估计需要用到同步复制技术了。目前还没有下决心做，担心性能问题。目前有过1个表的初步测试，还没有进行大量表的测试。
对你的ppt提几个疑问：
1。传统同步软件方案为10年前的技术，比较落后。
这个恐怕有些武断，相反对于数据库的复制我个人更看好如Quest的shareplex等产品。同样dataguard也使用类似技术，绝对不是如你所言是10年前的落后技术。
2。传统同步软件方案，因其本身的缺陷，导致需要大量复杂的机制和操作来保证数据的一致，实施成本大。
复 杂的机制不是最终客户需要考虑的，相反这些软件的实施成本是相应较小的（当然如果你的成本是指money的话，那自然是比物化视图高，不过仍然可以选用 DG），说起复杂的机制，即使是你使用的物化视图，也仍然有大量内部的控制是较复杂的，不过这些不需要实施者去考虑而已。
3。采用硬件存储快照的方式，同步方式不灵活，将生产系统上所有的数据全部同步。（经过长时间运行和维护的生产系统往往大量的临时表和大量的垃圾数据，这些实际上是不需要同步的。
通常基于存储的复制提供了卷一级的管理，完全可以通过配置不同的数据文件在不同的卷上来达到复制关键数据的目的。
4。采用硬件存储快照的方式，耗费大量的存储设备，成本巨大。
就我所知，至少veritas的vvr不需要太多额外的存储。
5。华尔东城公司采用的独特方案，采用oracle的各种技术相结合，结合本公司独特的同步参数设置。通过本公司软件控制进行同步的管理。
其实你这个ppt真是说的很含糊，用于单纯的sales宣传恐怕还可以，如果是用于技术交流实在是有些不痛不痒。
6。华尔东城产品重要的益处，保证容灾数据完全一致，报表数据与10分钟前一致 。
既然有10分钟的差距，为何仍然说容灾数据完全一致？如果说你们使用了物化视图的方案，那么就不可能在一个刷新期内（你们这儿的10分钟？）保证数据不丢失。除非还有业务log的分析软件作后备。
7。华尔东城产品重要的益处，对主机性能影响小。
其实物化视图的刷新对于主机并不是很小的影响，如果10分钟之内需要刷新大量的数据，可以明显的看到CPU的波峰，特别是oracle本身对于mvlog的处理还是有些问题的，所以不确定你们是否真的作过跟其它专业同步软件的主机性能影响的比较。
8。本公司得益于oracle新技术的推出，加上本公司的努力，终于能够为数据同步提供完美的方案，这也是我们值得骄傲的一件事情。
不否认你们确实作出了一个比较完备的同步解决方案，但是希望能够本着技术交流的想法在itpub讨论问题，而不是作单纯的商业宣传。我想很多人都希望知道你所指的oracle新技术是什么？不应该说就是物化视图吧。

Continue reading 【转】数据库远程复制和异地容灾 大讨论

1：引擎还是要改进一下：动画显示很慢，没有达到指定的fps的效果【不明白】，
在有的机器上怎么cpu在85%以上，fps越高，cpu越厉害，但是这里26 fps就这么慢了【不明白】
2：音乐格式FF不支持mp3,但是ogg都支持。wav的播放很卡，safari还好。ie9不支持ogg，支持mp3和aac
3：对于坐标系统，要注意相对坐标高宽的变化，最好每次会只是都计算（要计算zoom比），因为如果canvas是百分比高宽的时候，浏览器的resize会导致绘制的图形压缩或扩大。
4:ie9需要设置html5 doctype才能运行canvas，其它的浏览器即使你用的html4 doctype也可以。
5:ie9不支持new Audio,但是document.createElement('audio');可以

Continue reading html5开发连连看问题

2009-06-12 10:04

Continue reading 【转】双机/RAC/Dataguard的区别

一、中国工商银行上海数据中心数据备份和恢复的需求
1.1. 用户的需求
中国工商银行上海数据中心(以下简称上海数据中心)，每天需要对 VSE/ESA 生产主机 和 OS/390 生产系统上的生产和系统数据进行备份，包括批处理前和批处理后的数据备份。上海数据中心每天需要从 8 个 VSE/ESA 系统和 8 个 OS/390 系统上的数百个 3390-3 型磁盘卷上备份大量 VSAM 文件(业务数据) 和备份磁盘卷的整卷数据。现在，每个VSE/ESA 生产系统的每天的数据备份量达 200 盘 3490E 磁带，其中有 60 盘左右为对磁盘卷的备份。为了不间断业务运行，缩短批处理时间，不影响生产运行。上海数据中心对数据备份操作的要求是：
确保数据安全性和完整性。
缩短备份时间，减少由于备份对业务的中断。
如果需要进行数据恢复时，恢复操作要准确、迅速，时间短。
备份和恢复操作要简捷，便于操作员的日常使用。
为了将数据备份时间缩短到最小，上海数据中心希望利用磁盘快速复制技术，或者虚 拟磁带系统来快速完成备份操作。
上海数据中心最终备份的的数据是 VSAM 文件。单个文件的数据量不大，但是文件数量众多。对这种类型数据的备份和恢复，虚拟磁带系统(VTS)技术将是最好的解决方案。上海数据中心最终利用 StorageTek 公司 的、运行在 OS/390 操作系统上的 HSC 和 VTCS 软件，配合以运行在 VSE/ESA 操 作系统上的、MT Consultant 公司的 LMS/VSE 软件来完成这些备份任务的。
二、方案介绍
由于上海数据中心需要备份的数据量庞大，将来的备份磁带数量一定很多。因此，上海数据中心应该采用自动磁带库来管理备份磁带。并采用物理磁带及 和虚拟磁带机相结合的数据备份和恢复技术，来提高数据备份的效率和存储空间的利用率。 9490 磁带机与 3490E 磁带机完全兼容，采用 IDRC 压缩和 3490E E-cart，单盘磁带的容量为 2.4 GB。由于上海数据中心的磁盘卷大多数为 3390-3 型，容量为2.89 GB，将占用 2 盘 3490E E-cart 磁带。上海中心采用 9490 磁带机 EE-tape 功能，一盘磁带的容量可以高达 4.8 GB (压缩后)。对于 OS/390 磁盘卷整卷的备份，上海数据中心采用 StorageTek 9310 自动磁带库和 9840高性能、大容量磁带机。如果配合 StorageTek exHPDM 软件，可以将数个磁盘卷同时 备份到一盘 9840 磁带上。将能充分发挥 9840 磁带机的性能和充分利用 9840 磁带的容量。
根据工商银行上海数据中心对数据备份和恢复的要求，采用 StorageTek 公司 9310 自动磁带库加 StorageTek 公司的 VSM(虚拟存储系统)的综合磁带解决方案。
VSM 主要处理大量小文件的备份和恢复，如 VSAM 文件、CICS 日志、数据库增量 备份等。而对大型文件备份和恢复，则直接使用 9310 自动磁带库中磁带驱动器，如对磁盘卷的整卷备份、数据库的全备份等操作。
本方案涉及的硬件和软件产品
1 1套 StorageTek 9310 自动磁带库系统
2. 1套 StorageTek VSM 虚拟存储系统
3. 8 套 HSC (主机软件部件) 软件
4. 1套 VTCS (虚拟磁带控制软件)
5. 8 套 LMS/VSE 软件及 8 套 5193 磁带库管理网关
6. 磁带管理软件
在 OS/390 系统上采用 CA 公司的 CA-1/TMS 磁带管理软件。
在 VSE/ESA 系统上采用 CA 公司的 DYNAM/T 磁带管理软件。
2.4. 磁带库和 VSM 系统硬件连接方案
若要实现虚拟磁带卷的迁移和回迁，VSM 至少需要 9310 磁带库中的 2 台 9840 物 理磁带驱动器与其相连接。如果迁移和回迁的工作量比较大，则需要更多的磁带机驱动器。由于 VSM 主要用于处理大量小文件的备份和恢复。而对大型文件的备份和恢复仍需要直接使用 9310 自动磁带库中 9840 磁带驱动器。因此 9310 自动磁带库必须要有 直接(或通过 ESCON 通道转接器)连接到 OS/390 主机上的磁带机驱动器。如果主机上同时提交了多个大型文件的备份或恢复作业，则需要有多个磁带机驱动器。否则，将会有作业因没有可用的磁带驱动器而等待。 如果将 9310 中的多个磁带驱动器给 VSM 专用，再将另一些磁带驱动器给主机专用，则需要更多的磁带驱动器。直连的优点是，日常操作比较简便。但是，这样做投资 比较大，而且磁带驱动器不能得到充分的利用。这样如何充分、有效地利用磁带库 中磁带驱动器，则是需要解决的问题。
上海中心每个VSE系统每天的数据备份量平均为 200 盘 3490E 磁带。不含磁盘卷的备份磁带。按照实际存储在每盘磁带上的数据量平均为 100 MB，那么 8 个 VSE 系统每天的备份数据总量为 160 GB。如果这些备份数据驻留在 VSM 的时间为 1 天，那么VSM的容量至少为 160GB。如果这些备份数据的保留时间为 30 天，则总的数据容量为 9.6 TB。 自动磁带库中将 需要至少 120 盘 9840 磁带来保留这些备份磁带。如果将每天每个 VSE 系统的备份数 据迁移到一盘 3490E 磁带中， 30 天则需要 240 盘 3490 磁带。 如果 OS/390 系统的备份的数据量与 VSE/ESA 系统的相近，则对 VSM 容量的要求将 与以上分析大体相近。
三、方案技术要点
虚拟磁带存储管理是对磁带和自动磁带库解决方案的重大革新。它是自从磁带库出现以来，第一个为批量处理而发明的新技术。虚拟磁带使现有的技术能够得到充分地利用。虚拟磁带技术将批处理中的磁带操作变得更加有效，使高密度介质、高性能磁带机和高速通道得以充分利用。
VSM 虚拟磁带系统所带来的最大利益是极大地提高了批处理的性能，这是用户可以直接感受到的虚拟磁带技术所带来的影响。其带来的间接利益还有很多，包括：充分利用现有的磁带机和磁带资源，解决磁带驱动器紧张的问题，简化了磁带管理。
对于小型批处理文件的备份，装带和卸带时间占整个磁带操作时间(占用磁带机驱动器的时间)的很大一部分。利用虚拟磁带技术，将没有装带和卸带的 时间，所以整个磁带操作时间将显著降低。 这将带来两大好处：第一，批处理作业将运行地更快，从而缩小批处理窗口;第二， 虚拟磁带机驱动器的利用率更高，减少作业等待驱动器的时间，降低了对驱动器数 量的需求。再加上虚拟磁带系统提供的虚拟磁带驱动器数量很多，使系统可以同时 处理大量批处理备份作业，减少作业的等待时间。如果需要从仍驻留在 VSM 中 虚拟磁带中恢复数据，由于该虚拟磁带卷仍然驻留在缓存中，VSM 将会直接将它恢复到主机磁盘上。整个过程不需要装带/卸带操作，缩短了恢复的时间，也缩短了批处理的时间。用户可以定义虚拟磁带卷驻留的时间。

Continue reading 【转】工商银行上海数据中心备份方案解析