【转】SQLServer DBA 必看：一次 DBeaver 导入失败，竟内藏玄机！
【转】SQLServer DBA 必看：一次 DBeaver 导入失败，竟内藏玄机！
原作者： 三笠、
前言
在前篇文章《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
CROSSAPPLY sys.dm_exec_sql_text(qs.sql_handle) qt
WHERE qt.text LIKE'%zhangsan%'
OR qt.text LIKE'%IDENTITY_INSERT%'
ORDERBY 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
CROSSAPPLY sys.dm_exec_sql_text(qs.sql_handle) qt
WHERE qt.text LIKE'%ALTER%'
AND qt.text LIKE'%zhangsan%'
ORDERBY 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
LEFTJOIN sys.database_role_members rm ON p.principal_id = rm.member_principal_id
LEFTJOIN 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
LEFTJOIN sys.objects o ON p.major_id = o.object_id
LEFTJOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE p.grantee_principal_id = USER_ID('LUCIFER')
ORDERBY 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
LEFTJOIN sys.objects o ON p.major_id = o.object_id
LEFTJOIN 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')
)
ORDERBY p.permission_name, s.name, o.name;当然还有很多授权的语句，就不一一列举了！
写在最后
在技术问题的排查过程中，表面现象往往只是冰山一角。本次问题看似是简单的权限不足，但实际涉及到 DBeaver 内部的导入机制和 SQLServer 的安全策略。
通过这次问题的解决，不仅找到了根本原因，还深入了解了 DBeaver 的内部工作机制和 SQL Server 的权限管理体系。正如古语所言："山重水复疑无路，柳暗花明又一村"，技术问题的解决过程虽然曲折，但最终的收获往往超出预期。
本文系转载，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文系转载，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
