彻底删除SQL里的数据 数据库现在有5G的数据量,为了压缩空间,本人用Delete命令,并带条件地删除了n张表里上百万条数据,之后也收缩了数据库,数据为日志文件仅有504K,但整个数据库的数据量仍未减少,也几乎为5G.据说用Delete命令删除数据库,仅是将数据作上标识,有利于恢复,所以空间是没能减少.但我现在确实不想保留这部分数据,该如何清理出这部分数据? 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 〉〉据说用Delete命令删除数据库,仅是将数据作上标识,有利于恢复sqlserver不是，老的dbase才是这样 学习,DELETE都不行????还有一个TRUN..什么的 但是我需要带条件删除,truncate table似乎不能带条件!我删了上百万条数据,怎么数据库空间还是那么大? 使用DBCC SHRINKDATABASE 和DBCC SHRINKFILE 命令来压缩数据库 对，truncate table是整个表数据清除，且不记录进日志，也就是说不能根据日志恢复的，要慎用！上百万数据，应该占用不少空间的，你是在企业管理器手工收缩的吗？ DBCC SHRINKDATABASE收缩指定数据库中的数据文件大小。语法DBCC SHRINKDATABASE ( database_name [ , target_percent ] [ , { NOTRUNCATE | TRUNCATEONLY } ] )参数database_name是要收缩的数据库名称。数据库名称必须符合标识符的规则。有关更多信息，请参见使用标识符。target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比。NOTRUNCATE导致在数据库文件中保留所释放的文件空间。如果未指定，将所释放的文件空间释放给操作系统。TRUNCATEONLY导致将数据文件中的任何未使用的空间释放给操作系统，并将文件收缩到上一次所分配的大小，从而减少文件大小，而不移动任何数据。不试图重新定位未分配页的行。使用 TRUNCATEONLY 时，忽略 target_percentis。注释Microsoft? SQL Server? 可收缩：特定数据库的所有数据和日志文件。执行 DBCC SHRINKDATABASE。一次一个特定数据库中的数据或日志文件。执行 DBCC SHRINKFILE。 DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而，DBCC SHRINKDATABASE 在对日志文件进行收缩时，看起来好像所有的日志文件都存在于一个连续的日志池中。假设名为 mydb 的数据库有两个数据文件和两个日志文件。这些数据文件和日志文件大小都为 10 MB。第一个数据文件包含 6 MB 数据。对于每个文件，SQL Server 计算目标大小，即要收缩文件到的大小。当用 target_percent 指定 DBCC SHRINKDATABASE 时，SQL Server 计算的目标大小是收缩后文件中的 target_percent 可用空间大小。例如，如果指定按 target_percent 为 25 收缩 mydb。SQL Server 计算的该文件的目标大小为 8 MB（6 MB 数据加上 2 MB 可用空间）。因此，SQL Server 将任何数据从数据文件的最后 2 MB 中移动到数据文件前 8 MB 的可用空间中，然后对该文件进行收缩。假设 mydb 的第一个数据文件包含 7 MB 的数据。若将 target_percent 指定为 30，则允许将该数据文件收缩到所要的可用百分比 30。然而，若将 target_percent 指定为 40，就不会收缩该数据文件，因为 SQL Server 不能将文件收缩到比数据当前占有的空间还小的程度。也可以从另一个角度考虑这个问题：40% 要求的可用空间 + 70% 完整的数据文件（10 MB 中的 7 MB）大于 100%。因为所要求的可用百分比加上数据文件占用的当前百分比大于 100%（多出 10%），所以任何大于 30 的 target_size 都不会收缩该数据文件。对于日志文件，SQL Server 使用 target_percent 以对整个日志的目标大小进行计算；因此，target_percent 是收缩操作后日志中的可用空间大小。之后，整个日志的目标大小可以解释为每个日志文件的目标大小。DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。如果虚拟日志中的所有逻辑日志部分都没有超出日志文件的目标大小，则该文件将成功截断，DBCC SHRINKDATABASE 完成且不显示任何消息。然而，如果虚拟日志中的逻辑日志部分超出其目标大小，则 SQL Server 释放尽可能多的空间并发出一条消息。该消息告诉您需要执行什么操作来移动文件末尾超出虚拟日志的逻辑日志部分。执行完该操作后，可以重新发出 DBCC SHRINKDATABASE 命令以释放剩余的空间。有关收缩事务日志的更多信息，请参见收缩事务日志。因为日志文件只能收缩到虚拟日志文件边界，所以不可能将日志文件收缩到比虚拟日志文件更小（即使现在没有使用该文件）。例如，可以将数据库的 1 GB 日志文件收缩到只有 128 MB。有关截断的更多信息，请参见截断事务日志。有关确定虚拟日志文件大小的更多信息，请参见虚拟日志文件。由 DBCC SHRINKDATABASE 计算的数据和日志文件的目标大小始终不小于文件的最小大小。文件的最小大小是在文件最初创建时指定的大小，或是上一次用更改文件大小的操作（如用带有 MODIFY FILE 选项的 ALTER DATABASE 或 DBCC SHRINKFILE）显式设置的大小。例如，如果在执行 CREATE DATABASE 时，将 mydb 的所有数据和日志文件大小都指定为 10 MB，则每个文件的最小大小都为 10 MB。DBCC SHRINKDATABASE 不能收缩任何小于 10 MB 的文件。如果使用带有 MODIFY FILE 选项的 ALTER DATABASE 将其中的一个文件显示增长到 20 MB，则该文件新的最小大小为 20 MB。若要将文件大小收缩到小于其最小大小，请使用 DBCC SHRINKFILE 并指定新大小。执行 DBCC SHRINKFILE 会将文件的最小大小更改为所指定的新大小。在使用数据文件时，DBCC SHRINKDATABASE 有 NOTRUNCATE 和 TRUNCATEONLY 选项。如果为日志文件指定这两个选项，则将忽略这两个选项。DBCC SHRINKDATABASE 不带任何选项等价于 DBCC SHRINKDATABASE 带有 NOTRUNCATE 选项，后面还要跟着带有 TRUNCATEONLY 选项的 DBCC SHRINKDATABASE。不论是否指定 target_percent，NOTRUNCATE 选项都执行 DBCC SHRINKDATABASE 的实际数据移动操作（包括将分配页从文件的末尾移动到文件前面的未分配页）。然而，文件末尾的可用空间不会返回给操作系统，文件的物理大小也不会更改。因此，如果指定 NOTRUNCATE 选项，数据文件好像没有收缩。例如，假设再次使用 mydb 数据库，该 mydb 有两个数据文件和两个日志文件。第二个数据文件和第二个日志文件的大小都为 10 MB。执行 DBCC SHRINKDATABASE mydb NOTRUNCATE 时，Microsoft SQL Server 将数据从数据文件的后面几页移动到前面几页中。而文件的大小仍然为 10 MB。TRUNCATEONLY 选项将文件末尾的所有可用空间收回给操作系统。然而，TRUNCATEONLY 在文件内不执行任何页移动操作。指定的文件只能收缩到上一次分配的大小。如果使用 TRUNCATEONLY 选项指定 target_percent，则忽略后者。所生成的数据库不能比 model 数据库更小。要收缩的数据库不必在单用户模式下；其他的用户仍可以在数据库收缩时对其进行工作。这也包括系统数据库。好好看看 backup log db with no_log --截断事务日志GODBCC SHRINKDATABASE(N'db' ) --收缩数据库GODBCC SHRINKFILE (N'db' , 0, TRUNCATEONLY) --收缩数据文件GODBCC SHRINKFILE (N'db_log' , 0, TRUNCATEONLY)--收缩日志文GO db表示数据库名吗?为什么下段的需要加N'db'? DBCC SHRINKDATABASE (dbname) 经典的SQL语句 但不要滥用 否则会很大镬 加上 N 代表存入数据库时以 Unicode 格式存储。N'string' 表示string是个Unicode字符串Unicode 字符串的格式与普通字符串相似，但它前面有一个 N 标识符（N 代表 SQL-92 标准中的国际语言 (National Language)）。N 前缀必须是大写字母。例如，'Michél' 是字符串常量而 N'Michél' 则是 Unicode 常量。Unicode 常量被解释为 Unicode 数据，并且不使用代码页进行计算。Unicode 常量确实有排序规则，主要用于控制比较和区分大小写。为 Unicode 常量指派当前数据库的默认排序规则，除非使用 COLLATE 子句为其指定了排序规则。Unicode 数据中的每个字符都使用两个字节进行存储，而字符数据中的每个字符则都使用一个字节进行存储。有关更多信息，请参见使用 Unicode 数据。Unicode 字符串常量支持增强的排序规则 使用这个DBCC SHRINKDATABASE (dbname)命令,结果空间少了1G左右,不知道是算不算极限压收缩了? 收缩数据库文件 -- 清空日志 --压缩日志及数据库文件大小 /*--特别注意 请按步骤进行,未进行前面的步骤,请不要做后面的步骤 否则可能损坏你的数据库. --*/ select*fromsysfiles --1.清空日志 DUMPTRANSACTIONusernameWITHNO_LOG --2.截断事务日志： BACKUPLOGusernameWITHNO_LOG --3.收缩数据库文件(如果不压缩,数据库的文件不会减小 -- 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 -- 也可以用SQL语句来完成 --收缩数据库 DBCCSHRINKDATABASE(username) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select*fromsysfiles DBCCSHRINKFILE(2) 求一个SQL写法 求一SQL语句 求SQL语句 菜鸟问题：csdn是那几个字的缩写？ 发布,分发,订阅数据库服务器问题 SQL问题请高手解决,在线等···· 郁闷！对前途的茫然 在2000里加锁是系统自动的呢？还是要用语句来实现的呢？ 这个问题怎么解决？存储过程错在哪？请教 求sql语句 一个有点难度的数据库查询，请各位高手帮忙 关于MSDE2000的问题
还有一个TRUN..什么的
我删了上百万条数据,怎么数据库空间还是那么大?
上百万数据，应该占用不少空间的，你是在企业管理器手工收缩的吗？
收缩指定数据库中的数据文件大小。语法
DBCC SHRINKDATABASE
( database_name [ , target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)参数
database_name是要收缩的数据库名称。数据库名称必须符合标识符的规则。有关更多信息，请参见使用标识符。target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比。NOTRUNCATE导致在数据库文件中保留所释放的文件空间。如果未指定，将所释放的文件空间释放给操作系统。TRUNCATEONLY导致将数据文件中的任何未使用的空间释放给操作系统，并将文件收缩到上一次所分配的大小，从而减少文件大小，而不移动任何数据。不试图重新定位未分配页的行。使用 TRUNCATEONLY 时，忽略 target_percentis。注释
Microsoft? SQL Server? 可收缩：特定数据库的所有数据和日志文件。执行 DBCC SHRINKDATABASE。
一次一个特定数据库中的数据或日志文件。执行 DBCC SHRINKFILE。
DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而，DBCC SHRINKDATABASE 在对日志文件进行收缩时，看起来好像所有的日志文件都存在于一个连续的日志池中。假设名为 mydb 的数据库有两个数据文件和两个日志文件。这些数据文件和日志文件大小都为 10 MB。第一个数据文件包含 6 MB 数据。对于每个文件，SQL Server 计算目标大小，即要收缩文件到的大小。当用 target_percent 指定 DBCC SHRINKDATABASE 时，SQL Server 计算的目标大小是收缩后文件中的 target_percent 可用空间大小。例如，如果指定按 target_percent 为 25 收缩 mydb。SQL Server 计算的该文件的目标大小为 8 MB（6 MB 数据加上 2 MB 可用空间）。因此，SQL Server 将任何数据从数据文件的最后 2 MB 中移动到数据文件前 8 MB 的可用空间中，然后对该文件进行收缩。假设 mydb 的第一个数据文件包含 7 MB 的数据。若将 target_percent 指定为 30，则允许将该数据文件收缩到所要的可用百分比 30。然而，若将 target_percent 指定为 40，就不会收缩该数据文件，因为 SQL Server 不能将文件收缩到比数据当前占有的空间还小的程度。也可以从另一个角度考虑这个问题：40% 要求的可用空间 + 70% 完整的数据文件（10 MB 中的 7 MB）大于 100%。因为所要求的可用百分比加上数据文件占用的当前百分比大于 100%（多出 10%），所以任何大于 30 的 target_size 都不会收缩该数据文件。对于日志文件，SQL Server 使用 target_percent 以对整个日志的目标大小进行计算；因此，target_percent 是收缩操作后日志中的可用空间大小。之后，整个日志的目标大小可以解释为每个日志文件的目标大小。DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。如果虚拟日志中的所有逻辑日志部分都没有超出日志文件的目标大小，则该文件将成功截断，DBCC SHRINKDATABASE 完成且不显示任何消息。然而，如果虚拟日志中的逻辑日志部分超出其目标大小，则 SQL Server 释放尽可能多的空间并发出一条消息。该消息告诉您需要执行什么操作来移动文件末尾超出虚拟日志的逻辑日志部分。执行完该操作后，可以重新发出 DBCC SHRINKDATABASE 命令以释放剩余的空间。有关收缩事务日志的更多信息，请参见收缩事务日志。因为日志文件只能收缩到虚拟日志文件边界，所以不可能将日志文件收缩到比虚拟日志文件更小（即使现在没有使用该文件）。例如，可以将数据库的 1 GB 日志文件收缩到只有 128 MB。有关截断的更多信息，请参见截断事务日志。有关确定虚拟日志文件大小的更多信息，请参见虚拟日志文件。由 DBCC SHRINKDATABASE 计算的数据和日志文件的目标大小始终不小于文件的最小大小。文件的最小大小是在文件最初创建时指定的大小，或是上一次用更改文件大小的操作（如用带有 MODIFY FILE 选项的 ALTER DATABASE 或 DBCC SHRINKFILE）显式设置的大小。例如，如果在执行 CREATE DATABASE 时，将 mydb 的所有数据和日志文件大小都指定为 10 MB，则每个文件的最小大小都为 10 MB。DBCC SHRINKDATABASE 不能收缩任何小于 10 MB 的文件。如果使用带有 MODIFY FILE 选项的 ALTER DATABASE 将其中的一个文件显示增长到 20 MB，则该文件新的最小大小为 20 MB。若要将文件大小收缩到小于其最小大小，请使用 DBCC SHRINKFILE 并指定新大小。执行 DBCC SHRINKFILE 会将文件的最小大小更改为所指定的新大小。在使用数据文件时，DBCC SHRINKDATABASE 有 NOTRUNCATE 和 TRUNCATEONLY 选项。如果为日志文件指定这两个选项，则将忽略这两个选项。DBCC SHRINKDATABASE 不带任何选项等价于 DBCC SHRINKDATABASE 带有 NOTRUNCATE 选项，后面还要跟着带有 TRUNCATEONLY 选项的 DBCC SHRINKDATABASE。不论是否指定 target_percent，NOTRUNCATE 选项都执行 DBCC SHRINKDATABASE 的实际数据移动操作（包括将分配页从文件的末尾移动到文件前面的未分配页）。然而，文件末尾的可用空间不会返回给操作系统，文件的物理大小也不会更改。因此，如果指定 NOTRUNCATE 选项，数据文件好像没有收缩。例如，假设再次使用 mydb 数据库，该 mydb 有两个数据文件和两个日志文件。第二个数据文件和第二个日志文件的大小都为 10 MB。执行 DBCC SHRINKDATABASE mydb NOTRUNCATE 时，Microsoft SQL Server 将数据从数据文件的后面几页移动到前面几页中。而文件的大小仍然为 10 MB。TRUNCATEONLY 选项将文件末尾的所有可用空间收回给操作系统。然而，TRUNCATEONLY 在文件内不执行任何页移动操作。指定的文件只能收缩到上一次分配的大小。如果使用 TRUNCATEONLY 选项指定 target_percent，则忽略后者。所生成的数据库不能比 model 数据库更小。要收缩的数据库不必在单用户模式下；其他的用户仍可以在数据库收缩时对其进行工作。这也包括系统数据库。好好看看
backup log db with no_log --截断事务日志
GO
DBCC SHRINKDATABASE(N'db' ) --收缩数据库
GO
DBCC SHRINKFILE (N'db' , 0, TRUNCATEONLY) --收缩数据文件
GO
DBCC SHRINKFILE (N'db_log' , 0, TRUNCATEONLY)--收缩日志文
GO
db表示数据库名吗?为什么下段的需要加N'db'?
N'string' 表示string是个Unicode字符串Unicode 字符串的格式与普通字符串相似，但它前面有一个 N 标识符（N 代表 SQL-92 标准中的国际语言 (National Language)）。N 前缀必须是大写字母。例如，'Michél' 是字符串常量而 N'Michél' 则是 Unicode 常量。Unicode 常量被解释为 Unicode 数据，并且不使用代码页进行计算。Unicode 常量确实有排序规则，主要用于控制比较和区分大小写。为 Unicode 常量指派当前数据库的默认排序规则，除非使用 COLLATE 子句为其指定了排序规则。Unicode 数据中的每个字符都使用两个字节进行存储，而字符数据中的每个字符则都使用一个字节进行存储。有关更多信息，请参见使用 Unicode 数据。Unicode 字符串常量支持增强的排序规则
-- 清空日志
--压缩日志及数据库文件大小
/*--特别注意
请按步骤进行,未进行前面的步骤,请不要做后面的步骤
否则可能损坏你的数据库.
--*/
select*fromsysfiles
--1.清空日志
DUMPTRANSACTIONusernameWITHNO_LOG
--2.截断事务日志：
BACKUPLOGusernameWITHNO_LOG
--3.收缩数据库文件(如果不压缩,数据库的文件不会减小
-- 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
-- 也可以用SQL语句来完成
--收缩数据库
DBCCSHRINKDATABASE(username)
--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select*fromsysfiles
DBCCSHRINKFILE(2)