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

Содержание

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

Содержание статьи:

SQL-сервер не найден или недоступен, ошибки соединения с SQL-сервером

  • Если SQL-сервер не найден, убедитесь, что ваш экземпляр SQL-сервера действительно установлен и запущен. Для этого зайдите на компьютер, где он установлен, запустите диспетчер конфигурации SQL и проверьте, есть ли там тот экземпляр, к которому вы пытаетесь подключиться и запущен ли он. Нелишним будет также получить отчет об обнаружении компонентов SQL-серверов.
  • Если вы проделали п1. и не обнаружили источник проблемы, возможно, неверно указан IP-адрес компьютера или номер порта TCP. Перепроверьте их настройки.
  • Причиной того, что невозможно подключиться к SQL-серверу, также может быть сеть, убедитесь, что компьютер с SQL-сервером доступен по сети.
  • Проверьте, может ли клиентское приложение, установленное на том же компьютере, что и сервер, подключиться к SQL-серверу. Запустите SQL Server Management Studio(SSMS), в диалоговом окне “Подключиться к серверу” выберите тип сервера Database Engine, укажите способ аутентификации “Аутентификация Windows”, введите имя компьютера и экземпляра SQL-сервера. Проверьте подключение.

Обратите внимание, что многие сообщения об ошибках могут быть не показаны или не содержат достаточной информации для устранения проблемы. Это сделано из соображений безопасности, чтобы при попытке взлома злоумышленники не могли получить информацию об SQL-сервере. Полные сведения содержатся в логе ошибок, который обычно хранится по адресу C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log\ERRORLOG, или там, куда его поместил администратор системы.

Ошибка SQL-сервера 26

Одна из наиболее часто встречающихся ошибок подключения к SQL-серверу, обычно связана с тем, что в настройках SQL-сервера не разрешены или ограничены удаленные соединения. Чтобы это исправить, попробуйте:

  • в SSMS в настройках SQL-сервера включите аутентификацию Windows
  • для брандмауэра Windows  создайте новое правило, которое разрешает подключение для всех программ и протоколов с указанного IP-адреса
  • убедитесь, что запущена служба SQL Server Browser

Ошибка SQL-сервера 18456

Эта ошибка означает, что попытка подключиться к серверу не успешна из-за проблем с именем пользователя или паролем. По коду ошибки в журнале ошибок можно узнать более точную причину, чтобы устранить ее.

Не удалось запустить SQL-server — код ошибки 3417

Возникает в случае, если были изменены настройки Windows или перемещена папка с файлами MSSQL.

  • зайдите в C:\Program Files\Microsoft SQLServer\MSSQL.1\MSSqL\Data — Безопасность\Настройки доступа — Учетная запись сетевой службы — добавьте учетную запись сетевой службы
  • проверьте, что MDF-файл не сжимается. Если это не так, отключите “Сжимать содержимое для экономии места на диске” в свойствах файла

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

Повреждена база данных

Код ошибки SQL-сервера 945

Ошибка 945 возникает, когда БД SQL-сервера помечена как IsShutdown. Проверьте, достаточно ли места на диске, достаточно ли прав у учетной записи для операций с БД, файлы MDF и LDF не должны быть помечены “Только для чтения”.

Код ошибки SQL-сервера 5172

SQL-сервер хранит свою физическую БД в первичном файле, в котором информация разбита постранично. Первая страница содержит информацию о заголовке mdf-файла и называется страницей заголовка. Она состоит из разнообразной информации о БД, такой как размер файла, подпись и т.д. В процессе прикрепления MDF на SQL-сервере часто возникает ошибка 5172. Это в основном происходит, если MDF-файл поврежден, информация в его заголовке тоже и соответственно сложно добраться до данных. Причиной может быть вирус, аварийное выключение системы, ошибка оборудования.

Ошибка SQL-сервера 823

SQL использует API Windows для операций ввода-вывода, но кроме завершения этих операций SQL проверяет все ошибки обращений к API. Если эти обращения несовместимы с ОС, появляется ошибка 823. Сообщение об ошибке 823 означает, что существует проблема с базовым оборудованием для хранения данных или с драйвером, который находится на пути запроса ввода-вывода. Пользователи могут столкнуться с этой ошибкой, если в файловой системе есть противоречия или поврежден файл базы данных.

Ошибка SQL-сервера 8946

Основной причиной ошибки 8946 так же, как и для 5172, является повреждение заголовков страниц БД SQL вследствие сбоя питания, вирусной атаки, отказа оборудования — SQL-сервер больше не может прочесть эти страницы.

Перечисленные ошибки 945, 5172, 823, 8946 можно устранить двумя методами:

  • если у вас есть свежая резервная копия базы — восстановить базу из этой копии
  • можно попробовать использовать специализированное ПО, такое как SQL Recovery Tool, чтобы восстановить поврежденные файлы

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

Другие ошибки SQL

Код ошибки SQL-сервера 1814

SQL-сервер не может создать базу данных tempdb.  Убедитесь, что на выделенном под нее диске достаточно места и что у учетной записи хватает прав для записи в указанную директорию.

Код ошибки SQL-сервера 1067

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

SQL-сервер запускается, но работает слишком медленно

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

Мы работаем с разными версиями SQL-сервера уже много лет, знакомы со всевозможными инструкциями SQL-сервера, видели самые разные варианты его настройки и использования на проектах у своих клиентов. В целом мы можем выделить четыре основных источника неполадок:

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

Если у вас не получается устранить ошибки сервера SQL-server самостоятельно, если они появляются снова и снова, то скорее всего в основе лежит одна из этих причин. В таком случае — если у вас произошла ошибка с SQL сервером, ваше ПО не видит SQL-сервер, либо нужно развернуть кластер SQL-серверов — вы всегда можете обратиться за консультацией и технической поддержкой к специалистам Интегруса, отправив заявку с сайта, написав на e-mail, либо позвонив в колл-центр нашей компании.

Устранение ошибок подключения к SQL Server

Какие функции выполняет это руководство?

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

В этой статье вы можете найти версию документа, в статье Устранение ошибок подключения для SQL Server 

Кто может использовать это средство?

Любой, кто работает с SQL Server и возникли проблемы с подключением.

Как это работает?

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

Приблизительное время завершения

Зависит от сценария, но может занять от 15 минут до 2 часов.

Ошибки СУБД базы данных (ошибка SQL) в программе 1С

Данный материал будет полезен пользователям, столкнувшимся с неточностями в работе программных продуктов на платформе 1С: Предприятие 8.

Наличие большого количества сообщений пользователей (администраторов компаний, клиентов) с просьбой о содействии в ликвидации крупных ошибок СУБД базы данных (ошибка SQL) в программе 1С: Предприятие 8, стало причиной создания данной публикации.

На рисунке 1 приведен пример окна ошибки: Ошибка СУБД Ошибка SQL.


Почему возникают такие ошибки?

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

Примеры источников ошибок в функционировании программ 1С и виды визуального выражения нарушения целостности БД (база данных):

  • аварийное завершение работы ОС с работающей программой 1С: Предприятие 8, в особенности во время формирования, проведения либо удаления файлов;

  • удаление и повреждение конфигурационных файлов в результате вмешательства со стороны пользователя либо техники;

  • приостановка процесса восстановления архивной информации;

  • отсутствие внешнего надежного напряжения питания;

  • присутствие файлов без нумерации, дат создания;

  • присутствие файлов с датой создания, которая не соответствует рядом стоящим файлам, к примеру, 2001 г. 01 ч. 01 мин. 01 с.;

  • присутствие операций без нумерации, дат создания;

  • недоступность ранее созданных файлов и операций;

  • отсутствие ссылок на объекты.

Таким образом, в первую очередь нужно завершить работу программы 1С.

После этого создайте копию БД (база данных) с повреждениями (для этого нужно сохранить базу в отдельный каталог на винчестере). Путь, ведущий к местонахождению БД (база данных), можно определить с помощью панели запуска 1С: Предприятие 8 внизу, найдите данный каталог на жестком диске и скопируйте его (смотрите рисунок 2).

Рисунок 2: Окно запуска 1С: Предприятие 8.

Далее протестируйте БД (база данных) на физическую целостность (на предмет «разрушения»). Чтобы это сделать, выполните переход к стандартной встроенной обработке 1С: Предприятие 8 по исправлению и тестированию неточностей – chdbfl.exe (загрузить для 1С: Предприятие 8). Данный документ должен присутствовать в каталоге с установленной программой 1С, найдите и выполните его запуск (смотрите рисунок 3).

Рисунок 3: Местонахождение документа chdbfl.exe.


Потом выбираем документ 1CV8.1 CD, который можно найти в каталоге нашей БД (база данных) с повреждениями, устанавливаем галочку «Исправлять обнаруженные ошибки» и жмем «Выполнить» (смотрите рисунок 4).

На проверку физической целостности документа БД (база данных) может уйти от 10 мин. до нескольких часов – это определяется объемом вашей БД (база данных) и количеством неточностей в ней. По завершении проверки обнаруженные неточности рекомендуется сохранить в отдельный документ для последующей экспертной диагностики.

Рисунок 4: Окно проверки физической целостности документа информационной базы


После этого зайдите в режим конфигуратора (смотрите рисунок 5) и найдите в нем сервисную утилиту “Тестирование и исправление информационной базы” (смотрите рисунок 6).

Меню – Администрирование – Тестирование и исправление

Рисунок 5: Конфигуратор


Рисунок 6: Окно тестирования и исправления БД (база данных)


Выберите такие пункты, как:

  • Реиндексация таблиц информационной базы – функция восстановления табличной части БД (база данных).

  • Проверка логической целостности информационной базы – функция проверки логической целостности БД (база данных).

  • Проверка ссылочной целостности информационной базы – тестирование внутренних связей таблиц, которые устанавливает программа 1С: Предприятие 8, проверка фактического существования элементов данных со ссылками в полях записи таблиц.

  • Перерасчет итогов – выполнение полного перерасчета итоговых данных.

  • Переключатель ниже, выбор пункта «Тестирование и исправление».

Операция «Тестирование и исправление» может длиться от 10 мин. до нескольких часов – это определяется объемом БД (база данных) и количеством неточностей в ней. По завершении проверки обнаруженные неточности рекомендуется сохранить в отдельный документ для последующей экспертной диагностики.

На следующем этапе закройте конфигуратор, откройте БД (база данных) в стандартном режиме и оцените произошедшие изменения с поврежденными файлами либо справочниками, сформируйте ключевые отчеты для сравнения. Если проблемы отсутствуют и все в порядке, смело продолжайте работу с БД (база данных). Если проблема с информационной базой все еще присутствует, приглашайте эксперта по 1С из обслуживающей компании «АйТи-Консалтинг», либо сразу обращайтесь в техническую поддержку 1С.

