Questions tagged «bulk-insert»

4
为什么批量插入被认为是危险的?
此问题是从Information Security Stack Exchange 迁移的,因为可以在Database Administrators Stack Exchange上回答。 迁移 2年前。 我想了解为什么一般的网络安全团队(我处理过的一个以上的组织BULK INSERT)对于向应用程序和数据库程序员授予(例如TSQL)权限是一成不变的?我无法相信“填补磁盘滥用”的借口,除非我遗漏了一些东西,因为最终结果与执行类似操作的应用程序没有什么不同: for (long i = 0; i < LONG_MAX; ++i) executeSQL("INSERT INTO table VALUES(...)"); 并且INSERT是具有基本写权限的任何人都可以执行的常见DML命令。 为了使应用程序受益,BULK INSERT它效率更高,速度更快,并且使程序员无需解析SQL之外的文件。 编辑:我最初在信息安全站点上问这个问题是有原因的-不是DBA反对使用BULK INSERT,而是“信息保证”(IA简称-网络安全人员)正在迫使该问题。我让这个问题再讲一两天,但是如果批量操作确实确实绕过了约束或触发器,我可以看到这是一个问题。

1
依靠INSERT的OUTPUT子句的顺序是否安全?
给定此表: CREATE TABLE dbo.Target ( TargetId int identity(1, 1) NOT NULL, Color varchar(20) NOT NULL, Action varchar(10) NOT NULL, -- of course this should be normalized Code int NOT NULL, CONSTRAINT PK_Target PRIMARY KEY CLUSTERED (TargetId) ); 在两种略有不同的方案中,我想插入行并从标识列返回值。 场景1 INSERT dbo.Target (Color, Action, Code) OUTPUT inserted.TargetId SELECT t.Color, t.Action, t.Code …


4
通过网络批量插入
有人可以帮我这些吗? BULK INSERT DATABESE01.dbo.TABLE01 FROM '\\COMPUTER01\FOLDER01\TextFile.txt' WITH ( FIELDTERMINATOR = ' ', rowterminator = '\n', tablock ) 错误显示,无法打开: 无法批量插入,因为无法打开文件“ \ SERVERNAME \ FOLDERNAME \ textFile.txt”。操作系统错误代码5(访问被拒绝。) 该路径在网络上的另一台计算机上。

2
为BULK INSERT配置不受约束的委托
我在Always On可用性组中有一对Microsoft SQL Server 2016节点。我正在尝试对BULK INSERTWindows Server 2016文件服务器故障转移群集上的文件执行(使用SQL Server 2016 Management Studio查询),但是出现以下错误: 消息4861,级别16,状态1 无法批量加载,因为无法打开文件“ \ nas2.my.domain \ Microsoft SQL Server 2016 Enterprise \ test.txt”。操作系统错误代码5(访问被拒绝。)。 无论我使用活动节点名称(nas2.my.domain)还是故障转移群集侦听器(nas.my.domain),都会发生这种情况。 环顾四周后,我发现这是由于SQL Server无法模拟与我连接的用户帐户所致BULK INSERT。 如果使用Windows身份验证连接到SQL Server,则SQL Server服务帐户将在连接到文件服务器时尝试模拟您的用户帐户。如果使用SQL Server身份验证进行连接,它将以SQL Server服务帐户连接到文件服务器。 如果未正确配置委派和模拟(默认状态),则SQL Server服务将无法模拟您的用户帐户,并且将退回尝试以匿名用户身份连接到文件服务器。 可以通过查看文件服务器上的安全事件日志来确认。这些事实以及有关配置不受约束和受约束的委派的指南记录在以下链接中: 如何:约束委派的SQL Server批量插入(访问被拒绝) 批量插入和Kerberos 我已经尝试按照thesqldude指南中的说明进行操作,但是仍然无法正常工作。 我尝试访问的数据库BULK INSERT不是可用性组的一部分,因此只有MSSQL1节点才有意义。文件服务器在NAS2节点上处于活动状态。检查文件服务器上的事件日志确实表明它仍然遇到此问题,并且SQL Server尝试以匿名用户身份验证文件服务器,而不是模拟我的用户帐户。 有人知道出什么事了吗?还是为了使这些指南过时而在SQL Server 2016中进行了某些更改? 文件服务器安全事件日志条目 服务帐户委托 服务帐户SPN SQL …

