SQL-Ex blog

Як виправити помилку "Символьні або двійкові дані можуть бути усічені"

Спочатку погляньмо на помилку: створимо таблицю з невеликими полями, а потім спробуємо вставити більше даних, ніж вони можуть вмістити.

CREATE TABLE dbo.CoolPeople(PersonName VARCHAR(20), PrimaryCar VARCHAR(20));  
GO  
INSERT INTO dbo.CoolPeople(PersonName, PrimaryCar)  
VALUES ('Baby', '2006 Subaru Impreza WRX GD');  
GO

Msg 8152, Level 16, State 30, Line 5  
String або binary data would be truncated.  
The statement has been terminated.

Це засідка, оскільки ми не маємо ідей щодо того, яке поле викликало проблеми! Це особливо жахливо, коли ви намагаєтеся вставити багато рядків.

Щоб усунути помилку, увімкніть прапор трасування 460

Прапор трасування 460 був введений в SQL Server Sevice Pack 2, Cummulative Update 6, і в SQL Server 2017. (Ви можете знайти та завантажити останні оновлення з SQLServerUpdates.com.) Ви можете увімкнути прапор на рівні запиту, наприклад:

INSERT INTO dbo.CoolPeople(PersonName, PrimaryCar)  
VALUES ('Baby', '2006 Subaru Impreza WRX GD')  
OPTION (QUERYTRACEON 460);  
GO

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

Msg 2628, Level 16, State 1, Line 9  
String or binary data would be truncated in  
table 'StackOverflow2013.dbo.CoolPeople', column 'PrimaryCar'.  
Truncated value: '2006 Subaru Impreza'.

Ви можете включити цей прапор трасування як на рівні запиту (у прикладі вище), так і на рівні сервера:

DBCC TRACEON (460-1);  
GO

Цей оператор включає його для всіх, а не тільки для вас - тому спочатку домовтеся зі своєю командою розробників, перш ніж вмикати його. Це змінить номер помилки 8152 на 2628 (як показано вище), що означає, що якщо ви будували обробку помилок на підставі цих номерів, ви відразу отримаєте іншу поведінку.

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

DBCC TRACEON (460-1);  
GO

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

Не залишайте цей прапор увімкненим

Принаймні, є пов'язаний з цим один баг у SQL Server 2017 CU13: табличні змінні будуть викидати помилки, що свідчать, що їх вміст усікається, навіть якщо жодні дані не вставляються в них.

Ось простий скрипт, щоб перевірити, чи пофіксували цю поведінку:

CREATE OR ALTER PROC dbo.Repro @BigString VARCHAR(8000) AS  
BEGIN  
DECLARE @Table TABLE ( SmallString VARCHAR(128) )  
IF ( 1 = 0 )  
/* Це ніколи не виконується */  
INSERT INTO @Table (SmallString)  
VALUES(@BigString)  
OPTION (QUERYTRACEON 460)  
END  
GO  
DECLARE @BigString VARCHAR(8000) = REPLICATE('blah',100)  
EXEC dbo.Repro @BigString  
GO

SQL Server 2017 CU13 все ще повідомляє про усічення рядка, навіть якщо рядок не вставляється:

Перемикання з табличною змінною на тимчасову таблицю призводить до очікуваної поведінки:

Це чудовий приклад, чому не слід використовувати прапори трасування за умовчанням.Звичайно, вони можуть пофіксувати проблеми, але вони також можуть викликати непередбачувану або небажану поведінку. (І, взагалі, я не фанат табличних змінних.)

Зворотні посилання

Немає зворотних посилань

Коментарі

Показувати коментарі Як список | Деревоподібною структурою

Автор не дозволив коментувати цей запис

Усунення помилок із узгодженістю бази даних, виявлених командою DBCC CHECKDB

У цій статті пояснюється, як усувати помилки, які повідомляють команда DBCC CHECKDB .

Вихідна версія продукту: SQL Server
Вихідний номер бази знань: 2015748

Симптоми

При виконанні DBCC CHECKDB (або інших аналогічних команд, таких як DBCC CHECKTABLE), повідомлення, наприклад, записується в журнал помилок SQL Server:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors і repaired 3 errors. Elapsed time: 0 hours 0 minutes 0 seconds. Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001. Це is informational message only. No user action is required.

У цьому повідомленні показано, скільки помилок узгодженості бази даних було знайдено та скільки виправлено, якщо використовувався параметр відновлення. Це повідомлення також записується в журнал подій Windows як повідомлення рівня інформації з EventID=8957. Навіть якщо повідомляється про помилки, повідомлення є повідомленням рівня інформації.

Відомості в повідомленні, починаючи з "внутрішнього моментального знімка бази даних. " Відображається лише в тому випадку, якщо DBCC CHECKDB він запущений у мережі, в якій база даних не в режимі SINGLE_USER . Це з тим, що з мережевого DBCC CHECKDB знімка бази даних використовується уявлення узгодженого набору даних для перевірки.

