如何释放SQL表中己分配但又未使用的空间

创建数据库

选择开始菜单中→程序→Management SQL Server 2008→SQL Server Management Studio命令，打开SQL Server Management Studio窗口，并使用Windows或 SQL Server身份验证建立连接。

在对象资源管理器窗口中展开服务器，然后选择数据库节点

右键单击数据库节点，从d出来的快捷菜单中选择新建数据库命令。

执行上述 *** 作后，会d出新建数据库对话框。在对话框、左侧有3个选项，分别是常规、选项和文件组。完成这三个选项中的设置会后，就完成了数据库的创建工作，

在数据库名称文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。

在所有者文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用使用全文索引复选框。

在数据库文件列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的添加、删除按钮添加或删除数据库文件。

切换到选项页、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。

切换到文件组页，在这里可以添加或删除文件组。

完成以上 *** 作后，单击确定按钮关闭新建数据库对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再对象资源管理器窗口看到。

你可以先给数据进行一下压缩，顺序：右键点击数据库-任务-收缩-数据库 你可以根据需要设置一下，最后点击确定，这样会减小不少的空间。

清除2011年以前的数据，你可以用sql语句进行删除，怕出问题可以先将数据库备份一份，然后再删除，就算有问题也可能恢复回去。

Tempdb 信息

tempdb 是一个临时工作区。除其他用途外，SQL Server 还将 tempdb 用于：

•

显式创建的临时表的存储。

•

保存在查询处理和排序过程中创建的中间结果的工作表。

•

具体化的静态光标。

SQL Server 在 tempdb 事务日志中记录的信息只足够用于回滚事务，而不足以用于在数据库故障恢复过程中重新执行事务。这一特点提高了

tempdb 中 INSERT 语句的性能。另外，由于每次重新启动 SQL Server 时都会重新创建

tempdb，无需记录用于重新执行任何事务的信息。因此，没有任何要前滚或回滚的事务。当 SQL Server 启动时，通过使用 model

数据库的副本重新创建 tempdb，并将其重置为上次配置的大小。

默认情况下，tempdb

数据库配置为根据需要自动增长；因此，此数据库可能最终增长到大于所需的大小。简单地重新启动 SQL Server 会将 tempdb

的大小重置为上次配置的大小。配置的大小是用文件大小更改 *** 作（如带有 MODIFY FILE 选项的 ALTER DATABASE 或者 DBCC

SHRINKFILE 语句）设置的上次显式大小。本文说明您可以用来将 tempdb 收缩到小于其配置的大小的三种方法。

收缩 Tempdb 的方法 1

此方法要求您重新启动 SQL Server。

1

停止 SQL Server。打开命令提示符，然后键入以下命令启动 SQL Server：

sqlservr -c -f

-c 和 -f 参数使 SQL Server 以最小配置模式启动，让数据文件的 tempdb 大小为 1 MB，日志文件的 tempdb 为 05 MB。

注意：如果使用 SQL Server 命名实例，必须切换到适当的文件夹 (Program Files/Microsoft SQL Server/MSSQL$instance name/Binn)，并使用 -s 开关 (-s%instance_name%)。

2

用查询分析器连接到 SQL Server，然后运行下列 Transact-SQL 命令：

ALTER DATABASE tempdb MODIFY FILE

(NAME = 'tempdev', SIZE = target_size_in_MB)

--Desired target size for the data file

ALTER DATABASE tempdb MODIFY FILE

(NAME = 'templog', SIZE = target_size_in_MB)

--Desired target size for the log file

3

通过在命令提示符窗口中按 Ctrl-C 停止 SQL Server，将 SQL Server 作为服务重新启动，然后验证 Tempdbmdf 和 Templogldf 文件的大小。

此方法的局限是它只能对默认的 tempdb 逻辑文件 tempdev 和 templog 进行 *** 作。如果将其他文件添加到了 tempdb，您可以在将 SQL Server 作为服务重新启动后收缩它们。在启动过程中将重新创建所有 tempdb 文件；因此，它们是空的并可删除。要删除 tempdb 中的其他文件，请使用带有 REMOVE FILE 选项的 ALTER DATABASE 命令。

