在SQL Server中出于数据安全的考虑，所以需要定期的备份数据库。而备份数据库一般又是在凌晨时间基本没有数据库操作的时候进行，所以我们不可能要求管理员 每天守到晚上1点去备份数据库。要实现数据库的定时自动备份，最常用的方式就是使用SQL Server代理中的作业。启动SQL Server Agent服务，然后在其中新建作业，作业中添加1个备份步骤，类型是T-SQL脚本，然后在命令中输入如下SQL语句，该语句实现了对数据库TestDB1的完整备份，备份文件在C盘Backup文件夹中，文件名就是TestDB1+当时备份的日期字符串.bak。

declare @name varchar(250)

set @name='C:\Backup\TestDB1_'+

convert(varchar(50),getdate(),112)+'.bak'

BACKUP DATABASE [TestDB1] TO

DISK = @name

WITH NOFORMAT, NOINIT,

NAME = N'TestDB1-完整 数据库 备份',

SKIP, NOREWIND, NOUNLOAD

创建好步骤以后，接下来就是创建计划，创建计划的操作十分简单，界面上说明的很详细了，我就不多说了。另外还可以配置警报和通知，不过一般很少用这 个。

使用SQL作业中执行SQL脚本进行备份的方法虽然已经很简单了，但是至少还是要去写BACKUP脚本，这点有些人觉得不爽，那有没有更简单，更懒 的方法来实现数据库的自动定时备份呢？有，那就是“维护计划”。 “维护计划”是在SSMS的对象资源管理中“管理”节点下面。使用维护计划可以通过可视化的操作，只点点鼠标就可以创建数据库维护的SSIS包，然 后仍然是通过SQL Server作业的方式来运行。维护计划与前面说到的备份方法本质的不同就是：维护计划是SSIS包，上面的是T-SQL脚本。

…… …… 余下全文

SQLServer数据库维护作业计划

