問題タブ [sql-server]

私の現在の開発プロジェクトには 2 つの側面があります。まず、外部ユーザーがさまざまな目的で情報を送信および更新できる公開 Web サイトがあります。この情報は、コロ施設のローカル SQL Server に保存されます。

2 番目の側面は、従業員が同じレコードを (概念的に) 管理し、ステータスの更新、承認などを提供するために使用する内部アプリケーションです。このアプリケーションは、独自のローカル SQL Server データベースを使用して、企業のファイアウォール内でホストされます。

2 つのネットワークはハードウェア VPN ソリューションによって接続されています。これはまともですが、明らかに世界で最も高速なものではありません.

2 つのデータベースは類似しており、同じテーブルの多くを共有していますが、100% 同じではありません。両側のテーブルの多くは、内部または外部アプリケーションに非常に固有のものです。

問題は、ユーザーが自分の情報を更新したり、公開 Web サイトで記録を送信したりするとき、そのデータを内部アプリケーションのデータベースに転送して、内部スタッフが管理できるようにするにはどうすればよいかということです。またその逆も同様です... スタッフが行った更新を Web サイトに戻すにはどうすればよいですか?

これらの更新がより「リアルタイム」に行われるほど、より良いことに言及する価値があります。すぐに実行する必要はありませんが、適度に高速です。

これまでのところ、次のタイプのアプローチを使用することを考えてきました。

1. 双方向レプリケーション
2. 変更が行われたときに (リアルタイムで) 同期するためのコードを含む、両側の Web サービス インターフェイス。
3. 変更を非同期的に同期するためのコードを含む両側の Web サービス インターフェイス (キューイング メカニズムを使用)。

何かアドバイス？以前にこの問題に遭遇した人はいますか? あなたにとってうまくいく解決策を思いつきましたか？

レコードが存在する場合は更新を行い、そうでない場合は挿入を行うストアド プロシージャを作成しました。次のようになります。

このように書くことの背後にある私のロジックは、更新が where 句を使用して暗黙的な選択を実行し、それが 0 を返す場合、挿入が行われるということです。

この方法に代わる方法は、選択を行い、返された行数に基づいて更新または挿入を行うことです。更新を行う場合、2 つの選択 (最初の明示的な選択呼び出しと、更新の場所での 2 番目の暗黙的な呼び出し) が発生するため、これは非効率的であると考えました。プロシージャが挿入を行う場合、効率に違いはありません。

ここで私の論理は正しいですか？これは、挿入と更新をストアド プロシージャに結合する方法ですか?

これまで、私はデータベース テーブルでトリガーを使用するのが好きではありませんでした。私にとって、それらは常に、アプリケーション コードの制御から遠く離れたデータベース側で発生する「魔法」を表していました。また、DB は一般に共有リソースであり、高負荷のシナリオではトリガーが高価になる可能性があると常に想定していたため、DB が実行しなければならない作業量を制限したいと考えていました。

そうは言っても、トリガーを使用するのが理にかなっている例をいくつか見つけました (少なくとも私の意見では、トリガーは理にかなっています)。しかし最近、トリガーを「バイパス」する必要がある場合があることに気付きました。これを行う方法を探さなければならないことに本当に罪悪感を覚えましたが、データベースの設計を改善すれば、このバイパスの必要性が軽減されると今でも思っています。残念ながら、この DB は複数のアプリケーションで使用されており、そのうちのいくつかは、スキーマの変更について大声で叫ぶ非常に非協力的な開発チームによって維持されているため、行き詰まりました。

トリガーに関する一般的な意見は何ですか? 好きですか？嫌いですか？いくつかのシナリオで目的を果たすと思いますか? トリガーをバイパスする必要があるということは、「やり方が間違っている」ことを意味すると思いますか?

System.Data.SqlClient.SqlException: Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed.

誰もこのエラーを受け取ったことがありますか、および/またはその原因および/または解決策について何か考えがありますか?

このリンクには関連情報が含まれている場合があります。

アップデート

接続文字列は=.\SQLEXPRESS;AttachDbFilename=C:\temp\HelloWorldTest.mdf;Integrated Security=True

提案されたものは機能しUser Instance=falseました。

SQL サーバーでスケジュールされたレポートが実行されません。ログを確認したところ、失敗しているジョブが見つかりました。ログのエラー メッセージは次のとおりです。

要求されたログイン 'NT AUTHORITY\NETWORK SERVICE' の 'EXECUTE AS LOGIN' が失敗しました。ステップは失敗しました。

レポートに SQL 認証を使用しているため、データへのアクセス許可に問題はありません。サーバー上でスケジュールされたレポートは実行されません。

SQL Server 2005 クラスターで散発的でランダムなクエリ タイムアウトが発生しています。私はそれを使用するいくつかのアプリを所有しているので、調査を手伝っています. 通常の古い Perfmon で CPU 時間の割合を見ると、確実に固定されていることがわかります。ただし、SQL アクティビティ モニターは、プロセスによって使用された累積 CPU および IO 時間のみを提供し、その時点または特定の時間枠で使用されているものではありません。おそらく、プロファイラーを使用してトレースを実行することもできますが、このクラスターは非常に頻繁に使用されているため、干し草の山から針を探すことになるのではないかと心配しています。私は間違った木を吠えていますか？

この環境で高価なクエリ/プロセスを追跡するための良い方法はありますか?

データベース 'master' で CREATE DATABASE 権限が拒否されました。ファイル C:\Documents and Settings\..\App_Data\HelloWorld.mdf の自動命名データベースをアタッチしようとして失敗しました。同じ名前のデータベースが存在するか、指定されたファイルを開くことができないか、ファイルが UNC 共有にあります。

私はこれらのリンクを見つけました：

