Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Гавриленко Сергей Алексеевич
a_voronin
пропущено...


А почему оно должно падать? Оно может что-то прочитать или не прочитать. Но с какого ... оно должно валиться с ошибкой.
Да....

Открываем хелп и читаем:
ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10de_5techref/html/2039cc0a-9a43-4369-a04a-935e384388b6.htm
Explanation
The SQL Server Database Engine cannot continue executing the query because it is trying to read data that was updated or deleted by another transaction. The query is using either the NOLOCK locking hint or the READ UNCOMMITTED transaction isolation level.

Typically, access to data that is being changed by another transaction is denied because of locks put on the data. However, the NOLOCK locking hint and READ UNCOMMITTED transaction isolation level let a query read data that is locked by another transaction. This is referred to as a dirty read because you can read values that have not yet been committed and that are subject to change.

User Action
This error cancels the query. Either resubmit the query or remove the NOLOCK locking hint.


Прочитал.

http://www.mollerus.net/tom/blog/2008/03/using_mssqls_nolock_for_faster_queries.html
Now remember, locking is a good thing. Databases do it automatically so that your data doesn't become corrupted. So don't use NOLOCK to do any writing of data, or even for quick reads. But if you've got a long-running query which needs to read a large number of records, you won't hurt anything by reading without a lock. Plus, any other transactions won't have to wait to run, which could speed up the application for everyone else while you're running your report.

Остается фактом следующее. При использовании NOLOCK и NTEXT ошибка валиться практически гарантированно. При использовании NOLOCK и NVARCHAR(MAX) она не воспроизводится. Это говорит о том, что NVARCHAR(MAX) лучше устроен. Это также говорит о том, что "Either resubmit the query or remove the NOLOCK locking hint." это костыль, которым прикрывают баг. И это не как не говорит о том, что бага нет.
17 июн 14, 20:52    [16178253]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
a_voronin
Остается фактом следующее. При использовании NOLOCK и NTEXT ошибка валиться практически гарантированно. При использовании NOLOCK и NVARCHAR(MAX) она не воспроизводится. Это говорит о том, что NVARCHAR(MAX) лучше устроен
Если забивать гвозди микроскопом, то он ломается. Если забивать гвозди молотком, то молоток не ломается. Это говорит о том, что молоток лучше устроен.

a_voronin
Это также говорит о том, что "Either resubmit the query or remove the NOLOCK locking hint." это костыль, которым прикрывают баг. И это не как не говорит о том, что бага нет.
Ага, теория заговора, прям. Срыв покровов, все дела.

"Execute the transaction again" - это из описания другой ошибки. Тоже костыль, который баг прикрывает?
17 июн 14, 21:01    [16178280]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Гавриленко Сергей Алексеевич
a_voronin
Остается фактом следующее. При использовании NOLOCK и NTEXT ошибка валиться практически гарантированно. При использовании NOLOCK и NVARCHAR(MAX) она не воспроизводится. Это говорит о том, что NVARCHAR(MAX) лучше устроен
Если забивать гвозди микроскопом, то он ломается. Если забивать гвозди молотком, то молоток не ломается. Это говорит о том, что молоток лучше устроен.

a_voronin
Это также говорит о том, что "Either resubmit the query or remove the NOLOCK locking hint." это костыль, которым прикрывают баг. И это не как не говорит о том, что бага нет.
Ага, теория заговора, прям. Срыв покровов, все дела.

"Execute the transaction again" - это из описания другой ошибки. Тоже костыль, который баг прикрывает?


В той ситуации этого было сделать нельзя. Данные выгружались десятками минут, а иногда часами. READCOMMITTED увеличивать время до недопустимого. READUNCOMMITED валился по ошибке, практически гарантированно после 30-60 минут. Перезапуск транзакций, приводил к тому, что сервер перегружался до предела. Про новое железо забудьте. Вполне стандартная ситуации. Ваше решение? Моё было перейти на NVARCHAR(MAX) и оставить NOLOCK. Продукту уже 15 лет и он работает c NOLOCK на NVARCHAR(MAX). Дальше говорите про костыли, доктора, хелп, подлого админа, которые хорошо читал хелп, и т.п.
17 июн 14, 21:14    [16178310]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
a_voronin
Продукту уже 15 лет и он работает c NOLOCK на NVARCHAR(MAX)
15 лет назад nvarchar(max) еще не существовало...
17 июн 14, 21:25    [16178334]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Дальше говорите про костыли, доктора, хелп, подлого админа, которые хорошо читал хелп, и т.п.