У цій статті не розглядаються способи усунення кожної конкретної помилки, яку повідомляє DBCC CHECKDB , а загальний підхід при виявленні помилок. Будь-яке посилання на CHECKDB цю статтю також стосується DBCC CHECKTABLE DBCC CHECKFILEGROUP, якщо не вказано.

Причина

Команда DBCC CHECKDB перевіряє фізичну та логічну узгодженість сторінок бази даних, рядків, сторінок виділення, зв'язків індексів, системної таблиці цілісності посилання та інших перевірок структури. Якщо будь-яка з цих перевірок завершується помилкою (залежно від вибраних параметрів), повідомляється про помилки.

Причина цих проблем може бути пов'язана з пошкодженням файлової системи, проблемами системи обладнання, проблемами драйвера, пошкодженими сторінками в пам'яті або кеші сховища або SQL Server. Відомості про те, як визначити причину сполучених помилок, див. у статті "Дослідження першопричини".

Рішення

1. Перш ніж продовжити відновлення резервної копії або відновлення бази даних, усуніть усі базові проблеми, пов'язані з обладнанням у системі. Застосуйте будь-які оновлення драйвера пристрою, вбудованого програмного забезпечення, BIOS та операційної системи, які стосуються шляху вводу-виводу. Зверніться до адміністратора повного шляху введення-виводу (локальний комп'ютер, драйвери пристроїв, мережеві адаптери сховища, SAN, серверне сховище та кеш), щоб ізолювати та усунути будь-які проблеми. Приклади включають оновлення драйверів пристроїв та перевірку конфігурації всього шляху вводу-виводу. Додаткові відомості про перевірку причини див. у статті "Дослідження першопричини".
2. Якщо DBCC CHECKDB повідомляє про помилки постійної узгодженості, найкраще відновити дані з відомої хорошої резервної копії. Для отримання додаткових відомостей див.у розділі "Відновлення та відновлення".
3. Застосуйте останню версію накопичувального оновлення SQL Server або пакета оновлення, щоб переконатися, що ви не працюєте з відомими проблемами. Ознайомтеся з документацією щодо накопичувальних оновлень або пакетом оновлень для всіх відомих проблем, пов'язаних із пошкодженням бази даних (помилками узгодженості) та застосуванням будь-яких відповідних виправлень. Одне центральне розташування, де можна знайти всі виправлення певної версії, якщо докладні списки виправлень для SQL Server 2022, 2019, 2017.
4. DBCC CHECKDB Якщо помилки періодично виникають, тобто якщо вони відображаються в одному запуску і зникають на наступному, можуть виникнути проблеми з кешем диска (драйвер пристрою або інша проблема шляхом введення-виведення). Зверніться до підтримувачів вводу-виводу, щоб ізолювати та усунути будь-які проблеми. До прикладів відносяться оновлення драйверів пристроїв, перевірка конфігурації всього шляху введення-виводу та оновлення вбудованого ПЗ та BIOS на пристроях та системах шляху введення-виводу.
5. Якщо відновлення з резервної копії неможливе, CHECKDB функція відновлення помилок, які можна використовувати. Існує два рівні ремонту:
   • REPAIR_REBUILD — відновлення без можливості втрати даних.
   • REPAIR_ALLOW_DATA_LOSS – виконує відновлення, яке має можливість втрати даних.

Додаткові відомості див. у документації з DBCC CHECKDB.

При виборі способу відновлення з дозволом втрати даних необхідно бути обережним, так як вона може залишити базу даних в логічному неузгодженому стані. Вихідні DBCC CHECKDB дані роблять рекомендацію щодо мінімального рівня відновлення для використання.Це поширена практика виконання CHECKDB з REPAIR_ALLOW_DATA_LOSS кілька разів, поки більше не повідомлятимуть про помилки. Це з тим, що з виправленні набору помилок може бути виявлено інші несправні зв'язку. Однак, нові помилки можуть відображатися, якщо основна причина не усунена. Таким чином, якщо проблеми на рівні системи, такі як обладнання або файлова система, викликають пошкодження даних, перед відновленням резервного копіювання або відновлення необхідно спочатку усунути ці проблеми. Інженери підтримки Майкрософт не можуть допомогти у фізичному відновленні пошкоджених даних, якщо відновлення не виправляє помилки узгодженості або якщо резервна копія бази даних пошкоджена.

При запуску DBCC CHECKDB надається рекомендація, щоб визначити мінімальний варіант відновлення, необхідний для виправлення всіх помилок. Ці повідомлення схожі на наступні вихідні дані:

CHECKDB виявив 0 помилок виділення та 15 помилок узгодженості у базі даних mydb.
REPAIR_ALLOW_DATA_LOSS – це мінімальний рівень відновлення для помилок, виявлених (DBCC CHECKDB mydb).

Рекомендація відновлення — мінімальний рівень відновлення для усунення всіх помилок CHECKDB . Мінімальний рівень відновлення не означає, що цей параметр відновлення виправляє всі помилки. Деякі помилки просто не можуть бути виправлені. Крім того, може знадобитися виконати процес відновлення більше одного разу. Не всі помилки, що повідомляються, вимагають дозволу цього рівня відновлення. Це означає, що не всі виправлення CHECKDB при REPAIR_ALLOW_DATA_LOSS призводять до втрати даних. Необхідно виконати відновлення, щоб визначити, чи надає дозвіл помилки до втрати даних.Один із способів звузити рівень відновлення кожної таблиці — використовувати DBCC CHECKTABLE для будь-якої таблиці, повідомляючи про помилку. Це показує мінімальний рівень відновлення цієї таблиці.

Після відновлення або імпорту даних CHECKDB необхідно виконати перевірку вручну. Для отримання додаткових відомостей див. у розділі аргументів DBCC CHECKDB. Дані можуть бути логічно узгодженими після відновлення. Наприклад, відновлення (особливо параметр REPAIR_ALLOW_DATA_LOSS) може видалити цілі сторінки даних, які містять неузгоджені дані. У таких випадках таблиця із зовнішнім ключем зв'язку з іншою таблицею може зрештою містити рядки, що не мають відповідних рядків первинного ключа в батьківській таблиці.

• Помилка 605 (MSSQLSERVER_605)
• Помилка 823 (MSSQLSERVER_823)
• Помилка 824 (MSSQLSERVER_824)
• Помилка 825 (MSSQLSERVER_825)
• Помилка 2508 (MSSQLSERVER_2508)
• Помилка 2511 (MSSQLSERVER_2511)
• Помилка 2512 (MSSQLSERVER_2512)
• Помилка 7987 (MSSQLSERVER_7987)
• Помилка 7988 (MSSQLSERVER_7988)
• Помилка 7995 (MSSQLSERVER_7995)
• Помилка 8993 (MSSQLSERVER_8993)
• Помилка 8994 (MSSQLSERVER_8994)
• Помилка 8996 (MSSQLSERVER_8996)

Вивчення причин помилок узгодженості бази даних

Щоб визначити причину помилок узгодженості бази даних, розглянемо такі методы:

• Перевірте журнал подій Windows для будь-яких помилок, драйверів або дисків, а також зверніться до виробника обладнання, щоб усунути їх.
• Запустіть будь-який діагностика, що надається вашими виробниками обладнання для комп'ютера та (або) дискової системи.
• Зверніться до постачальника обладнання або виробника пристроїв, щоб переконатися, що:
  • Апаратні пристрої та конфігурація підтверджують вимоги ядро ​​СУБД Microsoft SQL Server вхідних та вихідних даних.
  • драйвери пристроїв та інші програмні компоненти, які підтримують усі пристрої на шляху введення-виводу, оновлено.

  Додаткова інформація

  Для отримання додаткових відомостей про синтаксис та параметри або параметри DBCC CHECKDB виконання команди див. у розділі DBCC CHECKDB (Transact-SQL).

  При виявленні помилок за допомогою CHECKDB інших повідомлень, аналогічних до наступного повідомлення, передаються в ERRORLOG з метою створення звітів про помилки:

  **Dump thread - spid = 0, EC = 0x00000000855F5EB0 ***Stack Dump being sent toFilePath\FileName * *************************** ************************************************** * * * BEGIN STACK DUMP: * Date/Timespid 53 * * DBCC database corruption * * Input Buffer 84 bytes - * dbcc checkdb(mydb) * * ************************************************ ************************************ * ------------- -------------------------------------------------- ---------------- * Short Stack Dump Stack Signature for dump is 0x00000000000001E8 External dump process return code 0x20002001.
  

  Відомості про помилки надіслано до звітів про помилки Вотсона.

  Файли, які використовуються для створення звітів про помилки, включають файл SQLDump.txt . Цей файл може бути корисним для історичних цілей, оскільки він містить перелік помилок, CHECKDB виявлених у форматі XML.

  Щоб дізнатися час DBCC CHECKDB останнього виконання без помилок, виявлених для бази даних (останнє відоме очищення CHECKDB ), перевірте журнал ПОМИЛКА SQL Server. Знайдіть наступне повідомлення для бази даних користувача або системної бази даних. Це повідомлення записується як повідомлення рівня інформації в журналі подій програми Windows з eventID = 17573, а також:

  Date/Time spid7s CHECKDB для бази даних master завершений без помилок у date/Time22:11:11.417 (локальний час). Це лише інформаційне повідомлення; ніяких дій користувача не потрібно