0

トランザクション（成功/失敗の場合は最後にBEGIN TRANSACTION、COMMIT、またはROLLBACK）を使用しているため、ConnectionManagerでRetainSameConnection=trueを使用しています。

また、デフォルトのSQL Serverログプロバイダーを使用しており、OnErrorイベント（およびその他のイベント）を選択しました。

問題は、sysssislogテーブルにログに記録されたOnErrorイベントを確認できないことです（テーブルが存在し、デフォルトの挿入SPが作成されます）-ログに記録された他のタイプのイベントを確認できます。

SQLプロファイラーを使用すると、sp_ssis_addlogentryが実行されたことを確認できます。

exec sp_executesql N'exec sp_ssis_addlogentry @ P1、@ P2、@ P3、@ P4、@ P5、@ P6、@ P7、@ P8、@ P9、@ P10、@ P11'、N'@ P1 nvarchar（4000）、@ P2 nvarchar（4000）、@ P3 nvarchar（4000）、@ P4 nvarchar（4000）、@ P5 uniqueidentifier、@ P6 uniqueidentifier、@ P7 datetime2（7）、@ P8 datetime2（7）、@ P9 int、@ P10 varbinary（ 8000）、@ P11 nvarchar（4000）'、N'OnError'、N'EWOIU027013096'、N'ad \ oiu099'、N'Empty AF SINtemp'、' 4CCEB32F-E884-483C-A02F-56D5C8438E44'、' 15F585B3- AC6C-476F-8A2E-FC926438AC84'、' 2012-07-12 14:46:15'、' 2012-07-12 14:46:15'、0,0x、N'主キー制約の違反'' CIRNAGF0p0_AF ' '。オブジェクト''dbo.TIRNAGF0_AF''に重複キーを挿入できません。

ただし、OnErrorイベントは挿入されません。

RetainSameConnectionプロパティをfalseに変更すると機能しますが、トランザクションSQLタスクに依存できません。

注：RetainSameConnection = falseを使用して、ロギング専用に別の接続マネージャーを作成しようとしましたが、機能しませんでした。

テキストファイルに問題なくログインできますが、テーブルにログインする必要があります。

前もって感謝します

4

1 に答える 1

2

私はあなたの問題を再現することはできません。あなたの説明に基づいて、私はあなたのパッケージがこのように見えると思います。SO_retain OLE接続マネージャーは、作業しているデータベースを指し、RetainConnectionプロパティをTrueに設定しました。

generic control flow

イベントOnErrorおよびOnPre/PostExecuteのログを追加しました。パッケージを2回実行しました。1回はSO_retain接続マネージャーを使用し、もう1回はSO_no_retainを使用します。

sql logging

After execution, I queried the log to see what had occurred. SELECT L.id, L.event, L.source, L.executionid FROM dbo.sysdtslog90 L ORDER BY 1; If you're using 2008/2008R2, modify the table to dbo.sysssislog.

My results were

1   PackageStart    so_Andre_LoggingTrxn    B2D17896-199F-4213-B800-E812CE95D45F
2   OnPreExecute    so_Andre_LoggingTrxn    B2D17896-199F-4213-B800-E812CE95D45F
3   OnPreExecute    Begin tran  B2D17896-199F-4213-B800-E812CE95D45F
13  OnPostExecute   Rollback    B2D17896-199F-4213-B800-E812CE95D45F
14  OnPostExecute   so_Andre_LoggingTrxn    B2D17896-199F-4213-B800-E812CE95D45F
15  PackageEnd  so_Andre_LoggingTrxn    B2D17896-199F-4213-B800-E812CE95D45F

