执行更改，数据库日志导致盘满了，数据表消失。

try this,use masteralter database test001 set single_userDBCC CHECKDB(test001,REPAIR_FAST)alter database test001 set multi_user

在别的盘，创建一个和priamry同等大小的数据文件，以.ndf结尾。然后通过alter database 和alter table命令，可以把一些大表和大索引，移到这个新文件组中，这样空间就有了。

参考！1.检查你的磁盘剩余空间是否足够,如果没有磁盘剩余空间,则清理磁盘,腾出空间

2.检查你的磁盘分区格式
      如果是FAT16,则数据文件最大只能是2G
      如果是FAT32,则数据文件最大只能是4G
      改为NTFS分区则没有这种限制

3.检查一下你有没有限制数据库文件的大小
      企业管理器--右键你的数据库--属性--文件增长限制--如果有限制大小,取消限制

4.检查你的SQL版本,如果你用MSDE,则限制了数据文件最大是2G

5.你也可以为   primary   组添加新的数据文件来解决这个问题
      alter   database   库名   add   file(NAME   =   逻辑文件名,FILENAME   =   'c:\实际文件名.ndf')

楼主说的很清楚了，是去修改列的类型，这个应该导致了Drop原来的表，然后创建新表，然后插入数据这个过程
但是由于primary满了，操作没有完成，导致旧表已经没有，新表也没有了
这真挺让人绝望的···有备份的话把备份还原到新的数据库上，然后补丢失的表的数据吧

新表应该是叫dbo.Tmp_user
你看看里面还有多少数据吧

也没有 tmp_user 这个表

我觉得去TempDB找找看是唯一的希望了···

我承认我是个奇葩好吧，语句是通过 sql 修改然后生成更改脚本来的。

那问题就比较明确了执行时缺少了 BEGIN TRANSACTION 语句（没有复制过来或者没有选择等原因吧），导致原表已经被删除。

email. Varchar(40) 更改到 Varchar（60）

有 BEGIN TRANSACTION的 sql生成的更改语句是包含的。
现在机器执行更改很卡，现在日志已经增加到80G多个G，怎么消耗这么多，也就5000万条数据左右。
语句晚上贴上来。

lz得看看数据库是否还是好的。
DBCC checkdb看看。
如果没有错误，表的消失，可能并非添加列，硬盘占满引起。