收缩 Tempdb 的方法 2

使用 DBCC SHRINKDATABASE 命令将 tempdb 数据库作为整体收缩。DBCC SHRINKDATABASE 接收参数 target_percent，该参数是数据库收缩后数据库文件中剩余可用空间的所需百分比。如果使用 DBCC SHRINKDATABASE，可能必须重新启动 SQL Server。

重要说明：如果运行 DBCC SHRINKDATABASE，则 tempdb 数据库不能正在发生其他活动。要确保在运行 DBCC SHRINKDATABASE 时其他进程无法使用 tempdb，必须以单用户模式启动 SQL Server。有关更多信息，请参考本文的在使用 Tempdb 时执行 DBCC SHRINKDATABASE 或 DBCCSHRINKFILE 的结果 一节。

1

通过使用 sp_spaceused 存储过程确定 tempdb 中当前使用的空间。然后，计算剩余可用空间的百分比，它将用作 DBCC SHRINKDATABASE 的参数；该计算是基于所需数据库大小进行的。

注意：在某些情况下，您可能必须执行 sp_spaceused @updateusage=true 来重新计算使用的空间和获得更新的报告。有关 sp_spaceused 存储过程的更多信息，请参考 SQL Server 联机丛书。

请考虑以下示例：

假定 tempdb 有两个文件：主数据文件 (Tempdbmdf) 和日志文件 (Tempdbldf)，其大小分别为 100 MB 和 30 MB。假定 sp_spaceused 报告主数据文件包含 60 MB 的数据。还假定您要将主数据文件收缩到 80 MB。计算收缩后剩余可用空间的所需百分比，即 80 MB - 60 MB = 20 MB。现在，用 20 MB 除以 80 MB = 25%，这就是您的 target_percent。事务日志文件将据此进行收缩，从而在数据库收缩后剩下 25% 即 20 MB 的可用空间。

2

用查询分析器连接到 SQL Server，然后运行下列 Transact-SQL 命令：

dbcc shrinkdatabase (tempdb, 'target percent')

-- This command shrinks the tempdb database as a whole

对 tempdb 数据库使用 DBCC SHRINKDATABASE

命令具有局限性。数据文件和日志文件的目标大小不能小于创建数据库时指定的大小，也不能小于用文件大小更改 *** 作（如带有 MODIFY FILE 选项的

ALTER DATABASE 命令或 DBCC SHRINKFILE 命令）显式设置的上次大小。DBCC SHRINKDATABASE

的另一个限制是 target_percentage 参数的计算和它对当前使用的空间的依赖。

收缩 Tempdb 的方法 3

使用命令 DBCC SHRINKFILE 收缩单个 tempdb 文件。DBCC SHRINKFILE 比 DBCC SHRINKDATABASE 提供更多的灵活性，因为您可以对单个数据库文件使用它而不必影响属于同一数据库的其他文件。DBCC SHRINKFILE 接收 target size 参数，这是所需的数据库文件的最终大小。

重要说明：必须在 tempdb 数据库不发生任何活动时运行 DBCC SHRINKFILE 命令。要确保在执行 DBCC SHRINKFILE 时其他进程不能使用 tempdb，必须以单用户模式重新启动 SQL Server。有关 DBCC SHRINKFILE 的更多信息，请参见本文中在使用 Tempdb 时执行 DBCC SHRINKDATABASE 或 DBCCSHRINKFILE 的结果 一节。

1

确定主数据文件 (tempdbmdf)、日志文件 (templogldf) 和/或添加到 tempdb 的其他文件的所需大小。确保在这些文件中使用的空间小于或等于所需的目标大小。

2

用查询分析器连接到 SQL Server，然后为需要收缩的特定数据库运行下列 Transact-SQL 命令：

use tempdb

go

dbcc shrinkfile (tempdev, 'target size in MB')

go

-- this command shrinks the primary data file

dbcc shrinkfile (templog, 'target size in MB')

go

-- this command shrinks the log file, look at the last paragraph