Внимательно изучите ситуацию, сделайте верные выводы: обеспечьте вашим работникам обучение корректной работе с программами 1С, купите новую технику на замену старой.

Если Вы слишком заняты и не можете тратить на это время, мы ждем Ваших обращений в сертифицированный центр обслуживания 1С — «АйТи-Консалтинг».

Ошибка MySQL, #1060 Error SQL DB на CMS Joomla

 

От автора

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

Что означает ошибка MySQL, #1060 Error SQL DB на CMS Joomla

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

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

Этот скриншот не относится к примеру в статье, но относиться к ошибке #1060

Исправление ошибки 1060 Error SQL DB

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

Важно! Сделайте резервную копию базы данных. Кнопка «Экспорт», выбрать все таблицы, сжатие ZIP или gZIP. В случае ошибки можно восстановить БД (кнопка «Импорт»).

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

Получаем ответ, от MySQL. В моем примере я обновлял компонент ARTIO JoomSEF. Запрос вы видите на фото, как в принципе и ответ MySQL: #1060-dublicate column name ‘metecustom’. В запросе видим название таблицы: sefurls. В ответе видим, что колонка ‘metecustom’ уже есть в базе данных.

Дальше не сложно. Открываете таблицу sefurls (кликаете по названию в левом списке таблиц), ищите колонку ‘metecustom’. Это текстовая колонка без данных. Далее, удаляем эту колонку, нажав на красный крест в ее строке. Или выделяем чекбокс колонки и нажимаем кнопку «Удалить» в фильтре «Действия» внизу таблицы.

Возвращаемся в административную часть сайта и устанавливаем расширение заново. Должно все получиться.

Причина ошибки MySQL #1060

Откуда появляется ошибка дублирования колонок. В моем примере эта ошибка появилась из-за того, что я в ручную переносил базу данных ARTIO JoomSEF при обновлении Joomla1.5 до Joomla2.5. В работе это не мешало, а вот при обновлении расширения проявилось. В любом случае, Ошибка MySQL, #1060 Error SQL DB на CMS Joomla не сложная, просто внимательно читайте сообщение JInstaller (инсталлятора Joomla).

©Joomla-abc.ru

Другие ошибки Joomla

 

 

10 распространенных ошибок программирования на SQL и как их избежать

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

Первичные ключи – ваш первый шаг к реляционным базам данных. Они ссылаются на внешние ключи в реляционных таблицах. Например, если у вас есть таблица со списком клиентов, столбец «CustomerId» будет уникальным для каждого клиента. Это может быть ваш столбец первичного ключа. Ваше значение CustomerId будет затем помещено в таблицу “Order”, ​​чтобы связать две таблицы вместе. Всегда используйте первичный ключ в каждой создаваемой вами таблице независимо от ее размера.

 

2. Плохо управляемая избыточность данных

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

Например, предположим, что у вас есть таблица клиентов, которая содержит адрес клиента. Поскольку адрес относится к клиенту, он находится в правильном месте. Затем вы создаете таблицу “Order” и добавляете адрес клиента в таблицу “Order”. Этот тип избыточности данных плохо спроектирован. Таблица Customer и “Order” могут связываться друг с другом, используя связи между первичным и внешним ключами. Что произойдет, если вы забудете обновить адрес клиента в таблице заказов? В результате у вас теперь есть два адреса для клиента, и вы не знаете, какой из них является точным.

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

 

3. Избегайте NOT IN или IN и используйте вместо этого JOIN

Операторы NOT IN и IN плохо оптимизированы. Они удобны, но обычно их можно заменить простым оператором JOIN. Посмотрите на пример запроса.

SELECT *FROM Customer
WHERE NOT IN (SELECT CustomerId FROM Order)

 

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

Альтернативный, более эффективный вариант заключается в следующем.

SELECT * FROM Customer c
LEFT JOIN Order o on c.CustomerId = o.CustomerId
WHERE o.CustomerId IS NULL

 

Оператор LEFT JOIN возвращает тот же набор данных, что и предыдущий оператор, но он гораздо более оптимизирован. Он объединяет две таблицы по первичному и внешнему ключу, что повышает скорость запроса и позволяет избежать предложений NOT IN и IN.

 

4. Забытые значения NULL и пустые строковые значения

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

Когда вы определите, что вы хотите использовать, убедитесь, что ваши запросы учитывают эти значения. Например, если вы разрешите NULL для фамилии пользователя, вы должны выполнить запрос с использованием фильтра NULL (NOT NULL или IS NULL) в ваших предложениях, чтобы включить или исключить эти записи.

 

5. Символ звездочки в операторах SELECT

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

SELECT * FROM Customer

 

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

Вместо приведенного выше запроса всегда определяйте каждый столбец. Следующее утверждение является примером.

SELECT CustomerId, FirstName, LastName FROM Customer

 

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

 

6. Цикл с слишком многими курсорами

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

Лучше всего написать процедуру по-другому, чтобы избежать негативного влияния на производительность базы данных, если это возможно. Большинство курсоров можно заменить хорошо написанным оператором SQL. Если вы не можете избежать этого, то курсоры следует сохранить для запланированных заданий, которые выполняются в непиковые часы. Курсоры используются в отчетах о запросах и заданиях на преобразование данных, поэтому их не всегда можно избежать. Просто ограничьте их как можно больше в производственных базах данных, которые ежедневно выполняют запросы к вашей базе данных.

 

7. Несоответствия данных в процедурах назначения на местах

Когда вы объявляете столбцы таблицы, вы должны назначить каждому столбцу тип данных. Убедитесь, что этот тип данных охватывает все необходимые значения, которые необходимо сохранить. Определив тип данных, вы можете хранить только этот тип значения в столбце.

Например, вам, вероятно, нужна десятичная точность на 2-3 пункта в столбце, в котором хранится общая стоимость заказа. Если вы назначите этот столбец как целое число, ваша база данных сможет хранить только целые числа без десятичных значений. Что происходит с десятичными знаками зависит от вашей платформы базы данных. Он может автоматически обрезать значения или выдать ошибку. Любая альтернатива может создать серьезную ошибку в вашем приложении. Всегда учитывайте то, что вам нужно хранить при разработке ваших таблиц.

Это включает в себя написание запросов – когда вы пишете свои запросы и передаете значения параметров в хранимую процедуру, переменная должна быть объявлена ​​с правильным типом данных. Переменные, которые не представляют тип данных столбца, также будут выдавать ошибки или обрезать данные в процессе.

 

8. Логические операции OR и AND

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

Давайте посмотрим на оператор SQL, который смешивает операторы AND и OR.

SELECT CustomerId
FROM Customer
WHERE FirstName = 'AndreyEx' AND LastName = 'Destroyer' OR CustomerId > 0

 

Цель приведенного выше утверждения состоит в том, чтобы получить любых клиентов с именем и фамилией «AndreyEx» и «Destroyer», а идентификатор клиента больше нуля. Однако, поскольку мы смешали оператор AND с OR, возвращаются все записи, в которых идентификатор клиента больше нуля. Мы можем преодолеть это логическое препятствие, используя круглые скобки. Давайте добавим их к приведенному выше утверждению.

SELECT CustomerId
FROM Customer
WHERE (FirstName = 'AndreyEx' OR LastName = 'Destroyer') AND CustomerId > 0

 

Мы изменили логику для этого утверждения. Теперь первый набор скобок возвращает все записи, в которых имя клиента – AndreyEx или фамилия Destroyer. С помощью этого фильтра мы сообщаем SQL, чтобы он возвращал только те значения, где CustomerId больше нуля.

Эти типы логических утверждений должны быть хорошо проверены перед выпуском их в производство.

 

9. Подзапросы должны возвращать одну запись

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

Давайте посмотрим на пример.

SELECT CustomerId,
(SELECT OrderId FROM Order o WHERE c.CustomerId = o.CustomerId)
FROM Customer c

 

В приведенном выше запросе мы получаем список идентификаторов клиентов из таблицы Customer. Обратите внимание, что мы получаем идентификатор заказа из таблицы заказов, где совпадает идентификатор клиента. Если есть только один заказ, этот запрос работает нормально. Однако, если для клиента существует более одного заказа, подзапрос возвращает более одной записи, и запрос не выполняется. Вы можете избежать этой проблемы, используя оператор «Top 1».

Давайте изменим запрос на следующий.

SELECT CustomerId,
(SELECT Top 1 OrderId FROM Order o WHERE c.CustomerId = o.CustomerId ORDER BY OrderDate)
FROM Customer c

 

В приведенном выше запросе мы извлекаем только одну запись и упорядочиваем записи по дате. Этот запрос получает первый заказ, размещенный клиентом.

 

10. JOIN к индексам

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

Любые операторы JOIN, которые вы используете, должны иметь индекс для столбца. Если индекса нет, рассмотрите возможность добавления его в таблицу.

 

Заключение

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

Не удается найти страницу | Autodesk Knowledge Network

(* {{l10n_strings.REQUIRED_FIELD}})

{{l10n_strings.CREATE_NEW_COLLECTION}}*

{{l10n_strings.ADD_COLLECTION_DESCRIPTION}}

{{l10n_strings.COLLECTION_DESCRIPTION}} {{addToCollection.description.length}}/500 {{l10n_strings.TAGS}} {{$item}} {{l10n_strings.PRODUCTS}} {{l10n_strings.DRAG_TEXT}}  

{{l10n_strings.DRAG_TEXT_HELP}}

{{l10n_strings.LANGUAGE}} {{$select.selected.display}}

{{article.content_lang.display}}

{{l10n_strings.AUTHOR}}  

{{l10n_strings.AUTHOR_TOOLTIP_TEXT}}

{{$select.selected.display}} {{l10n_strings.CREATE_AND_ADD_TO_COLLECTION_MODAL_BUTTON}} {{l10n_strings.CREATE_A_COLLECTION_ERROR}}

Как найти причину ошибки сети при работе с 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

. . .
-84 DB2 не может принять этот оператор SQL. Невозможно подготовить инструкцию PREPARE или EXECUTE IMMEDIATE SQL

Fix :
Проверьте источник запроса SQL.

-101 Оператор SQL превышает максимальный предел.

Fix :
Разбейте большие операторы SQL на более мелкие, чтобы снизить сложность.

-104 Код ошибки 104 DB2 sql возникает из-за недопустимого токена символа

Исправление :
В указанном токене проверьте оператор SQL.

-105 Оператор SQL содержит недопустимую строку.

Fix :
Убедитесь, что формат строки правильный.

-111 Функция столбца, такая как SUM, MAX, AVG и т. Д., Недопустима, поскольку она не включает имя столбца в свой операнд.

Fix :
Упомяните имя столбца как операнд его функции.

-117 Количество столбцов и количество вставляемых значений не совпадают.

Fix :
Задайте то же количество значений, что и количество столбцов.