• http://blog.benhall.me.uk/2008/03/sql-server-and-vista-create-database.html
• http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=702726&SiteID=1

私が働いている会社には、SQL Server 2000 バックエンドを使用していた古い Access 2000 アプリケーションがあります。私たちは、バックエンドを新しいサーバー上の SQL Server 2005 データベースに移動する任務を負っていました。残念ながら、挿入または更新を実行しようとしている間、アプリケーションは正しく機能していませんでした。私の調査では、Access 2000 -> SQL 2005 は Microsoft によってサポートされていないという多くのフォーラム投稿が見つかりましたが、それを確認するための Microsoft ドキュメントは見つかりませんでした。

誰かが私をいくつかの公式ドキュメントにリンクできますか、または誰かがこのセットアップを使用して、これが機能するはずであり、私たちの問題が別の場所にあることを確認できますか?

問題があるかどうかはわかりませんが、アプリは ADE にコンパイルされた ADP です。

SQL を C# ソース コードまたはストアド プロシージャに保持することの利点と欠点は何ですか? これについては、現在取り組んでいるオープン ソース プロジェクト (C# ASP.NET フォーラム) の友人と話し合っています。現時点では、データベース アクセスのほとんどは、C# で SQL インラインを構築し、SQL Server DB を呼び出すことによって行われます。だから私は、この特定のプロジェクトに最適なものを確立しようとしています.

これまでのところ、私は持っています:

コード内の利点:

• メンテナンスが容易 - クエリを更新するために SQL スクリプトを実行する必要がない
• 別の DB への移植が容易 - 移植する proc が不要

ストアド プロシージャの利点:

• パフォーマンス
• 安全

まず最初に、非常に大規模で長時間実行されるレポートを実行するのは恐ろしい考えであることを理解しています。Microsoft には、SSRS レポートの実行に 30 秒以上かかるべきではないという経験則があることは承知しています。ただし、州法を遵守するなどの外部の力により、巨大なレポートが好まれる悪である場合があります。

私の職場には、Crystal Reports から SSRS に移行した asp.net (2.0) アプリがあります。大規模なユーザー ベースと複雑なレポート UI 要件のため、ユーザーが入力したパラメーターを受け入れ、夜間に実行されるスケジュールを作成する一連の画面があります。アプリケーションは複数のレポート フレームワークをサポートしているため、SSRS のスケジューリング/スナップショット機能は使用しません。システム内のすべてのレポートは、スケジュールされたコンソール アプリによって生成されます。このアプリは、ユーザーが入力したパラメーターを取得し、レポートが作成された対応するレポート ソリューションを使用してレポートを生成します。SSRS レポートの場合、コンソール アプリは SSRS レポートを生成し、SSRS Web サービス API を介して PDF としてエクスポートします。

最近 Crystal レポートから SSRS に変換した特定の 25,000 ページのレポートを除いて、これまでのところ、SSRS は Crystal よりもはるかに扱いが簡単でした。SSRS サーバーは、SSRS 2005 を実行する 32 GB の RAM を備えた 64 ビット 2003 サーバーです。小さなレポートはすべて素晴らしく機能しますが、このような大きなレポートには問題があります。残念ながら、Web サービス API を使用して事前レポートを生成することはできないようです。次のエラーは、生成/エクスポートの約 30 ～ 35 分後に発生します。

例外メッセージ: 基になる接続が閉じられました: 受信時に予期しないエラーが発生しました。

Web サービス呼び出しは、皆さんが以前に見たことがあると確信しているものです。

奇妙な点は、レポート マネージャーを使用してレポート サーバー上でレポートを直接実行すると、このレポートが実行/レンダリング/エクスポートされることです。レポートのデータを生成するプロセスは、約 5 分間実行されます。レポートは、約 12 分後にブラウザー/ビューアーに SSRS ネイティブ形式で表示されます。レポート マネージャーのブラウザー/ビューアーを使用して PDF にエクスポートするには、さらに 55 分かかります。これは確実に機能し、なんと 1.03 GB の pdf が生成されます。

以下は、Web サービス API を介してレポートを機能させるために私が試みた、より明白なことのいくつかです。

• レポート サーバーで HttpRuntime ExecutionTimeout 値を 3 時間に設定します。
• レポート サーバーで HTTP キープ アライブを無効にしました
• レポート サーバーのスクリプト タイムアウトを増やしました
• レポートがサーバーでタイムアウトしないように設定する
• クライアント呼び出しでレポートのタイムアウトを数時間に設定する

私が試した微調整から、タイムアウトの問題はすべて解消されたと言ってよいでしょう。

エラー メッセージを調査したところ、Web サービス API はデフォルトではチャンクされた応答を送信しないと思われます。これは、1 回の応答ですべての 1.3 GB を回線経由で送信しようとすることを意味します。ある時点で、IIS はタオルを投げます。残念ながら、API は Web サービスの構成を抽象化するため、応答のチャンクを有効にする方法を見つけることができないようです。

1. 総ページ数を減らさずにPDFエクスポートフェーズやPDFのサイズを縮小/最適化する方法を知っている人はいますか?
2. SSRS の応答チャンクを有効にする方法はありますか?
3. なぜこれがサーバー上で実行され、APIを介して実行されないのかについて、他の誰かが他の理論を持っていますか?

編集: kcrumley の投稿を読んだ後、ファイル サイズ/ページ数を取得して、平均ページ サイズを調べ始めました。興味深いことに、小さなレポートでは、各ページが約 5K になるように計算されます。興味深いことに、レポートが大きくなると、この「平均」が増加します。たとえば、8000 ページのレポートは平均 40K/ページを超えています。非常に奇妙な。また、各グループの最後のページを除いて、ページごとのレコード数が設定されているため、一部のページに別のページよりも多くのレコードがある場合はありません。