Ошибка sql: Ошибки sql server — коды ошибок и как запустить работу сервера, если нет соединения, sql не найден, не доступен

{{l10n_strings.DRAG_TEXT_HELP}}

{{article.content_lang.display}}

{{l10n_strings.AUTHOR_TOOLTIP_TEXT}}

Как найти причину ошибки сети при работе с Microsoft SQL Server

В большинстве случаев истинная причина периодически возникающей проблемы с подключением клиентского компьютера к удаленному серверу базы данных MS SQL Server  связана с сетевым уровнем модели OSI. Собирая данные трассировки сети и анализируя их, мы можем сузить зону поиска и определить точную причину того, почему не удалось установить соединение или было внезапно разорвано существующее соединение.

Для большей наглядности предоставляемой информации в рамках данной статьи, мы дополнили ее пошаговыми иллюстрациями практического решения проблемы из реальной жизни. Проблема в предлагаемом нами кейсе заключалась в том, что клиент с определенной периодичностью получал сообщение GNE (General Network error, «Общая ошибка сети») от приложения, которое пыталось подключиться удаленно к серверу Microsoft SQL Server. Ниже приведен пример такого сообщения об ошибке:

«OleDB Error Microsoft OLE DB Provider for SQL Server [0x80004005][11] : [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation».

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

• Используйте данные, полученные с помощью утилиты «ipconfig», запущенную с ключом «/all», со всех задействованных серверов.
• Ориентируйтесь на сообщения об ошибке с установленной временной меткой (timestamp). Если по какой-то причине сообщения об ошибке с временной меткой вам недоступны, попросите клиента сделать запись точного времени возникновения проблемы и отправить ее вам.

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

Для захвата и анализа трассировок вы можете использовать Wireshark, либо любой другой инструментарий с подобной функциональностью. В данном примере был использован Wireshark, поскольку трассировки, отправленные клиентом, не могли быть открыты другим инструментарием (это было связано с расширением полученных файлов).

IP-адреса и точное время возникновение проблемы

Для начала стоит проверить информацию, полученную с помощью утилиты ipconfig, чтобы узнать необходимые нам IP-адреса. В рассматриваемом примере они следующие:

«SQL server:

IP Address. . . . . . . . . . . . : 10.10.100.131

App server:

IP Address. . . . . . . . . . . . : 10.10.100.59»

Теперь из сообщения об ошибке выясним, когда именно возникла проблема. Наше сообщение об ошибке выглядит так:

«02/24/2010 09:28:08 DataBase Warning OleDB Error Microsoft OLE DB Provider for SQL Server [0x80004005][11] : [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation».

Таким образом, проблема произошла 24.02.2010 в 09:28:08.

Почему так важно точное время события? Зачастую, при сборе трассировок сети для решения периодически возникающих сетевых проблем вы получите внушительное количество файлов трассировки с каждого сервера, так как вам может понадобиться осуществлять захват сетевых трассировок в течение довольно продолжительного периода времени, и это может привести к генерации большого количества файлов трассировки, хранящих информацию о всей цепочке событий, произошедших за это время. В рассматриваемом нами примере клиент отправил более 60 файлов трассировки размером 25 МБ каждый для сервера приложений, а также было получено 6 подобных файлов для сервера Microsoft SQL Server. Когда у вас слишком много данных для анализа, информация о точном времени возникновения проблемы становится бесценной.

Анализ трассировок сервера приложений

Начнем наш анализ с файлов трассировки, полученных от сервера приложений. С помощью временной метки мы можем определить, какой файл трассировки необходимо проанализировать первым. Первое, что необходимо сделать, когда мы имеем дело с периодически возникающими проблемами сетевого соединения, это проверить данные трассировки сети на наличие каких-либо сбросов соединения (сообщений по протоколу TCP с установленным флагом RST, означающим «RESET»). Кроме того, из журнала ошибок сервера SQL можно узнать, какой порт прослушивает SQL-сервер. В рассматриваемом нами примере это был порт 1433. Таким образом, мы начинаем свой анализ со следующего фильтра:

«tcp.port eq 1433 && tcp.flags.reset==1»

С помощью данного фильтра можно получить список всех сообщений «RESET», относящихся к данному SQL-серверу (конечно же, сразу стоит удостовериться, что сервер приложений подключается только к проблемному SQL-серверу, и не происходит других подключений еще к какому-то другому SQL-серверу, который также прослушивает порт 1433). В рассматриваемом нами примере с помощью этого фильтра было обнаружено около 20 сообщений по протоколу TCP с флагом RST:

Следующим нашим шагом будет проверка полного взаимодействия в течение состоявшегося TCP-соединения, частью которого является сообщение о сбросе соединения. Для того чтобы увидеть сетевое взаимодействие, включающее в себя фрейм с флагом RST, следуйте следующему шаблону действий:

«Выберите фрейм с флагом RST —> кликните правой кнопкой мыши —> Conversation Filter («Фильтр взаимодействия») —> TCP».

В результате вы получите все фреймы для текущего взаимодействия. В ходе выполнения аналогичной проверки для рассматриваемого нами примера было найдено всего два фрейма:

Теперь, если вы работаете с несколькими файлами трассировки, формирующих непрерывную цепочку событий, а не с одним файлом, вам следует проанализировать и другие файлы трассировки, которые содержат информацию о событиях непосредственно до и после обнаруженного вами события, чтобы найти и другие фреймы этого сетевого взаимодействия, если таковые существуют. Нам необходимо восстановить полную картину событий и узнать, что происходило до того, как сообщение о сбросе соединения было отправлено. Эта информация поможем нам узнать первопричину отправки сообщения с флагом RST. Чтобы сделать это, скопируйте фильтр для данного взаимодействия из текущего файла трассировки. Для нашего примера он следующий:

«(ip.addr eq 10.10.100.59 and ip.addr eq 10.10.100.131) and (tcp.port eq 1194 and tcp.port eq 1433)»

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

Если вы не нашли проблему, а только наблюдаете нормальный траффик (наподобие пакетов «keep-alive»), откройте файл трассировки, предшествующий этому, и проанализируйте его, используя тот же фильтр. Продолжайте делать это, пока не увидите какую-то проблему или не дойдете до начала разговора (трехстороннего рукопожатия TCP для установления соединения).

В нашем примере было много траффика «keep-alive». Microsoft SQL Server (10.10.100.131) и сервер приложений (10.10.100.59) отправляли туда и обратно пакеты «TCP Keep-Alive» и «TCP Keep-Alive ACK». Но в конце сетевого взаимодействия сервер приложений (10.10.100.59) отправил пять пакетов «TCP Keep-Alive» на сервер SQL, но не получил никакого ответа от сервера SQL, как вы можете убедиться ниже:

Проверка всех предыдущих файлов трассировки, содержащих исследуемое взаимодействие, других проблем не выявила. Затем был проверен файл трассировки, следующий за изначальным файлом трассировки (в котором было обнаружено сообщение с флагом RST), но он не содержал фреймов для текущего соединения. Таким образом, данное сетевое взаимодействие закончилось после этого сообщения с сигналом о разрыве соединения.

Анализ трассировок сервера Microsoft SQL Server

Теперь приступаем к проверке файлов трассировки, которые были получены от сервера SQL. Еще раз использовав временную метку возникновения ошибки, мы можем определиться с файлом трассировки, с которого нам нужно начать.

Данный материал доступен только зарегистрированным пользователям!

Коды ошибок DB2 SQL — TutorialBrain

Как реализовать обработку ошибок в SQL Server

Обзор обработки ошибок

Обработка ошибок в SQL Server дает нам контроль над кодом Transact-SQL.Например, когда что-то идет не так, у нас есть шанс что-то с этим сделать и, возможно, исправить это снова. Обработка ошибок SQL Server может быть такой же простой, как просто регистрация того, что что-то произошло, или это может быть наша попытка исправить ошибку. Он может даже переводить ошибку на язык SQL, потому что все мы знаем, как технические сообщения об ошибках SQL Server могут стать бессмысленными и трудными для понимания. К счастью, у нас есть шанс преобразовать эти сообщения в нечто более значимое, чтобы передать их пользователям, разработчикам и т. Д.

В этой статье мы более подробно рассмотрим оператор TRY… CATCH: синтаксис, как он выглядит, как работает и что можно делать при возникновении ошибки. Кроме того, метод будет объяснен на примере SQL Server с использованием группы операторов / блоков T-SQL, которые, по сути, являются способом обработки ошибок SQL Server. Это очень простой, но структурированный способ сделать это, и как только вы освоите его, во многих случаях он может оказаться весьма полезным.

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

Обработка ошибок с помощью TRY… CATCH

Вот как выглядит синтаксис. Разобраться в этом довольно просто. У нас есть два блока кода:

Все, что находится между BEGIN TRY и END TRY, — это код, который мы хотим отслеживать на предмет ошибок.Таким образом, если бы в этом операторе TRY произошла ошибка, элемент управления сразу же был бы передан оператору CATCH, а затем он начал бы выполнение кода построчно.

Теперь внутри оператора CATCH мы можем попытаться исправить ошибку, сообщить об ошибке или даже зарегистрировать ошибку, чтобы мы знали, когда это произошло, кто это сделал, зарегистрировав имя пользователя и все полезные вещи. У нас даже есть доступ к некоторым специальным данным, доступным только внутри оператора CATCH:

• ERROR_NUMBER — возвращает внутренний номер ошибки.
• ERROR_STATE — возвращает информацию об источнике.
• ERROR_SEVERITY — Возвращает информацию обо всем, от информационных ошибок до ошибок, которые пользователь DBA может исправить, и т. Д.
• ERROR_LINE — Возвращает номер строки, в которой произошла ошибка.
• ERROR_PROCEDURE — возвращает имя хранимой процедуры или функции.
• ERROR_MESSAGE — возвращает наиболее важную информацию, а именно текст сообщения об ошибке.

Это все, что нужно, когда дело доходит до обработки ошибок SQL Server. Все можно сделать с помощью простых операторов TRY и CATCH, и единственная часть, где это может быть сложно, — это когда мы имеем дело с транзакциями.Почему? Потому что, если есть НАЧАЛО ТРАНЗАКЦИИ, она всегда должна заканчиваться транзакцией COMMIT или ROLLBACK. Проблема в том, что ошибка возникает после того, как мы начали, но до того, как мы зафиксируем или откатимся. В этом конкретном случае в операторе CATCH можно использовать специальную функцию, которая позволяет проверять, находится ли транзакция в состоянии фиксации или нет, что затем позволяет нам принять решение об откате или фиксации.

Давайте перейдем к SQL Server Management Studio (SSMS) и начнем с основ обработки ошибок SQL Server.В статье используется образец базы данных AdventureWorks 2014. Приведенный ниже сценарий максимально прост:

Это пример того, как это выглядит и как работает.Единственное, что мы делаем в BEGIN TRY, — это делим 1 на 0, что, конечно же, вызовет ошибку. Итак, как только этот блок кода будет обнаружен, он передаст управление блоку CATCH, а затем выберет все свойства с помощью встроенных функций, о которых мы упоминали ранее. Если мы выполним сценарий сверху, то получим:

Мы получили две таблицы результатов из-за двух операторов SELECT: первая — это 1, деленная на 0, что вызывает ошибку, а вторая — это переданный элемент управления, который фактически дал нам некоторые результаты.Слева направо мы получили ErrorNumber, ErrorState, ErrorSeverity; в этом случае нет процедуры (NULL), ErrorLine и ErrorMessage.

А теперь давайте сделаем что-нибудь более значимое. Хорошая идея — отслеживать эти ошибки. Вещи, подверженные ошибкам, в любом случае должны фиксироваться и, по крайней мере, регистрироваться. Вы также можете поместить триггеры в эти зарегистрированные таблицы и даже настроить учетную запись электронной почты и проявить немного творчества в способе уведомления людей при возникновении ошибки.

Если вы не знакомы с электронной почтой базы данных, ознакомьтесь с этой статьей для получения дополнительной информации о системе электронной почты: Как настроить почту базы данных в SQL Server

Приведенный ниже сценарий создает таблицу с именем DB_Errors , которую можно использовать для хранения данных отслеживания:

Здесь у нас есть простой столбец идентификаторов, за которым следует имя пользователя, поэтому мы знаем, кто сгенерировал ошибку, а остальное — это просто точная информация из встроенных функций, которые мы перечислили ранее.

Теперь давайте изменим настраиваемую хранимую процедуру из базы данных и поместим туда обработчик ошибок:

Изменение этой хранимой процедуры просто оборачивает обработку ошибок в этом случае вокруг единственного оператора внутри хранимой процедуры.Если мы вызовем эту хранимую процедуру и передадим некоторые допустимые данные, произойдет следующее:

Оператор быстрого выбора указывает, что запись была успешно вставлена:

Однако, если мы вызовем вышеупомянутую хранимую процедуру еще раз, передав те же параметры, сетка результатов будет заполнена по-другому:

На этот раз в таблице результатов у нас есть два индикатора:

0 строк затронуло — эта строка указывает на то, что на самом деле ничего не попало в таблицу продаж

1 строка затронула — эта строка указывает, что что-то вошло в нашу недавно созданную таблицу регистрации

Итак, что мы можем сделать здесь, это посмотреть на таблицу ошибок и посмотреть, что произошло.Простая инструкция Select выполнит эту работу:

Здесь у нас есть вся информация, которую мы предварительно установили для регистрации, только на этот раз мы также заполнили поле процедуры и, конечно же, «дружественное» техническое сообщение SQL Server о том, что у нас есть нарушение:

Нарушение ограничения PRIMARY KEY «PK_Sales_1». Невозможно вставить повторяющийся ключ в объект «Продажи. Распродажа». Повторяющееся значение ключа — (20).

Это был очень искусственный пример, но дело в том, что в реальном мире передача неверной даты очень распространена.Например, передача идентификатора сотрудника, которого не существует, в случае, когда у нас есть внешний ключ, настроенный между таблицей продаж и таблицей сотрудников, что означает, что сотрудник должен существовать, чтобы создать новую запись в таблице продаж. Этот вариант использования вызовет нарушение ограничения внешнего ключа.

Общая идея заключается в том, чтобы ошибка не исчезла. Мы, по крайней мере, хотим сообщить человеку, что что-то пошло не так, а затем также зарегистрировать это под капотом. В реальном мире, если бы существовало приложение, полагающееся на хранимую процедуру, разработчики, вероятно, также где-нибудь закодировали бы обработку ошибок SQL Server, потому что они знали бы, когда произошла ошибка.Здесь также было бы разумно передать сообщение об ошибке пользователю / приложению. Это можно сделать, добавив функцию RAISERROR, чтобы мы могли выдать нашу собственную версию ошибки.

Например, если мы знаем, что ввод несуществующего идентификатора сотрудника более вероятен, мы можем выполнить поиск. Этот поиск может проверить, существует ли идентификатор сотрудника, а если его нет, выдать точную ошибку, которая произошла. Или, в худшем случае, если у нас возникла непредвиденная ошибка, о которой мы не знали, что это было, мы можем просто передать, что это было.

Расширенная обработка ошибок SQL

Мы лишь вкратце упомянули сложную часть транзакций, поэтому вот простой пример того, как с ними работать. Мы можем использовать ту же процедуру, что и раньше, только на этот раз давайте обернем транзакцию вокруг оператора Insert:

Итак, если внутри транзакции Begin все выполняется успешно, она вставляет запись в Sales, а затем фиксирует ее.Но если что-то пойдет не так до того, как произойдет фиксация и она передаст управление нашему Catch, возникает вопрос: как мы узнаем, фиксируем ли мы или откатываем все это?

Если ошибка несерьезная и она находится в состоянии фиксации, мы все равно можем зафиксировать транзакцию. Но если что-то пошло не так и находится в нефиксируемом состоянии, мы можем откатить транзакцию. Это можно сделать, просто запустив и проанализировав функцию XACT_STATE, которая сообщает о состоянии транзакции.

Эта функция возвращает одно из следующих трех значений:

1 — транзакция фиксируется

-1 — транзакция не фиксируется и ее следует откатить

0 — незавершенных транзакций нет

Единственная загвоздка здесь — не забыть сделать это внутри оператора catch, потому что вы не хотите начинать транзакции, а затем не фиксировать или откатывать их:

Как, если мы выполним ту же хранимую процедуру, предоставив e.грамм. неверный EmployeeID , мы получим те же ошибки, что и ранее созданная таблица наизнанку:

Чтобы узнать, что это не вставлено, выполните простой запрос Select, выбрав все из таблицы Sales , где EmployeeID равен 20 :

Создание пользовательского SQL-сообщения об ошибке подъема

Давайте подведем итоги и посмотрим, как мы можем создавать собственные сообщения об ошибках.Это хорошо, когда мы знаем, что может возникнуть возможная ситуация. Как мы упоминали ранее, возможно, кто-то передаст неверный идентификатор сотрудника. В этом конкретном случае мы можем выполнить проверку до этого и, конечно же, когда это произойдет, мы можем создать собственное сообщение, например, что идентификатор сотрудника не существует. Это можно легко сделать, еще раз изменив нашу хранимую процедуру и добавив поиск в наш блок TRY:

Если этот счетчик возвращается к нулю, это означает, что сотрудника с таким идентификатором не существует.Затем мы можем вызвать RAISERROR, где мы определяем определяемое пользователем сообщение и, кроме того, нашу настраиваемую серьезность и состояние. Таким образом, для кого-то, использующего эту хранимую процедуру, было бы намного проще понять, в чем проблема, чем увидеть очень техническое сообщение об ошибке, которое в данном случае выдает SQL о проверке внешнего ключа.

С последними изменениями в нашей процедуре хранения в блоке Catch появился еще один RAISERROR. Если произошла другая ошибка, мы можем снова вызвать RAISERROR и передать то, что произошло.Вот почему мы объявили все переменные и результаты всех функций. Таким образом, он не только будет зарегистрирован, но и отчитается перед приложением или пользователем.

И теперь, если мы выполним тот же код, что и раньше, он будет зарегистрирован, а также укажет, что идентификатор сотрудника не существует:

Еще одна вещь, о которой стоит упомянуть, — это то, что мы можем предопределить этот код сообщения об ошибке, серьезность и состояние. Существует хранимая процедура sp_addmessage, которая используется для добавления наших собственных сообщений об ошибках.Это полезно, когда нам нужно вызвать сообщение в нескольких местах; мы можем просто использовать RAISERROR и передать номер сообщения, а не набирать все заново. Выполнив выбранный ниже код, мы добавили эту ошибку в SQL Server:

Это означает, что теперь, вместо того, чтобы делать это так, как мы делали раньше, мы можем просто вызвать RAISERROR и передать номер ошибки, и вот как это выглядит:

Конечно, процедура sp_dropmessage используется для удаления указанного пользователем сообщения об ошибке.Мы также можем просмотреть все сообщения в SQL Server, выполнив запрос снизу:

Их много, и вы можете увидеть наше пользовательское сообщение SQL об ошибке повышения в самом верху.

Я надеюсь, что эта статья была для вас информативной, и благодарю вас за то, что вы ее прочитали.

Список литературы

Он много писал о SQL Shack и ApexSQL Solution Center по самым разным темам, от клиентских технологий, таких как разрешение 4K и тематика, обработки ошибок до стратегий индексации и мониторинга производительности.

Боян работает в ApexSQL в Нише, Сербия, как неотъемлемая часть команды, занимающейся проектированием, разработкой и тестированием следующего поколения инструментов баз данных, включая MySQL и SQL Server, а также автономных инструментов и интеграции с Visual Studio, SSMS. и VSCode.

Подробнее о Бояне на LinkedIn

Просмотреть все сообщения Боян Петрович

PostgreSQL: Документация: 12: Приложение A. Коды ошибок PostgreSQL

Как читать и интерпретировать различные коды ошибок SQL

Коды ошибок в SQL генерируются сервером для предоставления информации о том, что пошло не так.Они имеют разное значение в зависимости от используемой вами версии SQL, но обычно указывают на невозможность выполнения запрошенной операции.

Самый простой способ изучить его — это простейший язык программирования BASIC и его программы, такие как «Hello world». Введите в интерфейс следующее:

  ПЕЧАТЬ "Hello, World!"  

Если вы наберете PRINT как PRRRR, вы получите сообщение об ошибке (эквивалент в реальной жизни: кто-то говорит вам ехать по правой стороне дороги, например.грамм. соблюдая правила).

Это относительно просто, когда дело доходит до простых операций, но как насчет более сложных систем? Мы также включаем сюда примеры кода SQL. Наслаждаться!

Следующий код импортирует необходимые функции из стандартной библиотеки, затем создает консоль, получает указатель на свой стандартный выходной поток, выводит сообщение в этот поток и освобождает используемые объекты:

  Опция Явная

    Объявить функцию AllocConsole Lib "kernel32" () до тех пор, пока
    Объявить функцию FreeConsole Lib "kernel32" () до тех пор, пока
    Объявить функцию CloseHandle Lib "kernel32" (ByVal hObject As Long) до тех пор, пока
    Объявить функцию GetStdHandle Lib "kernel32" (ByVal nStdHandle As Long) до тех пор, пока
    Объявить функцию WriteConsole Lib "kernel32", псевдоним "WriteConsoleA" _
           (ByVal hConsoleOutput As Long, lpBuffer As Any, ByVal _
           nNumberOfCharsToWrite As Long, lpNumberOfCharsWritten As Long, _
           lp Зарезервировано как любое) до тех пор, пока
    Объявить функцию Sleep Lib "kernel32" (ByVal dwMilliseconds As Long) As Long

Частный вспомогательный главный ()
    'создать экземпляр консоли
    AllocConsole
    'получить дескриптор вывода консоли
    Dim hOut до тех пор, пока
    hOut = GetStdHandle (-11 &)
    'выводить строку в консольный вывод
    Dim s As String
    s = "Привет, мир!" & vbCrLf
    WriteConsole hOut, ByVal s, Len (s), vbNull, vbNull
    'сделаем паузу, чтобы посмотреть на результат
    Сон 2000
    'закрой ручку и уничтожь консоль
    CloseHandle hOut
    FreeConsole
Конец подписки
  

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

Что такое коды ошибок SQL и как они работают?

Полезность кодов ошибок SQL заключается в том, что программа находит ваш код и указывает на него (пример). Вам не нужно вручную проверять тысячи строк кода самостоятельно. Представьте, что когда-либо вы получаете всего один код ошибки («Удачи в следующий раз, неудачник!» Или «Кто научил вас программировать, лошадь?») И вам снова приходится просматривать весь проект!

В каком-то смысле коды ошибок — отличные помощники Санты: понятные, полезные и экономящие массу времени.Вам просто нужно их узнать.

Начиная с базового уровня, базы данных представляют собой совокупность собранной и классифицированной информации. Нас интересует тип реляционных баз данных, т. Е. Существуют отношения между ячейками, в которых хранятся данные.

Например, у вас может быть целая группа студентов в университете и вы хотите наградить призом всех, кто набрал более 90% на экзаменах. Вы можете вручную написать их имена, пол, адреса, номера банковских счетов (все они связаны, следовательно, реляционные базы данных), оценки, а затем вручную выбрать те, которые имеют высокие баллы.

Архаичный? Да, но вы будете удивлены, узнав, сколько компаний все еще ведут бизнес таким образом в 21 веке. На выполнение операций, на выполнение которых у компьютера потребуются секунды, могут уйти месяцы. Особенно, если речь идет о сотнях или тысячах студентов.

Теперь, поместив всех этих студентов в базу данных, вы можете использовать такой язык, как SQL:

  ВЫБРАТЬ * ОТ Студента, ГДЕ Процент> = 90;  

Готово! Однако проблемы начинаются, когда вы пишете свой код.

Понятно, что это становится очень сложным, поэтому чем больше вы пишете, тем выше вероятность того, что ваш код содержит ошибки. Здесь наиболее полезны коды ошибок. Когда мы видим коды ошибок, мы должны быть благодарны (что не мешает нам каждый раз ругаться на них). Они делают всю работу за вас, и все, что вам нужно сделать, — это обратиться к источнику и устранить проблему.

Расскажите мне немного подробностей!

Когда база данных не дает желаемых результатов, выдается код ошибки.Это помогает определить проблему и способы ее устранения. Коды ошибок SQL, подобные приведенным ниже, будут полезны при устранении любых проблем с вашими базами данных:

Сообщения об ошибках базы данных Oracle9i

Версия 2 (9.2)

ORA-00904: «указанное количество строк превышает максимальное».

ORA-00900: «Недостаточные права на объект».

ORA-00900: «Недействительный оператор SQL».

ORA-00902: «неверный тип данных».

У нас есть много разных типов ошибок в SQL. Но если вы не собираетесь обрамлять их и повесить на стену, вам нужно знать, как с ними бороться. Хорошо то, что ошибки SQL содержат ссылку на точное местоположение ошибки в коде, а также предоставляют информацию о том, что не так.

Начнем с простейшего примера ошибки:

ORA-00900: «Недействительный оператор SQL».

Как вы, наверное, догадались, вам нужно правильно написать команду.Там может быть опечатка или запятая где-то там, где ему не место. Или, в зависимости от обстоятельств, вам может потребоваться установить дополнительное программное обеспечение:

«Оператор не распознается как допустимый оператор SQL.

Эта ошибка может возникнуть, если Procedural Option не установлен, а инструкция SQL требует наличия этой опции (например, CREATE PROCEDURE). Вы можете определить, установлен ли Procedural Option, запустив SQL * Plus.Если баннер PL / SQL не отображается, значит, опция не установлена.

Действие: Исправьте синтаксис или установите Procedural Option ».

То же самое касается типа форматирования или размещения неправильных типов данных там, где они не принадлежат:

ORA-00902 недопустимый тип данных

«Причина: тип данных, введенный в операторе CREATE или ALTER TABLE, недействителен.

Действие: Исправьте синтаксис ».

Дополнительную информацию можно найти в документации Oracle.

SQL — это наиболее распространенный способ отладки SQL-запросов. Всякий раз, когда вы запрашиваете базу данных и возникает проблема, ядро ​​базы данных генерирует код ошибки SQL. Эти коды отображают местоположение проблемы в запросе и дают программистам информацию о том, как ее исправить или как интерпретировать причину ее возникновения.

Основные типы ошибок

Ошибки формата

Например, когда вы используете SELECT, вам нужно следовать ему в определенной последовательности (перечислить столбцы в таблице, которая содержит наших учащихся и их оценки), а затем поставить звездочку.Если вы не соблюдаете формат, поменяйте местами звездочку и запятую, вы получите сообщение об ошибке.

«если есть НАЧАЛО ТРАНЗАКЦИИ, она всегда должна заканчиваться транзакцией COMMIT или ROLLBACK».

Другой пример: после FROM используются такие операторы, как WHERE, для которых требуется условие. Это может быть любое условие, в том числе условия, извлекающие данные, например, все учащиеся с оценками ниже 30. Если вы оставите это поле пустым, вы получите ошибку форматирования.

Ошибка оператора

Команды должны быть совместимы с SQL.Вы можете включить СУММ и СЧЁТ с ГДЕ. В противном случае вы получите ошибку.

Процедурные ошибки

Процедурный код — это код, хранящийся на сервере, который вы можете использовать для своих целей с небольшими изменениями.

«Хранимая процедура — это подготовленный код SQL, который вы можете сохранить, чтобы код можно было повторно использовать снова и снова… Итак, если у вас есть SQL-запрос, который вы пишете снова и снова, сохраните его как хранимую процедуру и затем просто вызовите его, чтобы выполнить его ». ( W3 школы )

Чтобы создать хранимую процедуру из таблицы с именем Customers со всеми ее записями и выполнить ее, у нас есть следующий код:

  СОЗДАТЬ ПРОЦЕДУРУ SelectAllCustomers
В КАЧЕСТВЕ
ВЫБРАТЬ * ОТ клиентов
ИДТИ;

EXEC SelectAllCustomers;
  

Другими словами, процедуры подобны шаблонам, хранящимся на сервере, которые вы можете брать, изменять и использовать по мере необходимости.

Процедурные ошибки — это более или менее обычные ошибки. Разница в том, что они относятся не к одной строчке кода, а ко всей процедуре (шаблону), которую вы взяли и попытались немного изменить.

Представьте, что у вас есть две таблицы, одна пустая и одна полная. Вы применяете приведенный ниже код к пустой таблице:

  ВСТАВИТЬ для передачи данных
ВЫБРАТЬ и ГДЕ выбрать данные
  

Примером стратегической ошибки может быть использование операторов типа IN и NOT IN.Это заманчиво, но не очень хорошо оптимизировано (использование JOIN — гораздо лучший стратегический выбор).

Фатальные и нефатальные ошибки

База данных, такая как MySQL или PostgreSQL, хранит данные в таблицах, которые состоят из строк и столбцов. Запросы к базе данных — это команды SQL, которые сообщают базе данных, что делать с ее данными. Они могут быть такими простыми, как выбор всех записей из таблицы, или достаточно сложными, чтобы создать совершенно новую таблицу.

Существует два типа ошибок, которые могут возникнуть при использовании этих команд: фатальные и нефатальные.

Фатальная ошибка останавливает выполнение оператора, а нефатальная ошибка — нет.

Неустранимая ошибка — это ошибка базы данных, которую невозможно исправить. Некритическая ошибка — это проблема, которую можно каким-либо образом решить, например, перезапустив службу SQL Server или экземпляр SQL Server.

База данных может иметь как фатальные, так и нефатальные ошибки в любой момент времени по многим причинам. Иногда, если вы знаете о проблеме, ее можно решить без особых трудностей.В других случаях не так уж и много.

Наиболее распространенный тип ошибки — это синтаксическая или другая проблема времени выполнения в системе базы данных, которая обращается к данным из таблицы SQL. Эти ошибки можно выявить при тестировании перед запуском кода. Вы можете убедиться, что все работает правильно, когда выполняется против системы базы данных.

Создание кодов ошибок с помощью RAISERROR

«Существует функция RAISERROR, которую можно использовать для генерации наших пользовательских сообщений об ошибках, что является отличным способом перевести запутанные сообщения об ошибках в нечто более значимое, понятное людям.”

Функция RAISERROR — это системная команда SQL-сервера, которая может вызывать сообщение об ошибке. Вы можете использовать его для обозначения ошибок, предупреждений или информационных сообщений.

Ошибки могут быть вызваны программистом или самим SQL Server. Это полезно для предоставления обратной связи, когда что-то идет не так, но также когда что-то должно произойти, не прерывая выполнение других операторов в пакете.

Используйте следующий синтаксис:

  RAISERROR ([номер_ошибки], [сообщение], [состояние])  

Вы также можете применить RAISERROR либо для прекращения выполнения оператора, либо для передачи ошибок, сгенерированных операторами SQL, другому приложению.Например, вы можете создать сообщение об ошибке, которое приведет к остановке выполнения текущего пакета или оператора, а также отобразит указанное сообщение.

Чаще всего RAISERROR используется для создания сообщения об ошибке, когда данные не соответствуют некоторым критериям, например, при вводе слишком большого количества символов в поле, которое позволяет использовать только 50 символов.

Raiserror (msg) полезно для обработки ошибок, возникающих во время обработки, и не требует сбоя всей транзакции из-за одной отдельной ошибки.

Теперь вы можете создавать столько собственных ошибок, сколько захотите. Радуйтесь!

Работа с ошибками

Чтобы справляться с ошибками, мы должны уметь их контролировать и узнавать всю связанную информацию. Это необходимо в любом случае, более сложном, чем опечатка PRINT в «Hello World».

Одним из полезных способов обнаружения ошибок является использование TRY… CATCH. Этот инструмент позволяет вам взять ваш код и поместить его в среду, где его можно будет исследовать и безопасно обрабатывать.Там вы можете извлечь из него данные. Решите, хотите ли вы сообщить об ошибке, узнать о ней больше или исправить.

Эта песочница SQL-сервера выглядит так:

  НАЧАТЬ ПОПРОБОВАТЬ
 --код, чтобы попробовать
КОНЕЦ ПОПЫТКИ
НАЧАТЬ ЛОВ
 --код для запуска при возникновении ошибки
- генерируется при попытке
КОНЕЦ ЗАХВАТ
  

Код, который вы хотите просмотреть, помещается между BEGIN TRY и END TRY. Если случаются ошибки, он отправляется в оператор CATCH. Это дает нам много полезных функций:

• ERROR_NUMBER возвращает внутренний номер ошибки
• ERROR_STATE возвращает информацию об источнике
• ERROR_SEVERITY возвращает информацию обо всем, от информационных ошибок до ошибок, которые пользователи DBA могут исправить, и т. Д.
• ERROR_LINE возвращает номер строки, в которой произошла ошибка
• ERROR_PROCEDURE возвращает имя хранимой процедуры или функции
• ERROR_MESSAGE возвращает наиболее важную информацию, а именно текст сообщения об ошибке.

Вот что мы получаем, когда пытаемся разделить 1 на 0:

  ЕГЭ AdventureWorks2014
ИДТИ
- Базовый пример TRY ... CATCH
 
НАЧАТЬ ПОПРОБОВАТЬ
- Сгенерировать ошибку деления на ноль
  ВЫБРАТЬ
    1/0 Ошибка AS;
КОНЕЦ ПОПЫТКИ
НАЧАТЬ ЛОВ
  ВЫБРАТЬ
    ERROR_NUMBER () как номер ошибки,
    ERROR_STATE () как ErrorState,
    ERROR_SEVERITY () AS Уровень серьезности ошибок,
    ERROR_PROCEDURE () как ErrorProcedure,
    ERROR_LINE () как ErrorLine,
    ERROR_MESSAGE () AS ErrorMessage;
КОНЕЦ ЗАХВАТ;
ИДТИ
  

Как видите, функция TRY… CATCH очень полезна.

Сводка

Теперь вы точно знаете, что такое код ошибки SQL, какие типы ошибок бывают, почему они возникают, как они изолированы и изучаются, как создавать сигналы об ошибках и т. Д. Вы гораздо больше, чем просто готовы к работе с ошибками. ! Если нет, дайте нам знать, и в будущем мы выпустим больше руководств. Удачи!

(Посещали 57 раз, сегодня 1 посещали)

Помощник по SQL Server — сообщение об ошибке от 1 до 500

Сообщение 823, уровень 24, состояние 2, строка 2
Операционная система вернула ошибку 21 (Устройство не готово.) в SQL Server во время чтения по смещению 0x00000000012000 в файле 'C: \ Program Files \ Delphix \ DelphixConnector \ ENGINE-UUID-vdb-1 \ DATA \ db \ databasename.mdf'.

Дополнительные сообщения в журнале ошибок SQL Server и журнале системных событий могут содержать более подробную информацию.
Это серьезная ошибка системного уровня, которая угрожает целостности базы данных и должна быть немедленно исправлена.
Выполните полную проверку целостности базы данных (DBCC CHECKDB).
Эта ошибка может быть вызвана многими факторами; Дополнительные сведения см. в электронной документации по SQL Server.