test001的 DBCC 结果。
Service Broker 消息 9675，状态 1: 已分析的消息类型: 14。
Service Broker 消息 9676，状态 1: 已分析的服务约定: 6。
Service Broker 消息 9667，状态 1: 已分析的服务: 3。
Service Broker 消息 9668，状态 1: 已分析的服务队列: 3。
Service Broker 消息 9669，状态 1: 已分析的会话端点: 0。
Service Broker 消息 9674，状态 1: 已分析的会话组: 0。
Service Broker 消息 9670，状态 1: 已分析的远程服务绑定: 0。
sys.sysrowsetcolumns的 DBCC 结果。
对象 'sys.sysrowsetcolumns' 的 7 页中有 590 行。
sys.sysrowsets的 DBCC 结果。
对象 'sys.sysrowsets' 的 1 页中有 90 行。
sysallocunits的 DBCC 结果。
对象 'sysallocunits' 的 2 页中有 102 行。
sys.sysfiles1的 DBCC 结果。
对象 'sys.sysfiles1' 的 1 页中有 2 行。
sys.syshobtcolumns的 DBCC 结果。
对象 'sys.syshobtcolumns' 的 9 页中有 590 行。
sys.syshobts的 DBCC 结果。
对象 'sys.syshobts' 的 1 页中有 90 行。
sys.sysftinds的 DBCC 结果。
对象 'sys.sysftinds' 的 1 页中有 1 行。
sys.sysserefs的 DBCC 结果。
对象 'sys.sysserefs' 的 1 页中有 102 行。
sys.sysowners的 DBCC 结果。
对象 'sys.sysowners' 的 1 页中有 14 行。
sys.sysprivs的 DBCC 结果。
对象 'sys.sysprivs' 的 1 页中有 156 行。
sys.sysschobjs的 DBCC 结果。
对象 'sys.sysschobjs' 的 2 页中有 90 行。
sys.syscolpars的 DBCC 结果。
对象 'sys.syscolpars' 的 11 页中有 558 行。
sys.sysnsobjs的 DBCC 结果。
对象 'sys.sysnsobjs' 的 1 页中有 1 行。
sys.syscerts的 DBCC 结果。
对象 'sys.syscerts' 的 0 页中有 0 行。
sys.sysxprops的 DBCC 结果。
对象 'sys.sysxprops' 的 0 页中有 0 行。
sys.sysscalartypes的 DBCC 结果。
对象 'sys.sysscalartypes' 的 1 页中有 27 行。
sys.systypedsubobjs的 DBCC 结果。
对象 'sys.systypedsubobjs' 的 0 页中有 0 行。
sys.sysidxstats的 DBCC 结果。
对象 'sys.sysidxstats' 的 2 页中有 153 行。
sys.sysiscols的 DBCC 结果。
对象 'sys.sysiscols' 的 2 页中有 264 行。
sys.sysbinobjs的 DBCC 结果。
对象 'sys.sysbinobjs' 的 1 页中有 23 行。
sys.sysobjvalues的 DBCC 结果。
对象 'sys.sysobjvalues' 的 32 页中有 187 行。
sys.sysclsobjs的 DBCC 结果。
对象 'sys.sysclsobjs' 的 1 页中有 16 行。
sys.sysrowsetrefs的 DBCC 结果。
对象 'sys.sysrowsetrefs' 的 0 页中有 0 行。
sys.sysremsvcbinds的 DBCC 结果。
对象 'sys.sysremsvcbinds' 的 0 页中有 0 行。
sys.sysxmitqueue的 DBCC 结果。
对象 'sys.sysxmitqueue' 的 0 页中有 0 行。
sys.sysrts的 DBCC 结果。
对象 'sys.sysrts' 的 1 页中有 1 行。
sys.sysconvgroup的 DBCC 结果。
对象 'sys.sysconvgroup' 的 0 页中有 0 行。
sys.sysdesend的 DBCC 结果。
对象 'sys.sysdesend' 的 0 页中有 0 行。
sys.sysdercv的 DBCC 结果。
对象 'sys.sysdercv' 的 0 页中有 0 行。
sys.syssingleobjrefs的 DBCC 结果。
对象 'sys.syssingleobjrefs' 的 1 页中有 144 行。
sys.sysmultiobjrefs的 DBCC 结果。
对象 'sys.sysmultiobjrefs' 的 1 页中有 180 行。
sys.sysdbfiles的 DBCC 结果。
对象 'sys.sysdbfiles' 的 1 页中有 4 行。
sys.sysguidrefs的 DBCC 结果。
对象 'sys.sysguidrefs' 的 0 页中有 0 行。
sys.sysqnames的 DBCC 结果。
对象 'sys.sysqnames' 的 1 页中有 91 行。
sys.sysxmlcomponent的 DBCC 结果。
对象 'sys.sysxmlcomponent' 的 1 页中有 93 行。
sys.sysxmlfacet的 DBCC 结果。
对象 'sys.sysxmlfacet' 的 1 页中有 97 行。
sys.sysxmlplacement的 DBCC 结果。
对象 'sys.sysxmlplacement' 的 1 页中有 17 行。
sys.sysobjkeycrypts的 DBCC 结果。
对象 'sys.sysobjkeycrypts' 的 0 页中有 0 行。
sys.sysasymkeys的 DBCC 结果。
对象 'sys.sysasymkeys' 的 0 页中有 0 行。
sys.syssqlguides的 DBCC 结果。
对象 'sys.syssqlguides' 的 0 页中有 0 行。
sys.sysbinsubobjs的 DBCC 结果。
对象 'sys.sysbinsubobjs' 的 0 页中有 0 行。
tbl_dic_enword的 DBCC 结果。
对象 'tbl_dic_enword' 的 207 页中有 53123 行。
tbl_dic_cnword的 DBCC 结果。
对象 'tbl_dic_cnword' 的 510 页中有 56008 行。
sys.queue_messages_629577281的 DBCC 结果。
对象 'sys.queue_messages_629577281' 的 0 页中有 0 行。
sys.queue_messages_661577395的 DBCC 结果。
对象 'sys.queue_messages_661577395' 的 0 页中有 0 行。
sys.queue_messages_693577509的 DBCC 结果。
对象 'sys.queue_messages_693577509' 的 0 页中有 0 行。
sys.fulltext_catalog_freelist_6的 DBCC 结果。
对象 'sys.fulltext_catalog_freelist_6' 的 17 页中有 10240 行。
qqlist的 DBCC 结果。
对象 'qqlist' 的 67021 页中有 8718115 行。
sys.fulltext_catalog_freelist_7的 DBCC 结果。
对象 'sys.fulltext_catalog_freelist_7' 的 1 页中有 0 行。
sys.fulltext_index_map_805577908的 DBCC 结果。
对象 'sys.fulltext_index_map_805577908' 的 39484 页中有 8718115 行。
tblexchangeuser的 DBCC 结果。
对象 'tblexchangeuser' 的 1326 页中有 45233 行。
tbluser的 DBCC 结果。
对象 'tbluser' 的 20742 页中有 488672 行。
dtproperties的 DBCC 结果。
对象 'dtproperties' 的 0 页中有 0 行。
CHECKDB 在数据库 'test001' 中发现 0 个分配错误和 0 个一致性错误。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