DBCC SHRINKFILE 的一个优点是它可以将文件大小减小到小于其原始大小。您可以对任何数据文件或日志文件执行 DBCC SHRINKFILE。DBCC SHRINKFILE 的一个局限是您无法使数据库小于 model 数据库的大小。

在 SQL Server 70 中，事务日志收缩是一个推迟 *** 作，您必须执行日志截断和备份，以帮助进行数据库中的收缩 *** 作。但是，默认情况下，tempdb 将 trunc log on chkpt 选项设置为“打开”(ON)；这样，您就无需为该数据库执行日志截断。有关如何在 SQL Server 70 中收缩数据库事务日志的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

256650 (>

很多人都有这样的了解 检测Oracle的可用性所需要的命令比简单的ping或者ps ef | grep 等Oracle的命令要多得多 有观点认为它需要一个使用SQLNet 来验证监听器已经开启并运行的测试访问Oracle——这是用户经常用到的访问 通过实际地登录到实际环境中 你可以确认这个实例环境可以接受登录的 如果你只是做了以上的检测的话 你如何才能知道是否登录没有被接受 只是因为需要等待文档日志

除了Oracle的激活和可用性之外 我们还需要进行检测以确保它可以用 这样我们还可以检测表空间的容量

检测的脚本:

假设所有的Oracle环境都已经搭建起来了

假设所有的扩展都已经达到了最大的限度

假设左右的表空间都缺乏运行的空闲空间

下面的脚本可以在你想要的任何时候通过crontab 来中断 另外 如果上面的例外情况出现了的话 您还可以就这个脚本写信或者电子邮件给支持人员获得帮助

如果您有什么其他的测试 这个脚本可以让您轻松地进行修改以加以利用 我使用这个Monitororcl 脚本作为模板并且在末尾添加了功能

按crontab来调用query_oracle_instances sh 脚本:

#!/bin/ksh /u /home/oracle/ profile /u /app/oracle/admin/monitororcl cat /u /app/oracle/admin/Get_Oracle_Instance_List exit

Get_Oracle_Instance_List 脚本如下:

instance_name tnsname sys_password_for_this_instance instance_name tnsname sys_password_for_this_instance instance_name tnsname sys_password_for_this_instance

下面是MONITORORCL脚本:

lishixinzhi/Article/program/Oracle/201311/17406

在数据库应用系统中编写可执行的SQL语句可以有多种方式实现，但哪一条是最佳方案却难以确定。为了解决这一问题，有必要对SQL实施优化。简单地说，SQL语句的优化就是将性能低下的SQL语句转换成达到同样目的的性能更好的SQL语句。

优化SQL语句的原因

数据库系统的生命周期可以分成: 设计、开发和成品三个阶段。在设计阶段进行优化的成本最低，收益最大。在成品阶段进行优化的成本最高，收益最小。如果将一个数据库系统比喻成一座楼房，在楼房建好后进行矫正往往成本很高而收效很小（甚至可能根本无法矫正），而在楼房设计、生产阶段控制好每块砖瓦的质量就能达到花费小而见效高的目的。

为了获得最大效益，人们常需要对数据库进行优化。数据库的优化通常可以通过对网络、硬件、 *** 作系统、数据库参数和应用程序的优化来进行。根据统计，对网络、硬件、 *** 作系统、数据库参数进行优化所获得的性能提升全部加起来只占数据库应用系统性能提升的40%左右，其余60%的系统性能提升全部来自对应用程序的优化。许多优化专家甚至认为对应用程序的优化可以得到80%的系统性能提升。因此可以肯定，通过优化应用程序来对数据库系统进行优化能获得更大的收益。

对应用程序的优化通常可分为两个方面: 源代码的优化和SQL语句的优化。由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高(尤其是对正在使用中的系统进行优化) 。另一方面，源代码的优化对数据库系统性能的提升收效有限，因为应用程序对数据库的 *** 作最终要表现为SQL语句对数据库的 *** 作。

对SQL语句进行优化有以下一些直接原因：

1 SQL语句是对数据库(数据) 进行 *** 作的惟一途径，应用程序的执行最终要归结为SQL语句的执行，SQL语句的效率对数据库系统的性能起到了决定性的作用。

2 SQL语句消耗了70%～90%的数据库资源。

3 SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低。

4 SQL语句可以有不同的写法，不同的写法在性能上的差异可能很大。

5 SQL语句易学，难精通。SQL语句的性能往往同实际运行系统的数据库结构、记录数量等有关，不存在普遍适用的规律来提升性能。

传统的优化方法

SQL程序人员在传统上采用手工重写来对SQL语句进行优化。这主要依靠DBA或资深程序员对SQL语句执行计划的分析，依靠经验，尝试重写SQL语句，然后对结果和性能进行比较以试图找到性能较佳的SQL语句。这种做法存在着以下不足：

1 无法找出SQL语句的所有可能写法。很可能花费了大量的时间也无法找到性能较佳的SQL语句。即便找到了某个性能较佳的SQL语句也无法知道是否存在性能更好的写法。

2 非常依赖于人的经验，经验的多寡往往决定了优化后SQL语句的性能。

3 非常耗时间。重写-->校验正确性-->比较性能，这一循环过程需要大量的时间。

根据传统的SQL优化工具的功能，人们一般将优化工具分为以下三代产品：

第一代的SQL优化工具是执行计划分析工具。这类工具对输入的SQL语句从数据库提取执行计划，并解释执行计划中关键字的含义。

第二代的SQL优化工具只能提供增加索引的建议，它通过对输入的SQL语句的执行计划的分析来产生是否要增加索引的建议。这类工具存在着致命的缺点——只分析了一条SQL语句就得出增加某个索引的结论，根本不理会(实际上也无法评估到)增加的索引对整体数据库系统性能的影响。

第三代工具是利用人工智能实现自动SQL优化。

人工智能自动SQL优化

随着人工智能技术的发展和在数据库优化领域应用的深入，在20世纪90年代末优化技术取得了突破性的进展，出现了人工智能自动SQL优化。人工智能自动SQL优化的本质就是借助人工智能技术，自动对SQL语句进行重写，找到性能最好的等效SQL语句。LECCO SQL Expert就采用了这种人工智能技术，其SQL Expert支持Oracle、Sybase、MS SQL Server和IBM DB2数据库平台。其突出特点是自动优化SQL语句。除此以外，还可以以人工智能知识库“反馈式搜索引擎”来重写SQL语句，并找出所有等效的SQL语句及可能的执行计划，通过测试运行为应用程序和数据库自动找到性能最好的SQL语句，提供微秒级的计时; 能够优化Web应用程序和有大量用户的在线事务处理中运行时间很短的SQL语句; 能通过比较源SQL和待选SQL的不同之处，为开发人员提供“边做边学式训练”，迅速提高开发人员的SQL编程技能等等。

该工具针对数据库应用的开发和维护阶段提供了数个特别的模块：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块之一“SQL 语法优化器”的工作原理大致如下：输入一条源SQL语句，“人工智能反馈式搜索引擎”对输入的SQL语句结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出，产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满，接下来对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句(不同的执行计划意味着不同的执行效率)，最后，对得到的SQL语句进行批量测试，找出性能最好的SQL语句（参见下图）。

图 人工智能自动SQL优化示意图

LECCO SQL Expert不仅能够找到最佳的SQL语句，它所提供的“边做边学式训练”还能够教会开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的SQL语句自动优化功能使SQL的优化变得极其简单，只要能够写出SQL语句，它就能帮开发人员找到最好性能的写法。

小 结

SQL语句是数据库应用中一个非常关键的部分，它执行性能的高低直接影响着应用程序的运行效率。正因为如此，人们在SQL语句的优化上投入了很大的精力，出现了许多SQL语句优化工具。随着人工智能等相关技术的日益成熟, 肯定还会有更多更好的工具出现，这将会给开发人员提供更多的帮助。

以上就是关于如何释放SQL表中己分配但又未使用的空间全部的内容，包括:如何释放SQL表中己分配但又未使用的空间、数据库日志已满,如何释放日志空间、Mysql数据库错误代码中文详细说明等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！