SQL Server Reporting Services、Analysis Services、およびIntegrationServicesの開発のベストプラクティスをいくつか見つけようとしています。
誰かがこの主題に関して提供できるいくつかの有用なリンクやガイダンスを持っていますか？
1 に答える
2
私は特に SSIS についてのみ話すことができますが、これのいくつかは他のものにも当てはまります。
パッケージをファイルとして保存し、ソース管理に配置します。
可能であれば、サーバーからサーバーへ、または実行ごとに変化するものに対して変数を使用します。
構成ファイルを使用して、さまざまな環境の構成を保存します。
外部ソースからのデータを処理するときは、警告なしにフォーマットが変更されると想定してください (つまり、各列に期待するデータが取得したデータであることを確認してください!) 姓のフィールドに電子メールを入力するようなものはありません (または起こったように) DTS で一度私たちに、その人に支払う金額を示す社会保障番号をフィールドに入力しました。誰かがその金額を支払う前にそれを見つけてよかった.)
私が見たのは、新しい列の追加、プロセスにとって重要な列の削除、列の順序の再配置 (ファイル自体に列名がない場合は特に悪い)、列のタイトルは同じままでデータの変更などです。それらには含まれています（はい、姓データがFirst_nameというラベルの付いた列にあるファイルを取得したら、その逆も同様です）、システムの値と一致しない新しい値を持つデータ（ルックアップタイプだと思いますここでは医療専門分野のようなもの)、電子メール フィールドのメモなどの奇妙なデータを一掃し、この形式の名前 lastname - 'Willams, Jo' first_name - 'hn'(2 つのフィールドを組み合わせて完全な名前を取得します。明らかに、彼らのデータ入力担当者は、スペースがなくなるまで名前を入力し、名前のどこにいても次のフィールドに進みました!)。
クリーンアップされていないデータをデータベースに入れないでください。
処理または送信するファイルのコピーを常に保持してください。驚くほど頻繁に調査する必要があります。
エラーをログに記録し、クリーニングが必要なレコードをログに記録します。特に、フィールドの問題が原因でプロセスが失敗した場合はそうです。1 つのレコードに余分な | があったために 2,000 万のレコード ファイルが失敗したことを知るよりも、テーブルでエラーを確認する方がはるかに簡単です。その中で、それがどれであったかを把握してみてください。
SSIS で同様のインポートを多数行う場合は、すべての標準ログとデータ クリーニングを含むテンプレート プロジェクトを作成します。すべての SSIS パッケージを最初から書き直すよりも、テンプレートから開始し、作業中の新しいファイルに基づいて新しいマッピングに調整し、そのファイルに固有のものに小さな調整を加える方がはるかに高速です。
メタデータを保存します。遅かれ早かれ、どれくらいの頻度で失敗したか、ファイルを受信してからどれくらいでインポートが行われたか、最後にインポートしたのはいつだったかなどを尋ねられるでしょう。すべてのパッケージは、メタ データ テーブルに開始時刻と終了時刻を保存するタスクで開始および終了します。すべての失敗パスには、メタデータでインポートを失敗としてマークするタスクが含まれています。最終的に、予想されるレコード数を認識し、新しいファイルが大幅にずれている場合に失敗するシステムを構築できます。メタデータを使用して、レコード数などを保存することもできます。これにより、期待していたファイル全体ではなく、部分的なファイルをいつ送信したかを特定し、実際にまだ必要な 300,000 の販売目標を吹き飛ばすのを防ぐことができます.
于 2009-07-30T15:07:04.833 に答える