2012-04-17 19 views
3

SSISスクリプトタスクを実行するだけのSSISパッケージがあります。このスクリプトはパッケージを動的に作成し、スレッドのアクティブな数を管理するスレッド形式でパッケージを実行します。これはSQL Agentを使用して起動されます。これは、Attunity Sourceから11gのOracle DBに対してデータを取得しています。SSIS C#スクリプトタスクが約250MBのメモリ使用に失敗しました

私がタスクマネージャーでプロセスを見ると、DTexec.exeはますます多くのメモリを消費しています。約250MBになると失敗します。毎回異なるエラーを返すことが多く、時にはSQLエージェントからのキャンセル要求として表示されることもあります。

私は、OSに多くを与えるために最大メモリを減らし、うまくいかなかった。

64ビットであるため、memToLeaveの問題であってはなりません。 私は何もコマンドラインで実行しようとしていません。

のWindows Server 2003 SQL 2008R2

私はこれでそんなにトラブルを抱えていると私は、ウェブ上で見つけることができるすべてのものを試してみました。誰にでもアイデアはありますか?私はここに何かを残して頼むと確信して、私はあなたのために見つけるでしょう。

+0

あなたは私の哀悼の意を表します。私は、マスターパッケージの理由は、DBAにインストールするexeを与えるよりも簡単に生産に絞ることができると仮定します。あなたが 'コマンドラインから実行すると、それは何もない'と言うと、それはエラーを意味しないか、まったく動かないのでしょうか? – billinkc

+0

エージェントを実行しているときと同じ動作を示します。それはSSISlogメッセージを残さずにゆっくりと(RAM)を満たし、その後(250MB)死にます。ほとんどの場合、Windowsイベントはありませんが、SQLDumperはまったく見えません。 – Grinder

答えて

2

私はそれを理解しました。

C#の記述方法には、作成するスレッドを明示的に破棄するメカニズムがありませんが、スクリプトタスクでSSISパッケージ内にDLLが作成されるため、これまで問題にならなかった理由があります。私の環境は、デフォルトで32ビットのランタイムを持ち、それをそのように構築しました。 SSISパッケージが32ビットモードで構築されている場合、ハードウェアRAMの上限は256MBですが、64bitにはそのような制限はありません。だから私は何をしなければならなかったのですか?

Visual Studioでパッケージをサーバーの上に開いて保存します。これにより、64ビットモードで強制的に再コンパイルされます(そのサーバー上のデフォルトの実行時間の場合)。

+0

好奇心のため、64ビットdtexecを使用してパッケージを実行しただけの場合でも、同じ動作を示していますか? – billinkc

+1

はい。これは同じ動作を示し、256MBで死んでしまいました。エラーロギングに関しては64ビットが最も冗長ではないので、これを完全な嵐にした他の多くの要因の中で、トラブルシューティングは本当に困難でした。 – Grinder

関連する問題