Tag/
共2531个网摘 [
1 2 3 4 5 6 7 8 9 10 ...
85 ]
上一页 |
下一页 |
xuejinyoulan收录，使用标签：数据库，时间：2008-8-18 16:52:19 | 相关网摘，我也收藏
出处:IT168
IBM的DB2 V9 引入了自动存储器管理，使用自动存储功能可以帮助您简化表空间的存储管理，新创建的使用自动存储功能的表空间，其容器和空间分配完全由 DB2数据库管理器确定。本文重点介绍使用DB2® V9 自动存储功能的数据库如何进行非增量重定向还原。
简介
数据库可能会因为软件或硬件故障而不可用，可能会遇到存储问题、断电、应用程序故障或误操作等各种需要采取不同恢复措施的故障情况。本文重点介绍使用了DB2® V9 的自动存储功能，不允许增量备份的数据库如何进行重定向还原。由于使用自动存储器功能的数据库在还原方面和以往有了很大区别，客户在实际使用的过程中容易出现各种问题，所以本文对自动存储功能会有详细的阐述。
自动存储特性最初是在DB2 V8.2.2中引入的，DB2 V9扩展了这一特性，使用自动存储功能可以帮助您简化表空间的存储管理，新创建的使用自动存储功能的表空间，其容器和空间分配完全由 DB2数据库管理器确定。
自动存储管理
自动存储器跨磁盘和文件系统自动增大数据库大小。因此，在保持数据库管理的存储器性能和灵活性的同时，不再需要管理存储器容器。在DB2 V9.1中，已对多分区数据库增加了自动存储器支持。如果您使用的是带DPF(Data Partitioning Feature，数据库分区功能)的企业服务器版，那您可以使用支持自动存储器功能的多分区数据库。在DB2 V9中创建新数据库的时候，默认启用自动存储功能，主要目的是简化表空间的存储管理，使用自动存储功能的数据库有一个或多个相关联的存储器路径，在创建表空间的时候不用指定存储的路径等特性。对使用自动存储器功能的数据库，其表空间可以使用自动存储管理，也可以不使用自动存储管理。对于不使用自动存储器功能的数据库，则其表空间不能使用自动存储管理。
自动存储器简化了存储管理，它使您能够指定用于数据库管理器存放表空间数据以及为各种用途分配空间的存储路径。另外，在创建和填充表空间时，DB2 将管理这些表空间的容器和空间分配。如果不需要使用自动存储器，则必须通过运行 CREATE DATABASE 命令并将 AUTOMATIC STORAGE 选项设置为NO，或通过使用 sqlecrea API 并将 SQLEDBDESCEXT 参数设置为 SQL_AUTOMATIC_STORAGE_NO 来创建数据库。
自动存储器功能只能在创建数据库时指定，不能对已经创建的未使用自动存储器功能的数据库启用自动存储器;同样，对创建数据库时启用自动存储器的数据库也不能禁用自动存储器，变通的方法就是在创建表空间的时候可以指定是否使用自动存储器，即虽然数据库启用了自动存储器功能，但可以创建不使用自动存储器功能的表空间。
由于对多分区配置引入了自动存储器数据库，所以更改了 db2look 命令。现在在发出 db2look 命令之前，必须确保所有数据库分区都是活动的。如果有任何数据库分区处于不活动状态，则会发出警告消息，该消息说明无法生成表空间的DDL。此 db2look 命令更改会影响所有表空间类型。
接下来，我们将通过示例的方式分别解释如何在创建数据库的时候使用自动存储器功能。
示例1：创建不使用自动存储器的DB2数据库DB2TEST1
CREATE DATABASE DB2TEST1 AUTOMATIC STORAGE NO ON /db2/databases/db2test1
如果在实际过程中不需要使用自动存储功能，则必须在创建数据库时将 AUTOMATIC STORAGE 选项设置为 NO，否则，将创建使用自动存储器功能的数据库。
示例2：创建使用自动存储器的DB2数据库DB2TEST2
CREATE DATABASE DB2TEST2
因为在DB2 V9中创建新数据库的时候，默认启用自动存储功能，我们在创建数据库的时候没有显式将指定AUTOMATIC STORAGE 选项设置为NO，所以新创建的数据库DB2TEST2 将自动启用自动存储功能，其数据库路径是使用 dftdbpath 数据库管理器配置参数来确定，其存储器路径也是使用 dftdbpath 数据库管理器配置参数来确定。
默认创建了3个表空间：SYSCATSPACE、TEMPSPACE1和USERSPACE1，都是使用自动存储管理。需要注意的是，对USERSPACE1表空间，和其在DB2 V8相比其表空间类型由常规变成了大型。
示例3：创建使用自动存储器的DB2数据库DB2TEST3
CREATE DATABASE DB2TEST3 ON /db2/databases/db2test3
因为在DB2 V9中创建新数据库的时候，默认启用自动存储功能，我们在创建数据库的时候没有显式将指定AUTOMATIC STORAGE 选项设置为NO，所以新创建的数据库DB2TEST3 将自动启用自动存储功能，其数据库路径是：/db2/databases/db2test3，其存储器路径也是：/db2/databases/db2test3。
示例4：创建使用自动存储器的DB2数据库DB2TEST4
CREATE DATABASE DB2TEST4 AUTOMATIC STORAGE YES
也可以在创建数据库的时候显式将指定AUTOMATIC STORAGE 选项设置为YES，效果和默认时相同，创建的数据库DB2TEST4也使用自动存储，其数据库路径和存储器路径由dftdbpath 数据库管理器配置参数确定。
示例5：创建使用自动存储器的DB2数据库DB2TEST5
CREATE DATABASE DB2TEST5 ON /db2/databases/db2test5/autostorage DBPATH ON /db2/databases/db2test5
因为在DB2 V9中创建新数据库的时候，默认启用自动存储功能，我们在创建数据库的时候没有显式将指定AUTOMATIC STORAGE 选项设置为NO，所以新创建的数据库DB2TEST5 将自动启用自动存储功能，数据库路径由DBPATH ON directory参数指定，在当前示例中数据库路径是：/db2/databases/db2test5，存储器路径由ON directory 参数指定，在当前示例中存储器路径是 /db2/databases/db2test5/autostorage。
对于前面显示的示例，下表总结了所使用的存储器路径：
表 1. 自动存储器数据库路径和存储器路径
http://database.ctocio.com.cn/tips/229/8263229.shtml
xuejinyoulan收录，使用标签：数据库，时间：2008-8-18 16:47:42 | 相关网摘，我也收藏
来源：IT168
不管这个观点是对还是错，SQL Server一直以来都被看作是适合用作数据集市更甚于大规模数据仓库的一个数据库。很多大企业都有一个中心辐射型架构，也就是采用Teradata这样的技术构建一个大型中央数据仓库，然后以SQL Server或Oracle等数据库为基础构建若干小型数据集市。不管微软如何努力，始终都无法摆脱“可扩展性有限”这样一种观点，直到最近收购了DATAllegro这样一家在以Netezza为先驱的数据仓库设备市场风生水起之际涌现出来的新兴企业，业界也开始对SQL Server未来可扩展性的潜力进行重新评估。
DATAllegro是一家很有意思的公司，它并没有像其他的很多厂商一样混迹在中端数据仓库市场，要知道它最小的客户也拥有高达50TB的数据(这里指的是实际的数据，不包括索引和备份)。它很少向外透露其客户基础和财政营收情况，但确实招揽了不少大客户，如Sears和Teoco。将这一家已被证实具备高端可扩展性的数据仓库设备商据为己有，微软无疑获得了一个大好机会把大家对SQL Server可扩展性根深蒂固的看法一劳永逸清除掉。微软首先要做的是，将DATAllegro的技术从Ingres/Linux平台转接到SQL Server/Windows环境，鉴于该技术的设计模式，这个任务的难度并不是很大。目前，DATAllegro紧密地构建在EMC硬件基础之上，不过很有可能会在和SQL Server整合的中期阶段进行更换。
很多评论家在谈到DATAllegro的技术时，似乎都忽略了也许是最有意思的一点：除了能在一个大型数据仓库进行多并行处理外，DATAllegro技术还具有网格功能，使其能够像整合了中央数据仓库和若干独立数据集市的中心辐射型网络一样运行。为了达到这个目的，DATAllegro利用其并行处理能力开发实现了极快的数据传输速度;例如，在其为Teoco提供的数据仓库案例中，设置了一个中央呼叫中心详细操作数据存储器为数据仓库输送数据，然后还有一个独立的归档数据仓库用来处理紧迫程度不太高的查询。这个数据仓库部署存储了400TB的真实数据，传输速度约为每天1TB。
假设有一家企业部署了一个中央数据仓库和若干SQL Server数据集市。原则上，这个架构是有可能迁移到拥有一个中央数据仓库和多个独立数据集市的单个DATAllegro网格，而这个网格里运行的都是SQL Server。当然，如果这些数据集市在迁移之前是相互独立的，那么可能要花费很大的功夫来协调各自的模式和其中包含的主数据，不管怎样至少有这么一个选择可以在一个单一的技术平台完成所有的工作。
微软对这次的收购相当郑重其事，从微软将成立一个与SQL Server部的行政级别平行的数据仓库部并任命DATAllegro的创始人Stuart Frost为部门主管这件事就可以看出微软的态度来。微软很聪明地让收购到手的研发团队保持原样，而没有强迫他们加入到微软总部工作，这是尽量减少人才流失的一个手段。
如果微软能够很好地利用这次的收购，利用DATAllegro带来的网格技术将数据仓库和数据集市整合到一个平台上，那么相信最终也就能够解决SQL Server可扩展性这个顽疾了。
http://tech.it168.com/a2008/0804/199/000000199437.shtml
xuejinyoulan收录，使用标签：数据库，时间：2008-8-18 16:33:24 | 相关网摘，我也收藏
来源：傻妞的blog_新浪博客
由于Oracle不提供用于实时输出消息的工具, Oracle数据库开发者总是要面临实时监视他们的储备过程执行的挑战。他们必须使用dbms_output.put_line调用，这个调用直到过程完成才返回结果。
在本文中，我想演示如何从Oracle8i数据库直接发送电子邮件，作为一种实时通信解决方案。这样我们要监视存储过程就不再需要等待它们完成了，这样的方法还为开发者提供了其他的一些好处：
可以在几分钟内调试一些很长的批处理过程，而不需要等几个小时；
计算用于指定代码块所需的执行时间；
这就需要解决一个问题，我们如何从运行的存储过程中输出消息以便我们可以即时检查它们，即使我们不在办公场所？我们的做法是把所有必需的过程与函数包装在自定义的包中，然后使用Oracle8i UTL_SMTP包直接地从Oracle数据库中发送电子邮件。下面我将详细讲解一些这个过程。
Oracle的UTL_SMTP包
在Oracle8i中引入了UTL_SMTP包（SMTP代表Simple Mail Transfer Protocol简单邮件传送协议，使用TCP端口25在客户机和服务器之间建立通信联络)，使开发者能够从数据库发送电子邮件。
只有安装带有Java虚拟机(JVM)的8i或更高的版本才能使用UTL_SMTP。此外还必须把plsql.jar载入数据库中。否则，当调用UTL_SMTP API来发送电子邮件的时候我们将得到下面的异常：ORA - 29540 : class oracle/plsql/net/TCPConnection does not exist。
默认的$ORACLE_HOME/javavm/install/initjvm.sql脚本（安装了JVM）不运行把plsql.jar载入数据库的initplsj.sql脚本。系统用户或者内部用户可以手工运行$ORACLE_HOME/RDBMS/ADMIN/initplsj.sql脚本以解决这个问题。如果你没有可用的脚本，你要么可以从Oracle支持那里得到它，要么可以简单地直接使用loadjava载入实用程序plsql.jar：
loadjava -user sys/password@database -resolve plsql/jlib/plsql.jar
UTL_SMTP API:
本文的代码中使用了下列UTL_SMTP包中的API：
OPEN_CONNECTION()：打开到简单邮件传送协议服务器的连接。
HELO()：执行连接之后建立与简单邮件传送协议服务器初始的收发关系功能，它能识别发送到服务器的“信使”。
MAIL()：初始化与服务器的邮件交换，但是事实上不发送消息。
RCPT()：识别消息的接受者。为了把一条消息发送到多个接受者，你必须多次调用这个过程。
DATA()：指定电子邮件的内容。
QUIT()：终止一个SMTP会话并且断开与服务器的连接。
为了利用应用程序编程接口，把下面的调用按照给定的顺序放入程序中：
调用 OPEN_CONNECTION
调用 HELO
调用 MAIL
调用 RCPT for each recipient
格式化电子邮件的内容然后调用MAIL
调用 QUIT
EmailUtils包规范
EmailUtils包包括下列API：
SetSender/GetSender-设置/取得发送者
SetRecipient/GetRecipient -设置/取得接受者
SetCcrecipient/GetCcrecipient -设置/取得抄件接受者
SetMailHost/GetMailHost -设置/取得邮件主机
SetSubject/GetSubject -设置/取得主题
Send-发送邮件
代码1说明了EmailUtils包的规范：
create or replace package EmailUtils as
procedure SetSender(pSender in varchar2);
function GetSender
return varchar2;
procedure SetRecipient(pRecipient in varchar2);
function GetRecipient
return varchar2;
procedure SetCcRecipient(pCcRecipient in varchar2);
function GetCcRecipient
return varchar2;
procedure SetMailHost(pMailHost in varchar2);
function GetMailHost
return varchar2;
procedure SetSubject(pSubject in varchar2);
function GetSubject
return varchar2;
procedure Send(pMessage in varchar2);
procedure Send(pSender in varchar2,
pRecipient in varchar2,
pMailHost in varchar2,
pCcRecipient in varchar2 := null,
pSubject in varchar2 := null,
pMessage in varchar2 := null);
end EmailUtils;
可以看出，Send过程是重载过程：包规范中包括这个过程的两个版本。一个版本当至少三个强制性参数要规定的时候引用，pSender，pRecipient和pMailHost：
procedure Send(pSender in varchar2,
pRecipient in varchar2,
pMailHost in varchar2,
pCcRecipient in varchar2 := null,
pSubject in varchar2 := null,
pMessage in varchar2 := null);
另一个版本只有当提供pMessage参数值时执行：
procedure Send(pMessage in varchar2);
第二个版本是用作调试的版本。所有的电子邮件消息共用同样的发送者、接受者、邮件主机、抄送接受者和主题信息，这些都是我在会话的开始的时候设置好的。下面是一个PL/SQL程序块的例子：
begin
EmailUtils.SetSender('WayneZ@MyCompany.com');
EmailUtils.SetRecipient('waynezheng@vip.sina.com');
EmailUtils.SetCcRecipient('WayneZ@MyCompany.com');
EmailUtils.SetMailHost('MyServer.MyCompany.com');
EmailUtils.SetSubject('DeleteClassifications procedure: Run 1');
end;
/
一个实际的电子邮件消息将在每个Send过程调用中被指定。我们可以把所用的EmailUtils.Send()调用插入到我们调试的代码中，我们以前为了得到同样的调试结果使用的是DBMS_OUTPUT.PUT_LINE()调用。:
vMessage := 'Point 1.' || utl_tcp.crlf ||
'Rows processed: ' || to_char(vRows) || utl_tcp.crlf ||
'Elapsed time: ' || vTime;
EmailUtils.Send(vMessage);
vMessage := 'Point 3.' || utl_tcp.crlf ||
'Rows processed: ' || to_char(vRows) || utl_tcp.crlf ||
'Elapsed time: ' || vTime;
EmailUtils.Send(vMessage);
代码2显示带有重载Send过程的EmailUtils规格。 我们可以看到，Send过程的代码相当简单。 UTL_SMTP包不提供用于格式化消息内容的应用编程接口。 而是由用户负责格式化消息。这就是为什么下列程序块要被包含到每个Send过程中以便格式化电子邮件的头部。
vMessage := 'Date: ' ||
to_char(sysdate, 'fmDy, DD Mon YYYY fxHH24:MI:SS') ||
utl_tcp.crlf ||
'From: ' || pSender || utl_tcp.crlf ||
'Subject: ' || pSubject || utl_tcp.crlf ||
'To: ' || pRecipient || utl_tcp.crlf;
同时,如果消息长度超过2000字符的话，你可能得到一个错误( ORA - 06502 : PL/SQL : numeric or value error)。 所以为了避免出现这个错误，我们使用下面的程序块,不允许消息超过2000个字符：
if length(vMessage) > 2000
then
vMessage := substr(vMessage, 1, 2000);
end if;
如果需要发送带有超过2000字的电子邮件，那么可以使用另三个UTL_SMTP应用程序编程接口，提供比DATA()过程更加精细的控制。首先, OPEN_DATA()发送数据命令。 然后WRITE_DATA()添加数据到你要发送的字符串中。你可以调用WRITE_DATA()任意多次，这样你就可以一次写2000个字符以克服字数的限制。 最后, CLOSE_DATA()通过发送一个封装在CRLF中的终止周期结束电子邮件消息。
实时消息使你的生活更加舒适
从数据库发送电子邮件就是那么容易。一旦你试用这个简单的操作，我相信你会发现它很有用，便于你的数据库操作,例如调试、远程的数据库监控和输出数据库数据。
每个数据库开发者都有在代码中使用大量的DBMS_OUTPUT调用的调试经历。 在开始一个SQL * Plus会话之后,输入SET SERVEROUTPUT ON然后运行这个过程。放进DBMS_OUTPUT.PUT_LINE调用的消息显示在屏幕上--但是只有在过程完成以后才能显示出来。这个过程极端地麻烦，尤其在调试长的批处理时通常是要运行整晚。你可以等待10到12小时仅仅是为了查出错误的代码，然后修改，再去等待下一个10到12个小时？然而，如果你有访问消息的实时的办法，那么你可以在头5到10分钟内捕捉到问题。
DBMS_OUTPUT包也有其他的缺点。例如,它不接受可变的布尔类型以及它有255字符每行的限制（如果你想输出一个长的消息的话，那么你会得到这个异常：ORA - 20000 : ORU - 10028 : line length overflow, limit of 255 bytes per line）。把它的缺点全部列出这已经超出本文的范围了，但是重要结论就是DBMS_OUTPUT包不许数据库开发者实时的看到消息。
谈到服务器上的OS文件，你会不会喜欢把选定的数据从服务器中输出到一个Excel电子表格呢？一个办法就是使用Oracle的UTL_FILE包,它提供了一个标准OS流文档输入/输出的限制级版本。 然而, PL/SQL程序只能访问在初始化文件INIT.ORA的UTL_FILE_DIR参数规定的目录。这个参数大多数情况下是空的。为了使这个目录可用来进行文件访问，必须请数据库管理者修改初始化文件。这有些麻烦。使用EmailUtils包,你可以简简单单的把数据写入一个电子邮件中，发送给自己，然后收到它的副本粘贴到自己喜欢的文档编辑器中。
http://blog.sina.com.cn/s/blog_59c1c5140100aj1y.html
xuejinyoulan收录，使用标签：数据库，时间：2008-8-4 10:47:32 | 相关网摘，我也收藏
来源：博文视点官方博客
性能调校的工作千头万绪，最怕的就是像无头苍蝇般盲目地错误尝试（trial and error），不但旷日费时，还累积不到经验，团队与个人都难以成长，也就是说下次再碰到性能议题时，还是乱试一通。
我们需要拟定计划、有步骤分阶段地执行，如此才能循序渐进，一步步朝目标前进。据微软的研究显示，过程应该分为6个阶段，分别是发现、探究、提案、执行、复查、收尾。这不一定适用于任何调校的情境，笔者从来也没有完全这么做，但却是个可供参考的方法论，能据以修正成自己的方法。有固定的准则后，才可以累积经验并加以分门别类。
现将各步骤的原文列出如下：
Discover the problem：发现问题。
Explore the conditions：探究原因，为问题提供明确的定义与定位。
Track down possible approaches：提供可能的解决方案。
Execute the most likely approach：执行最有可能的解决方案。
Check for success（如果需要的话，重复之前的步骤）：确认解决方案成功与否。
Tie up loose ends：完成收尾的工作。
1.3.1
各阶段重点说明
以下对各阶段稍做说明。
1.3.1.1 发现问题
这可能是支持性能调校的专家们花时间最少的一个阶段，因为大部分的工作都是用户在做，他们可能已经有一大堆的观察经验，而找你来，不会期望你完全重做一遍他们已经做过多次的事情，而是希望看到你马上采取一些行动，并一针见效。
这个阶段专业与否就看你是否可以立刻找到重点，把握住各个细节，而不是在整个调校的各个程序中，来来回回、反反复复询问相同的问题。这个阶段最重要的就是发现（Discover）问题、详述（Describe）问题，并且正确而详细地记录下来（Document）。在进入下一步骤前，你应该问问自己以下这些问题。
对于问题是否已经有简明的描述
若无法简明地描述问题，代表你尚不了解问题，或者没抓到重点。这是很有可能的，因为用户常拉拉杂杂地说了一大堆，让你晕头转向，只好急着做点东西，不见得是有方向，只是想摆脱用户像倾倒垃圾一样，噼里啪啦地描述现象时，还夹缠着抱怨与谩骂，大家一拥而上，对你一股脑儿地说个不停。信息虽然多，但零零碎碎看不到全貌。
你可以尝试将自己听到的，重新有序地整理一遍再诉说给用户听，看看是否符合大家共通的观点，若没有异议，就有了一个大致正确的开始。
用户的基线与期待在哪
在前面一节中强调了基线的重要，这让你可以比较成果，并有前进的目标。例如，当用户抱怨“SQL Server 跑得太慢了”，这时要理清他们的“慢”是怎么定义的，而什么是合理可接受的速度。若没有基线，则需要你为他们建立。
性能调校可能是一再循环的过程，除了时间难以掌握外，还不一定所有的问题都有解。不要让用户有错误或过高的期待，从而能减少承担不可能完成任务的压力，更可减少长时间调校后，达不到用户期望而招致的愤怒。
在查找的过程中尽量不要急躁或恐慌，贸然进入到下一个步骤，只会让你再一次回到原点，重新定义问题。
1.3.1.2 探究原因，为问题提供明确的定义与定位
确定用户的问题与需求后，下一步是探究原因，此步骤的重点是“探索（Explore）”、“找寻证据（Evidence）”、“建立（Establish）”描述整个问题来龙去脉的假设。
当你从以上步骤确切了解用户的问题后，就需要建立问题发生原因的假设和导致性能不足的运行模型，而当前这个步骤便是在搜集证据，以建立并确认该假设。在这个阶段中，你可以通过SQL Server Management Studio、SqlDiag.exe、性能计数器、事件查看器、SQL Profiler、SQL Server 2005 Performance Dashbord Reports、DMV与DMF等工具来找线索（以上工具在本书第3章“性能调校相关工具程序”中有详细说明）。
这个步骤的主要任务是广泛搜集相关数据，但并未深入分析数据间的关联性，这是下一步骤要做的事情。当然，要搜集正确而相关的证据，难免要稍做分析，但不要过度耗时在某项单一的事件上。此步骤要的是全貌，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键现象而误入歧途。
当然，若在这个阶段就发现重大问题，一眼就看出关键点，例如，硬件毁损，某个硬盘区间或内存区间不稳，某个程序吃掉所有的内存，让SQL Server无内存可用，抑或是该程序常常出问题，拖垮CPU等，则可以跳过DETECT方法论之后的步骤，进行深入探讨这个问题并予以解决。
通常性能调校并不是那么容易一眼看出重大错误，或许用户自己就可以解决，而需要专门做性能调校的情况可能如战场上不断带来的伤患，第一步要做的是决定伤患的轻重，再决定如何利用有限的资源做最有效的治疗。当你在前一步获得用户大量的问题后，接下来就要搜集并探究各种现象，决定轻重缓急，通盘考虑后，进入下一步。
1.3.1.3 提供可能的解决方案
在深入分析前述两步骤搜集到的数据，并对整个问题的前因后果提出假设，进而拟出对应策略，如果前一个步骤做得不够详实，就可能误判，导致努力了半天，但没有碰到瓶颈点。
在拟定策略时，应当参考大量的在线说明、Knowledge Base，在网络上广泛查找资料，看看前人或是微软对于你所面对的问题是否有好的方案。到相关网站讨论区提出问题，或是询问技术顾问，最好不要闭门造车，防止解决问题时又出现新问题。
这个步骤最重要的是拟定计划，而这又可分为两个部分：用来证明对问题所建立的假设的计划，以及解决问题的计划。前文一再强调，性能调校可能是个一再循环的过程，有一个好的计划，你才能知道方向与步骤。
不要冲动地进入到下一步骤，信息界有句名言：“最早开始的，最晚结束”。言下之意就是凡事要谋定而后动，若匆忙进入到下一步执行解决方案，可能因为疏失而导致更多的错误，甚至因为你的操作让系统更为不稳定，原本性能不佳的系统宕掉了，这时会招致用户更大的不满。
1.3.1.4 执行最有可能的解决方案
这可能是DETECT 方法中最简单的一步，因为只要执行上一步中所拟定的计划即可。但是在执行计划时，仍然要注意系统的反应，随时都可能会要放弃当前的计划，因为新的证据可能证明先前的判断是错误的，因而要修正计划，甚至是退回到重新拟定计划。
随时反省，不要急着操作。每一步愈稳也就愈少反复，因此，现在的时间花费可以节省未来的时间（Spend time now to save time later）。整个性能调校的过程就是在考验团队的细心与耐力、知识的广度与深度，切勿急躁。
在这一部分执行的计划也有二个，分别是上一步拟定的：其一是对问题的假设，验证某些行为导致性能不足的计划；其二是解决问题的计划。先证明假设成立，再执行解决该问题的方案。若假设错误，当然就不需要执行解决方案。否则努力地重载了程序、变更了数据库架构、买了新的硬件等，却是验证了瓶颈点不在此，结果就尴尬了。
同时要小心观察你的计划会不会导致新的问题，并严重影响当前系统的执行，不要原来是系统迟缓，而你的测试却成了压垮骆驼的最后一根稻草。
1.3.1.5 确认解决方案成功与否
执行计划后，需要重新收集数据，以验证该计划成功与否。这一步骤又分两个阶段，第一阶段是确认计划是否证实了假设，若证实假设是对的，则需要继续搜集相关的数据，以确立接下来的步骤。
第二阶段是分析已收集到的数据，看看是否解决了优先级最高的瓶颈，若已解决，应有瓶颈转移的现象，此时要针对次要瓶颈开始拟定新的计划，并确定是否已经符合用户的目标。
如果执行结果不如预期，证明假设错误，会非常让人气馁。
其实，定错性能调校的目标是常有的事，这时就是要你在错误的面前，停下来好好思考，不要立刻行动。查看先前步骤的各项产出，重新理出头绪，最重要的是清楚知道这一回的错误在哪，如此新的步骤就会更逼近目标。犯错是常有的事，踩着错误走向成功是性能调校的常态。现在，你可以休息一下，喝杯咖啡，和合作伙伴放轻松，回顾一下这个过程，对整个问题建立更清晰的轮廓。
1.3.1.6 完成收尾的工作
前5个步骤循环重复地执行，每一次循环的结果都更逼近问题的核心，直到达到性能调校的目标。
但当我们完成目标后，依然要注意以下的问题。
解决的方式是否有边际效应而造成其他的问题？
例如，为了某类的查询工作建立了大量的索引，事后原本正常的添加、修改、删除都出现了性能问题。
是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚？
建立问题的假设时，很容易将问题特殊化，仅局部地解决该问题。例如，加了某个索引或稍稍改变查询语句，舒缓了当前的瓶颈，但当用户稍微增加或采用不同的查询方式时，老问题就容易复发。
是否要建立持续跟踪的计划？
当你无法确定已经根除问题时，那可能就要拟定持续跟踪的计划了。决定是否要持续观察某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等。如此不但可以让用户安心，更可以让你知道之前的行为到底有多少效益，下次的性能调校才能提出更完整的解决方案。
http://blog.csdn.net/bvbook/archive/2008/07/30/2738306.aspx
xuejinyoulan收录，使用标签：数据库，时间：2008-7-30 11:16:44 | 相关网摘，我也收藏
出处:博客园
作为微软新一代企业级应用平台旗舰产品之一的SQL Server 2005，有太多的精彩值得我们关注。而SOA(面向服务的架构)，对于新一代面向同步和异步应用的、基于以因特网平台为主的请求/响应模式的分布式计算来说，无疑是一场革命。数据库，作为基于面向服务的数据库架构(SODA)构建分布式架构的一个战略组成部分之一，举足轻重。本系列文章中，我们将试图剖析SODA背后的相关概念，并进而观察微软如何以其力图“撼动未来”的SQL Server 2005适应这种新型架构。
一、SOA架构的出现
当我们把上世纪九十年代占主流的客户机-服务器和N层应用程序架构用于开发今天大规模的因特网电子商务站点时，这些方案遇到了严重的问题—可伸缩性和可用性。其中一个主要的问题就是，数据越来越倾向于存储在一个大规模、高度集中的数据库中，而且所有客户端组件都可以对之实现直接访问。此时，几乎所有与这些数据库相关的通信都是以SQL语句(或存在于一个存储过程中的批语句)形式执行的;于是，客户端将接收到一个特定于要解决的任务的数据集合。
而今，当我们试图把“遗留”系统加入到较新的应用程序中时，又遇到了其它的问题。在经过多年来使用各种专利性技术和平台发布大范围的系统后，整个世界可谓“遍布”这种能够较好地实现“自身”工作的系统;但是，这些系统却往往缺乏清晰的思路来实现与其它应用程序的交互—悉知，如今的连接环境正变得越来越方便。因此，实现今天的应用程序所要求的灵活性已经变得相当困难。B2B(业务到业务)应用甚至于使得事情进一步复杂化，因为这要求必须满足特定的标准并使用可靠的方法来实现业务传输的电子化。非常明显，满足今天全球业务环境需要的不断演变的系统都要求实现某种新架构，这种架构必须能够高效地使用“遗留”系统并能提供一个灵活的商业基础框架。
为了满足这些需要，最近三到五年间已经出现了一种“新的”大规模、松耦合、分布式的系统架构，特别是作为因特网电子商务站点已经成长为其主要的商业运作模式。面向服务的架构(SOA)已经开始作为主流的松耦合、以服务为中心的架构出现。事实证明，基于SOA的应用程序更能经得起失败，并且更为容易地按比例调整规模—通过使用多种方法添加必要的资源来满足不断发展的要求;而且，它们也允许把“遗留”系统轻松地集成到现有B2B及其它系统中。
二、 面向服务架构对数据的要求
在一个SOA应用程序中，SOA服务提供者、服务消费者及其它组件都会将数据处理作为其自身角色的一个“自然”的特征。典型情况下，一个SOA应用程序仍然使用中央数据库来存储和保护数据;但是，也有可能使用许多这种大型的数据库来存储各类数据—例如单独存储的销售、生产和操作数据以及每一部分中的特定数据子集等。每个服务提供者和消费者都可能需要对数据或其自己特定的数据存储进行本地缓冲。此外，跨越应用程序的远距离部分传输的消息本身常常就是一些值得加以存档而备以后使用的数据。
根据数据在系统中的特征，我们可以按下列四种方式对之进行划分：
①引用数据—用于创建服务请求(例如一个产品目录)。它必须是以一种为所有部分可用的格式存在，而且以一种恒定不变的方式(例如一个目录日期)加以标识。
②活动数据—是短暂的数据，用于执行一个特定的活动，例如一个产品列表(用于从库存中检索购买项)。既然它是私有于服务的，所以该格式不需要被其它模块所理解。
③资源数据—是一种长期存在的数据。这种数据为一个服务(例如顾客数据和帐户数据)内部使用。
④服务交互数据—用于服务间的通讯。这必须是以一种为所有部分都能理解的格式进行，并且必须长期保持不变。例如，在服务之间以一个订单表单形式进行通讯。如果该订单被丢失，那么它必须能够被以与以前相同的形式重新生成并且被再次转换。
下图1展示了一些可能构成一个松耦合的应用程序(基于SOA原则进行构建)的端点。其中的服务消费者可能代表一个客户端应用程序;而一个服务器应用程序(例如一个Web服务器)，或者是任何其它类型的应用程序，将把消息发送给一个服务提供者。在复杂的系统中，可能通过一个消息路由器最初接收消息，然后应用特定的逻辑把该请求路由到适当的服务提供者。然后，该服务提供者接收此消息并加以处理—解包并重新格式化它，执行任何要求实现的工作，最后可能把一个响应发送回服务消费者。
图1.一个面向服务构架应用程序局部示意图。
上图1中向我们提供了一个重要的细节—事务中的每一个结点都在以各种形式接收、存储和传输数据。有时这些数据是“短暂”的，而有时每个结点可能会把数据存储到一个缓存或其自己的本地数据库中。
基于在一个应用程序中的这些新的数据处理方式，如今，处于SOA应用程序核心位置的数据库面临着一些与以往N层应用程序不同的挑战。但是，数据一致性仍然同以往一样重要;不过，现在又出现了其它的要求：
1.数据库操作处于一种新的环境—数据请求经由基于XML的消息而不是通过专用连接方式进行;
2.缓冲数据仓库部分需要了解何时刷新数据更为有效，而不是根据某个固定时间表实现刷新;
3.数据库不得不参与以一种固定顺序发生的“对话”;
4. 存在复杂的逻辑必须宿主在数据库中(或宿主在这些数据库附近)。
今天，XML成为一种应用于新一代分布式系统的良好的消息格式。这种格式能够为几乎任何系统容易地分析并通过某种模式建模语言来定义这些数据的适当结构。于是，交换消息的系统可以把信息依附到一条XML消息中;结果，当这些消息“流经”系统时，数据将“汇集”于消息中。系统只需分析和处理它们能够理解的部分而忽略掉其它内容。简言之，设计XML的目的是为了作为一种灵活的格式来支持分布式系统。
微软的架构师们正是看到了这种结构化趋势，及时地推出了新一代SQL Server 2005以满足这种新的挑战;而同时，SQL Server 2005仍能继续支持许多现有的非SOA应用程序。本文中，我们将全面探讨如何在一个使用SQL Server 2005的SOA应用程序中应用本地Web服务存取，数据库改变通知，Service Broker以及SQLXML等技术。
【阅读提示】本文将略去介绍SOA的基本知识，同时也没有概括SQL Server 2005所有新的特征，而是假定你已经熟悉这些内容。
三、 SQL SERVER 2005适应SOA数据要求
随着我们对SOA概念的不断深入，有一个问题越来越明晰：组成整个系统的每一个组件都会把接收、处理与传送数据作为自身的主要功能之一。即使一个服务提供者对于一条发送自某个服务消费者的消息的响应只是简单地进行“位”设置(置为“on”或“off”)而根本不必与一个数据库交互，此提供者也必须处理该消息中的数据以便确定相应的任务。事实上，现代商业应用程序通常会广泛地与数据打交道;所以，对于一个SOA组件来说，常常会存取一个本地的或集中的数据库，或经常二者兼有。
SQL Server 2005提供了一组新的特征来进一步方便集成化结构化设计—支持把数据库作为一个SOA服务提供者使用。微软SQL Server 开发小组称这组新的特征为“面向服务的数据库架构”(或简称为“SODA”)。
直接在数据库引擎中实现SOA特征存在如下重要理由：
调整系统规模。即使在最大的企业SOA应用程序中，单个服务也可能按几乎任何规模被实例化;一个使用不太频繁的服务有可能具有比一个典型的小型部门数据库更少的活动。与SQL SERVER集成到一起意味着，一个服务程序可以利用所有的本地支持来适应从嵌入式设备到最为丰富的企业数据库服务器，而不必改进管理复杂性。服务逻辑代码可以在任何规模下执行，而任何实现都可以在发布时刻被调整到一个单独的中间层中。借助于SQL SERVER 2005，服务逻辑可以在数据层上运行或者被发布到中间层中。如果你仔细地设计一个应用程序，那么你会注意到，如何调整的问题将会是一种发布决策而不是一项设计或开发时刻决策。
按比例调整。你可以通过许多方式来按比例调整以数据中心的计算，通常以按比例调整数据库或通过使用面向服务的架构的方式来分布这些处理。按比例调整数据库将会导致一个数据库簇—而它是紧耦合的;而相比之下，面向服务的方案导致更为松弛的耦合度。直接通过数据库支持SOA的构建有助于减少在一个真正的网格方案中的组件处理问题。
消息作为数据。各种请求和响应消息都成为一些“有趣”的数据—把它们存档到一个数据库中可能有重大价值。保持这些消息长时间可用则为我们提供了一种历史数据，从而便利了以后的审计和事务分析。因为消息存储在表格中并且有系统目录视图可用，所以你可以很容易地使用Transact-SQL来观察任何系统部分的状态。
在SQL SERVER中实现SOA特征存在大量的优点。也只有这样，它才有理由充当一个SOA应用程序中的一个独立的服务提供者。为此，它必须能够实现类似一个服务提供者的行为。
对于SQL Server 2005(或任何数据库引擎)来说，要承担起作为一个独立的SOA服务程序的角色，它必须实现若干超出其本地数据处理能力的特征：
端点(End Point)支持。SODA提供者必须提供通信支持以接收和传输消息。典型情况下，这可以通过一个TCP套接字，HTTP GET或PUT，SOAP端点，或其它类型的端点实现。
过程服务请求。大多数SOA消息要使用XML方式加以格式化;因此，服务提供者必须能够处理并且可能要把打包的数据转换成其它形式以满足组成服务的组件的需要。它还必须能够参与复杂的对话和会话—而它们将作为相互依赖的消息由其它组件接收或发送到这些组件。
服务逻辑宿主。提供者必须能够执行要求的任何复杂程度的逻辑来处理消息并提供必要的响应，而且还可以协调若干其它服务的输入;而这可能要求普通的应用程序服务器任务，例如对资源进行“池”存储，激活，以及按规模调整处理逻辑。
SQL SERVER 2005中的各种新特征为这些功能提供了支持;此外，还提供了其它基础性结构来支持数据管理。例如，一个服务提供者必须安全地加入到一个SOA系统中，并且能够对客户端实现认证，而且提供凭证来实现对其它实体的认证，提供持久性，参与会话和事务及其它应用程序级特征。
SQL Server 2005建立在SQL Server 2000关系数据库引擎特征之上，以及自从它的最初发行版本以来所开发的新技术(例如SQLXML 3.0，通知服务以及其它工具)，从而全面实现了面向服务的数据库架构。
四、小结
本篇中，我们仅粗略地分析了SOA出现的缘由及其对数据存储的新要求，并进而简要概括了SQL Server 2005对这种新式数据要求所提供的支持。在下篇中，我们将展开SQL Server 2005对SOA架构支持的全面探讨。
http://database.ctocio.com.cn/analysis/53/8236553.shtml
xuejinyoulan收录，使用标签：数据库，时间：2008-7-30 11:13:01 | 相关网摘，我也收藏
出处:blog
SQL SERVER 2005提供的对存储过程签名(signature)功能是我最喜欢的。
如果我们要编写一个存储过程,执行该存储过程里的代码需要权限P,并且我们想要用户Alice可以执行这个存储过程，但是我们不想将权限P直接赋予给用户Alice， 我们可以用证书(certificate)对这个存储过程进行签名来完成这一需求：
a) 如果P是一个数据库级别的权限，那我们可以在相应的数据库中创建一个证书，使用证书创建一个用户(user)，然后将权限p授权给这个用户
b) 如果P是一个服务器级别的权限，那我们能要在master数据库中创建一个证书，使用证书创建一个登录(login)，然后将权限P授权给这个登录
签名之后，存储过程就会在执行期间获得权限P，而我们仅仅授予了Alice执行这个存储过程的权限。
如果我们既需要服务器级别的权限，又需要数据库级别的权限，那么我们既要创建用户，又要创建登录。下面列出步骤：
1) 在数据库中创建证书
2) 创建一个用户(user)并映射到这个证书
3) 将数据库级别的权限授予这个用户
4) 备份这个证书
5) 在master数据库中还原这个证书
6) 创建一个登录(login)，并将登录映射到证书
7) 将服务器级别的权限授予给这个登录
我们也可以先在master数据库中创建证书，然后再将其还原到用户alice工作的数据库。也就是证书的创建顺序并不重要，重要的是master数据库中的证书一定要和用户数据库中的相同。
下面是演示：
-- 目的
-- 展示如何用证书签名一个存储过程,
--并授予证书相应的权限
create database demo;
use demo;
com/Images/OutliningIndicators/None.gif" width=11 align=top>-- 创建一个存储过程，该过程会创建一个主体(包含登录和用户)
-- 这需要服务器级别的ALTER ANY LOGIN 权限
-- 和数据库级别的 ALTER ANY USER 权限
create procedure sp_CreatePrincipal
@name varchar(256),
@password varchar(128)
as
declare @sqlcmd varchar(2000);
begin tran;
-- create login
set @sqlcmd = 'create login ' + quotename(@name) + ' with password = ' + quotename(@password, '''');
exec (@sqlcmd);
if @@error <> 0
begin
rollback tran;
print 'Cannot create login'
return;
end
-- create user
set @sqlcmd = 'create user ' + quotename(@name);
exec (@sqlcmd);
if @@error <> 0
begin
rollback tran;
print 'Cannot create user'
return;
end
commit tran;
go
-- 调用这个存储过程
-- 创建主体
sp_CreatePrincipal 'alice', 'Apufe@))%';
--我们需要让alice可以调用这个存储过程，创建新的主体，
-- 但并不直接授予她权限(创建主体的权限，译者注)
grant execute on sp_CreatePrincipal to alice;
-- 目前 alice还不能创建主体
execute as login = 'alice';
sp_CreatePrincipal 'bob', 'Apufe@))%';
revert;
-- 使用证书对存储过程进行签名
-- 首先我们要创建一个数据库主密钥(database master key)
create master key encryption by password = 'Apufe@))%'; create certificate certSignCreatePrincipal with subject = 'for signing procedure sp_CreatePrincipal';
-- 签名存储过程sp_CreatePrincipal
add signature to sp_CreatePrincipal by certificate certSignCreatePrincipal;
-- 现在签名完成了，可以将证书的私钥移除了
alter certificate certSignCreatePrincipal remove private key;
-- 对证书进行备份，随后在master数据库中将要使用该备份
backup certificate certSignCreatePrincipal to file = 'certSignCreatePrincipal.cer';
-- 创建一个用户并将用户映射到证书
create user u_certSignCreatePrincipal from certificate certSignCreatePrincipal;
--通过授权映射映射的方式将ALTER ANY USER权限赋给证书 (因为用户和证书是映射的，所以权限也就赋给了证书，SQLSERVER本身没有直接将权限赋给证书的方法。译者注)
grant alter any user to u_certSignCreatePrincipal;
-- 在master数据库中创建该证书
use master; create certificate certSignCreatePrincipal from file = 'certSignCreatePrincipal.cer';
-- 创建登录并映射到证书
create login l_certSignCreatePrincipal from certificate certSignCreatePrincipal;
-- 通过授权映射登录的方式将ALTER ANY LOGIN权限赋给证书
grant alter any login to l_certSignCreatePrincipal;
-- 完成!
use demo;
-- 验证一下，master数据库中的证书和demo数据库中的证书是一样的。
select c.name from sys.certificates c, master.sys.certificates mc where c.thumbprint = mc.thumbprint;
-- 现在alice可以创建主体了
execute as login = 'alice';
sp_CreatePrincipal 'bob', 'Apufe@))%';
revert;
-- cleanup
drop user u_certSignCreatePrincipal;
drop login l_certSignCreatePrincipal;
drop procedure sp_CreatePrincipal;
drop certificate certSignCreatePrincipal;
drop user alice;
drop login alice;
drop user bob;
drop login bob;
use master;
drop certificate certSignCreatePrincipal;
drop database demo;
-- EOD
http://database.ctocio.com.cn/tips/254/8238754.shtml
xuejinyoulan收录，使用标签：数据库，时间：2008-7-30 11:02:14 | 相关网摘，我也收藏
出处:IT专家网
尽管存储的成本已经很低了，但是我们仍然需要考虑使用多种技术(例如压缩和存档)来节省空间。当你思考怎样节省空间时，你第一个想到的是文件系统，但是空间节省也可以用在数据库。当我们创建一个数据库时，我们确保数据文件具有合适的大小和增长速度。我们定期分析我们的数据库规模并执行缩小操作。我们可能执行这些任务用于不同的目的，但是有一个方面是相同的，这些任务帮助我们确保我们的数据库具有最佳的存储。Microsoft SQL Server为我们提供了用于降低数据库所用空间的各种技术。SQL Server 2008推出了一个用于定位可为空字段的技术，它为可为空字段提供了最佳的存储。在SQL Server 2008中的这个新特性就是稀疏列。这篇文章不会讲述很多关于稀疏列的特性，它介绍了具有列集的稀疏列的使用，以及在使用它们时你需要了解和考虑的事情。
这篇文章描述：
什么是稀疏列?
什么是列集?
在一个列集中插入和更新数据。
使用触发器跟踪变更。
对列集实施安全。
什么是稀疏列?
稀疏列是一个普通字段，就像其它字段一样，但是它降低了对空值的存储要求。一个可为空字段可以在表创建或修改时添加SPARSE关键字来成为稀疏列。如果一个列是稀疏列，那么SQL Server不会为空值分配空间。注意，在使用这个特性时它会增加对非空值数据提取的花费。因此你需要计算可以节省的空间来仔细地对字段应用这个特性。推荐只在空间至少可以节省20%至40%时使字段成为稀疏列。BLO提供了一个包含字段中每个数据类型所需空值百分比的表，以便使这些字段成为稀疏列。
什么是列集?
列集是一个显示所有稀疏列的字段，它作为一个XML类型的字段添加到表中。它不是物理上存在于这个表中的，它只像是一个计算出来的字段，但是它允许你对它进行修改。推荐你只在有很多稀疏列时使用列集，因为如果使用了列集而不是使用各个稀疏列，那么它会加快修改和提取。
下面的代码显示了为一个表创建一个列集的方法。
代码1：创建一个具有稀疏列和一个列集的表。
CREATE TABLE [dbo].[Customers]
(
[Id] int PRIMARY KEY,
[FirstName] varchar(50) NOT NULL,
[LastName] varchar(50) NOT NULL,
[Gender] bit SPARSE NULL, -- 1 = male, 2 = female
[Telephone] varchar(15) SPARSE NULL,
[MonthlyIncome] money SPARSE NULL,
[Comments] varchar(1000) SPARSE NULL
[AllSparseColumns] xml COLUMN_SET FOR ALL_SPARSE_COLUMNS
我为所有可为空字段添加了SPARSE关键字，但是如同我前面提到的，应该在使它们成为稀疏列之前分析空值所占百分比。注意，当你创建这个表时你需要添加这个字段。SQL Server 不允许你没有稀疏列的情况下拥有列集字段。之后添加为稀疏列的字段可以使用添加的列集，看下面的代码：
代码2：创建具有一个列集的表，不使任何字段成为稀疏列。
-- adding column set without sparse columns
CREATE TABLE [dbo].[Customers_1]
(
[Id] int PRIMARY KEY,
[FirstName] varchar(50) NOT NULL,
[LastName] varchar(50) NOT NULL,
[Gender] bit NULL, -- 1 = male, 2 = female
[Telephone] varchar(15) NULL,
[MonthlyIncome] money NULL,
[Comments] varchar(1000) NULL,
[AllSparseColumns] xml COLUMN_SET FOR ALL_SPARSE_COLUMNS
)
-- inserting a record
INSERT INTO dbo.Customers_1
([Id], [FirstName], [LastName], [Gender], [Telephone], [MonthlyIncome], [Comments])
VALUES
(1, 'Dinesh', 'Priyankara', 1, '777395871', 20000, 'no comments')
-- this returns null
SELECT AllSparseColumns FROM dbo.Customers_1
-- Make the Gender column as a sparse column
ALTER TABLE [dbo].[Customers_1]
ALTER COLUMN [Gender] bit SPARSE NULL
GO
-- Make the Telephone column as a sparse column
ALTER TABLE [dbo].[Customers_1]
ALTER COLUMN [Telephone] varchar(15) SPARSE NULL
-- Now it returns values of sparse columns as a xml
SELECT AllSparseColumns FROM dbo.Customers_1
在一个列集中插入和更新数据
可以对稀疏列插入记录而不使用列集，但是一旦插入了，那么记录就可以使用列集来获得。
代码1：对列集插入一个记录而不插入任何值。
-- Insert a record to the table.
INSERT INTO dbo.Customers
([Id], [FirstName], [LastName], [Gender], [Telephone], [MonthlyIncome], [Comments])
VALUES
(1, 'Dinesh', 'Priyankara', 1, '777395871', 20000, 'no comments')
-- Retrieve the record and see
SELECT [Id], [FirstName], [LastName], [Gender], [Telephone], [MonthlyIncome], [Comments], [AllSparseColumns] FROM dbo.Customers
/*
Result:
177739587120000.0000no comments
*/
可以使用这个列集来插入和更新记录。代码2显示了通过列集来插入一个记录和更新一个记录的方法。
代码2：插入和更新这个列集。
-- Inserting a new record. Note that the statement uses the column set to
-- insert values for Comments and Telephone columns
INSERT INTO dbo.Customers
([Id], [FirstName], [LastName], [AllSparseColumns])
VALUES
(3, 'Yeshan', 'Santhush', 'No comments777225656')
-- Update the record.
-- This makes Comments column NULL because xml string does not contain a node for Comments column.
-- This updates the Telephone column with the new value.
UPDATE dbo.Customers
SET [AllSparseColumns] = '7774546321'
WHERE Id = 3
使用触发器跟踪变更
这是一个小技巧。一般我们使用UPDATE()函数来查看一个特定列是否更新了。如果你在一个与具有稀疏列和列集的表所关联的触发器中执行了它，那么UPDATE()函数返回的值不会是你所预期的。下面的代码测试了这一点。
代码1：对Customers表创建一个UPDATE触发器。
-- Creating a update trigger on Customers table.
CREATE TRIGGER tr_Customers_Update ON dbo.Customers
FOR UPDATE
AS
BEGIN
IF UPDATE(Gender)
print 'Gender column updated.'
IF UPDATE(Telephone)
print 'Telephone column updated.'
IF UPDATE(Comments)
print 'Comments column updated.'
IF UPDATE(AllSparseColumns)
print 'AllSparseColumns column updated.'
END
当你显式更新列集时，UPDATE()函数对这个列集返回true。不只这样，写给所有稀疏列的UPDATE()函数都返回true。当一个稀疏列被显式更新时，UPDATE()函数对稀疏列和列集返回true。
代码2：在触发器中更新这个表，并测试UPDATE()函数。
-- Update the column set.
-- This update makes all UPDATE() functions
-- to return true.
UPDATE dbo.Customers
SET [AllSparseColumns] = '4455'
WHERE Id = 3
/*
Result:
Gender column updated.
Telephone column updated.
Comments column updated.
AllSparseColumns column updated.
(1 row(s) affected)
*/
-- Update the Gender column.
-- This update makes UPDATE() function of
-- Gender column and column set to return true.
UPDATE dbo.Customers
SET Gender = 1
WHERE Id = 3
/*
Result:
Gender column updated.
AllSparseColumns column updated.
(1 row(s) affected)
*/
如果你为INSERT 语句写了相同的触发器，那么你将看到INSERT操作出现相同的行为。当对一个稀疏列插入一个值并且你使得其它为NULL时，UPDATE()函数对稀疏列和列集返回true。当对列集插入值时，UPDATE()函数对列集和所有稀疏列返回true。
对列集实施安全
对列集实施安全就像对其它字段实施安全一样，但是稀疏列的权限可能会影响从列集获取数据。让我们做些测试。
首先，让我们授予对所有稀疏列的SELECT权限，并试图从列集获取数据。你需要有一个用于这个测试的单独账户。如果你没有额外的账户，那么创建一个登录和一个用户为User1。让我们使用User1权限来试着获取数据。
代码1：使用User1的帐户获取和更新数据。
--Set the execution context to the user User1
EXECUTE AS USER = 'User1'
-- select statement 1
SELECT Gender, Telephone, MonthlyIncome, Comments FROM Customers
-- select statement 2
SELECT AllSparseColumns FROM Customers
-- select statement 3
UPDATE dbo.Customers
SET Gender = 1
WHERE Id = 3
-- select statement 4
UPDATE dbo.Customers
SET [AllSparseColumns] = '777225656Test msg1'
WHERE Id = 3
REVERT
代码2：将稀疏列的SELECT权限授予User1并执行代码1。
-- Grant select permission to all sparse columns
GRANT SELECT (Gender, Telephone, MonthlyIncome, Comments) ON OBJECT::dbo.Customers TO User1
-- Execute the code 1:
-- select statement 1 - will success
-- select statement 2 - will fail
-- select statement 3 - will fail
-- select statement 4 - will fail
-- Remove SELECT permission from User1
REVOKE SELECT (Id, Gender, Telephone, MonthlyIncome, Comments) ON OBJECT::dbo.Customers TO User1
尽管我们授予了对所有稀疏列的SELECT权限，但是用户却不能从列集获取数据。它要求显式的SELECT权限。但是如果我们授予稀疏列上的SELECT和UPDATE权限，User1就将可以访问这个列集。但是User1不能更新这个列集。
代码3：授予稀疏列上的SELECT和UPDATE权限给User1并执行代码1。
-- Grant select permission to all sparse columns
GRANT SELECT, UPDATE (Gender, Telephone, MonthlyIncome, Comments) ON OBJECT::dbo.Customers TO User1
-- Execute the code 1
-- select statement 1 - will success
-- select statement 2 - will success
-- update statement 3 - will success
-- update statement 4 - will fail
-- Remove SELECT, and UPDATE permissions from User1
REVOKE SELECT, UPDATE (Id, Gender, Telephone, MonthlyIncome, Comments) ON OBJECT::dbo.Customers TO User1
现在让我们授予对列集的SELECT权限，并尝试访问稀疏列。
代码4授予列集上的SELECT权限给User1并执行代码1。
-- Grant select permission to the column set
GRANT SELECT (AllSparseColumns) ON OBJECT::dbo.Customers TO User1
-- Execute the code 1
-- select statement 1 - will fail
-- select statement 2 - will success
-- update statement 3 - will fail
-- update statement 4 - will fail
-- Remove SELECT permission from User1
REVOKE SELECT (AllSparseColumnss) ON OBJECT::dbo.Customers TO User1
就像代码3中的代码一样，如果我们授予对列集的SELECT和UPDATE权限给User1，那么SELECT语句2将会成功。此外，User1将可以对列集执行UPDATE语句，但不能对稀疏列执行UPDATE语句。看下面的代码5。
代码5：授予对列集的SELECT和UPDATE权限给User1并执行代码1。
-- Grant select and update permissions to the column set
GRANT SELECT, UPDATE (AllSparseColumns) ON OBJECT::dbo.Customers TO User1
-- Execute the code 1
-- select statement 1 - will success
-- select statement 2 - will success
-- update statement 3 - will fail
-- update statement 4 - will success
-- Remove SELECT and UPDATE permission from User1
REVOKE SELECT, UPDATE (AllSparseColumnss) ON OBJECT::dbo.Customers TO User1
现在让我们测试DENY权限是怎样传播的。让我们授予对稀疏列的SELECT权限并拒绝对列集SELECT的权限。正如你所预料的，User1将可以访问所有的稀疏列，但不能访问列集。拒绝对列集SELECT的权限不会影响稀疏列。
代码6：授予对稀疏列SELECT的权限并拒绝列集的SELECT权限给User1并执行代码1。
-- Grant SELECT permission on sparse columns
GRANT SELECT (Id, Gender, Telephone, MonthlyIncome, Comments) ON OBJECT::dbo.Customers TO User1
-- Deny SELECT permission on the column set
DENY SELECT (AllSparseColumns) ON OBJECT::dbo.Customers TO User1
-- Execute the code 1
-- select statement 1 - will success
-- select statement 2 - will fail
-- update statement 3 - will fail
-- update statement 4 - will fail
REVOKE ALL ON OBJECT::dbo.Customers TO User1
GO
但是当对稀疏列SELECT的权限被拒绝时，它会传播到列集。看代码7。User1将不能访问到列集，即使我们授予了列集上的SELECT权限。
代码7拒绝对稀疏列SELECT的权限并授予对列集SELECT的权限给User1并执行代码1。
-- Deny SELECT permission on sparse columns
DENY SELECT (Id, Gender, Telephone, MonthlyIncome, Comments) ON OBJECT::dbo.Customers TO User1
-- Grant SELECT permission on the column set
GRANT SELECT (AllSparseColumns) ON OBJECT::dbo.Customers TO User1
-- Execute the code 1
-- select statement 1 - will fail
-- select statement 2 - will fail
-- update statement 3 - will fail
-- update statement 4 - will fail
REVOKE ALL ON OBJECT::dbo.Customers TO User1
GO
http://database.ctocio.com.cn/tips/361/8239861.shtml
xuejinyoulan收录，使用标签：数据库，时间：2008-7-30 10:49:52 | 相关网摘，我也收藏
出处:blog
最近学习了一下Oracle数据库启动原理，于是，就把在Windows创建起来做测试的数据库。
移植到Linux下使用,前几天把Linux移植到Windows成功，但Windows移植到Linux碰到问题会多，
Windows下不区分大小写，但在Linux是区分的，这点务必请大家注意，下面让我们一起去这过程吧!
还是和上面讲的一样，我直接通过文件复制，把原来在Windows下使用的数据库移植到linux下，
而不需要通过其他工具。
虽然此移植在实际生产用途不大，但对一个刚Oracle来说，确实能从中学到很多东西， 所以写下此文以供参考：
系统环境:linux 下是32 位平台，linux内存，CPU等硬件条件和windows是一样。
如果硬件条件不一至，下面讲的数据迁移可能会碰到其他问题。
软件环境：linux平台和windows平台装的oracle软件版本是
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
都是以企业版安装。
如果两边版本不一至，还没有实验过。
我粗略讲一下过程，把windows下的数据文件，控制文件，重做日志组文件，
参数文件，复到到linux下，然后把参数文件里的控制文件改成linux目录
下结构，同时使数据重新生成控制文件。详细步骤如下：
linux平台下的数据库配制如下
数据库是以文件系统管理
实例名:orcl
数据库名:orcl
ORACLE_BASE=/u01/app/oracle/
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
数据库文件存放位置:/u02/oradata/orcl
windows平台下的数据库配制如下
数据库是以文件系统管理
实例名:orcl
数据库名:orcl 由于数据库是从windows文件直接复制过来，所以数据库名是不能更改的
ORACLE_BASE=D:\oracle
ORACLE_HOME=D:\oracle\product\10.2.0\db_1
ORACLE_SID=orcl
数据库文件存放位置:D:\oracle\oradata\orcl
步骤如下：
--登录到windows下数据库
c:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on 星期二 7月 1 14:53:23 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
--创建参数pfile文件
SQL> create pfile='initorcl.ora' from spfile;
文件已创建。
--关毕数据库
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
linux平台如输入如下创建文件夹
mkdir -o /u02/oradata/orcl
复制参数文件，控制文件，数据文件，重做日志组文件到linux平台下的目录，
我这里是在linux开了一个samba服务，然后把/u02/oradata/orcl文件夹共享
也可以在linux开个FTP，通过FTP把文件传到linux机器上
windows平台数据文件，，重做日志组文件和控制文件放在 D:\oracle\oradata\orcl
linux平台下的数据文件 /u02/oradata/orcl
linux平台下的实例参数文件window平台下的 D:\oracle\product\10.2.0\db_1\database\initorcl.ora
复制到linux平台下的目录
/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora
注意这里的文件名，linux下文件名是区分大小写的，所以把全部改成小写的
以下是linux平台输入如下命令来创建文件夹:
mkdir -p /u01/app/oracle/admin/orcl/adump
mkdir -p /u01/app/oracle/admin/orcl/bdump
mkdir -p /u01/app/oracle/admin/orcl/cdump
mkdir -p /u01/app/oracle/admin/orcl/dpdump
mkdir -p /u01/app/oracle/admin/orcl/pfile
mkdir -p /u01/app/oracle/admin/orcl/udump
如果/u01/app/oracle/flash_recovery_area也不存在，也创建
mkdir -p /u01/app/oracle/flash_recovery_area
设计环境变量
set ORACLE_SID=linux
或者更改oracle用户下的.bash_profile文件
ORACLE_SID=orcl; export ORACLE_SID
把ORACLE_SID改成orcl
用vi打开文件/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora
把windows下的目录结构改成linux下的目录结构。
注意下，在linux下文件名和文件夹都是区分大小写的，请确保下面参数实际文件名大小写一至，否则就起动不了数据库。
下面文件是我的参数文件信息。供参考:
orcl.__db_cache_size=75497472
orcl.__java_pool_size=4194304
orcl.__large_pool_size=4194304
orcl.__shared_pool_size=75497472
orcl.__streams_pool_size=4194304
*.audit_file_dest='/u01/app/oracle/admin/orcl/adump'
*.audit_trail='DB'
*.background_dump_dest='/u01/app/oracle/admin/orcl/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/u02/oradata/orcl/CONTROL01.CTL','/u02/oradata/orcl/CONTROL02.CTL','/u02/oradata/orcl/CONTROL03.CTL'
*.core_dump_dest='/u01/app/oracle/admin/orcl/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/orcl/udump'
创建密码文件
orapwd file=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworcl password=
linux下登录数据库
[oracle@localhost ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Jul 7 13:24:38 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL>
--启动到mount下
SQL> startup mount pfile=/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 88082676 bytes
Database Buffers 75497472 bytes
Redo Buffers 2973696 bytes
Database mounted.
--创建一个spfile文件，下次以spfile文件启动
SQL> create spfile='spfileorcl.ora' from pfile;
File created.
下次启时候直接以spfile文件启动
--做一个把控制文件的内容生成到跟踪文件命令,这一部很重要，生成到跟踪文件里的就是重创控制文件的命令。
SQL> alter database backup controlfile to trace;
Database altered.
--关闭数据库
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
打开跟踪文件，目录为$ORACLE_BASE/admin/linux/udump
查找最新修改文件*.trc,如我的机子上是linux_ora_3647.trc
用vi打开，并查找这行：“-- Set #1. NORESETLOGS case”
选中并复制到
“-- End of tempfile additions.
--
-- Set #2. RESETLOGS case”为止。
把选中这段文字所有目录结构改成linux平台下的目录结构，
注意，linux下是区分在小写的，这里改过来，必须和实际文件名大小写一至，否则创建的控制文件不能启动。
http://database.ctocio.com.cn/tips/388/8238888.shtml
共2531个网摘 [
1 2 3 4 5 6 7 8 9 10 ...
85 ]
上一页 |
下一页