SQL Server 2005マシンに2つのスケジュール済みジョブがあり、毎朝(午前2時頃)実行するようにスケジュールされています。これらの仕事は(ほとんど)何年もうまく機能しており、この問題を解決しなければならないいくつかの問題がありましたが、私は完全に困惑しています。
2朝前、私のパッケージの1つが次のエラーを報告し始めました。
Executed as user: [Service Acount]. ...n 9.00.4035.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 1:15:01 AM Error: 2012-10-17 01:15:03.98
Code: 0xC0016016
Source:
Description: Failed to decrypt protected XML node "DTS:Password"
with error 0x8009000B "Key not valid for use in specified state.".
You may not be authorized to access this information. This error
occurs when there is a cryptographic error. Verify that the
correct key is available. End Error Error: 2012-10-17 01:15:03.99
Code: 0xC0016016
Source:
Description: Failed to decrypt protected XML node "DTS:Password"
with error 0x8009000B "Key not valid for use in specified state.".
You may not be authorized to access this information. This error
occurs when there is a cryptographic error. Verify that the
correct key is available. End Error Error: 2012-10-17 01:15:04.01
Code: 0xC0016016
Source:
Description: Failed to ... The package execution fa... The step failed.
これは一般的な問題のようですが、私が見つけた推奨事項のいずれも私のシナリオに当てはまりませんし、インスタンスがこれが発生する他のほとんどのケースと一致しないようです。これが私の実装に関する重要な詳細です。
ProtectionLevel
はDontSaveSensitive
に設定され、iSeries資格情報はSQLServerがアクセスする構成ファイルに保管されます。ヒントや考えは非常に役に立ちます。このエクスポートは非常に重要であり、多くのユーザー/ワーカーは日常業務でこのデータに依存しています。
まあ、私はそのような応答を投稿する必要が嫌いですが、問題を解決しました。
私がこの問題を抱えた簡単な答えの理由は、データテーブルのフィールドの1つが正しく定義されていなかったためです。この場合、それはdecimal (11, 3)
として宣言されており、decimal (13, 3)
である必要があります。 (11, 3)
の範囲に適合しない値がテーブルに投稿されるまで、この問題は発生しませんでした。
この問題は、SSISに対する私の最大の不満の1つを浮き彫りにします。時々私はよくインターネット上に文書化されているエラーを受け取ります。私はすべてのログを検索し、エラーメッセージが正直であるという前提でさまざまなテストシナリオを設定しようとしています。しかし、最終的に問題を解決したとき、ログファイルに書き込まれるエラーメッセージとはまったく関係ありません。
この場合、上記のエラーは問題とはまったく関係ありませんか?!実際、私はこの問題を見ることができてとても幸運でした。 SSISがこのように誤って通信するのを見たことがありますので、テーブルの更新が潜在的な修正になる可能性があることを私は知っていました。
私はこれを私のサーバーを爆撃する宇宙からのニュートリノのせいにしたいのですが、この経験からの最善の持ち帰りは、他の人のアドバイスに基づいてあなたのSSIS問題を解決しようとすることですしかしアドバイスは役に立ちません。問題がSSISエラーメッセージとは無関係である可能性があることを認識し、障害点に関連するすべてをトリプルチェックしてください。
コメントに画像を投稿できなかったので、回答として投稿しました。
パッケージをSQLServerにインポートしようとすると、右クリックして[パッケージのインポート]を実行するとすぐに、次のウィンドウが表示されます。
ウィンドウの右側にある長方形のボックスをクリックします。パッケージの保護レベルを変更するオプションが表示されます。 「機密情報を保存しない」に変更して、パッケージを実行してみてください。注意してください、これはあなたが既存のパッケージを削除して再度それを再インポートすることを要求するでしょう。そのため、既存の構成に触れる前に、別のマシンで試してみるとよいでしょう。
私にとっては、保存されなかったのはSSISの接続マネージャーのパスワードだけでした。パスワードを入力-> OK-> dtsxファイルを閉じて再度開きます。エラーがなくなりました。
SQL Server 2012で同じエラーメッセージに遭遇しました。私にとって、SQL Server Management Studioを再起動すると問題が解決しました。この問題は、SSMSが開いている数日前にドメインパスワードが変更されたことが原因である可能性があります。同様の問題が発生し、簡単に再起動しても解決しない場合は、Control Panel\User Accounts\Credential Manager
でキャッシュされたアカウント情報を確認するか、再起動してみてください。
パッケージdtsxを開き、プロパティセットProtectionLevel EncryptSensitiveWithPasswordに移動してパスワードを入力します。パッケージフォームのSQLサーバージョブを同じパスワードで接続します。
http://support.Microsoft.com/kb/91876 および http://www.mssqltips.com/sqlservertip/2091/securing-your-ssis-packages-using-を参照してくださいパッケージ保護レベル/
これは、パッケージに機密性の高いパスワードを保存するという最初の場所での問題を回避するための回避策です。
FTPタスクを削除し、代わりにファイルシステムタスクを使用して、ftpサーバー上のネットワーク共有を介してファイルを同じ場所にコピーし、ftpプロトコルの使用を回避しました。
また、SQLサーバーストアではなくファイルシステムにパッケージを保存することもでき、問題なく実行されました。
うまくいけば、それはあなたを助けます!