3
如何调查BULK INSERT语句的性能?
我主要是使用Entity Framework ORM的.NET开发人员。但是,因为我不想失败使用ORM,所以我试图了解数据层(数据库)中发生的情况。基本上,在开发过程中,我启动了探查器,并检查了查询中代码的某些部分生成了什么。 如果我发现非常复杂的东西(即使不仔细编写,ORM甚至可以从相当简单的LINQ语句生成可怕的查询)和/或繁重的事情(持续时间,CPU,页面读取),请在SSMS中进行处理并检查其执行计划。 对于我的数据库知识水平,它工作正常。但是,BULK INSERT似乎是一种特殊的生物,因为它似乎不会产生SHOWPLAN。 我将尝试说明一个非常简单的示例: 表定义 CREATE TABLE dbo.ImportingSystemFileLoadInfo ( ImportingSystemFileLoadInfoId INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_ImportingSystemFileLoadInfo PRIMARY KEY CLUSTERED, EnvironmentId INT NOT NULL CONSTRAINT FK_ImportingSystemFileLoadInfo REFERENCES dbo.Environment, ImportingSystemId INT NOT NULL CONSTRAINT FK_ImportingSystemFileLoadInfo_ImportingSystem REFERENCES dbo.ImportingSystem, FileName NVARCHAR(64) NOT NULL, FileImportTime DATETIME2 NOT NULL, CONSTRAINT UQ_ImportingSystemImportInfo_EnvXIs_TableName UNIQUE …

1
批量插入后,外键变得不受信任
在具有2012兼容模式下数据库的SQL 2014版服务器(12.0.2430.0-尚无SP1)中(正在努力将其切换到2014 ...),我有少数几个外键对象,这些外键对象not trusted在数据库中始终标记为。我删除并重新创建了没有NOCHECK选项的它们,但是在5到10分钟内,它们再次变得不受信任,如果我生成CREATE脚本,它将显示为: ALTER TABLE [dbo].[Points] WITH NOCHECK ADD CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId]) REFERENCES [dbo].[Badge] ([Id]) GO 使用的创建脚本为: ALTER TABLE [dbo].[Points] ADD CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId]) REFERENCES [dbo].[Badge] ([Id]) GO ALTER TABLE [dbo].[Points] CHECK CONSTRAINT [FK_BadgeId] GO 没有复制,没有第三方工具,而且我正在监视数据库中的所有DDL语句,因此它不是另一个用户。 我能够很好地检查约束(WITH CHECK CHECK在每个约束上使用),但是不久之后它们仍然变得不受信任。只有运行的维护工作是Ola在AM的早期工作,并且整天都在进行。 更新: 因此,在经过几次跟踪以缩小可能性后,似乎BULK INSERT可能导致FK变得不可信。这个msdn问题指出,这是密钥变得不受信任的有效途径,这是我第一次听说。 所以我现在的问题是,有没有一种替代方法BULK INSERT可以保持外键is_trusted状态?它是在每小时运行几次的应用程序的上下文中执行的。我可以让开发人员批处理其插入语句,但是BULK INSERT如果不需要的话,我不希望在使用时使用最后通atum 。

2
Tablock提示触发死锁
我使用最少的日志记录,通过两个并行运行的Execute SQL Tasks和以下形式的SQL将两个数据集插入到空堆表中。 INSERT INTO Table (TABLOCK) SELECT FROM ... 作业暂停后,其中一个SQL任务成为死锁受害者。下面是死锁图的XML输出。 有人可以解释幕后发生的事情吗? <resource-list> <objectlock lockPartition="0" objid="1586156746" subresource="FULL" dbid="7" objectname="dbo.TargetTable" id="lock7374a00" mode="IX" associatedObjectId="1586156746"> <owner-list> <owner id="process9609dc8" mode="Sch-S"/> <owner id="process9609dc8" mode="IX"/> </owner-list> <waiter-list> <waiter id="process5e13048" mode="X" requestType="convert"/> </waiter-list> </objectlock> <objectlock lockPartition="0" objid="1586156746" subresource="FULL" dbid="7" objectname="dbo.TargetTable" id="lock7374a00" mode="IX" associatedObjectId="1586156746"> <owner-list> <owner id="process5e13048" mode="Sch-S"/> …

1
SQL中的最小记录条件
我已经写了一个脚本来测试此页面上的声明http://technet.microsoft.com/zh-cn/library/dd425070(v=sql.100).aspx,其标题为“何时汇总最小记录条件”最小记录不会或不会发生。 使用此脚本,我发现每种不同类型的插入的日志记录长度的总和如下: 堆空没有Tablock 60000 带有锁的堆空​​56000 堆非空无制表符60000 非空堆,带锁56000 堆加索引为空,没有制表符126188 堆加索引为空,带挂锁114188 堆加索引非空无选项卡锁138696 带有Tablock的堆加索引不为空112000 集群为空命令无制表符64168 集群空,带tablock 56168命令 群集为空无序无标签锁73388 空群集,无序,带有tablock 65388 群集非空无标签锁63912 带锁的群集非空55944 群集加索引为空,没有制表符124336 带有Tablock的簇加索引为空108336 群集加索引非空无选项卡锁123876 带Tablock的群集加索引不为空107924 其中一些数字似乎与technet页面上的表不匹配。特别是: 插入到空表和非空表之间的日志记录似乎没有什么区别,但是该页面声称,插入到没有制表符的非空集群中时,应该有完整的日志记录 使用tablock插入具有and index的堆或群集似乎确实减少了日志记录,但是该页面声称应该有完整的日志记录。 使用insert的SELECT INTO方法时,fn_dblog中没有要插入其操作的行,但是该页将该方法列为应具有表中所述行为的批量加载操作。 作为参考,它在SQL Express数据库上运行,当我运行DBCC TRACESTATUS(610)时,所有内容均为0。 谁能帮助解释为什么我会看到这些差异? 供参考,代码如下: SET NOCOUNT ON CREATE TABLE numbers (num INT) CREATE TABLE numbersUnordered (num INT) Declare @cnt int …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.