-119 Столбец в предложении HAVING отсутствует в предложении GROUP BY.

Fix :
Добавьте этот столбец в предложение GROUP BY.

-121 Имя столбца встречается более одного раза, пока вы определяете оператор INSERT или UPDATE.

Fix :
Следовательно, исправьте оператор SQL.

-172 Неверное имя функции.

Fix :
Следовательно, вам необходимо исправить имя функции.

-180 DB2 SQLCODE 180 обозначает недопустимый синтаксис для строки, представляющей значение DATETIME.

Fix :
Следовательно, проверьте значение datetime и его тип данных.

-203 Неоднозначная ссылка на имя столбца.

Fix :
Укажите для неоднозначного имени столбца правильное имя таблицы.

-206 Если оператор SQL пытается использовать INSERT, UPDATE или SELECT имя столбца, которое не является частью таблицы, то генерируется этот код ошибки SQL DB2.

Fix :
Проверьте имена столбцов, используемые в операторах INSERT и UPDATE. В случае SELECT проверьте имена столбцов в разделе FROM

-208 Предложение ORDER BY неверно, поскольку имя столбца не является частью таблицы результатов.

Fix :
Удалите имя столбца из предложения ORDER BY или добавьте требуемое имя столбца в таблицу результатов.

-302 SQLCODE 302 означает —
  • Либо тип столбца и длина значения в нем не синхронизированы, либо
  • Тип данных и номер позиции переменной хоста не синхронизированы

    Fix :
    SQLcode 302 немного сбивает с толку, вам нужно проверить, содержат ли переменные хоста допустимое значение.

  • -305 Невозможно присвоить значение NULL выходной переменной хоста без использования индикатора NULL.

    Fix :
    Изучите инструкцию FETCH или SELECT и используйте переменные индикатора NULL для всех переменных хоста, которые могут принимать значения NULL.

    -312 Переменная хоста непригодна для использования или не объявлена.

    Fix :
    Проверьте, правильно ли объявлены переменные хоста.Кроме того, свойства переменной должны быть совместимы с использованием переменной в операторе SQL

    -313 Количество переменных хоста, представленных в операторе OPEN или EXECUTE, не соответствует количеству маркеров параметров в операторе SQL. Маркер параметра — это вопросительный знак.

    Fix :
    Короче говоря, сопоставьте эти значения должным образом.

    -407 Имя столбца, объявленное как NOT NULL, получило значение NULL после оператора UPDATE или INSERT.

    Fix :
    Проверьте все столбцы NOT NULL и примите меры по исправлению.

    -501 DB2 sqlcode 501 возникает, когда программа пытается извлечь или закрыть курсор, который еще не открыт.

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

    -502 Программа попыталась открыть уже открытый курсор.

    Fix :
    Проверьте все предыдущие шаги, правильно ли закрыт курсор.

    -503 Программа не может обновить столбец, поскольку это имя столбца отсутствует в предложении FOR UPDATE оператора SELECT курсора.

    Fix :
    Добавьте имя столбца в предложение FOR UPDATE курсора.

    -504 Имя курсора не определено и не объявлено.

    Fix :
    Сначала объявите имя курсора.

    -507 Программа попыталась запустить курсор UPDATE или DELETE, даже не открывая курсор.

    Fix :
    Сначала откройте курсор.

    -509 Имя таблицы в предложении UPDATE или DELETE не совпадает с именем таблицы, которое используется при объявлении курсора.

    Fix :
    Имя таблицы в предложении UPDATE или DELETE должно совпадать с именем таблицы, которое используется при определении курсора.

    -530 Программа попыталась использовать INSERT или UPDATE для FOREIGN KEY, который был недопустимым, поскольку это значение не соответствовало первичному ключу его родительской таблицы.

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

    -531 Не удалось выполнить ОБНОВЛЕНИЕ первичного ключа в родительской таблице, поскольку у нее есть зависимые строки.

    Fix :
    Проверьте связь первичного ключа с его зависимыми строками.

    -539 Внешний ключ попытался сослаться на родительскую таблицу, но у родительской таблицы нет первичного ключа.

    Fix :
    Либо добавьте первичный ключ в родительскую таблицу, либо обратитесь к правильной таблице с первичным ключом

    -540 Уникальный индекс или первичный индекс не определен для первичного ключа до обращения к таблице

    Fix :
    Во-первых, вы должны создать первичный индекс или уникальный индекс до обращения к таблице.

    -542 Определенный столбец, который может содержать значения NULL, не может быть частью первичного ключа.

    Fix :
    Убедитесь, что имя столбца, являющееся частью первичного ключа, определено как NOT NULL

    -602 CREATE INDEX содержит слишком много столбцов.

    Fix :
    Уменьшите количество столбцов.

    -603 DB2 не может создать УНИКАЛЬНЫЙ ИНДЕКС, поскольку для имени столбца, необходимого в качестве уникального индекса, присутствуют повторяющиеся записи.

    Исправление :
    Удалите повторяющиеся записи в обязательном столбце, который должен быть уникальным индексом.

    -612 При создании таблицы, представления или индекса вы указали повторяющееся имя столбца.

    Fix :
    Следовательно, следует указывать только уникальные имена столбцов.

    -613 Либо первичный ключ содержит слишком много столбцов, либо первичный ключ очень длинный.

    Fix :
    Уменьшите количество столбцов и в то же время убедитесь, что длина столбца не очень большая.

    -624 Таблица не может иметь более одного первичного ключа.

    Fix :
    Не создавайте другой первичный ключ для той же таблицы.

    -638 Вы пытались создать таблицу без добавления определений столбцов.

    Fix :
    Проверьте, не пропустили ли вы установку определений столбцов

    -680 Программа попыталась создать более 750 столбцов в таблице.

    Fix :
    Нельзя добавить более 750 столбцов в таблицу.

    -687 Вы пытаетесь сравнить 2 столбца с разными типами данных.

    Fix :
    Проверьте оператор SQL, чтобы проверить любое сравнение между несовместимыми полями.

    -803 Вы попытались вставить или обновить повторяющееся значение в уникальный индекс.

    Fix :
    Проверьте повторяющуюся запись и удалите ее.

    -805 Код SQLCode 805 очень распространен, и это происходит из-за того, что имя программы отсутствует в ПЛАНЕ

    Fix :
    Свяжите программу в плане должным образом.

    -811 Код ошибки SQL 811 также является распространенной ошибкой. Либо оператор SELECT вернул более одной строки, либо базовый предикат содержит подзапрос, который приводит к более чем одному значению.

    Fix :
    Итак, лучше правильно привязать программу к плану.

    -818 TIMESTAMP внутри LOAD MODULES, который генерируется PreCompiler, отличается от TIMESTAMP внутри DBRM, который создается во время BIND.

    Fix :
    Следовательно, снова привяжите программу.

    -901 Оператор SQL не удалось выполнить из-за системной ошибки

    Исправление :
    Уточните у администратора базы данных или группы системных программистов, почему произошла системная ошибка.

    -904 Оператор SQL завершился неудачно из-за недоступности ресурса

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

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

    Исправление :
    Проверьте, почему оператор SQL превышает максимальное время использования ресурса.Кроме того, вам следует оптимизировать SQL-запросы, индексацию и т. Д.

    -909 Прикладная программа могла отбросить таблицу или индекс и попытаться получить доступ к таблице или индексу соответственно, но потерпела неудачу, потому что таблица или индекс уже отброшены.

    Fix :
    Исправьте прикладную программу.

    -911 Db2 SQLCODE 911 — это распространенная ошибка, связанная с DEADLOCK или TIMEOUT. Выполнение завершается неудачно, и работа откатывается до последней фиксации.

    Fix :
    В частности, вы можете изменить логику, чтобы зафиксировать частоту. Кроме того, вы можете избежать более частого использования очень загруженного ресурса.

    -913 Выполнение завершается неудачно из-за DEADLOCK или TIMEOUT

    Fix :
    Разработайте логику, чтобы работа могла фиксироваться или откатываться к последней фиксации в зависимости от логики.

    -922 Ошибка авторизации во время подключения

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

    -923 Ошибка подключения

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

    -924 Код SQL 924 — это внутренняя ошибка для подключения к DB2

    Исправление :
    Обратитесь к группе администраторов баз данных по вопросу подключения

    Как реализовать обработку ошибок в 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

    BEGIN CATCH

    —код для запуска при возникновении ошибки

    — генерируется при попытке

    END 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. Приведенный ниже сценарий максимально прост:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    17 9009 16

    18

    19

    USE AdventureWorks2014

    GO

    — Базовый пример TRY…CATCH

    BEGIN TRY

    — сгенерировать ошибку деления на ноль

    SELECT

    1/0 AS Error;

    END TRY

    BEGIN CATCH

    SELECT

    ERROR_NUMBER () AS ErrorNumber,

    ERROR_STATE () AS ErrorState,

    ERROR_SEVERITY () AS ErrorSeverity,

    ERROR_PROcedure

    ERROR_PROCEDURE 9 (AS) ,

    ERROR_MESSAGE () AS ErrorMessage;

    КОНЦЕВОЙ ЗАЖИМ;

    ГО

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

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

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

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

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

    — Таблица для записи ошибок

    СОЗДАТЬ ТАБЛИЦУ DB_Errors

    (ErrorID INT IDENTITY (1, 1),

    UserName VARCHAR (100),

    ErrorNumber INT,

    ErrorState INT,

    ErrorSeverity INT,

    ErrorLine INT,

    ErrorProcedure VARCHAR (MAX),

    ErrorMessage VARCHAR (MAX),

    ErrorDateTime DATETIME)

    GO

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

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

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    17 9009 16

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    ИЗМЕНЕНИЕ ПРОЦЕДУРЫ dbo.AddSale @employeeid INT,

    @productid INT,

    @quantity SMALLINT,

    @saleid UNIQUEIDENTIFIER OUTPUT

    AS

    SET @saleid = NEWID ()

    BEGIN TRY

    INSECT

    @saleid,

    @productid,

    @employeeid,

    @quantity

    END TRY

    BEGIN CATCH

    INSERT INTO dbo.DB_Errors

    VALUES

    (SUSER_SNAME (),

    ERROR_NUMBER (),

    ERROR_STATE (),

    ERROR_SEVERITY (),

    ERROR_LINE (),

    ERROR_LINE (),

    ERRESS_PROESS9 ());

    КОНЦЕВОЙ ЗАХВАТ

    GO

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

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

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

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

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

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

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

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

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

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

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

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

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


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

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    17 9009 16

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33 34

    35

    36

    37

    ИЗМЕНЕНИЕ ПРОЦЕДУРЫ dbo.AddSale @employeeid INT,

    @productid INT,

    @quantity SMALLINT,

    @saleid UNIQUEIDENTIFIER OUTPUT

    AS

    SET @saleid = NEWID ()

    BEGIN TRY

    BEGIN TRY

    BEGIN TRY

    BEGIN TRY

    BEGIN TRY

    BEGIN

    SELECT

    @saleid,

    @productid,

    @employeeid,

    @quantity

    COMMIT TRANSACTION

    END TRY

    BEGIN CATCH

    INSERT INTO dbo.DB_Errors

    VALUES

    (SUSER_SNAME (),

    ERROR_NUMBER (),

    ERROR_STATE (),

    ERROR_SEVERITY (),

    ERROR_LINE (),

    ERROR_LINE (),

    ERRESS_PROESS9 ());

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

    IF (XACT_STATE ()) = -1

    ROLLBACK TRANSACTION

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

    IF (XACT_STATE ()) = 1

    COMMIT TRANSACTION

    END CATCH

    ГО

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

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

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

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

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

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

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

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

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

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

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

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    17 9009 16

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33 34

    35

    36

    ИЗМЕНЕНИЕ ПРОЦЕДУРЫ dbo.AddSale @employeeid INT,

    @productid INT,

    @quantity SMALLINT,

    @saleid UNIQUEIDENTIFIER OUTPUT

    AS

    SET @saleid = NEWID ()

    BEGIN TRY

    IF (SEL .Employee e WHERE employeeid = @employeeid) = 0

    RAISEERROR (‘EmployeeID не существует.’, 11, 1)

    INSERT INTO Sales.Sales

    SELECT

    @saleid,

    @productid,

    @employeeid,

    @quantity

    END TRY

    BEGIN CATCH

    INSERT INTO dbo.DB_Errors

    VALUES

    (SUSER_SNAME (),

    ERROR_NUMBER (),

    ERROR_STATE (),

    ERROR_SEVERITY (),

    ERROR_LINE (),

    ERROR_LINE (),

    ERRESS_PROESS9 ());

    DECLARE @Message varchar (MAX) = ERROR_MESSAGE (),

    @Severity int = ERROR_SEVERITY (),

    @State smallint = ERROR_STATE ()

    RAISEERROR (@StateS), @StateS, @StateS, @Message, @Message, @Message,

    КОНЦЕВОЙ ЗАХВАТ

    GO

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

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

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

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

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

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

    ВЫБРАТЬ * ИЗ master.dbo.sysmessages

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

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

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

    Боян, он же «Бокси», выпускник AP в области ИТ-технологий, специализирующийся на сетях и электронных технологиях Копенгагенской школы дизайна и технологий, является аналитиком программного обеспечения с опытом в области обеспечения качества, поддержки программного обеспечения, пропаганды продуктов и взаимодействия с пользователями.

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

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

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

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

    Последние сообщения Боян Петрович (посмотреть все)

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

    Класс 00 — Успешное завершение
    00000 успешное завершение
    Класс 01 — Предупреждение
    01000 предупреждение
    0100C dynamic_result_sets_returned
    01008 implicit_zero_bit_padding
    01003 null_value_eliminated_in_set_function
    01007 Privilege_not_granted
    01006 Privilege_not_revoked
    01004 string_data_right_truncation
    01P01 deprecated_feature
    Класс 02 — Нет данных (это также класс предупреждения по стандарту SQL)
    02000 no_data
    02001 no_additional_dynamic_result_sets_returned
    Класс 03 — SQL-запрос еще не завершен
    03000 sql_statement_not_yet_complete
    Класс 08 — исключение подключения
    08000 connection_exception
    08003 connection_does_not_exist
    08006 connection_failure
    08001 sqlclient_unable_to_establish_sqlconnection
    08004 sqlserver_rejected_establishment_of_sqlconnection
    08007 transaction_resolution_unknown
    08P01 нарушение протокола
    Класс 09 — исключение инициируемого действия
    09000 triggered_action_exception
    Класс 0A — функция не поддерживается
    0A000 feature_not_supported
    Класс 0B — недопустимое инициирование транзакции
    0B000 invalid_transaction_initiation
    Класс 0F — исключение локатора
    0F000 locator_exception
    0F001 invalid_locator_specification
    Класс 0L — Недействительный праводатель
    0L000 invalid_grantor
    0LP01 invalid_grant_operation
    Класс 0P — недопустимая спецификация роли
    0P000 invalid_role_specification
    Класс 0Z — исключение диагностики
    0Z000 Diagnostics_exception
    0Z002 stacked_diagnostics_accessed_without_active_handler
    Класс 20 — Случай не найден
    20000 case_not_found
    Класс 21 — Нарушение мощности
    21000 cardinality_violation
    Класс 22 — исключение данных
    22000 исключение_данных
    2202E array_subscript_error
    22021 character_not_in_repertoire
    22008 datetime_field_overflow
    22012 деление_по_зеро
    22005 error_in_assignment
    2200B escape_character_conflict
    22022 indicator_overflow
    22015 interval_field_overflow
    2201E invalid_argument_for_logarithm
    22014 invalid_argument_for_ntile_function
    22016 invalid_argument_for_nth_value_function
    2201F недопустимый_аргумент для_функции мощности
    2201G invalid_argument_for_width_bucket_function
    22018 invalid_character_value_for_cast
    22007 invalid_datetime_format
    22019 invalid_escape_character
    2200D invalid_escape_octet
    22025 invalid_escape_sequence
    22P06 нестандартное_использование_экранированного_символа
    22010 invalid_indicator_parameter_value
    22023 invalid_parameter_value
    22013 invalid_preceding_or_following_size
    2201B недействительное_регулярное_выражение
    2201 Вт invalid_row_count_in_limit_clause
    2201X invalid_row_count_in_result_offset_clause
    2202H invalid_tablesample_argument
    2202G invalid_tablesample_repeat
    22009 invalid_time_zone_displacement_value
    2200C invalid_use_of_escape_character
    2200G most_specific_type_mismatch
    22004 null_value_not_allowed
    22002 null_value_no_indicator_parameter
    22003 numeric_value_out_of_range
    2200H sequence_generator_limit_exceeded
    22026 string_data_length_mismatch
    22001 string_data_right_truncation
    22011 substring_error
    22027 trim_error
    22024 unterminated_c_string
    2200F zero_length_character_string
    22P01 исключительная_плавающая_точка
    22P02 недействительный_текст_представление
    22P03 недопустимое_бинарное_представление
    22P04 bad_copy_file_format
    22P05 непереводимый_символ
    2200L not_an_xml_document
    2200M invalid_xml_document
    2200N invalid_xml_content
    2200S invalid_xml_comment
    2200 т invalid_xml_processing_instruction
    22030 duplicate_json_object_key_value
    22032 invalid_json_text
    22033 invalid_sql_json_subscript
    22034 more_than_one_sql_json_item
    22035 no_sql_json_item
    22036 non_numeric_sql_json_item
    22037 non_unique_keys_in_a_json_object
    22038 singleton_sql_json_item_required
    22039 sql_json_array_not_found
    2203A sql_json_member_not_found
    2203B sql_json_number_not_found
    2203C sql_json_object_not_found
    2203D too_many_json_array_elements
    2203E too_many_json_object_members
    2203F sql_json_scalar_required
    Класс 23 — Нарушение ограничений целостности
    23000 нарушение_ целостности
    23001 restrict_violation
    23502 not_null_violation
    23503 foreign_key_violation
    23505 unique_violation
    23514 check_violation
    23P01 exclusion_violation
    Класс 24 — недопустимое состояние курсора
    24000 invalid_cursor_state
    Класс 25 — недопустимое состояние транзакции
    25000 invalid_transaction_state
    25001 active_sql_transaction
    25002 branch_transaction_already_active
    25008 hold_cursor_requires_same_isolation_level
    25003 неприемлемый_ режим_доступа_для_ответственной_транзакции
    25004 неприемлемый_уровень_изолированности_для_ответственной_транзакции
    25005 no_active_sql_transaction_for_branch_transaction
    25006 read_only_sql_transaction
    25007 schema_and_data_statement_mixing_not_supported
    25P01 no_active_sql_transaction
    25P02 in_failed_sql_transaction
    25P03 idle_in_transaction_session_timeout
    Класс 26 — недопустимое имя оператора SQL
    26000 invalid_sql_statement_name
    Класс 27 — нарушение инициируемого изменения данных
    27000 triggered_data_change_violation
    Класс 28 — Недействительная спецификация авторизации
    28000 invalid_authorization_specification
    28P01 неверный_пароль
    Класс 2B — зависимые дескрипторы привилегий все еще существуют
    2B000 зависимые_привилегированные_дескрипторы_still_exist
    2BP01 зависимые_объекты_постоянно_существующие
    Класс 2D — Недействительное прекращение транзакции
    2D000 invalid_transaction_termination
    Класс 2F — исключение процедуры SQL
    2F000 sql_routine_exception
    2F005 function_executed_no_return_statement
    2F002 modifying_sql_data_not_permitted
    2F003 hibited_sql_statement_attempted
    2F004 чтение_sql_data_not_permitted
    Класс 34 — Недействительное имя курсора
    34000 invalid_cursor_name
    Класс 38 — исключение внешней процедуры
    38000 external_routine_exception
    38001 contains_sql_not_permitted
    38002 modifying_sql_data_not_permitted
    38003 hibited_sql_statement_attempted
    38004 чтение_sql_data_not_permitted
    Класс 39 — исключение внешнего вызова подпрограммы
    39000 external_routine_invocation_exception
    39001 invalid_sqlstate_returned
    39004 null_value_not_allowed
    39P01 триггерный_протокол_ нарушен
    39P02 srf_protocol_violated
    39P03 event_trigger_protocol_violated
    Класс 3B — исключение точки сохранения
    3B000 savepoint_exception
    3B001 invalid_savepoint_specification
    Класс 3D — Недействительное имя в каталоге
    3D000 invalid_catalog_name
    Класс 3F — недопустимое имя схемы
    3F000 invalid_schema_name
    Класс 40 — Откат транзакции
    40000 transaction_rollback
    40002 transaction_integrity_constraint_violation
    40001 serialization_failure
    40003 statement_completion_unknown
    40P01 deadlock_detected
    Класс 42 — синтаксическая ошибка или нарушение правила доступа
    42000 syntax_error_or_access_rule_violation
    42601 syntax_error
    42501 недостаточная_привилегия
    42846 cannot_coerce
    42803 grouping_error
    42P20 windowing_error
    42P19 invalid_recursion
    42830 invalid_foreign_key
    42602 invalid_name
    42622 name_too_long
    42939 зарезервированное_имя
    42804 datatype_mismatch
    42P18 indeterminate_datatype
    42P21 collation_mismatch
    42P22 indeterminate_collation
    42809 неправильный_тип_объекта
    428C9 created_always
    42703 undefined_column
    42883 undefined_function
    42P01 undefined_table
    42P02 undefined_parameter
    42704 undefined_object
    42701 duplicate_column
    42P03 duplicate_cursor
    42P04 duplicate_database
    42723 дубликат_функции
    42P05 duplicate_prepared_statement
    42P06 duplicate_schema
    42P07 duplicate_table
    42712 duplicate_alias
    42710 duplicate_object
    42702 ambiguous_column
    42725 неоднозначная_функция
    42P08 неоднозначный_параметр
    42P09 ambiguous_alias
    42P10 invalid_column_reference
    42611 invalid_column_definition
    42P11 invalid_cursor_definition
    42P12 invalid_database_definition
    42P13 invalid_function_definition
    42P14 invalid_prepared_statement_definition
    42P15 invalid_schema_definition
    42P16 invalid_table_definition
    42P17 invalid_object_definition
    Class 44 — WITH CHECK OPTION Нарушение
    44000 with_check_option_violation
    Класс 53 — Недостаток ресурсов
    53000 недостаточно_ресурсов
    53100 диск_полный
    53200 out_of_memory
    53300 too_many_connections
    53400 configuration_limit_exceeded
    Класс 54 — Превышен предел программы
    54000 program_limit_exceeded
    54001 statement_too_complex
    54011 too_many_columns
    54023 too_many_arguments
    Класс 55 — объект не в обязательном состоянии
    55000 object_not_in_prerequisite_state
    55006 объект_в_использовании
    55P02 cant_change_runtime_param
    55P03 lock_not_available
    55P04 unsafe_new_enum_value_usage
    Класс 57 — вмешательство оператора
    57000 оператор_вмешательство
    57014 query_canceled
    57P01 admin_shutdown
    57P02 crash_shutdown
    57P03 cannot_connect_now
    57P04 database_dropped
    Класс 58 — Системная ошибка (ошибки, внешние по отношению к самому PostgreSQL)
    58000 system_error
    58030 io_error
    58P01 undefined_file
    58P02 duplicate_file
    Класс 72 — Ошибка моментального снимка
    72000 snapshot_too_old
    Класс F0 — ошибка файла конфигурации
    F0000 config_file_error
    F0001 lock_file_exists
    Class HV — Ошибка оболочки сторонних данных (SQL / MED)
    HV000 fdw_error
    HV005 fdw_column_name_not_found
    HV002 fdw_dynamic_parameter_value_needed
    HV010 fdw_function_sequence_error
    HV021 fdw_inconsistent_descriptor_information
    HV024 fdw_invalid_attribute_value
    HV007 fdw_invalid_column_name
    HV008 fdw_invalid_column_number
    HV004 fdw_invalid_data_type
    HV006 fdw_invalid_data_type_descriptors
    HV091 fdw_invalid_descriptor_field_identifier
    HV00B fdw_invalid_handle
    HV00C fdw_invalid_option_index
    HV00D fdw_invalid_option_name
    HV090 fdw_invalid_string_length_or_buffer_length
    HV00A fdw_invalid_string_format
    HV009 fdw_invalid_use_of_null_pointer
    HV014 fdw_too_many_handles
    HV001 fdw_out_of_memory
    HV00P fdw_no_schemas
    HV00J fdw_option_name_not_found
    HV00K fdw_reply_handle
    HV00Q fdw_schema_not_found
    HV00R fdw_table_not_found
    HV00L fdw_unable_to_create_execution
    HV00M fdw_unable_to_create_reply
    HV00N fdw_unable_to_establish_connection
    Класс P0 — Ошибка PL / pgSQL
    P0000 plpgsql_error
    P0001 raise_exception
    P0002 no_data_found
    P0003 too_many_rows
    P0004 assert_failure
    Класс XX — внутренняя ошибка
    XX000 внутренняя ошибка
    XX001 поврежденные данные
    XX002 index_corrupted

    Как читать и интерпретировать различные коды ошибок 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

    Инструкции Предложение Предложение
    Ошибка Уровень серьезности Описание
    251 16 Не удалось выделить вспомогательную таблицу для оптимизации запроса.Максимум количество таблиц в запросе (% d) превышено.
    252 16 Рекурсивное общее табличное выражение «<Имя общего табличного выражения>» не содержит оператора UNION ALL верхнего уровня.
    253 16 Рекурсивный член общего табличного выражения «<Имя общего табличного выражения>» имеет несколько рекурсивных ссылок.
    254 16 Столбцы с префиксом не допускаются в списке столбцов оператора PIVOT.
    255 16 Псевдостолбцы не разрешены в списке столбцов оператора PIVOT.
    256 16 Тип данных int недопустим для подстроки функция. Допустимые типы: char / varchar, nchar / nvarchar и двоичный / varbinary.
    257 16 Неявное преобразование из типа данных% ls в% ls запрещено.Использовать функция CONVERT для выполнения этого запроса.
    258 16 Невозможно вызвать методы на% ls.
    259 16 Специальные обновления системных каталогов не включены. Система администратор должен перенастроить SQL Server, чтобы разрешить это.
    260 16 Запрещено неявное преобразование из типа данных% ls в тип данных % ls, таблица «%.* ls ‘, столбец’%. * ls ‘. Используйте функцию CONVERT для выполнения этого запроса.
    261 16 «%. * Ls» не является распознанной функцией.
    262 16 Разрешение% ls отклонено в базе данных «%. * Ls».
    263 16 Необходимо указать таблицу для выбора.
    264 16 Имя столбца «%.* ls ‘появляется более одного раза в столбце результатов список.
    265 16 Имя столбца «%. * Ls», указанное в операторе% ls, конфликтует с существующим именем столбца в аргументе% ls.
    266 16 Счетчик транзакций после EXECUTE указывает, что COMMIT или Оператор ROLLBACK TRANSACTION отсутствует. Предыдущее количество =% ld, текущее количество =% ld.
    267 16 Объект «%. * Ls» не найден.
    268 16 Невозможно запустить SELECT INTO в этой базе данных. Владелец базы данных должен запустите sp_dboption, чтобы включить эту опцию.
    270 16 Невозможно изменить объект «%. * Ls».
    271 16 SQL Server 2005, SQL Server 2008, SQL Server 2012 — столбец «<Имя столбца>» нельзя изменить, поскольку он является либо вычисляемым столбцом, либо результатом оператора UNION.
    SQL Server 2000 — столбец «<имя столбца>» нельзя изменить, поскольку это вычисляемый столбец.
    272 16 Невозможно обновить столбец отметки времени.
    273 16 Невозможно вставить ненулевое значение в столбец отметки времени. Используйте INSERT со списком столбцов или со значением по умолчанию NULL для столбца с меткой времени.
    275 16 Префиксы не допускаются в столбцах значений или сводных столбцах оператора UNPIVOT.
    276 16 Псевдостолбцы нельзя использовать в качестве столбцов значений или сводных столбцов оператора UNPIVOT.
    277 16 Столбец «%. * Ls» указан несколько раз в списке столбцов оператора UNPIVOT.
    278 16 Типы данных text, ntext и image нельзя использовать в GROUP BY. пункт.
    279 16 Типы данных text, ntext и image недопустимы в этом подзапросе. или агрегатное выражение.
    280 16 Только текстовые, ntext и графические столбцы допустимы с TEXTPTR. функция.
    281 16 <Номер стиля> не является допустимым номером стиля при преобразовании из% ls в символьная строка.
    282 10 Процедура ‘%. * Ls’ попыталась вернуть состояние NULL, что не разрешено. Вместо этого будет возвращен статус 0.
    283 16 READTEXT нельзя использовать для вставленных или удаленных таблиц в ВМЕСТО триггера.
    284 16 Правила не могут быть привязаны к типам данных text, ntext или image.
    285 16 Операторы READTEXT, WRITETEXT и UPDATETEXT использовать нельзя. с представлениями или функциями.
    286 16 Логические таблицы INSERTED и DELETED не могут быть обновлены.
    287 16 Оператор% ls недопустим в триггере.
    288 16 Функция PATINDEX работает с char, nchar, varchar, nvarchar, Только типы данных text и ntext.
    290 16 Неверный оператор EXECUTE с использованием объекта «% ls», метод «% ls».
    291 16 CAST или CONVERT: для типа «%. * Ls» указаны недопустимые атрибуты
    292 16 Недостаточно места для результата для преобразования значения smallmoney в varchar / nvarchar.
    293 16 Невозможно преобразовать значение char в smallmoney.Значение char имеет неправильный синтаксис.
    294 16 Преобразование типа данных char в тип данных smallmoney привело к ошибке переполнения smallmoney.
    295 16 Синтаксическая ошибка преобразования символьной строки в данные smalldatetime тип.
    296 16 Преобразование типа данных char в тип данных smalldatetime привело к значению smalldatetime вне допустимого диапазона.
    297 16 У пользователя нет разрешения на выполнение этого действия.
    298 16 Преобразование из типа данных datetime в тип данных smalldatetime привело к ошибке переполнения smalldatetime.
    299 16 Функция DATEADD была вызвана с неверным типом% ls.
    300 14 В разрешении% ls отказано для объекта «%. * Ls», базы данных «%. * Ls».
    301 16 Запрос содержит недопустимый запрос внешнего соединения.
    302 16 Встроенная функция newsequentialid () может использоваться только в выражении DEFAULT для столбца типа uniqueidentifier в операторе CREATE TABLE или ALTER TABLE.Его нельзя комбинировать с другими операторами для формирования сложного скалярного выражения.
    303 16 Таблица «%. * Ls» является внутренним членом предложения внешнего соединения. Этот не допускается, если таблица также участвует в обычном предложении соединения.
    304 16 «% d» выходит за пределы диапазона для параметра индекса «%. * Ls». См. Допустимые значения в параметре sp_configure «% ls».
    305 16 Тип данных XML нельзя сравнивать или сортировать, за исключением случая использования оператора IS NULL.
    306 16 Типы данных text, ntext и image нельзя сравнивать или отсортировано, кроме случаев использования оператора IS NULL или LIKE.
    307 16 Идентификатор индекса% d в таблице «%.* ls ‘(указанный в предложении FROM) делает не существует.
    308 16 Индекс «%. * Ls» в таблице «%. * Ls» (указанный в предложении FROM) не соответствует не существует.
    309 16 Невозможно использовать индекс «%. * Ls» в таблице «%. * Ls» в подсказке. В подсказках нельзя использовать индексы XML.
    310 16 Значение , указанное для опции MAXRECURSION, превышает допустимый максимум% d.
    311 16 Невозможно использовать столбцы типа text, ntext или image во вставленных и «удаленные» таблицы.
    312 16 Невозможно сослаться на столбцы текста, ntext или изображения в сохраненном фильтре. процедура.
    313 16 Недостаточное количество аргументов поставляется для процедуры или функции%.* ls.
    314 16 Невозможно использовать GROUP BY ALL со специальными таблицами INSERTED или DELETED.
    315 16 Индекс «%. * Ls» в таблице «%. * Ls» (указанный в предложении FROM) отключен или находится в файловой группе, которая не находится в оперативном режиме.
    316 16 Идентификатор индекса% d в таблице «%. * Ls» (указанный в предложении FROM) отключен или находится в файловой группе, которая не находится в оперативном режиме.
    317 16 Возвращающая табличное значение функция «<Имя функции>» не может иметь псевдонима столбца.
    318 16 Таблица (и ее столбцы), возвращаемые методом, возвращающим табличное значение, должны иметь псевдоним.
    319 16 Неправильный синтаксис рядом с ключевым словом with. Если этот оператор является общим табличным выражением, предложением xmlnamespaces или предложением контекста отслеживания изменений, предыдущий оператор должен заканчиваться точкой с запятой.
    320 16 Значение переменной времени компиляции для «%. * Ls» в предложении OPTIMIZE FOR должно быть литералом.
    321 15 %. * Ls не является опцией подсказок для таблиц. Если он предназначен в качестве параметра для функции, возвращающей табличное значение, или для функции CHANGETABLE, убедитесь, что для режима совместимости вашей базы данных установлено значение 90.
    322 16 Переменная «%.* ls «указан в предложении OPTIMIZE FOR, но не используется в запросе.
    323 16 Предложение ‘COMPUTE’ не допускается в операторе, содержащем оператор INTERSECT или EXCEPT.
    324 15 Версия «ALL» оператора%. * Ls не поддерживается.
    325 15 Неправильный синтаксис рядом с «%.* ls ‘. Вам может потребоваться установить более высокий уровень совместимости текущей базы данных, чтобы включить эту функцию. См. Справку по параметру SET COMPATIBILITY_LEVEL команды ALTER DATABASE.
    326 16 Составной идентификатор «%. * Ls» неоднозначен. Оба столбца «%. * Ls» и «%. * Ls» существуют.
    327 16 Вызов функции «%. * Ls» неоднозначен: существуют как пользовательская функция, так и вызов метода с этим именем.
    328 16 Не удалось создать план курсора для данного оператора, поскольку функция textptr () использовалась для столбца LOB из одной из базовых таблиц.
    329 16 Каждое выражение GROUP BY должно содержать хотя бы одну ссылку на столбец.
    330 15 Целевой объект «<Имя объекта>» предложения OUTPUT INTO не может быть представлением или общим табличным выражением.
    331 15 Целевая таблица «<Имя таблицы>» предложения OUTPUT INTO не может иметь никаких включенных триггеров.
    332 15 Целевая таблица «<Имя таблицы>» предложения OUTPUT INTO не может находиться ни на одной из сторон отношения (первичный ключ, внешний ключ). Найдено ссылочное ограничение «<Имя ограничения первичного ключа или внешнего ключа>».
    333 15 Целевая таблица «<Имя таблицы>» предложения OUTPUT INTO не может иметь никаких включенных проверочных ограничений или каких-либо разрешенных правил.Найдено проверочное ограничение или правило «».
    334 15 Целевая таблица «<Имя таблицы>» оператора DML не может иметь никаких включенных триггеров, если оператор содержит предложение OUTPUT без предложения INTO.
    335 16 Вызов функции не может использоваться для сопоставления целевой таблицы в предложении FROM операторов DELETE или UPDATE.Вместо этого используйте имя функции «%. * Ls» без параметров.
    336 15 Неправильный синтаксис рядом с «%. * Ls». Если это должно быть обычное табличное выражение, вам необходимо явно завершить предыдущий оператор точкой с запятой.
    337 10 Предупреждение: значение с плавающей запятой «%. * Ls» слишком мало. Это будет интерпретировано как 0.
    338 16 READEXT, WRITETEXT и UPDATETEXT не могут использоваться с представлениями, удаленными таблицами и вставленными или удаленными таблицами внутри триггеров.
    339 16 DEFAULT или NULL не допускаются в качестве явных значений идентификатора.
    340 16 Невозможно создать триггер «%. * Ls» для представления «%. * Ls». Триггеры AFTER не могут быть созданы для представлений.
    341 16 Процедуры фильтра репликации не могут содержать столбцы большого объекта, большого значения, типа XML или CLR.
    342 16 Столбец «%. * Ls» недопустим в этом контексте, а пользовательская функция или агрегат «%. * Ls» не могут быть найдены.
    343 16 Неизвестный тип объекта «%. * Ls», используемый в операторе CREATE, DROP или ALTER.
    344 16 Ссылка на удаленную функцию «%. * Ls» недопустима, а имя столбца «%.* ls ‘не может быть найден или является неоднозначным.
    345 16 Функция «%. * Ls» не разрешена в предложении OUTPUT, поскольку она выполняет доступ к пользовательским или системным данным или предполагается, что выполняет этот доступ. По умолчанию предполагается, что функция выполняет доступ к данным, если она не привязана к схеме.
    346 15 Параметр «<Имя параметра>» не может быть объявлен ТОЛЬКО ДЛЯ ЧТЕНИЯ, поскольку это не возвращающий табличное значение параметр.
    347 16 Возвращающий табличное значение параметр «%. * Ls» не может быть объявлен как параметр OUTPUT.
    348 16 Табличную переменную «%. * Ls» нельзя передать хранимой процедуре с параметром OUTPUT.
    349 16 Процедура «%. * Ls» не имеет параметра с именем «%. * Ls».
    350 16 Столбец «%.* ls «не имеет допустимого типа данных. Столбец не может относиться к пользовательскому типу таблицы.
    351 16 Столбец, параметр или переменная%. * Ls. : Не удается найти тип данных%. * Ls.
    352 15 Возвращающий табличное значение параметр «%. * Ls» должен быть объявлен с параметром READONLY.
    353 16 Функция «%.* ls ‘не допускается в предложении% S_MSG, если предложение FROM содержит вложенные инструкции INSERT, UPDATE, DELETE или MERGE. Это связано с тем, что функция выполняет доступ к пользовательским или системным данным или предполагается, что выполняет этот доступ. По умолчанию предполагается, что функция выполняет доступ к данным, если она не привязана к схеме.
    354 15 Целевой объект «%. * Ls» оператора INSERT не может быть представлением или общим табличным выражением, если предложение FROM содержит вложенный оператор INSERT, UPDATE, DELETE или MERGE.
    355 15 Целевая таблица «<Имя таблицы>» оператора INSERT не может иметь никаких включенных триггеров, если предложение FROM содержит вложенный оператор INSERT, UPDATE, DELETE или MERGE.
    356 15 Целевая таблица «%. * Ls» оператора INSERT не может находиться ни на одной из сторон отношения (первичный ключ, внешний ключ), если предложение FROM содержит вложенный оператор INSERT, UPDATE, DELETE или MERGE.Обнаружено ограничение ссылки «% ls».
    357 15 Целевая таблица «%. * Ls» оператора INSERT не может иметь никаких включенных правил, если предложение FROM содержит вложенный оператор INSERT, UPDATE, DELETE или MERGE. Найдено правило «% ls».
    358 15 В целевой таблице «%. * Ls» инструкции MERGE не может быть разрешенных правил. Найдено правило «% ls».
    359 15 Целевой процент.* ls ‘предложения OUTPUT INTO имеет индекс с опцией ignore_dup_key и не может использоваться, когда также используется предложение OUTPUT.
    360 15 Список целевых столбцов инструкции INSERT, UPDATE или MERGE не может содержать одновременно разреженный столбец и набор столбцов, содержащий разреженный столбец. Перепишите инструкцию, чтобы включить либо разреженный столбец, либо набор столбцов, но не оба сразу.
    361 16 Число целевых столбцов, указанных в инструкции INSERT, UPDATE или MERGE, превышает максимальное значение% d.Это общее количество включает идентификатор, временную метку и столбцы со значениями по умолчанию. Чтобы исправить эту ошибку, измените запрос на набор разреженных столбцов вместо отдельных разреженных столбцов.
    362 16 Обработчику запросов не удалось создать план запроса, поскольку имя «%. * Ls» в подсказке FORCESEEK для таблицы или представления «<Имя объекта>» не соответствует именам ключевых столбцов индекса «<Имя индекса>».
    363 16 Обработчику запросов не удалось создать план запроса, поскольку подсказка FORCESEEK для таблицы или представления «<Имя объекта>» не может использоваться с% S_MSG, указанным индексом «%».* ls ‘.
    364 16 Обработчику запросов не удалось создать план запроса, поскольку подсказка FORCESEEK для представления «<Имя представления>» используется без подсказки NOEXPAND. Повторно отправьте запрос с подсказкой NOEXPAND или удалите подсказку FORCESEEK в представлении.
    365 16 Обработчику запросов не удалось создать план запроса, поскольку подсказка FORCESEEK для таблицы или представления «<Имя объекта>» указала больше столбцов поиска, чем количество ключевых столбцов в индексе «%».* ls ‘.
    366 16 Обработчику запросов не удалось создать план запроса, поскольку подсказку FORCESEEK для таблицы или представления «<Имя объекта>» нельзя использовать с индексом хранилища столбцов «%. * Ls».
    401 16 Не реализованный оператор или выражение% ls.
    402 16 Типы данных% s и% s несовместимы в операторе% s.
    403 16 Неверный оператор для типа данных. Оператор равно добавить, ввести равно тексту.
    404 16 Ссылка на столбец «вставлено.%. * Ls» недопустима, поскольку она относится к базовой таблице, которая не изменяется в этом операторе.
    405 16 Удаленная таблица не может использоваться в качестве цели DML в операторе, который включает предложение OUTPUT или вложенный оператор DML.
    406 16 % ls нельзя использовать в операторе PIVOT, поскольку он не инвариантен к значениям NULL.
    407 16 Внутренняя ошибка. Строковая процедура в файле% hs, строка% d завершилась ошибкой с HRESULT 0x% x.
    408 16 В списке ORDER BY, позиция% i обнаружено постоянное выражение.
    409 16 Операция% ls не может принимать в качестве аргумента тип данных% ls.
    410 20 Предложение COMPUTE #% d Выражение BY #% d не в порядке список.
    411 16 Предложение COMPUTE #% d, агрегатное выражение #% d отсутствует в выборе список.
    412 16 Столбец «%. * Ls» не подлежит обновлению, поскольку он производный или постоянный.
    413 16 Коррелированные параметры или подзапросы не поддерживаются встроенной функцией «%. * Ls».
    414 16 UPDATE не разрешено, поскольку оператор обновляет представление «%. * Ls», которое участвует в объединении и имеет триггер INSTEAD OF UPDATE.
    415 16 DELETE не разрешено, поскольку оператор обновляет представление «%. * Ls», которое участвует в объединении и имеет триггер INSTEAD OF DELETE.
    416 16 Очередь обслуживания «%. * Ls» не может быть обновлена ​​напрямую.
    417 16 TOP не допускается в операторе UPDATE или DELETE для секционированного представления.
    418 16 Объекты, отображающие столбцы типа CLR, не допускаются в распределенных запросах. Используйте сквозной запрос для доступа к удаленному объекту «%. * Ls».
    420 16 Типы данных text, ntext и image нельзя использовать в ЗАКАЗЕ. Предложение BY.
    421 16 Тип данных text / ntext / image не может быть выбран как DISTINCT, потому что он несовместим.
    422 16 Общее табличное выражение определено, но не используется.
    423 16 Методы типа данных Xml не поддерживаются в проверочных ограничениях. Создайте скалярную определяемую пользователем функцию, чтобы обернуть вызов метода. Ошибка произошла в таблице «%. * Ls».
    424 16 Методы типа данных Xml не поддерживаются в определениях вычисляемых столбцов табличных переменных и возвращаемых таблицах функций, возвращающих табличное значение.Ошибка произошла в столбце «%. * Ls» таблицы «%. * Ls» в операторе% ls.
    425 16 Тип данных% ls принимающей переменной не соответствует типу данных % ls столбца «%. * ls».
    426 16 Длина% d принимающей переменной меньше длины% d столбца «%. * ls».
    427 20 Не удалось загрузить записи sysprocedures для идентификатора ограничения% d в идентификатор базы данных% d.
    428 20 Не удалось найти строку в sysconstraints для идентификатора ограничения% d в идентификатор базы данных% d.
    429 20 Не удалось найти новый идентификатор ограничения% d в sysconstraints, идентификатор базы данных % d, во время компиляции.
    430 20 Не удалось разрешить имя таблицы для идентификатора объекта% d, идентификатора базы данных% d, при компиляции внешнего ключа.
    431 19 Не удалось связать ограничение внешнего ключа. Слишком много таблиц задействовано в запрос.
    432 16 Методы типа данных Xml больше не поддерживаются в проверочных ограничениях. Отмените ограничение или создайте скалярную определяемую пользователем функцию, чтобы обернуть вызов метода. Ошибка произошла в таблице «%. * Ls».
    433 20 Не удалось найти ограничение CHECK для «%.* ls ‘, хотя таблица отмечен как имеющий.
    434 16 Функция «% ls» не разрешена в предложении OUTPUT.
    435 16 Методы типа данных Xml не поддерживаются в определениях вычисляемых столбцов. Создайте скалярную определяемую пользователем функцию, чтобы обернуть вызов метода. Ошибка произошла в столбце «%. * Ls» таблицы «%. * Ls» в операторе% ls.
    436 20 Не удалось открыть указанную таблицу с идентификатором% d в базе данных с идентификатором% d.
    437 20 Не удалось разрешить указанное имя столбца в таблице с идентификатором% d.
    438 20 Не удалось разрешить имя ссылающегося столбца в таблице с идентификатором% d.
    439 20 Не удалось найти ограничения FOREIGN KEY для таблицы «%.* ls ‘в ID базы данных% d, хотя таблица помечена как имеющая их.
    440 16 Ошибка компиляции внутреннего запроса. Не удалось обработать переполнение стека.
    441 16 Невозможно использовать функцию «% ls» на удаленном источнике данных.
    442 16 Аргумент NEST должен быть ссылкой на столбец.Выражения не допускаются.
    443 16 Недопустимое использование getdate в функция.
    Недопустимое использование INSERT в функции.
    Недопустимое использование UPDATE в функции.
    444 16 Операторы выбора, включенные в функцию, не могут возвращать данные в клиент.
    445 16 COLLATE нельзя использовать в выражениях, содержащих COLLATE. пункт.
    446 16 Не удалось разрешить конфликт параметров сортировки для операции% ls.
    447 16 Тип выражения% ls недопустим для предложения COLLATE.
    448 16 Недопустимое сопоставление «%. * Ls».
    449 16 Конфликт сопоставления, вызванный предложениями сопоставления с разными сопоставление ‘%.* ls ‘и’%. * ls ‘.
    450 16 Переводы кодовой страницы не поддерживаются для текстового типа данных. От:% d До:% d.
    451 16 Не удалось разрешить конфликт сопоставления для столбца% d в операторе% ls.
    452 16 COLLATE нельзя использовать с пользовательскими типами данных.
    453 16 Параметры сортировки «%. * Ls» поддерживаются только для типов данных Unicode и не может быть установлен на уровне базы данных или сервера.
    454 16 Аргумент UNNEST должен быть столбцом вложенной таблицы.
    455 16 Последний оператор, включенный в функцию должно быть оператором возврата.
    456 16 Невозможно выполнить неявное преобразование значения% ls в% ls потому что результирующее сопоставление не разрешено из-за конфликта сопоставления.
    457 16 Невозможно выполнить неявное преобразование значения% ls в% ls поскольку сопоставление значения не разрешено из-за конфликта сопоставления.
    458 16 Невозможно создать целевую таблицу SELECT INTO «%.* ls «, поскольку столбец xml»%. * ls «набран с помощью коллекции схем»%. * ls «из базы данных»%. * ls «. Столбцы XML не могут ссылаться на схемы в разных базах данных.
    459 16 Параметры сортировки «%. * Ls» поддерживаются только для типов данных Unicode и не могут применяться к типам данных char, varchar или text.
    460 16 Оператор DISTINCT не разрешен в рекурсивной части рекурсивного общего табличного выражения «<Имя общего табличного выражения>».
    461 16 Оператор TOP не допускается в рекурсивной части рекурсивного общего табличного выражения «<Имя общего табличного выражения>».
    462 16 Внешнее соединение не допускается в рекурсивной части рекурсивного общего табличного выражения «<Имя общего табличного выражения>».
    463 16 Функции с параметрами не допускаются в рекурсивной части рекурсивного общего табличного выражения ‘%.* ls ‘.
    464 16 Функции с побочными эффектами не разрешены в рекурсивной части рекурсивного общего табличного выражения «%. * Ls».
    465 16 Рекурсивные ссылки в подзапросах не допускаются.
    466 16 Оператор UNION не разрешен в рекурсивной части рекурсивного общего табличного выражения ‘%.* ls ‘.
    467 16 GROUP BY, HAVING или агрегатные функции не допускаются в рекурсивной части рекурсивного общего табличного выражения ‘‘.
    468 16 Не удалось разрешить конфликт параметров сортировки между «%. * Ls» и «%. * Ls» в операции% ls.
    469 16 Для целевой таблицы «%» должен быть указан явный список столбцов.* ls ‘, если используется табличная подсказка KEEPIDENTITY и таблица содержит столбец идентификаторов.
    470 16 Синоним «<Имя синонима>» ссылается на синоним «<Имя синонима>». Цепочка синонимов не допускается.
    471 16 Можно указать только один из трех вариантов: SINGLE_BLOB, SINGLE_CLOB или SINGLE_NCLOB.
    472 16 Необходимо указать либо файл формата, либо одну из трех опций SINGLE_BLOB, SINGLE_CLOB или SINGLE_NCLOB.
    473 16 В операторе PIVOT указано неверное значение «%. * Ls».
    474 16 Не удалось загрузить определения вычисленных столбцов для таблицы «%. * Ls».
    475 16 Недопустимое предложение SAMPLE. Могут быть выбраны только имена таблиц в предложении FROM запросов SELECT, UPDATE и DELETE.
    476 16 Неверный PERCENT размер выборки «» для таблицы ««. Размер выборки таблицы PERCENT должен быть от 0 до 100. Столбцы
    477 16 Недопустимое значение ROWS или REPEATABLE seed в предложении TABLESAMPLE для таблицы «<Имя таблицы>». Значение или начальное число должно быть целым числом.
    478 16 Предложение TABLESAMPLE нельзя использовать в определении представления или в определении встроенной табличной функции.
    479 16 Недопустимое значение ROWS или REPEATABLE seed «% I64d» в предложении TABLESAMPLE для таблицы «%. * Ls». Значение или начальное число должно быть больше 0.
    480 16 Предложение TABLESAMPLE нельзя использовать с табличной функцией «%. * Ls».
    481 16 Предложение TABLESAMPLE нельзя использовать с таблицей связанного сервера «%.* ls «.
    482 16 Непостоянное или недопустимое выражение находится в предложении TABLESAMPLE или REPEATABLE.
    483 16 Предложение OUTPUT нельзя использовать в инструкции INSERT … EXEC.
    484 16 Невозможно объявить более% d локальных переменных.
    485 16 Представления и встроенные функции не могут возвращать столбцы XML, набранные с помощью коллекции схем, зарегистрированной в базе данных, отличной от текущей.Столбец «%. * Ls» набирается с набором схем «%. * Ls», который зарегистрирован в базе данных «%. * Ls».
    486 16 %. * Ls не позволяет указывать имя схемы в качестве префикса к имени сборки.
    487 16 Для оператора «%. * Ls» указан недопустимый параметр.
    488 16 % s должны быть сопоставимы.Тип столбца «%. * Ls» — «% s», что не является сопоставимым.
    489 16 Невозможно указать предложение OUTPUT, поскольку целевое представление «%. * Ls» является многораздельным.
    490 16 Функция повторной синхронизации временно отключена.
    491 16 Имя корреляции должно быть указано для массового набора строк в предложении from.
    492 16 Повторяющиеся имена столбцов не допускаются в наборах результатов, полученных с помощью OPENQUERY и OPENROWSET. Имя столбца «%. * Ls» повторяется.
    493 16 Столбец «%. * Ls», возвращенный методом nodes (), нельзя использовать напрямую. Его можно использовать только с одним из четырех методов типа данных XML, exist (), nodes (), query () и value (), или в проверках IS NULL и IS NOT NULL.
    494 16 Предложение TABLESAMPLE можно использовать только с локальными таблицами.
    495 16 Столбец возвращаемой таблицы «%. * Ls» не того же типа, что и тип, с которым он был создан. Отбросьте и воссоздайте модуль, используя имя типа, состоящее из двух частей, или используйте процедуру sp_refreshsqlmodule, чтобы обновить его метаданные параметров.
    496 16 Параметр «%.* ls «не того же типа, что и тип, с которым он был создан. Отбросьте и воссоздайте модуль, используя имя типа, состоящее из двух частей, или используйте процедуру sp_refreshsqlmodule для обновления метаданных его параметров.
    497 16 Переменные не допускаются в предложениях TABLESAMPLE или REPEATABLE.
    498 16 Недопустимое значение в предложении TABLESAMPLE или REPEATABLE.
    499 16 Неверный параметр для функции getchecksum.
    500 16 Попытка передать возвращающий табличное значение параметр с% d столбцами, где для соответствующего пользовательского типа таблицы требуется% d столбцов.

    Конфигурация журнала ошибок SQL Server

    У большинства приложений есть журнал, в котором отслеживается активность. SQL Server ничем не отличается. В нем есть файл журнала, известный как журнал ошибок, для отслеживания того, что происходит на экземпляре SQL Server.Сервер. Каждый экземпляр SQL Server имеет собственный набор файлов журнала ошибок. В этой статье я расскажу, что такое журнал ошибок, как SQL Server управляет им и где его найти. Я также покажу вам, как настроить журнал ошибок SQL Server.

    Что такое журнал ошибок?

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

    Журнал ошибок — это не отдельный файл, а серия файлов.Каждый раз при запуске SQL Server создается новый файл журнала ошибок. Работающий экземпляр SQL Server записывает в текущий журнал (тот, который создается при запуске) и по умолчанию имеет шесть архивных файлов журнала ошибок. Если вам нужно сохранить более шести заархивированных файлов, вы можете изменить значение по умолчанию, чтобы сохранить столько файлов, сколько вам нужно (подробнее об этом позже).

    Если экземпляр SQL Server выходит из строя или не запускается по какой-либо причине, журнал ошибок — это место, где можно найти и устранить эти проблемы. Как администратор баз данных, вы должны периодически просматривать журнал ошибок на предмет потенциальных проблем.Просматривая журнал, вы можете обнаружить некоторые необычные вещи, которые в противном случае могли бы остаться незамеченными, например, сбой задания резервного копирования или попытки взлома пароля SA.

    Где можно найти файлы журнала ошибок?

    По умолчанию файлы журнала ошибок хранятся в следующем месте: Program Files \ Microsoft SQL Server \ MSSQL < n>. <Имя экземпляра> \ MSSQL \ LOG \ ERRORLOG, , где — это номер заархивированной версии, а <имя экземпляра> — имя экземпляра.Это только местоположение по умолчанию. Некоторые экземпляры могут быть настроены для записи файлов журнала ошибок в другое место. Если файлы журнала ошибок находятся не в месте по умолчанию, их можно найти несколькими способами. Я покажу вам два из этих методов.

    Первый способ — использовать диспетчер конфигурации SQL Server. Чтобы найти расположение журнала с помощью этого метода, сначала откройте диспетчер конфигурации SQL Server. Затем дважды щелкните экземпляр SQL Server, на котором вы хотите найти расположение файла журнала ошибок.Затем щелкните вкладку Advanced . Расположение каталога файла журнала ошибок указано в элементе Dump Directory . Чтобы увидеть полное имя каталога файла журнала ошибок, щелкните маленькую ошибку справа от элемента Dump Directory, как показано ниже на рисунке 1.

    Рисунок 1. Расположение каталога файла журнала ошибок в Configuration Manager

    Второй способ найти расположение файлов журнала ошибок — использовать SSMS для просмотра одного из файлов журнала ошибок.Для этого вы должны подключиться к экземпляру SQL Server, в котором вы хотите найти расположение журнала ошибок с помощью SSMS. Разверните элемент Management и элемент Журналы SQL Server. Затем дважды щелкните файл журнала ошибок Current . Когда вы это сделаете, отобразится программа просмотра файлов журнала . Чтобы найти местоположение файла журнала ошибок, вы можете либо просмотреть файл журнала, пока не найдете его, либо использовать опцию Search… , чтобы найти его. При использовании параметра поиска используйте строку Logging SQL Server messages в файле в качестве критерия поиска.Изображение на Рисунке 2 показывает эти шаги. Местоположение журнала можно найти в выделенной строке журнала.

    Рисунок 2: Использование SSMS для поиска местоположения файлов журнала ошибок

    Типы файлов журнала ошибок и правила их именования

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

    Все имена файлов журнала ошибок начинаются с ERRORLOG .Журнал ошибок для запущенного экземпляра называется просто ERRORLOG , тогда как имена всех остальных файлов журнала ошибок начинаются с ERRORLOG , но имеют номер для расширения файла. Архивные файлы журнала ошибок: ERRORLOG.1 , ERRORLOG.2 , ERROLOG.3 ,… до заданного числа заархивированных файлов журнала ошибок. Где ERRORLOG.1 — это последний архивированный файл журнала ошибок, ERRORLOG.2 — второй последний архивированный файл журнала ошибок, ERRORLOG.3 является третьим последним архивированным файлом журнала ошибок и т. Д. Если экземпляр сконфигурирован с количеством файлов журнала ошибок по умолчанию, то последний архивированный файл журнала ошибок будет иметь имя ERRORLOG.6 .

    При перезапуске экземпляра самый старый архивный файл журнала ошибок ( ERRORLOG.6 , если используется номер по умолчанию) удаляется, а затем переименовывается каждый из оставшихся файлов журнала ошибок. ERRORLOG.5 переименован в ERRORLOG.6 , ERROLOG.4 переименован в ERRORLOG.5 и т. Д. До ERRORLOG.1 переименовывается в ERRORLOG.2 . Последний текущий файл журнала ошибок ( ERRORLOG ) переименовывается в ERRORLOG.1 , а файл журнала ошибок для вновь запущенного экземпляра создается с именем ERRORLOG .

    Изменение количества и размера журнала ошибок

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

    Сколько архивных файлов журнала ошибок вам нужно и каков максимальный размер? Как и на большинство вопросов, касающихся SQL Server, ответ — «в зависимости от обстоятельств». Здесь я продемонстрирую, как количество и размер журналов ошибок могут помочь или затруднить использование вами файлов журнала ошибок, и поделюсь своим личным мнением о том, сколько файлов журналов я хотел бы иметь.

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

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

    Существует несколько различных методов изменения конфигурации файла журнала ошибок, я упомяну два из них.Первый способ — использовать SSMS. Чтобы использовать этот метод, сначала подключитесь к экземпляру, разверните папку Management , щелкните правой кнопкой мыши папку SQL Server Log и затем выберите пункт Configure в отображаемом меню, как показано на рисунке 3.

    Рисунок 3: Вызов экрана конфигурации журнала ошибок

    При нажатии на Configure, открывается окно, показанное на рисунке 4.

    Рисунок 4; Параметры конфигурации для журнала ошибок

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

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

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

    Проблемы с многократным перезапуском

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

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

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

    Цикл ERRORLOG

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

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

    Листинг 1: Цикл журнала ошибок.

    Для выполнения системной хранимой процедуры sp_cycle_errorlog необходимо быть членом фиксированной серверной роли sysadmin . Сохраненная процедура sp_cycle_errorlog не принимает параметров и возвращает 0, если журнал ошибок успешно обработан, и 1, если цикл журнала завершился неудачно.

    Файл журнала ошибок

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

    Устранение постоянных ошибок «Ошибка 21» в виртуальных базах данных SQL Server (KBA1047)

    Проблема

    После нарушения сетевого подключения между движком Delphix и целевой средой SQL Server может появиться следующая ошибка:

    Сообщение 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.

    Эта ошибка SQL Server препятствует нормальному использованию затронутых баз данных и может препятствовать выполнению операций над VDB и dSources (включая операции Disable и Enable) механизмом Delphix Engine.

    Механизм Delphix обычно обнаруживает эту проблему во время мониторинга работоспособности VDB, и затронутые базы данных будут отображаться в состоянии Остановлено на странице Наборы данных.

    Устранение неполадок Ошибка 21

    Эта ошибка возникает в SQL Server после прерывания трафика iSCSI между Delphix Engine и средой SQL Server, если нарушение длится дольше заданного периода ожидания.Причины этого включают, но не ограничиваются:

    • Плановое обслуживание сети, хранилища или вычислительной инфраструктуры, поддерживающей Delphix Engine
    • Незапланированный отказ сети, хранилища или вычислительной инфраструктуры, поддерживающей Delphix Engine
    • Незапланированный перезапуск Delphix Engine
    • Запланированный перезапуск механизма Delphix, при котором dSources и виртуальные базы данных (VDB) не были отключены
    • Конфликт за ресурсы на уровне гипервизора (VMware)
    • Моментальные снимки VMware, консолидация моментальных снимков или операции vMotion, приводящие к задержке или остановке доступа к диску

    Ошибка «Ошибка 21» будет сохраняться даже после восстановления подключения к дискам iSCSI, что препятствует успешной работе VDB.

    Чтобы определить, когда могла начаться основная проблема, найдите первые экземпляры строк «ошибка 21» или «Сообщение 823, уровень 24, состояние 2, строка 2» в журнале ошибок SQL Server.

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

    Разрешение

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

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

    Тип контейнера Статус в графическом интерфейсе управления Действие по разрешению
    dSource Активный Отключить и Включить dSource

    Если это не удается из-за KB40

    , перезапустите экземпляр SQL Server.

    VDB Остановлен Start VDB

    Если это не удается из-за KB40

    , перезапустите экземпляр SQL Server.

    VDB Работает Отключить и Включить VDB

    Если это не удается из-за KB40

    , перезапустите экземпляр SQL Server.

    Временное решение для Microsoft KB40

    Из-за проблемы, описанной в Microsoft KB40

    , несколько версий SQL Server не могут сбросить состояние «Ошибка 21» при выполнении операции запуска, отключения или включения VDB:

    • SQL Server 2014 (исправлено в SP2 CU12)
    • SQL Server 2016 (исправлено в SP1 CU9 и SP2 CU1)
    • SQL Server 2017 (исправлено в CU6)
    • Решено в SQL Server 2019 и более поздних версиях

    Обратите внимание, что исправления для этой проблемы не препятствуют тому, чтобы Windows выдавала ошибку ввода-вывода Error 21, но они позволяют перезапускать зависшие VDB (с помощью шагов решения, описанных выше) без перезапуска экземпляра SQL Server.

    В случае сбоя операций Start или Enable для затронутого dSource или VDB может потребоваться перезапустить экземпляр SQL Server на затронутом хосте. Имейте в виду, что перезапуск экземпляра временно прервет доступ ко всем базам данных на экземпляре SQL Server, независимо от того, размещены они на сервере Delphix или нет.

    Предотвращение повторения проблемы

      Чтобы свести к минимуму сбои, мы рекомендуем выполнить операцию Disable на dSources и VDB перед выполнением любого прерывистого обслуживания сети.

      Мы также рекомендуем увеличить тайм-ауты диска в рамках наших требований к конфигурации Windows iSCSI.

      Показано, что значение MaxRequestHoldTime в HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Class \ {4D36E97B-E325-11CE-BFC1-08002BE10318} \ <Номер экземпляра> \ Parameters увеличивает продолжительность работы диска iSCSI оставался открытым во время сбоя в сети. Увеличение этого числа с 60 до 300 (как показано в документе с требованиями) будет полезно, если частые события технического обслуживания сети или проблемы с инфраструктурой вызывают эту проблему.

      Опубликовано в категории: Разное

      Добавить комментарий

      Ваш адрес email не будет опубликован. Обязательные поля помечены *

      2019 © Все права защищены.