т.е. если ошибка 601 получится для таблицы без блоб полей, то значит все остальные типы данных тоже багованные ?
И нужно срочно менять их все на VARCHAR(MAX) ?
17 июн 14, 21:40    [16178365]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
a_voronin
Именно это позволяет мне утверждать,что NTEXT, TEXT, IMAGE глючные типы.
Ну varchar(max) не менее глючный:

Тестовая таблица
use tempdb;
go

create table dbo.t (id int primary key, v varchar(max));
insert into dbo.t values (1, 'a');

1-я сессия
use tempdb;
go

declare @v varchar(max);

while 1 = 1
 select @v = v from dbo.t with (nolock) where id = 1;

2-я сессия
use tempdb;
go

while 1 = 1
 update dbo.t set v = replicate(cast('b' as varchar(max)), 9000 + rand() * 18000) where id = 1;

17 июн 14, 22:17    [16178434]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
a_voronin
Факт в следующем, если сделать тоже самое, но на VARCHAR(MAX), ошибки нет. Оно устойчиво при NOLOCK. Именно в этом состоял тогдашний старый баг, и он не исправлен сейчас на SQL 2012. Именно это позволяет мне утверждать,что NTEXT, TEXT, IMAGE глючные типы.

USE [TEST]
GO

CREATE TABLE X
(ID INT IDENTITY (1,1) NOT NULL ,
T VARCHAR(MAX) NOT NULL )
GO


если вы заполняете эту таблицу как и предыдущую вот таким образом:

INSERT INTO [dbo].[X]
           ([T])
     VALUES
           (REPLICATE(NEWID(), 10000))


то вы вообще LOB не записываете,
что видно, выполнив dbcc ind:

 CREATE TABLE X
(ID INT IDENTITY (1,1) NOT NULL ,
T varchar(max) NOT NULL )
GO

INSERT INTO [dbo].[X]
           ([T])
     VALUES
           (REPLICATE(NEWID(), 10000))


dbcc ind ('db1', 'x', 1)


PageFID PagePID IAMFID IAMPID ObjectID IndexID PartitionNumber PartitionID iam_chain_type PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID
1 196 NULL NULL 629577281 0 1 72057594040025088 In-row data 10 NULL 0 0 0 0
1 195 1 196 629577281 0 1 72057594040025088 In-row data 1 0 0 0 0 0


все данные, что легли в таблицу, IN-ROW

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

INSERT INTO [dbo].[X]
           ([T])
     VALUES
           (replicate('a', 10000))


INSERT INTO [dbo].[X]
           ([T])
     VALUES
          (replicate(cast('a' as varchar(max)),10000))
          
select id, LEN(t)
from x
------------------
id	(No column name)
1	7992
2	8000
3	10000
17 июн 14, 23:13    [16178631]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
Резюмируя для интересующихся:

Как и следовало ожидать, в контексте вопроса, поднятого a_voronin, никакой "глючности" и "багов" у типов TEXT, NTEXT и IMAGE нет.
Ошибка 601 может появиться при вычитке блобов с NOLOCK, если эти блобы хранятся out of row.
Для TEXT, NTEXT и IMAGE хранение по-умолчанию out of row, для VARCHAR(MAX) и т.п. - наоборот in row, с лимитом до 8000 байт. Отсюда и эффект исчезновения ошибки 601 у a_voronin после смены типа столбца.
18 июн 14, 15:58    [16183384]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
invm
Резюмируя для интересующихся:

Как и следовало ожидать, в контексте вопроса, поднятого a_voronin, никакой "глючности" и "багов" у типов TEXT, NTEXT и IMAGE нет.
Ошибка 601 может появиться при вычитке блобов с NOLOCK, если эти блобы хранятся out of row.
Для TEXT, NTEXT и IMAGE хранение по-умолчанию out of row, для VARCHAR(MAX) и т.п. - наоборот in row, с лимитом до 8000 байт. Отсюда и эффект исчезновения ошибки 601 у a_voronin после смены типа столбца.


Возражаю, эксперимент проводился на 2012 с командой.

sp_tableoption N'X', 'text in row', 'ON'
GO

При замене типа с TEXT на VARCHAR(MAX) ошибка пропадает. Поэтому "глючность" и "баги" у типов TEXT, NTEXT и IMAGE есть. Главное отличие в том, что в в случае varchar(max) блоб является единым целым с записью в таблице, а в случае с TEXT нет. Также еще раз обращаю внимание на то, что с 2005 года Microsoft трендит и трендит, что от этих типов надо отказываться.

