SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Standard Еще…Меньше
Корпорация Майкрософт распространяет исправления Microsoft SQL Server 2012 в один файл для загрузки. Поскольку исправления являются кумулятивными, каждый новый выпуск содержит все исправления и исправления для системы безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012.
Проблемы
При выполнении полнотекстового запроса, содержащего предикат CONTAINS, а предикат CONTAINS также имеет термин NEAR близость в SQL Server 2012, появляется следующее сообщение об ошибке:
Сообщение 0, уровень 11, состояние 0, строка 0, в текущей команде произошла серьезная ошибка. Результаты, если таковые имеются, должны быть удалены.
Кроме того, в журнале событий сервера SQL Server регистрируется следующее сообщение об ошибке:
Причина
Эта проблема возникает из-за ошибки в конвейере полнотекстового запроса.
Решение
Сведения о накопительном пакете обновления
Накопительный пакет обновления 1 (SP1) для SQL Server 2012 с пакетом обновления 1 (SP1)
Исправление для этой проблемы впервые выпущено в накопительном обновлении 1. За дополнительными сведениями о том, как получить этот накопительный пакет обновления для SQL Server 2012 с пакетом обновления 1 (SP1), щелкните следующий номер статьи базы знаний Майкрософт:
2765331 Накопительный пакет обновления 1 (SP1) для SQL Server 2012 с пакетом обновления 1 (SP1)Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2772858 Сборки SQL Server 2012, выпущенные после выпуска пакета обновления 1 (SP1) для SQL Server 2012
Накопительный пакет обновления 3 для SQL Server 2012
Исправление для этой проблемы впервые выпущено в накопительном обновлении 3. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2012, щелкните следующий номер статьи базы знаний Майкрософт:
2723749 Накопительное обновление 3 для SQL Server 2012Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2692828 Сборки SQL Server 2012, выпущенные после выпуска SQL Server 2012
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе «Применяется к».
Дополнительная информация
Дополнительные сведения о поиске слов, близких к другим словам, можно найти на веб-сайте MSDN по следующему адресу:
Поиск слов, близких к другому слову
Нужна дополнительная помощь?
|
dima_r 0 / 0 / 0 Регистрация: 31.03.2011 Сообщений: 13 |
||||||||
|
1 |
||||||||
Ошибка при выполнении запроса31.03.2011, 03:45. Показов 10294. Ответов 8 Метки нет (Все метки)
Обычненький запрос..
Все очень просто main — Это таблица… всего одна.. в ней записей около 48млн.. колонок около 11-12.. При этом если делать выборку только первых несколько тысяч строк, например 5-6, вот так:
То все нормально, но если кол-во строк увеличить например до 20тыс., то вылетает уже ошибка, при этом при просмотре хода выполнения видно что считал около 10200 записей, и потом уже вылетела ошибка.
__________________
0 |
|
Programming Эксперт 94731 / 64177 / 26122 Регистрация: 12.04.2006 Сообщений: 116,782 |
31.03.2011, 03:45 |
|
8 |
|
Devil_FoX 168 / 142 / 1 Регистрация: 01.04.2010 Сообщений: 474 |
||||
|
31.03.2011, 11:27 |
2 |
|||
|
я где-то читал что есть версии студий SQL, которые обрезаны по некоторым функционалам (не нашёл у себя инфы где расписано это) возможно у тебя такая. Попробуй скопировать во временную таблицу свои данные.
0 |
|
0 / 0 / 0 Регистрация: 31.03.2011 Сообщений: 13 |
|
|
31.03.2011, 18:16 [ТС] |
3 |
|
Тоже саоме выдает Microsoft SQL Server Management Studio 10.50.1600.1
0 |
|
0 / 0 / 0 Регистрация: 31.03.2011 Сообщений: 13 |
|
|
18.04.2011, 07:38 [ТС] |
4 |
|
Есть какие-нибудь пожелания?
0 |
|
197 / 197 / 5 Регистрация: 24.07.2010 Сообщений: 1,311 |
|
|
18.04.2011, 12:55 |
5 |
|
А если как-то сузить выборку? сделать какие-нибудь доп. условия?
0 |
|
0 / 0 / 0 Регистрация: 31.03.2011 Сообщений: 13 |
|
|
22.04.2011, 09:52 [ТС] |
6 |
|
Сузить запрос невозможно.. необходимо узнать кол-во этих записей
0 |
|
1107 / 753 / 181 Регистрация: 27.11.2009 Сообщений: 2,241 |
|
|
22.04.2011, 10:09 |
7 |
|
Тоже саоме выдает Microsoft SQL Server Management Studio 10.50.1600.1
10.50.1600.1 — это Microsoft SQL Server 2008 R2 RTM — Express (19.04.2010)
0 |
|
38 / 38 / 25 Регистрация: 14.12.2009 Сообщений: 202 |
|
|
22.04.2011, 13:15 |
8 |
|
Проблема не в запросе, а в менеджере, как уже описано выше. и Backup сделать не забудь перед шаманством
0 |
|
0 / 0 / 0 Регистрация: 31.03.2011 Сообщений: 13 |
|
|
25.05.2011, 14:23 [ТС] |
9 |
|
Вообще странно, вроде скачивал
0 |
Microsoft SQL Server 2014 — 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
Three SQL instances on this server. Update statistics for all databases in all instances is run nightly and weekly index rebuilds. The problem occurs in just one instance. Instance contains Team Foundation Server (TFS) database ‘Tfs_DefaultCollection’. Problem
started happening after the most recent weekly index rebuild.
The problem that surfaced this past weekend appears to have occurred because of the following index rebuild (in Tfs_DefaultCollection database): ALTER INDEX [PK_tbl_LocalVersion] ON [dbo].[tbl_LocalVersion] REBUILD PARTITION = ALL WITH (PAD_INDEX
= OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = ON, IGNORE_DUP_KEY = OFF, ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 MINUTES, ABORT_AFTER_WAIT = NONE)), ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE)
The index re-build when run as stand-alone simply results in «Command(s) completed successfully».
DBCC CHECKTABLE reports no problems on the table after index rebuild. DBCC CHECK DB also reports no problems.
However, ‘UPDATE STATISTICS [tbl_LocalVersion]’ reports ‘Msg 0, Level 11, State 0, Line 16. A severe error occurred on the current command. The results, if any, should be discarded.’
I have restored old backups to differently named DBs. The older backups do not error when updating stats for this table. However I can recreate the problem by doing the above index rebuild. Following the rebuild, the update stats
fails with above error.
Using one of the old backups where update stats worked, I tried drop/create the index (even with ‘drop existing’). The result of this gives me the following warning which I hope is not part of the problem because we didn’t change the database
design, it is TFS: ‘Warning! The maximum key length is 900 bytes. The index ‘PK_tbl_LocalVersion’ has maximum length of 1609 bytes. For some combination of large values, the insert/update operation will fail.’
I can stop rebuilding the indices weekly, but I would like to get it back to a state wherein the update statistics runs successfully.
I will post the dump file next if that will help solve this problem.
Thank you in advance for any help you can provide.
Microsoft SQL Server 2014 — 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
Three SQL instances on this server. Update statistics for all databases in all instances is run nightly and weekly index rebuilds. The problem occurs in just one instance. Instance contains Team Foundation Server (TFS) database ‘Tfs_DefaultCollection’. Problem
started happening after the most recent weekly index rebuild.
The problem that surfaced this past weekend appears to have occurred because of the following index rebuild (in Tfs_DefaultCollection database): ALTER INDEX [PK_tbl_LocalVersion] ON [dbo].[tbl_LocalVersion] REBUILD PARTITION = ALL WITH (PAD_INDEX
= OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = ON, IGNORE_DUP_KEY = OFF, ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 MINUTES, ABORT_AFTER_WAIT = NONE)), ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE)
The index re-build when run as stand-alone simply results in «Command(s) completed successfully».
DBCC CHECKTABLE reports no problems on the table after index rebuild. DBCC CHECK DB also reports no problems.
However, ‘UPDATE STATISTICS [tbl_LocalVersion]’ reports ‘Msg 0, Level 11, State 0, Line 16. A severe error occurred on the current command. The results, if any, should be discarded.’
I have restored old backups to differently named DBs. The older backups do not error when updating stats for this table. However I can recreate the problem by doing the above index rebuild. Following the rebuild, the update stats
fails with above error.
Using one of the old backups where update stats worked, I tried drop/create the index (even with ‘drop existing’). The result of this gives me the following warning which I hope is not part of the problem because we didn’t change the database
design, it is TFS: ‘Warning! The maximum key length is 900 bytes. The index ‘PK_tbl_LocalVersion’ has maximum length of 1609 bytes. For some combination of large values, the insert/update operation will fail.’
I can stop rebuilding the indices weekly, but I would like to get it back to a state wherein the update statistics runs successfully.
I will post the dump file next if that will help solve this problem.
Thank you in advance for any help you can provide.
Добрый день.
MS SQL 2014 Standart with SP2 установлен на MS Win Server 2014r2 Standart.
В связи с тем-что из софтового рэйда intel «выпал» диск и никак не хотел этим рэйдом подхватываться было решено перенести рэйд на другой контроллер(LSI 9240). Был остановлен SQL сервер, затем скопированы все файлы баз данных
на резервный диск, затем пересобран рэйд и файлы бд скопированы обратно в те же директории. В связи с тем, что перед отключением SQL базы не были корректно отключены, начали возникать ошибки:
Microsoft SQL Server Native Client 11.0: Операционная система возвратила ошибку 1(Неверная функция.) в SQL Server при запись в смещении 0x00000003aa0000
файла «E:Datatempdb.mdf».
Отключили базы, удалили целиком SQL сервер, установили с нуля, подключили обратно. Ошибка больше не появляется. Но теперь появляется ошибка при попытке сжатия базы или журнала. Резервное копирование этих баз и журналов проходит корректно, DBCC
CHECKDB проходит без ошибок (если предварительно не сделать попытку сжатия).
ЗАГОЛОВОК: Microsoft SQL Server Management Studio
——————————
Действие Сжатие завершилось неудачно для объекта «База данных» «crm_demo». (Microsoft.SqlServer.Smo)
Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=12.0.5000.0+((SQL14_PCU_main).160617-1804)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Сжатие+Database&LinkId=20476
——————————
ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ:
При выполнении инструкции или пакета Transact-SQL возникло исключение. (Microsoft.SqlServer.ConnectionInfo)
——————————
При выполнении текущей команды возникла серьезная ошибка.. При наличии результатов они должны быть аннулированы. (Microsoft SQL Server, ошибка: 0)
Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=12.00.5000&EvtSrc=MSSQLServer&EvtID=0&LinkId=20476
Перезапуск СУБД, естественно, пробовал. В логи ОС сыпется ошибка 9001, после отсоединения и присоединения базы ошибка в логах больше не появляется до следующей попытке сжатия базы.
Подскажите как решить данную проблему.
При сохранении базы средствами 1С выдает ошибку
Ошибка СУБД:
Microsoft SQL Server Native Client 11:0: SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неправильная контрольная сумма (ожидаемая 0x78a1455f; фактическая: 0x3ca0c55f). Она произошла при прочитать страницы (1:2106472) в базе данных с идентификатором 7 по смещению 0x000004048d0000 файла «C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLDATAtkpt.mdf». Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server. HRESULT=80004005, SQLSrvr:SQLSTATE=HY000, state=2, Severity=18, native=824, line=1
Делали CHECKDB. Он выдает ошибку в конце пишет
«При выполнении текущей команды возникла серьезная ошибка.. При наличии результатов они должны быть аннулированы.»
Что делать?
Выполнение следующего запроса в SQL Server Management Studio приводит к ошибке, указанной ниже.
update table_name set is_active = 0 where id = 3
Произошла серьезная ошибка в текущей команде. Результаты, если таковые имеются, следует отбросить.
- Журналы были усечены
- есть триггер обновления, но проблема не в этом
- количество транзакций равно нулю (@@ trancount)
Я пробовал тот же оператор обновления для пары других таблиц в базе данных, и они работают нормально.
DBCC CHECKTABLE('table_name');
дает
DBCC results for 'table_name'.
There are 13 rows in 1 pages for object "table_name".
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
12 ответы
У меня была такая же ошибка, и это было связано с повреждением индекса. Повторное индексирование таблицы устранило проблему.
ответ дан 10 мая ’19, 20:05
В моем случае я использовал SubQuery и была такая же проблема. Я понял, что проблема от утечки памяти.
Перезапуск MSSQL причина обслуживания для промывки tempDb ресурс и освободить огромное количество памяти. так что это было решить проблему.
Создан 07 янв.
ответ дан 14 авг.
Run DBCC CHECKTABLE('table_name');
Проверьте папку LOG, в которой установлен isntance (Program FilesMicrosoft SQL ServerMSSQL.1MSSQLLOG обычно) для любого файла с именем ‘SQLDUMP*‘
Создан 24 июля ’09, 01:07
Создан 21 янв.
В моем случае я использовал System.Threading.CancellationTokenSource отменить SqlCommand но не обрабатывая исключение с помощью catch (SqlException) { }
ответ дан 12 апр.
Эта ошибка как раз и означает: произошло что-то плохое, чего обычно не бывает.
В моем последнем случае НАСТОЯЩАЯ ошибка была:
Msg 9002, Level 17, State 2, Procedure MyProcedure, Line 2 [Batch Start Line 3]
The transaction log for database 'MyDb' is full due to 'LOG_BACKUP'.
Вот мой контрольный список того, что я могу попробовать, возможно, в таком точном порядке:
- Проверьте, нет ли у вас места на диске (это была моя настоящая проблема; наш NOC этого не заметил)
- Проверьте, мало ли у вас памяти
- Проверьте, не показывает ли журнал событий Windows какие-либо серьезные системные сбои, такие как сбой жестких дисков.
- Проверьте, не загружен ли небезопасный код с помощью расширенных процедур или небезопасных сборок SQLCLR, которые могут дестабилизировать процесс SQLServer.exe.
- Запустите CheckDB, чтобы увидеть, есть ли в вашей базе данных какие-либо проблемы с повреждением. В очень большой базе данных, если эта хранимая процедура касается только подмножества таблиц, вы можете сэкономить время, видя, какие разделы (файловые группы) затрагиваются хранимой процедурой, и проверяя только эти конкретные файловые группы.
- Я бы сделал это и для вашей базы данных, и для master db.
Создан 06 июн.
Похоже, это происходит, когда есть общая проблема с вашим источником данных, который он не обрабатывает.
В моем случае я вставил кучу данных, индексы в таблице были повреждены, их нужно было перестроить. Я нашел скрипт, чтобы их все перестроить, вроде исправил. Чтобы найти ошибку, я выполнил тот же запрос к базе данных — тот, который ранее работал более 100 раз.
ответ дан 20 окт ’19, 23:10
в моем случае метод: context.Database.CreateIfNotExists(); вызывается несколько раз перед созданием базы данных и выдает ошибку. Произошла серьезная ошибка в текущей команде. Результаты, если таковые имеются, следует отбросить.
ответ дан 07 дек ’20, 13:12
У меня была ошибка в Hangfire, из-за которой у меня не было доступа к внутренней работе библиотеки или я мог отследить, в чем заключалась основная причина.
Основываясь на @Ремус Русану ответ, я смог исправить это с помощью следующего скрипта.
--first set the database to single user mode
ALTER DATABASE TransXSmartClientJob
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
-- Then try to repair
DBCC CHECKDB(TransXSmartClientJob, REPAIR_REBUILD)
-- when done, set the database back to multiple user mode
ALTER DATABASE TransXSmartClientJob
SET MULTI_USER;
GO
ответ дан 28 авг.
Еще одно возможное решение, которое мы только что нашли после того, как эта проблема возникла в нескольких базах данных / таблицах на одном сервере.
Открыто ли максимальное количество подключений к серверу sql. У нас было приложение, которое не закрывало его SQL-соединение и оставляло их открытыми, поэтому у нас было около 28-31 32 подключений (у SQL-сервера максимальный выход составляет XNUMX КБ), и мы заметили, что как только мы убили несколько тысяч спящих подключений он позаботился об ошибке, указанной в этом вопросе.
Исправление заключалось в том, чтобы обновить приложения, чтобы убедиться, что они закрывают свои соединения, а не оставляют их открытыми.
ответ дан 21 окт ’20, 16:10
В моем случае это было что-то другое, += это вызвал оператор. Мне пришлось заменить += X с field = field + X чтобы преодолеть это. Я предполагаю, что это ошибка, хотя мне не удалось найти соответствующую КБ на сайтах Microsoft.
Я использую SQL Server 2008 R2 (10.50.1600).
Создан 04 янв.
Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками
sql-server
sql-server-2005
tsql
or задайте свой вопрос.


