Q&A
第三者が回答するには色々情報が不足している気がしますが、具体的にどんなタスクなのかとか、ログはどうなってるのとか、提示できる情報がないならMSのサポートに問い合わせた方がいい気がします。
ここはサポートセンターではないので、回答者が再現できないような質問をしても回答はつかない気が。
https://teratail.com/help/question-tips#questionTips1-1
ある時点から一つのSSISパッケージを起動させるジョブが 急に正常終了しなくなりました。
SSISパッケージ内では SQL発行・データフロータスクなど いくつかのステップを踏むつくりになっているのですが、本日から急に
OracleDatabaseからSQLServerへ データ取得するデータフロータスクの部分より 進行しなくなってしまいました。
（Integration Servicesカタログの標準レポートより）
一つ気になっているのは SQLServerの利用状況モニタを ジョブ起動時に確認すると 実行内容が全く空白のプロセスが現れていることです。
「質問①」：
現況生じている問題は やはりこれが関係しているのでしょうか？
正常終了していた際、これが現れていたか否か未確認なので、この状態が正常なのか否か分かりません。
現況生じている事象の特徴的なことを申し上げておくと、
ジョブ経由で起動しているSSISパッケージを開発した環境：Windows10（のMicrosoft Visual Studio Tools for Applications 2017）で、単体実行すると 現況（=ジョブで正常終了できない状況下でも） 必ず 正常終了に至れることを確認しています。
「質問②」：
実行環境に特化した問題、もしくはジョブ経由であることに関連した問題と思われますが、何が対策として考えられるでしょうか？
尚、SQLServerのジョブを動作させるためのサービス：エージェント、及びIntegrationサービスの再起動を試行しましたが 動作状況に変化はありませんでした。（毎回「ジョブの利用状況モニタ」で当該起動ジョブを強制終了しています。また、「サーバの利用状況モニタ」では、先に提示した内容が空ののプロセスが毎回残ってしまうので こちらも別途強制終了を行っています）
経験上、SSISに絡む内容は 回答が付きにくいことを存じ上げておりますが、藁をも掴む思いで 掲載させて頂きました。
質問①と質問②への ご見解よろしくお願い致します。
止まっていると思われる部分はOracleDatabaseからSQLServerへ4つのテーブルを転送するデータフロータスクです。より具体的に述べると、ADO.NET変換元からADO.NET変換先へ矢印をのばしたデータフロータスク、とでも言えますでしょうか。
異常終了にもなってくれないのですが、仰られているログとは何のログを確認すべきなのでしょうか？？
明日は4テーブルを取得している一つのタスクを、一つ一つのテーブルに細分化してみるところから始めたいと思います。
ちょっと気になりだしたのが、データ取得元のOracleDatabaseのサーバが ファイアウォールによって保護されている点です。
ある時まではSQLServerのジョブ経由でも無事に動作していたところをみると 違いますかね？？？
Integrationサービスの標準レポートで、問題のパッケージの標準レポートを確認すると、
「実行フェーズを開始しています」で ず～っと進行しない状況になっていることまではわかりました。
本来であれば この後に「実行後フェーズを開始しています」に移るべきなのですが。
ファイアウォールの問題ではないことをインフラ分野の担当から確認しました。
何かの閾値を超えて、従来まで動作していたサーバ上のパッケージが急に動作しなくなるようなこと、どなたか経験されていませんか？
私は何を疑うべきでしょうか？
本件誰も気にされていないかも知れませんが、一応ご報告です。
SQLServerのエージェントジョブ経由で実行して正常に動作しなくなったSSISパッケージですが、本日コマンドプロンプトで行ってみましたが やはり状況は変わらず進行しない状態でした。
ちなみに私が出くわしたこのOracle/SQLServer間の問題、多くの方が悩まされているようで 以下事象と酷似しています。
<https://www.sqlservercentral.com/forums/topic/ssis-package-works-properly-in-visual-studio-but-hangs-after-deploy-some-records-inserted-then-crashed>
環境が分からないのでコメントが難しい状況です。
上記リンク先の投稿だとVisualStudio上でのデバッグ実行はできるが、デプロイすると動かないという記事ですが、saya24さんも同様なのでしょうか。
また保守的な観点では、正常動作しなくなったタイミングで、何かしら環境に変化があったと考えるのが自然です。FWが設置されたのがそのタイミングであればやはりそのあたりが突っ込みどころになりますし、FWはもっと前から設置されていたのであれば、別の要因を当たるのが自然かと思います。
FWは関係ありませんでした。インフラの部隊にログを確認してもらいこの面の疑いは晴れています。
xdolphinxさんが尋ねられたように全く紹介の記事と同様の事象が発生しました。なんでもMSとOracle間で大量のデータが行き来するとこうなる事象が世間で散見されているようです。
またMSがこの問題を克服するためか、新たな手立て・プロバイダをSSISに用意した事が分かりました。Attunityというものなのですが、いかんせん自分の環境では利用できない解決策のため、この手段は諦めました。
現在ですが、VisualStudioからではなく ManagementStuduioでのデータインポートの手続きをSSISパッケージとして保存する代替え策を思い付き、このパッケージをジョブ経由で動作させることに成功した状況です。
原因不明であるも、難は超えた感じですね。
ひとまず回避できたようで良かったですね。個人的にはSSMSのインポートをSSISパッケージ化したのと、VSで手作りしたSSISで、どこに決定的な違いがあるかが気になりますが、目をつぶってしまいましょう。
Attunityは公式サイトだとSQLServer2016/2017用で、2019用には別のものが提供されているとあるので、そのあたりの推移が気になりますね。
ともあれ、お疲れさまでした。
自分の環境はSQServer2017ですが、Enterprise版ではなかったので Attunityを断念せざるをえませんでした。本当に今の解決策が幸いなことに良い結果に転んで助かりました。
回答1件
0
自己解決
VisualStudioからではなく ManagementStuduioでのデータインポートの手続きをSSISパッケージとして保存する代替え策を思い付き、このパッケージをジョブ経由で動作させることに成功
原因不明であるも、難は乗り越えました。これ以上開けていた所で真の原因が追及されるとは思えないので本件クローズ致します。
皆様有難うございました。
投稿2020/05/02 00:57
総合スコア222
あなたの回答
tips
プレビュー
