1

この質問は、私の以前の質問 ( SQL Server: Is there need to verify a data modified? ) に関連するフォローアップです。

グーグルで調べたところ、「CRCとTCPチェックサムが一致しない場合」という論文（アクセスできません）は、1600万から100億パケットに1回のチェックされていないエラー率が発生することを示しています。したがって、誤った挿入/更新/削除が成功するには、エラーが SQL ステートメントの値またはキーワードに (構文的に正しい方法で) 影響を与える必要があります。これは、SQL Server が誤った sql ステートメントを受け取って実行する可能性が、論文で示されているよりもはるかに低いことを意味します。

私が知りたいのは、誤ったSQLステートメントが受信される可能性をさらに下げる、またはそれを検出できるようにする何かが他にあるかどうかです:

  • SQL ステートメントには、ステートメントの整合性を確認するために SQL Server がチェックするチェックサムが含まれていますか?
  • 送信された sql ステートメントと比較するために、SQL Server が受信した最後の sql ステートメントを取得することはできますか? これは、送信された sql ステートメントが正しく受信されたかどうかを確認するためにデータベースにクエリを実行するよりも計算コストが低くなりますが、後者の手法とは異なり、sql ステートメントが正しく実行されたかどうかを確認することはできません。
  • 私が省略した他のもので、あなたが役に立つかもしれないと思うもの.

ご参考までに言うと、私が取り組んでいるのは軍事アプリケーションであり、それが必要とする高レベルの整合性を説明しています。

ありがとうございました。

4

4 に答える 4

2

簡単な答えは、それが機能するか、数十億回の呼び出しごとに何らかの理由で機能しないかのいずれかです。この種のエラー率でこのレベルをチェックするための適切なメカニズムはありません。

100％の稼働時間も100％の信頼性も保証できません。クライアントとSQLServerの間にディスク、メモリ、ネットワーク、CPUなどのエラーがあります。

率直に言って、軍用ソフトウェアに取り組んだ（そしてそれに合わせた戦争の話がある）ためには、SQL Serverの使用を正当化するのではなく、使用したいプラットフォームを尋ねる必要があることをお勧めします。または、単に「それは不可能です」と言って、何が起こるかを見てください。彼らはソフトウェアを望んでいるか、望まないかのどちらかです。

ソフトウェアにもこの種の整合性が必要な場合は、COTSではなくADAでも作成する必要があります。

なんらかの理由でSQLServerを使いたくない人がいるようですが、それだけです...

于 2010-08-29T08:35:24.503 に答える
1

トランスポート レベルのメッセージの整合性について質問していますが、これは SSL/TLS によって保証されています。SQL Server への接続の暗号化を参照してください。SSL/TLS は、クライアントからサーバーへのチャネルで誰かが耳を傾けるのを防ぐだけでなく、中間者、メッセージのなりすまし、メッセージの改ざんからも保護します。つまり、メッセージの整合性を保証します。SSL/TLS 暗号化チャネルを使用すると、サーバーによって処理されるテキストがクライアントによって送信されるテキストであることが保証されます。

そしてTCPチェックサムについて：メッセージに遭遇するよりも、ランダムなメモリビットフリップまたはCPUビットフリップ（つまり、パッケージを受信した後のサーバーのハードウェアエラー）に遭遇する可能性がはるかに高い（実際には非常に高い）.チェックサムを保持し、有効な SQL を生成する変更。

于 2010-08-29T15:57:55.627 に答える
0

別の方法として、OUTPUT句を使用して、各DML操作の結果を返します。次に、アプリケーションは、返された値が指定された値と一致することを確認し、適切に応答します。

問題はテストにあります。10億回の呼び出しごとに1回だけ発生する何かを適切にテストするにはどうすればよいですか？あなたはそうしない。エラーをシミュレートしますが、実際のものではなく、シミュレーションをテストしています。

于 2010-08-30T01:42:28.753 に答える
0

SQL Server で使用されるTDS プロトコルを確認してください。そこにチェックサムやCRCへの参照が見つからないので、質問するのは「いいえ」だと思います。

私の知る限り、「最後に実行されたクエリ」を SQL Server から直接取得することはできません。これが要件である場合は、これらを何らかの形でログに記録する必要があります。動的管理ビューからマイレージを取得できる場合があります。これらを使用して、特定の SPID に対して実行された、または実行された SQL ステートメントを取得しますが、これが役立つかどうかはわかりません。

クエリの形式が正しくなかったとします。メモリの破損やディスクの破損によるデータの破損を防ぐにはどうすればよいでしょうか。もちろん、これらの「レイヤー」に対してもエラー チェック/回復を行うことができますが、100% 保証されるものはありません。

于 2010-08-29T08:23:39.320 に答える