Есть ли в SQL Server какие-либо встроенные механизмы проверки ошибок в отношении получения оператора SQL?

Question

Этот вопрос является продолжением / в связи с моим предыдущим вопросом здесь: SQL Server: есть ли необходимость проверить изменение данных?

Я немного погуглил, и статья (к которой у меня нет доступа) «Когда контрольная сумма CRC и TCP не совпадают» указывает на возникновение непроверенной частоты ошибок 1 в 16–10 миллиардах пакетов. Следовательно, чтобы ошибочная вставка / обновление / удаление завершилась успешно, ошибка должна повлиять на значение (я) или ключевое слово (а) (синтаксически правильным образом) в выражении SQL. Это означает, что вероятность того, что SQL Server получит и выполнит ошибочный SQL-оператор, даже намного ниже, чем указано в документе.

Я хотел бы знать, есть ли что-нибудь еще, что еще больше снизит вероятность получения ошибочного SQL-оператора или позволит его обнаружить:

• Содержит ли оператор sql контрольную сумму, которую SQL Server проверяет, чтобы убедиться в целостности оператора?
• Можно ли получить последний SQL-оператор, полученный SQL Server, для сравнения с отправленным SQL-оператором? Это вычислительно дешевле, чем запрос к базе данных, чтобы проверить, правильно ли получен отправленный оператор SQL, хотя, в отличие от последнего метода, он не может проверить, правильно ли выполнен оператор SQL.
• Любая другая вещь, которую я пропустил, и вы думаете, может быть полезной.

Если вам интересно, то, над чем я работаю, это военное приложение, которое объясняет высокий уровень целостности, который им требуется.

Спасибо.

Answer 1

Простой ответ: или он работает, или каждые несколько миллиардов звонков по какой-то причине. Не существует нормального механизма проверки на этом уровне с такими типами ошибок.

Вы не можете гарантировать ни 100% работоспособности, ни 100% надежности. У вас есть ошибки диска, памяти, сети, процессора и т. Д. Между вашим клиентом и SQL Server.

Чтобы быть откровенным и поработав над военным программным обеспечением (и иметь соответствующие истории войны), я бы посоветовал вам спросить, какую платформу они хотят использовать, а не оправдывать использование им SQL Server. Или просто скажите «это невозможно» и посмотрите, что получится: либо им нужно программное обеспечение, либо нет.

Если программное обеспечение также требует такого рода целостности, то оно должно быть написано также на ADA, а не на COTS.

Похоже, у вас есть кто-то, кто по какой-то причине не хочет использовать SQL Server, вот и все ...

Answer 2

Вы спрашиваете о целостности сообщений транспортного уровня, и это гарантируется SSL / TLS.См. Шифрование подключений к SQL Server .SSL / TLS защищает не только от перехвата слуха на канале «клиент-сервер», он также защищает от посредников, подделки сообщений и от изменения сообщений, другими словами, гарантирует целостность сообщений.С зашифрованным каналом SSL / TLS вам гарантируется, что текст, обрабатываемый сервером, является текстом, отправленным клиентом.

И о контрольной сумме TCP: у вас гораздо больше шансов (на самом деле довольно много) встретиться с случайным переворотом памяти или с перехватом процессора (т.е. аппаратная ошибка на сервере после нее)получил пакет ), чем столкнулся с изменением сообщения, которое сохраняет контрольную сумму и приводит к действительному SQL .

Answer 3

В качестве альтернативы используйте предложение OUTPUT, чтобы вернуть результаты каждой операции DML. Затем приложение подтверждает, что возвращенные значения соответствуют предоставленным значениям, и отвечает соответствующим образом.

Проблема связана с тестированием. Как вы адекватно проверяете то, что происходит только один раз в каждом миллиарде звонков? Вы не Вы симулируете ошибки, но затем вы тестируете симуляцию, а не реальную вещь.

Answer 4

Проверьте протокол TDS , используемый SQL Server.Я не могу найти там никаких ссылок на контрольные суммы или CRC - поэтому я бы сказал, что это «нет», чтобы задавать вопрос 1.

Невозможно AFAIK получить «последний выполненный запрос» непосредственно из SQL Serverвам нужно будет как-то их регистрировать, если это является требованием - вы можете обнаружить, что вы получите некоторое преимущество от представлений динамического управления - вы, безусловно, можете использовать их для получения операторов SQL, которые выполняются или выполнялись для определенного SPID, но я не знаю, что это будет полезно для вас.

Предположим, ваш запрос не был искажен - что может помешать повреждению памяти или повреждению диска из-за повреждения данных?Конечно, вы можете также проверять / восстанавливать ошибки для этих «слоев», но ничто не будет гарантировано на 100%.