前言

在前篇文章《SQL Server 创建账号密码复杂度问题》中，我们创建了一个具有增删改查权限的数据库账号。然而，用户在使用 DBeaver 连接该账号导入 CSV 文件时遇到了报错：

按理说，既然账号具有 insert 权限，DBeaver 导入 CSV 应该能够正常工作啊！为了验证权限是否正确，我试了一下执行 INSERT 语句，数据可以插入成功。

因为 CSV 数据不多，我就先手动把几十条数据先手动 insert 进去了，临时解决了问题，但是后面要是有几千条数据呢？不能还手动 insert 吧，而且这个问题引起了我的好奇心 – 为什么会出现这种情况呢？

经过深入研究，终于找到了根本原因。本文记录一下问题分析和解决过程，以供后续参考。

问题复现

使用新创建的账号连接 DBeaver 进行数据导入操作：

导入过程中出现权限错误：

问题分析

理论上，DBeaver 导入 CSV 到表中只需要基本的 INSERT 权限。为了找出问题根源，我检查了 DBeaver 导入失败时的详细错误日志：

通过分析异常堆栈（这里花费了不少时间），发现错误发生在：

SQLServerTableBase.enableIdentityInsert(SQLServerTableBase.java:266)
SQLServerTableBase.beforeDataChange(SQLServerTableBase.java:253)

这说明 DBeaver 在导入数据前会尝试执行 SET IDENTITY_INSERT ON 操作。具体执行的 SQL 语句应该是：

SET IDENTITY_INSERT WANGDS.dbo.zhangsan ON;

而 SET IDENTITY_INSERT 操作需要表的 ALTER 权限！这是 SQL Server 的安全机制，因为该操作会临时改变表的行为，允许向 IDENTITY 列显式插入值。

为什么会执行 IDENTITY_INSERT 操作？

检查目标表的结构：

CREATE TABLE WANGDS.dbo.zhangsan (
      id int IDENTITY(1,1) NOT NULL,
......

表中确实存在 IDENTITY 自增列 id int IDENTITY(1,1)！

当 DBeaver 检测到目标表含有 IDENTITY 列时，其 SQLServer 适配器会预防性地启用 IDENTITY_INSERT，以确保在 CSV 文件包含 ID 值时也能正确导入。

DBeaver 的完整导入流程如下：

SET IDENTITY_INSERT WANGDS.dbo.zhangsan ON;
-- 导入数据
SET IDENTITY_INSERT WANGDS.dbo.zhangsan OFF;

突然想起来之前看 CSV 文件的发现 ID 列怎么都是空值，这解释了为什么 CSV 文件中的 ID 列都是空值，看来 CSV 文件是没问题的。

问题验证

为了验证分析结果，手动执行以下 SQL：

SET IDENTITY_INSERT WANGDS.dbo.zhangsan ON;

执行结果确实报错，错误信息与 DBeaver 的报错一致：

解决方案

问题的解决方法很简单，授予用户对目标表的 ALTER 权限：

GRANT ALTER ON dbo.zhangsan TO LUCIFER;

执行该语句后，DBeaver 导入功能恢复正常。

排查过程中的实用 SQL

在问题排查过程中，以下 SQL 语句提供了重要的诊断信息：

-- 查找包含特定关键词的最近执行语句，用于排查 IDENTITY_INSERT 相关操作
SELECT TOP 20
    qt.text AS sql_text,
    qs.execution_count,
    qs.last_execution_time,
    qs.total_elapsed_time,
    qs.total_logical_reads
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
WHERE qt.text LIKE '%zhangsan%'
   OR qt.text LIKE '%IDENTITY_INSERT%'
ORDER BY qs.last_execution_time DESC;

-- 专门查找 ALTER 语句，用于确认是否有实际的表结构修改操作
SELECT TOP 10
    qt.text AS sql_text,
    qs.last_execution_time
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
WHERE qt.text LIKE '%ALTER%'
   AND qt.text LIKE '%zhangsan%'
ORDER BY qs.last_execution_time DESC;

-- 查看用户所属的数据库角色，了解用户通过角色继承了哪些权限
SELECT
    p.name AS principal_name,
    p.type_desc AS principal_type,
    r.name AS role_name
FROM sys.database_principals p
LEFT JOIN sys.database_role_members rm ON p.principal_id = rm.member_principal_id
LEFT JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id
WHERE p.name = 'LUCIFER';

-- 查看用户直接被授予的对象级权限，显示用户对特定对象（表、视图等）的权限
SELECT
    p.permission_name,
    p.state_desc,
    s.name AS schema_name,
    o.name AS object_name
FROM sys.database_permissions p
LEFT JOIN sys.objects o ON p.major_id = o.object_id
LEFT JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE p.grantee_principal_id = USER_ID('LUCIFER')
ORDER BY s.name, o.name;

-- 查看用户的所有有效权限（包括通过角色继承的），这是最全面的权限检查，包括直接权限和角色权限
SELECT
    p.permission_name,
    p.state_desc,
    p.class_desc,
    ISNULL(s.name, '') AS schema_name,
    ISNULL(o.name, '') AS object_name
FROM sys.database_permissions p
LEFT JOIN sys.objects o ON p.major_id = o.object_id
LEFT JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE p.grantee_principal_id = USER_ID('LUCIFER')
   OR p.grantee_principal_id IN (
       SELECT role_principal_id
       FROM sys.database_role_members
       WHERE member_principal_id = USER_ID('LUCIFER')
   )
ORDER BY p.permission_name, s.name, o.name;

当然还有很多授权的语句，就不一一列举了！

写在最后

在技术问题的排查过程中，表面现象往往只是冰山一角。本次问题看似是简单的权限不足，但实际涉及到 DBeaver 内部的导入机制和 SQLServer 的安全策略。

通过这次问题的解决，不仅找到了根本原因，还深入了解了 DBeaver 的内部工作机制和 SQL Server 的权限管理体系。正如古语所言：“山重水复疑无路，柳暗花明又一村”，技术问题的解决过程虽然曲折，但最终的收获往往超出预期。