タグ付けされた質問 「bulk-insert」

4
なぜBULK INSERTは危険と見なされますか?
この質問は、データベース管理者のStack Exchangeで回答できるため、Information Security Stack Exchangeから移行されました。 2年前に移行され ました。 一般にサイバーセキュリティチーム(私が扱った複数の組織)がBULK INSERTアプリケーションやデータベースプログラマーに(TSQLなどの)権利を付与することに対して何の不満があるのか​​を理解したいと思いますか?最終的な結果は次のようなことを行うアプリケーションと変わらないため、何かを逃さない限り、「ディスクの乱用を埋める」という言い訳は信じられません。 for (long i = 0; i < LONG_MAX; ++i) executeSQL("INSERT INTO table VALUES(...)"); これINSERTは、基本的な書き込み権限を持つ人が実行できる一般的なDMLコマンドです。 アプリケーションの利点として、BULK INSERTはるかに効率的で高速であり、プログラマーはSQLの外部でファイルを解析する必要がなくなります。 編集:私はもともと情報セキュリティサイトでこの質問をしました-BULK INSERTを使用することに反対しているのはDBAではなく、「情報保証」(略してIA-サイバーセキュリティの人々)が問題を強要しているからです。この質問をあと1日か2日シチューさせますが、バルク操作が実際に制約またはトリガーをバイパスする場合、問題であることがわかります。

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) ); わずかに異なる2つのシナリオで、行を挿入し、ID列から値を返します。 シナリオ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
一括挿入の制約のない委任を構成する
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 私はsqldudeのガイドの指示に従ってみましたが、まだ機能していません。 私が行おうとし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 …

2
Tablockヒントがデッドロックをトリガーする
最小限のログを使用して、2つのデータセットを空のヒープテーブルに挿入しました。これは、次の形式のSQLで並列実行されている2つのSQL実行タスクを使用して行われました。 INSERT INTO Table (TABLOCK) SELECT FROM ... ジョブが少しハングした後、SQLタスクの1つがデッドロックの犠牲になりました。以下は、デッドロックグラフの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"/> <owner id="process5e13048" …

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それぞれで使用)が、その後すぐに信頼できなくなります。実行される保守ジョブのみが午前AMのOlaであり、これは1日中行われます。 更新: したがって、可能性を絞り込むためにいくつかのトレースを行った後、それBULK INSERTが原因でFKが信頼されなくなる可能性があります。このmsdnの質問は、これがキーが信頼されなくなるための有効なルートであることを示しています。これは私が聞いた最初のルートです。 だから私の質問は、BULK INSERT外部キーのis_trustedステータスを維持できる使用する代替戦略はありますか?1時間に数回実行されるアプリケーションのコンテキストで実行されています。代わりに、開発者に挿入ステートメントをバッチ処理させることもできますが、BULK INSERT必要がない場合は、最終通告を使用しないようにします。

1
SQLの最小限のロギング条件
このページhttp://technet.microsoft.com/en-us/library/dd425070(v=sql.100).aspxで行われた要求をテストするためのスクリプトを作成しました。最小限のロギングが行われるか、行われません。 このスクリプトを使用すると、さまざまな種類の挿入ごとのログレコード長の合計は次のようになります。 ヒープが空でタブロックなし60000 タブロック56000でヒープが空 ヒープは空ではなく、タブロックはありません60000 タブロック56000でヒープが空ではない ヒープとインデックスが空でタブロックがない126188 ヒープとタブロック114188で空のインデックス ヒープとインデックスが空ではないタブロックなし138696 タブロック112000でヒープとインデックスが空ではない 空のクラスターがタブロックなしで注文された64168 タブロック56168で空のクラスターを注文 クラスターが空で順序付けられていないタブロックなし73388 タブロック65388でクラスタが空の順序なし クラスターが空ではなくタブロックがない63912 タブロック55944で空でないクラスター クラスターとインデックスが空でタブロックがない124336 クラスターとタブロックで空のインデックス108336 クラスターとインデックスが空ではないタブロックなし123876 タブロック107924でクラスターとインデックスが空ではない これらの数値のいくつかは、technetページの表と一致していないようです。特に: 空のテーブルへの挿入と空でないテーブルへの挿入の間にロギングに違いはないようですが、タブロックなしで非空のクラスターに挿入すると完全なロギングがあるはずですとページは主張します tablockを使用して、indexを使用してヒープまたはクラスターに挿入すると、ロギングが削減されるように見えますが、ページでは完全なロギングが必要であると主張しています。 挿入のSELECT INTOメソッドを使用する場合、fn_dblogには操作が挿入である行はありませんが、ページにはこのメソッドが、表に記載されている動作を持つはずのバルクロード操作としてリストされています。 参考までに、これはSQL Expressデータベースで実行されました。DBCCTRACESTATUS(610)を実行すると、すべてが0です。 なぜ私がこれらの矛盾を目にする可能性があるのか​​を説明するのを手伝ってくれる人はいますか? 参考までに、コードを以下に示します。 SET NOCOUNT ON CREATE TABLE numbers (num INT) CREATE TABLE numbersUnordered (num INT) Declare @cnt int Select @cnt=0 while (@cnt<500) BEGIN …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.