У меня вообще возникло подозрение, что out of row и in row никак не связаны с проблемой.
18 июн 14, 16:10    [16183514]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
a_voronin
Возражаю, эксперимент проводился на 2012 с командой.

sp_tableoption N'X', 'text in row', 'ON'
GO
Прежде чем возражать, ознакомьтесь в документации каков в данном случае будет лимит объема хранения в строке. И как он соотносится с вашим репро, которое, кстати говоря, не работает.
a_voronin
Главное отличие в том, что в в случае varchar(max) блоб является единым целым с записью в таблице, а в случае с TEXT нет
Сами поняли, что написали?
a_voronin
У меня вообще возникло подозрение, что out of row и in row никак не связаны с проблемой.
Репро приведено (16178434). Ничто не мешает вам проверить собственные подозрения.
18 июн 14, 16:25    [16183667]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
invm
a_voronin
Продукту уже 15 лет и он работает c NOLOCK на NVARCHAR(MAX)
15 лет назад nvarchar(max) еще не существовало...


Из фразы "Продукту уже 15 лет и он работает c NOLOCK на NVARCHAR(MAX)" не следует, что NVARCHAR(MAX) был в нём 15 лет назад. И как я писал выше, я осуществлял переход на SQL 2005 и перевод типа NTEXT на NVARCHAR(MAX), после чего запросы стали стабильными. Было это в 2006-2007 году.

Я считал тогда и считаю сейчас, что присутствие NTEXT это риск.
18 июн 14, 16:29    [16183717]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
a_voronin
Я считал тогда и считаю сейчас, что присутствие NTEXT это риск.
Вы можете считать как вам заблагорассудится - вопрос не в этом. Вы заявили, что старые типы блобов "глючные" и с "багами", а доказать этого так и не смогли.
18 июн 14, 16:49    [16183931]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
invm
a_voronin
Я считал тогда и считаю сейчас, что присутствие NTEXT это риск.
Вы можете считать как вам заблагорассудится - вопрос не в этом. Вы заявили, что старые типы блобов "глючные" и с "багами", а доказать этого так и не смогли.


Я считаю, что доказал. Вы считаете, что нет. Давайте на этом закончим.
18 июн 14, 16:51    [16183944]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
ужас какой-то, a_voronin -- просто чемпион в звании "чукча -- не читатель".
не видно что-ли, что не вставили вы LOB-данные,
а обрезыши какие-то в таблицу?
ведь, блин, код написан, как проверить, что вставилось
18 июн 14, 17:04    [16184073]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
o-o
ужас какой-то, a_voronin -- просто чемпион в звании "чукча -- не читатель".
Так и должно быть, ибо, имхо, человек пришел на форум покрасоваться собой и потроллить остальных...
18 июн 14, 17:14    [16184186]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
тогда нечего ворониным представляться, коли они ПАВЛИНСКИХ будуть
вводят, понимаешь, в заблуждение
18 июн 14, 17:29    [16184336]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
o-o
ужас какой-то, a_voronin -- просто чемпион в звании "чукча -- не читатель".
не видно что-ли, что не вставили вы LOB-данные,
а обрезыши какие-то в таблицу?
ведь, блин, код написан, как проверить, что вставилось


Ребят, вы углубились в чтение документации по IN ROW OUT OF ROW, и да обрезыши вставились. И что? Как это связано с надежностью типа NTEXT. Какое отношение IN ROW OUT OF ROW имеет к этой проблеме? Какая разница, как он храниться. Как это влияет на результат?

Да по хрену мне, пишите с NTEXT. Пусть ваши системы валяться. Потом меня на большое бабло позовут разгребать ваш бардак. И я его разгребу.
18 июн 14, 17:46    [16184484]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
капец, товарищ, какое еще углубленное чтение?
оставьте в покое in-row, вы не поняли ваще что это такое, типун мне на язык, нефиг было даже упоминать,
забудьте на секунду про in-row это и прочтите то, чего вам в рупор орут!!

ваш эксперимент по замене в таблице TEXT на VARCHAR(MAX) закончился
помещением в таблицу обрезанных данных, о чем разговор вообще???
если у кого-то проблемы с данными длиной в гигабайт, а вы подменяете их данными в 8Кб,
это что, решение проблемы?
или вставляйте данные той же длины в VARCHAR(MAX),
или идите нафиг с утверждением "а вот заменил TEXT на VARCHAR(MAX) и все получилось".
вы, блин, не тип заменили, а данные урезали, вроде по-русски излагаю.
или вы правда потроллить пришли???