如果是真的，那这应该算个bug，我测试下。

这样看貌似应该不是空间满，造成表消失吧。有这等事儿，我也测测看，lz数据库版本是？
select @@version

经过测试，果然有问题噢：USE master
GO
--创建测试数库
CREATE DATABASE [DB_TEST]
ON PRIMARY
(
    NAME = N'DB_TEST',
    FILENAME = N'D:\SQL2008\Data\DB_TEST.mdf' ,
    SIZE = 512MB ,
    FILEGROWTH = 1024KB,
    MAXSIZE = 524288KB
)
LOG ON
(
    NAME = N'DB_TEST_log',
    FILENAME = N'D:\SQL2008\Log\DB_TEST_log.ldf' ,
    SIZE = 1024KB ,
    FILEGROWTH = 1024KB
)
GO USE [DB_TEST]
GO
CREATE TABLE TB_TEST (ID INT IDENTITY(1,1) PRIMARY KEY,B DATETIME)
GO
INSERT INTO  TB_TEST SELECT GETDATE()
GO 100000
SELECT name AS [File Name] , physical_name AS [Physical Name], size/128/1024.0 AS [Total Size in GB],
size/128.0/1024 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0/1024 AS [Available Space In GB],
case is_percent_growth when 0 then growth/128.0 else growth end  as [Growth Size in MB or Percent]
,is_percent_growth FROM sys.database_files;
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Tmp_TB_TEST
(
ID int NOT NULL IDENTITY (1, 1),
B char(7000) NULL
)  ON [PRIMARY]
GO
ALTER TABLE dbo.Tmp_TB_TEST SET (LOCK_ESCALATION = TABLE)
GO
SET IDENTITY_INSERT dbo.Tmp_TB_TEST ON
GO
IF EXISTS(SELECT * FROM dbo.TB_TEST)
EXEC('INSERT INTO dbo.Tmp_TB_TEST (ID, B)
SELECT ID, CONVERT(char(7000), B) FROM dbo.TB_TEST WITH (HOLDLOCK TABLOCKX)')
GO
SET IDENTITY_INSERT dbo.Tmp_TB_TEST OFF
GO
DROP TABLE dbo.TB_TEST
GO
EXECUTE sp_rename N'dbo.Tmp_TB_TEST', N'TB_TEST', 'OBJECT'
GO
ALTER TABLE dbo.TB_TEST ADD CONSTRAINT
PK__TB_TEST__3214EC277F60ED59 PRIMARY KEY CLUSTERED
(
ID
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]GO
COMMIT出错信息：
Msg 1105, Level 17, State 2, Line 1
无法为数据库 'DB_TEST' 中的对象 'dbo.Tmp_TB_TEST' 分配空间，因为 'PRIMARY' 文件组已满。请删除不需要的文件、删除文件组中的对象、将其他文件添加到文件组或为文件组中的现有文件启用自动增长，以便增加可用磁盘空间。
Msg 1088, Level 16, State 11, Line 1
找不到对象 "dbo.Tmp_TB_TEST"，因为它不存在或者您没有所需的权限。
Msg 15248, Level 11, State 1, Procedure sp_rename, Line 321
参数 @objname 不明确或所声明的 @objtype (OBJECT)有误。
Msg 4902, Level 16, State 1, Line 1
找不到对象 "dbo.TB_TEST"，因为它不存在或者您没有所需的权限。
Msg 3902, Level 16, State 1, Line 1
COMMIT TRANSACTION 请求没有对应的 BEGIN TRANSACTION。

这太BT了，我试着用ApexSQL Recover恢昨被drop的数据，是可以恢复的：-- Created with ApexSQL Recover 2011.2 ON 2012/12/26 16:18:43
-- Server MYSERVERNAME\SQL2008
-- Database DB_TEST
PRINT '***************************************************************************************************'
PRINT 'WARNING: ApexSQL Recover is under evaluation on this server and only every 10th row has been recovered.'
PRINT '***************************************************************************************************'IF EXISTS(SELECT * FROM sysobjects WHERE id = OBJECT_ID(N'[dbo].[TB_TEST]') AND OBJECTPROPERTY(id, N'IsTable') = 1)
PRINT 'Table [dbo].[TB_TEST] already exists.'
ELSE
CREATE TABLE [dbo].[TB_TEST] /* ID = 2105058535 */
(
[ID] int NOT NULL IDENTITY,
[B] datetime NULL
)
-- RECOVERED ROWS FROM [dbo].[TB_TEST], ID = 2105058535
SET IDENTITY_INSERT [dbo].[TB_TEST] ON
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (1, '20121226 16:10:16.443')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (101, '20121226 16:10:16.473')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (201, '20121226 16:10:16.500')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (301, '20121226 16:10:16.530')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (401, '20121226 16:10:16.560')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (501, '20121226 16:10:16.590')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (601, '20121226 16:10:16.607')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (701, '20121226 16:10:16.623')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (801, '20121226 16:10:16.640')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (901, '20121226 16:10:16.697')
GO
SET IDENTITY_INSERT [dbo].[TB_TEST] ON
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (1001, '20121226 16:10:16.713')
INSERT INTO [dbo].[TB_TEST] ([ID], [B]) VALUES (1101, '20121226 16:10:16.730')

这应该是生成脚本时产生的Bug，能过界面操作没有这个问题。
脚本生成时，自动加上了GO，造成了这个问题。因为是SQL2005，所以楼主可以尝试使用log explorer for sql server 4.2看看能不能找回数据。

看来在别更表列之前，为了防止日志文件大幅度增长还是把恢复模式置为大容量插入吧···
脚本自动加了go，导致没有找到 BEGIN TRANSACTION么····

用 alter table 就不会有这样的问题了

这个是用SQL Server Managent Studio的表设计器
然后生成变更脚本生成的脚本

ApexSQL Recover支持SQL Server 2008了？

早就支持的吧？我用的SQL 2008 R2呢。。不过收费的
总结了一下：
http://www.cnblogs.com/nzperfect/archive/2012/12/26/2834479.html

其實是自找麻煩，直接使用命令即可。因為使用SQL Server 的Design介面修改的時候，內部會先create一個table ：Tmp_TB_TEST，再copy原數據到mp_TB_TEST，再Drop 原table，然後調用系統存儲過程sp_rename，把Tmp_TB_TEST改成原table。即使按照SQL Server內部的過程一步一步的執行代碼，某一步驟出錯就停，也不至於到最後發現沒了原table。

这个傻子是在m-studio的图形界面做的。才会有这种情况。不过，看看图形界面的语句，是将数据表改名了，再插入到新的表的，改名的表是可以找到的

既然是盘满了,而且在盘满的时候又在做大容量的数据腾挪操作,出些错误就不奇怪了.DBMS本来要做的事情没继续向下做罢了.

你白痴我是用sql生成的语句执行的，看帖子没，会中文？
回去你的幼儿园再进修几年。
你不废话直接界面修改300W条数据就让数据超时丢失。

数据库就5000万条数据，mdf文件15G，第一次操作预留50G空间。
但是执行操作却消耗了 86G的空间，你懂？这是为什么么？

其实是Log文件导致的吧，下回修改表结构之前，把数据库恢复模式变成大容量插入就应该可以避免这种因为Insert语句导致的日志文件暴涨

调试易

执行更改，数据库日志导致盘满了，数据表消失。

解决方案 »