中华IT学院   【大 中 小】  [ 20##年9月9日 ]

-

数据库一直都是后台运行的关键所在，好的维护计划能更加优化好数据库

…… …… 余下全文

SQL Server“数据库维护计划”

　　“数据库维护计划”功能在SQL Server 2000的“企业管理器”中可以找到。

　　说明：

1.以下操作是在服务器的Windows 20## Server上进行操作的。

　2.由于SQL Server 2000执行备份时将产生许多文件(特别是在进行事务日志备份时)，所以建议按数据库名称分别建立独立的备份目录进行存储。

　　3.以下所有操作过程当中一般不会对数据库的使用产生影响。

　　第一步：打开SQL Server“企业管理器”窗体

　　用鼠标单击任务栏上的“开始”按钮中的“程序(P)”菜单下的“Microsoft SQL Server”子菜单中的“企业管理器”菜单项，即可打开SQL Server 2000的“企业管理器”窗体。

　　第二步：找到“数据库维护计划”功能

　　在“企业管理器”窗体中左侧的树型选项卡中，用鼠标单击“+”图标扩展开“控制台根目录”下的“Microsoft SQL Servers”，可以看到其下有一个“SQL Server组”；接着继续扩展开“SQL Server组”，此时可以看到其下出现了服务器的名称(图1中的“JXNC-SERVER”就是我的服务器的名称)；再继续扩展开此服务器，可以看到其下列出了诸如“数据库”、“数据转换服务”等项目；最后单击“管理”项目，可以看到其下存在一个“数据库维护计划”(如图1)。

　　图1

　　单击“数据库维护计划”项目，在“企业管理器”窗口右侧将会显示出已经存在的维护计划项目。每个维护计划均包括以下项目：

　　1.名称：就是维护计划的名称。此名称可以自定义，中英文皆可。

　　2.数据库：就是维护计划所进行维护的数据库的名称。

　　因为一个维护计划允许同时维护多个数据库，所以此处可以显示出多个数据库的名称(在图1中可以看到名为“系统数据库备份”的数据库维护计划中的“数据库”;就包括三个数据库：master、model和msdb)。

…… …… 余下全文

使用SQL Server 2008维护计划实现数据库定时自动备份 - [Database]

SQL Server中出于数据安全的考虑，所以需要定期的备份数据库。而备份数据库一般又是在凌晨时间基本没有数据库操作的时候进行，所以我们不可能要求管理员每天守到晚上1点去备份数据库。要实现数据库的定时自动备份，最常用的方式就是使用SQL Server代理中的作业。启动SQL Server Agent服务，然后在其中新建作业，作业中添加1个备份步骤，类型是T-SQL脚本，然后在命令中输入如下SQL语句，该语句实现了对数据库 TestDB1的完整备份，备份文件在C盘Backup文件夹中，文件名就是TestDB1+当时备份的日期字符串.bak。

declare @name varchar(250) 
set @name='C:\Backup\TestDB1_'+ 
convert(varchar(50),getdate(),112)+'.bak' 
BACKUP DATABASE [TestDB1] TO  
DISK = @name 
WITH NOFORMAT, NOINIT,  
NAME = N'TestDB1-完整 数据库 备份', 
SKIP, NOREWIND, NOUNLOAD

创建好步骤以后，接下来就是创建计划，创建计划的操作十分简单，界面上说明的很详细了，我就不多说了。另外还可以配置警报和通知，不过一般很少用这个。

使用SQL作业中执行SQL脚本进行备份的方法虽然已经很简单了，但是至少还是要去写BACKUP脚本，这点有些人觉得不爽，那有没有更简单，更懒的方法来实现数据库的自动定时备份呢？有，那就是“维护计划”。

…… …… 余下全文

? Table Scan(表扫描)：如果看到这个信息，就说明数据表上没有聚集索引，或者查询优化器

没有使用索引来查找。意即资料表的每一行都被检查到。如果资料表相对较小的话，表扫描可以非常快速，有时甚至快过使用索引。

因此，当看到有执行表扫描时，第一件要做的事就是看看数据表有多少数据行。如果不是太多的话，那么表扫描可能提供了最好的总体效能。但如果数据表大的话，表扫描就极可能需要长时间来完成，查询效能就大受影响。在这种情况下，就需要仔细研究，为数据表增加一个适当的索引用于这个查询。

假设你发现某查询使用了表扫描，有一个合适的非聚集索引，但它没有用到。这意味着什么呢？为什么这个索引没有用到呢？如果需要获得的数据量相对数据表大小来说非常大，或者数据选择性不高(意味着同一个字段中重复的值很多)，表扫描经常会比索引扫描快。例如，如果一个数据表有10000个数据行，查询返回1000行，如果这个表没有聚集索引的话，那么表扫描将比使用一个非聚集索引更快。或者如果数据表有10000个数据行，且同一个字段(WHERE条件句有用到这个字段)上有1000笔重复的数据，表扫描也会比使用非聚集索引更快。

查看图形执行计划上的数据表上的弹出式窗口时，请注意”预估的资料行数(Estimated Row Count)”。这个数字是查询优化器作出的多少个数据行会被返回的最佳推测。如果执行了表扫描且”预估的数据行数”数值很高的话，就意味着返回的记录数很多，查询优化器认为执行表扫描比使用可用的非聚集索引更快。

? Index Seek(索引查找)：索引查找意味着查询优化器使用了数据表上的非聚集索引来查找数

据。性能通常会很快，尤其是当只有少数的数据行被返回时。

? Clustered Index Seek(聚集索引查找)：这指查询优化器使用了数据表上的聚集索引来查

找数据，性能很快。实际上，这是SQL Server能做的最快的索引查找类型。

…… …… 余下全文

                                        目录


第1章 性能调整综述

第2章 有效的应用设计

第3章  SQL语句处理的过程

第4章 ORACLE的优化器

第5章 ORACLE的执行计划
        访问路径(方法) -- access path
        表之间的连接
        如何产生执行计划
        如何分析执行计划
        如何干预执行计划 - - 使用hints

提示
        具体案例分析

第6章 其它注意事项

第1章性能调整综述
   
    Oracle数据库是高度可调的数据库产品。本章描述调整的过程和那些人员应与Oracle服务器的调整有关，以及与调整相关联的操作系统硬件和软件。本章包括以下方面:
l        谁来调整系统?
l        什么时候调整?
l        建立有效调整的目标
l        在设计和开发时的调整
l        调整产品系统
l        监控产品系统

谁来调整系统:
  为了有效地调整系统，若干类人员必须交换信息并牵涉到系统调整中，例如:
l        应用设计人员必须传达应用系统的设计，使得每个人都清楚应用中的数据流动.
l        应用开发人员必须传达他们选择的实现策略，使得语句调整的过程中能快速、容易地识别有问题的应用模块和可疑的SQL语句.
l        数据库管理人员必须仔细地监控系统活动并提供它们的资料，使得异常的系统性能可被快速得识别和纠正.
l        硬件/软件管理人员必须传达系统的硬件、软件配置并提供它们的资料，使得相关人员能有效地设计和管理系统。

    简而言之，与系统涉及的每个人都在调整过程中起某些作用，当上面提及的那些人员传达了系统的特性并提供了它们的资料，调整就能相对的容易和更快一些。

     不幸的是，事实上的结果是：数据库管理员对调整负有全部或主要的责任。但是，数据库管理员很少有合适的系统方面的资料，而且，在很多情况下，数据库管理员往往是在实施阶段才介入数据库，这就给调整工作带来许多负面的影响，因为在设计阶段的缺陷是不能通过DBA的调整而得以解决，而设计阶段的缺陷往往对数据库性能造成极大的影响。
      其实，在真正成熟的开发环境下，开发人员作为纯代码编写人员时，对性能的影响最小，此时大部分的工作应由应用设计人员完成，而且数据库管理员往往在前期的需求管理阶段就介入，为设计人员提供必要的技术支持。
调整并不是数据库管理员的专利，相反大部分应该是设计人员和开发人员的工作，这就需要设计人员和开发人员具体必要的数据库知识，这样才能组成一个高效的团队，然而事实上往往并非如此。

什么时候作调整？
     多数人认为当用户感觉性能差时才进行调整，这对调整过程中使用某些最有效的调整策略来说往往是太迟了。此时，如果你不愿意重新设计应用的话，你只能通过重新分配内存(调整SGA)和调整I/O的办法或多或少地提高性能。Oracle提供了许多特性，这些特性只有应用到正确地设计的系统中时才能够很大地提高性能。

      应用设计人员需要在设计阶段设置应用的性能期望值。然后在设计和开发期间，应用设计人员应考虑哪些Oracle 特性可以对系统有好处，并使用这些特性。
通过良好的系统设计，你就可以在应用的生命周期中消除性能调整的代价和挫折。图1-1图1-2说明在应用的生命周期中调整的相对代价和收益，正如你见到的，最有效的调整时间是在设计阶段。在设计期间的调整能以最低的代价给你最大的收益。


图1-1　在应用生命周期中调整的代价　



　　　　　　图1-2  在应用生命周期中调整的收益
   
    当然，即使在设计很好的系统中，也可能有性能降低。但这些性能降低应该是可控的和可以预见的。

调整目标
      不管你正在设计或维护系统，你应该建立专门的性能目标，它使你知道何时要作调整。如果你试图胡乱地改动初始化参数或SQl 语句，你可能会浪费调整系统的时间，而且无什么大的收益。调整你的系统的最有效方法如下：
l        当设计系统时考虑性能
l        调整操作系统的硬件和软件
l        识别性能瓶颈
l        确定问题的原因
l        采取纠正的动作
当你设计系统时，制定专门的目标；例如，响应时间小于３秒。当应用不能满足此目标时，识别造成变慢的瓶颈（例如，I/O竞争），确定原因，采取纠正动作。在开发期间，你应测试应用研究，确定在采取应用之前是否满足设计的性能目标。

     当你正在维护生产库系统时，有多种快速有效的方法来识别性能瓶颈。
不管怎样，调整通常是一系列开销。一旦你已确定了瓶颈，你可能要牺牲一些其它方面的指标来达到所要的结果。例如，如果I/O有问题，你可能需要更多内存或磁盘。如果不可能买，你可能要限制系统的并发性，来获取所需的性能。然而，如果你已经明确地定义了性能的目标，那用什么来交换高性能的决策就变的很容易的，因为你已经确定了哪些方面是最重要的，如过我的目标为高性能，可能牺牲一些空间资源。

     随着应用的越来越庞大，硬件性能的提高，全面的调整应用逐渐变成代价高昂的行为，在这样情况下，要取得最大的投入/效率之比，较好的办法是调整应用的关键部分，使其达到比较高的性能，这样从总体上来说，整个系统的性能也是比较高的。这也就是有名的20/80原则，调整应用的20%(关键部分)，能解决80%的问题。

在设计和开发系统时作调整
     良好设计的系统可以防止在应用生命周期中产生性能问题。系统设计人员和应用开发人员必须了解Oracle的查询处理机制以便写出高效的SQL语句。“第2章 有效的应用设计”讨论了你的系统中各种可用的配置，以及每种配置更适合哪种类型的应用。“第5章 优化器”讨论了Oracle的查询优化器，以及如何写语句以获取最快的结果。

当设计你的系统时，使用下列优化性能的准则：
l        消除客户机／服务器应用中不必要的网络传输。-- 使用存储过程。
l        使用适合你系统的相应Oracle服务器选件（例如，并行查询或分布式数据库）。
l        除非你的应用有特殊的需要，否则使用缺省的Oracle锁。
l        利用数据库记住应用模块，以便你能以每个模块为基础来追踪性能。
l        选择你的数据块的最佳大小。  -- 原则上来说大一些的性能较好。
l        分布你的数据，使得一个节点使用的数据本地存贮在该节点中。

调整产品系统
     本节描述对应用系统快速、容易地找出性能瓶颈，并决定纠正动作的方法。这种方法依赖于对Oracle服务器体系结构和特性的了解程度。在试图调整你的系统前，你应熟悉Oracle调整的内容。

为调整你已有的系统，遵从下列步骤：
l        调整操作系统的硬件和软件
l        通过查询V $SESSION_WAIT视图，识别性能的瓶颈，这个动态性能视图列出了造成会话(session)等待的事件。
l        通过分析V $SESSION_WAIT中的数据，决定瓶颈的原因。
l        纠正存在的问题。

监控应用系统
这主要是通过监控oracle的动态视图来完成。
各种有用的动态视图：如v$session_wait, v$session_event等。

…… …… 余下全文

对于SqlServer的优化来说，可能优化查询是很常见的事情。关于数据库的优化，本身也是一个涉及面比较的广的话题， 首先，打开【SQL Server Management Studio】，输入一个查询语句看看SqlServer是如何显示查询计划的吧。 select v.OrderID, v.CustomerID, v.CustomerName, v.OrderDate, v.SumMoney, v.Finished

from OrdersView

as v

where v.OrderDate >= '2010-12-1' and v.OrderDate < '2011-12-1'; 其中，OrdersView是一个视图，其定义如下：

SELECT dbo.Orders.OrderID, dbo.Orders.CustomerID,

dbo.Orders.OrderDate,

dbo.Orders.SumMoney, dbo.Orders.Finished,

ISNULL(dbo.Customers.CustomerName, N'') AS CustomerName FROM dbo.Orders LEFT OUTER JOIN

dbo.Customers ON dbo.Orders.CustomerID =

dbo.Customers.CustomerID

对于前一句查询，SqlServer给出的查询计划如下（点击工具栏上的【显示估计的执行计划】按钮）：

从这个图，我们至少可以得到3个有用的信息：

1. 哪些执行步骤花费的成本比较高。显然，最右边的二个步骤的成本是比较高的。

2. 哪些执行步骤产生的数据量比较多。对于每个步骤所产生的数据量， SqlServer的执行计划是用【线条粗细】来表示的，因此也很容易地从分辨出来。

…… …… 余下全文