尝试创建聚集索引
时出现以下错误语句已终止。
Msg 596, Level 21, State 1, Line 0
无法继续执行，因为会话处于kill状态状态。Msg 0, Level 20, State 0, Line 0
当前命令发生严重错误。结果，如果有，应该被丢弃。
索引为:
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
GO
CREATE CLUSTERED INDEX IX_CO_DES_INPUT
ON dbo.CO_DES_INPUT(DESIGN_ID, PRODUCT_INPUT_NUM, INPUT_NAME)
WITH(STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE dbo.CO_DES_INPUT
SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
我使用
Microsoft SQL Server 2012 (SP3) (KB3072779) - 11.0.6020.0 (X64)
Windows NT 6.3 (Build 9600:)标准版(64位)
I have run
DBCC CheckDB ('concept-test') WITH NO_INFOMSGS, ALL_ERRORMSGS
没有发现任何问题
我担心我的数据库是损坏的，因为我得到这个错误。我如何纠正我的问题，并把这个索引放在桌子上?
感谢出现这种状态的常见原因有:
- 系统无法打开数据或日志文件所在的设备
- 在创建或打开物理设备时找不到指定的文件
- SQL Server在事务中崩溃
- 由于安装了杀毒软件，上网时无法访问数据或日志文件
- 数据库服务器被非法关闭
- 磁盘空间不足，无法写入
- SQL无法完成回滚或前滚操作
- 数据库文件被第三方备份软件锁定
如何解决
首先找出问题的原因。请回到上一步，检查是否是上述原因造成的。例如:磁盘空间不足。
对于根本原因，我们必须先解决根本问题，然后再修复数据库。
包括:
- 检查系统是否更新，是否存在严重安全隐患，是否被黑客入侵
- 检查系统电源是否稳定
- 检查磁盘空间是否足够
- 检查数据库文件是否对数据库进程有读写权限
- 检查是否安装了第三方杀毒软件
- 检查是否安装第三方备份软件
- 尝试将数据库文件挂载到另一台计算机
如果您已经解决了底层问题，您可以按照下面的步骤操作。注意，在启动数据库之前，如果数据库是虚拟机，强烈建议使用虚拟机快照。
10步修复法
1。打开ssm
打开SSMS并连接失败的SQL Server实例。
2。准备执行SQL
查找错误状态的数据库，注意不要扩展它。创建一个新的查询。
3。将数据库设置为紧急状态
执行以下SQL
EXEC sp_resetstatus database_name;
ALTER DATABASE database_name SET EMERGENCY
这将数据库设置为紧急状态，以允许进一步修复。
4。在数据库上运行错误扫描
执行以下SQL
DBCC CHECKDB (database_name)
DBCC CHECKCATALOG (database_name)
这将在当前故障数据库上运行故障扫描。你可能会看到很多失败。这些错误可以依次检查。请注意，此步骤不会修复任何错误。
5。准备修复
要运行数据库修复脚本，必须将数据库设置为单个用户。这也可以防止其他可能在修理过程中的人不小心进来。
同时，我们希望回滚最近的事务，因为最后一个事务一定失败了，并且很可能是最后一个事务导致了数据库故障。
ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE
6。运行修复
DBCC CHECKDB (database_name, REPAIR_FAST) -- quick fix
DBCC CHECKDB (database_name, REPAIR_REBUILD) -- reset index
DBCC CHECKDB (database_name, REPAIR_ALLOW_DATA_LOSS) -- Allows correction of missing data
DBCC CHECKALLOC (database_name, REPAIR_REBUILD) -- Fixed allocation problem
DBCC DBREINDEX (database_name, REPAIR_REBUILD) -- fix index problem
上面的代码将尝试修复数据库错误。如果您在执行过程中遇到障碍，请查看本文末尾的高频问题章节。
注意，在上面的代码中，REPAIR_ALLOW_DATA_LOSS表示为了修复数据库，允许丢弃数据。第六步可能需要很长时间，对于30GB左右的数据库，通常需要几个小时。需要耐心等待。
运行上面的SQL可能不会完全修复。您可以使用以下SQL多次修复错误。
DECLARE @Number INT = 1 ;
While @Number < = 10
Begin
PRINT @Number;
SET @Number = @Number + 1 ;
DBCC CHECKDB(database_name, REPAIR_ALLOW_DATA_LOSS)
End
7。重新允许多用户连接到数据库
此时，数据库已经恢复。我们可以重新允许多个数据库连接。
ALTER DATABASE database_name SET MULTI_USER
8。立即备份
此时，数据库已达到可用状态。应该立即备份数据库，以导出可用数据状态的副本。如果数据库是虚拟机，建议在备份的同时进行快照。
同时，建议重新启动整个数据库服务器，并检查重启后数据库是否仍然正常。这是为了避免可能导致重复的数据库泄漏。
9。检查数据
在可用数据可用后，我们可以检查当前数据库状态是否为新状态。
10。修复其他错误
在上述过程结束时，虽然大部分数据已经可用，但数据库中仍然存在更多的错误。
您可以使用以下SQL查看这些错误:
DBCC CHECKDB (database_name)
如果您想修复这部分错误，您可以尝试备份，然后恢复备份，这可能会解决这部分问题。
常见问题解答
当数据库处于单用户状态时，我们无法离开当前连接。因为一旦我们离开，可能还有其他连接直接被占用。
在这种情况下，我们必须手动杀死其他匆忙进入的连接，以确保我们是唯一正在操作数据库的用户。
方法如下:
先执行以下SQL
Select d.name, d.dbid, spid, login_time, nt_domain, nt_username, loginame
From sysprocesses p inner join sysdatabases d on p.dbid = d.dbid
Where d.name = 'testdb01'
Go
您将看到输出会话的列表，并找出传入连接的SPID。例如，SPID为51。
执行以下SQL
Kill 51
Go
此时，我们可以继续在这个单用户数据库上执行SQL。
被安度因接受的答案是正确的答案，这是为了方便人们搜索。如果
- 您缺少一个临时表，
- 你自己做了一个RAISERROR (sic)调用，指示表缺失
"Cannot continue execution because the session is in the kill state"是误导(因为它暗示你的连接会话无效;你仍然是连接的)，并且会把你发送到像这样的帖子。但是，在输出的前面，您将看到实际抛出的异常消息。忽略那些分散你注意力的可怕信息，它们会把你的注意力从真正的问题上移开。
的例子:SQL代码:
IF OBJECT_ID('tempdb..##example') IS NULL
BEGIN -- include ##example
RAISERROR('ERROR: table ##example not loaded', 20, -1) WITH LOG
-- This is often done to give intellisense hints when including tables
CREATE TABLE ##example(ID INT, mydata VALUE)
END -- include ##example
错误信息:
Msg 2745, Level 16, State 2, Line 3
Process ID 57 has raised user error 50000, severity 20. SQL Server is terminating this process.
Msg 50000, Level 20, State 1, Line 3
ERROR: table ##example not loaded
Msg 596, Level 21, State 1, Line 0
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.
Completion time: 2019-11-27T08:28:21.1089985-07:00`
类似于sajjad的问题，我在SQL Server 2017中使用时态表时遇到此错误。我从头开始复制它。下面是我管理的最小的例子。升级到SQL Server 2019解决了我的问题。
USE master
DROP DATABASE IF EXISTS MyTest
GO
CREATE DATABASE MyTest
GO
USE MyTest
CREATE TABLE MyParent (
ID int NOT NULL,
CONSTRAINT [PK_TestGroupDetails] PRIMARY KEY (ID)
);
CREATE TABLE MyChild (
ID int NOT NULL,
MyParentID int NOT NULL,
Dummy BIT NOT NULL,
SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START,
SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END,
PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime),
CONSTRAINT [PK_Child] PRIMARY KEY (ID),
CONSTRAINT [FK_Parent] FOREIGN KEY (MyParentID) REFERENCES MyParent (ID) ON DELETE CASCADE
);
-- To avoid the "Cannot continue the execution because the session is in the kill state", I can do any of the following:
-- Remove this DROP COLUMN line only
-- Remove all references to the Dummy column
-- Remove the Dummy column from the initial CREATE TABLE, and uncomment the ADD line below
-- Move this DROP COLUMN line so that it occurs after the SET (SYSTEM_VERSIONING = ON)
-- Remove the ON DELETE CASCADE
--ALTER TABLE MyChild ADD Dummy BIT
ALTER TABLE MyChild DROP COLUMN Dummy
ALTER TABLE MyChild SET (SYSTEM_VERSIONING = ON)
DELETE FROM MyParent
在查询中使用索引提示时收到此错误，如果索引已损坏
[...]
INNER JOIN WeigherReport AS Report WITH INDEX([IX_weigherYY])) ON ProdRun.Id = Report.ProductionRun
解决方案是删除并重新创建有问题的索引(在本例中是IX_weigherYY)。
- 备份数据库
- 卸载数据库
- 删除数据库日志文件
- 附加数据库
我的回答是针对发生在我身上的情况，我希望也许对你有用!当我运行删除行查询时，你的问题中提到了错误。我们的团队使用Sql Server历史(时态表)审计所有数据。通过禁用我数据库中的所有历史表，查询执行得很好，没有任何错误。我猜你有一个约束或配置在你的数据库中，防止执行你的查询，所以sql显示这个不清楚的消息。
在我的例子中，我耗尽了磁盘空间。我右键单击数据库，选择任务，然后收缩数据库。这将数据库的大小减少了50%。我重试了我的命令，它工作。
数据库属性->选项→兼容级别->
set Sql Server 2016