16  PackageStart    so_Andre_LoggingTrxn    F6898ECA-46E7-4760-8885-898FADCBEFFD
17  OnPreExecute    so_Andre_LoggingTrxn    F6898ECA-46E7-4760-8885-898FADCBEFFD
18  OnPreExecute    Begin tran  F6898ECA-46E7-4760-8885-898FADCBEFFD
19  OnPostExecute   Begin tran  F6898ECA-46E7-4760-8885-898FADCBEFFD
20  OnPreExecute    Sequence Container  F6898ECA-46E7-4760-8885-898FADCBEFFD
21  OnPreExecute    Divide by zero  F6898ECA-46E7-4760-8885-898FADCBEFFD
22  OnError Divide by zero  F6898ECA-46E7-4760-8885-898FADCBEFFD
23  OnError Sequence Container  F6898ECA-46E7-4760-8885-898FADCBEFFD
24  OnError so_Andre_LoggingTrxn    F6898ECA-46E7-4760-8885-898FADCBEFFD
25  OnPostExecute   Divide by zero  F6898ECA-46E7-4760-8885-898FADCBEFFD
26  OnPostExecute   Sequence Container  F6898ECA-46E7-4760-8885-898FADCBEFFD
27  OnPreExecute    Rollback    F6898ECA-46E7-4760-8885-898FADCBEFFD
28  OnPostExecute   Rollback    F6898ECA-46E7-4760-8885-898FADCBEFFD
29  OnPostExecute   so_Andre_LoggingTrxn    F6898ECA-46E7-4760-8885-898FADCBEFFD
30  PackageEnd  so_Andre_LoggingTrxn    F6898ECA-46E7-4760-8885-898FADCBEFFD

As you can see, things are happening as one would expect in a transaction. In the first execution, the package begins firing events which are logged (PackageStart, OnPreExecute). The OnPreExecute for source "Begin tran" is the last thing we see until the OnPostExecute of "Rollback" fires. However, there is a gap in the IDs. That gap are all the inserts that occurred under the transaction. That transaction is rolled back so all of that work is undone and the only indicator is the consumed identity values.

When I change logging to use SO_no_retain for the connection manager, I see the OnError events being logged.

edits

You are seeing the first set of entries in your log but the desire is to see the second.

Understanding why this is so is fundamental to how transactions work. A transaction packages up statements of work into a single block of stuff that's all going to work or it's all going to fail. In your transaction, the package is issuing sp_ssis_addlogentry commands. There's no way inside the current transaction to say "make these statements more durable than the rest" or "persist these outside the current transaction." All or none, that's the only option within the context of a transaction.

Given that, your options are either create a second connection manager dedicated to logging as I has shown with the SO_no_retain CM or write your own error logging system. I really, really would advocate the former as it's native behaviour. Otherwise, you're going to spend lots of time

A third option

This one struck me that perhaps you weren't aware of it. You don't need to the begin tran /commit/rollback pattern. SSIS can do that out of the box for you. Depending on where the packages run, it will require the MSDTC (MS distributed transaction coordinator) to be running but in short, you tell the package that you'd like to have these components enlist in a transaction and voila, magic happens and you don't have to manage it. Every task in SSIS has a property for TransactionOption. By default, that is set to Supported.

TransactionOption settings

  • Supported If a transaction exists, the task will enlist in it. It will not start a transaction.
  • Required This will start a transaction. If one already exists, then it will enlist in that transaction
  • NotRequired This will not start a transaction, nor will it enlist in an ongoing transaction. You can deadlock yourself by having required and not required objects attempting to manipulate the same resources so watch what you're doing.

Given the above package, what I would do is

  1. remove the Execute SQL Tasks that coordinate transaction,
  2. leave the RetainSameConnection property as False
  3. At the control flow level (or Sequence Container) I would set the TransactionOption to Required

Done, that's it. When the package runs, the "work" is rolled back but the logging, including errors, will be there. Quite honestly, most every package I write looks something like that. I've never had reason to attempt to control my own transactions as I, perhaps foolishly, trust the transaction coordinator to handle all of that. In 7 years of working with SSIS though, I haven't had troubles with the MSDTC not handling it.

于 2012-07-12T18:24:00.587 に答える