ВЫ ДАННЫЕ ВСТАВЛЯЕТЕ В СВОЕМ ЭКСПЕРИМЕНТЕ ***НЕПРАВИЛьНО***
У ВАС ДАННЫЕ ОБРЕЗАНЫ ДО 8КБ, ХОТь ВЫ ТАМ И ПИШЕТЕ REPLICATE(..., 10000)
18 июн 14, 18:07    [16184650]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
a_voronin
Какая разница, как он храниться. Как это влияет на результат?


результат тот, что инсертили вы 10000 символов, а вставили 8000,
теперь обратно свои 10000 требуете, а вам в ответ всего 8000,
вот так на результат влияет!
посчитайте еще раз длину вставленного вами в поле varchar(max),
функцией LEN() хотя бы
18 июн 14, 18:11    [16184679]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
o-o
a_voronin
Какая разница, как он храниться. Как это влияет на результат?


результат тот, что инсертили вы 10000 символов, а вставили 8000,
теперь обратно свои 10000 требуете, а вам в ответ всего 8000,
вот так на результат влияет!
посчитайте еще раз длину вставленного вами в поле varchar(max),
функцией LEN() хотя бы


Я это понял. Вы не поняли, что это не влияет на результат эксперимента.
18 июн 14, 18:13    [16184696]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
a_voronin
Да по хрену мне, пишите с NTEXT
Никто, будучи в трезвом уме и здравой памяти, не станет пользоваться старыми типами блобов при наличии новых. И не потому, что они "ненадежны", а потому что старыми практически невозможно пользоваться из-за урезанного функционала.
Уж вам-то такому "крутому спецу" с таким "богатым и бесценным опытом" это должно быть известно...
18 июн 14, 18:20    [16184751]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
a_voronin
Вы не поняли, что это не влияет на результат эксперимента.


я что-то вижу, что еще как влияет.
у тех, кто вставляет правильно, ситуевина повторяется и с varchar(max)
16178434
18 июн 14, 18:23    [16184766]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
invm
a_voronin
Да по хрену мне, пишите с NTEXT
Никто, будучи в трезвом уме и здравой памяти, не станет пользоваться старыми типами блобов при наличии новых. И не потому, что они "ненадежны", а потому что старыми практически невозможно пользоваться из-за урезанного функционала.
Уж вам-то такому "крутому спецу" с таким "богатым и бесценным опытом" это должно быть известно...


а это называется "стрелочник".
уже Mnior про это писал.
как только жареным пахнет, товарищ сразу в кусты.
он не признает ни за что, что поставил кривой эксперимент,
он, скорее, выкрикнет: "ну и продолжайте старые типы использовать"
т.е. стрелки переводит, и типа никто не заметил, как свой супер-тезис он доказать не сумел
18 июн 14, 18:25    [16184779]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
o-o
Guest
суть топика вкратце:

бла-бла-бла, "а напоследок я скажу" (c) рекомендую использовать varchar(max) вместо text.
[и все, тут бы и остановиться]
но кто-то продолжает: text такой багнутый, а varchar(max) -- супер-пупер.
куча народа требует доказательств, ЗАМЕТьТЕ, именно "багнутости" text-a в сравнении с varchar(max)-oм.
никто не лез в спор, какой из типов следует использовать, ибо сие очевидно и в каждом углу хэлпа написано.

доказательства лопнули, но товарищ фиг признает.
всего-то.
а теперь давайте хором прокричим:
используйте, граждане, varchar(max) вмест text.
...и, заметьте, все подпишутся
18 июн 14, 18:33    [16184824]     Ответить | Цитировать Сообщить модератору
 Re: Поиск по полю с типом text  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
o-o
суть топика вкратце:

бла-бла-бла, "а напоследок я скажу" (c) рекомендую использовать varchar(max) вместо text.
[и все, тут бы и остановиться]
но кто-то продолжает: text такой багнутый, а varchar(max) -- супер-пупер.
куча народа требует доказательств, ЗАМЕТьТЕ, именно "багнутости" text-a в сравнении с varchar(max)-oм.
никто не лез в спор, какой из типов следует использовать, ибо сие очевидно и в каждом углу хэлпа написано.

доказательства лопнули, но товарищ фиг признает.
всего-то.
а теперь давайте хором прокричим:
используйте, граждане, varchar(max) вмест text.
...и, заметьте, все подпишутся


На этой славной ноте давайте данный топик закроем. Glory!!! закройте его, пока я не начал доказывать, что LONG в Oracle тоже глючный!!!
18 июн 14, 18:38    [16184848]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить