Поиск по полю с типом text / Страница 3 / Microsoft SQL Server / Sql.ru

Добро пожаловать в форум, Guest >> Войти \| Регистрация \| Поиск \| Правила \|			В избранное \| Подписаться
Все форумы / Microsoft SQL Server

Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Glory

a_voronin
если я вам напишу шаги для воспроизведения проблемы, вы успокоитесь?

Сейчас это уже неважно.
Мне трудно воспринимать вас как серьезного и адекватного человека.
Имидж уже сложился.

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

17 июн 14, 17:30 [16177595] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

a_voronin
Можно я будут общаться с другими без вашего вмешательства.

Заведите себе свой форум и там общайтесь.

a_voronin
Без ваших комментариев, "это бред", "проверьтесь у доктора".

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

17 июн 14, 17:35 [16177626] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Glory

a_voronin
Можно я будут общаться с другими без вашего вмешательства.

Заведите себе свой форум и там общайтесь.

a_voronin
Без ваших комментариев, "это бред", "проверьтесь у доктора".

Можно вы сами будете соблюдать такие правила форума

Запрещается:
публикация грубых, оскорбляющих и унижающих сообщений.

Рекомендуется:
Быть взаимно вежливыми и уважать других участников форума.

17 июн 14, 17:43 [16177667] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

a_voronin
Запрещается: публикация грубых, оскорбляющих и унижающих сообщений.

И чем же я вас грубо оскорбил или унизил ?

a_voronin
Рекомендуется: Быть взаимно вежливыми и уважать других участников форума.

Как вы думаете, слово "выпендривается" - оно вежливое и уважительное ?
А в контексте со словом "опять" говорит ли об уже многократном применении слово "выпендривается"

17 июн 14, 17:46 [16177684] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Glory

a_voronin
Запрещается: публикация грубых, оскорбляющих и унижающих сообщений.

И чем же я вас грубо оскорбил или унизил ?

a_voronin
Рекомендуется: Быть взаимно вежливыми и уважать других участников форума.

Предложение сходить к доктору мне видится выходящим за рамки дозволенного. Если вам не нравиться слово "выпендривается", я готов уважИть вас и от него воздержаться. Мы может на этом придти к согласию?

17 июн 14, 17:50 [16177705] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

a_voronin
Предложение сходить к доктору мне видится выходящим за рамки дозволенного.

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

a_voronin
я готов уважИть вас и от него воздержаться.Мы может на этом придти к согласию?

Мне пофиг. Это не дает вам индульгенцию на все ваши следующие сообщения.

17 июн 14, 17:55 [16177734] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37139

a_voronin

Гавриленко Сергей Алексеевич
пропущено... Потому что не захотели или не смогли. Не отчитались они мне.

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

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

17 июн 14, 18:06 [16177793] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Гавриленко Сергей Алексеевич

a_voronin
пропущено... А мне между делом отчитались по телефону без протоколу, что да с типом есть проблемы, она намерены от него отказываться. Проблема в способе хранения.

Да, я так решил, что "что новый функционал был разработан именно потому что не смогли исправить старый." Именно после разговора с Support Microsoft и после чтение Release Notes от SQL Server. Вы можете иметь иное мне, но позвольте мне иметь такое.

Кстати в Oracle аналогичная история с типом LONG

LONG is an Oracle data type for storing character data of variable length up to 2 Gigabytes in length (bigger version of the VARCHAR2 datatype). Note that a table can only have one LONG column.

Since Oracle 8i, Oracle advised against using the LONG datatype. Users should convert to CLOB or NCLOB types.

17 июн 14, 18:11 [16177821] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37139

a_voronin

Саппорт не имеет к команде разработки никакого отношения и не принимает никаких решений. И команда разработки не отчитывается как правило о причинах принятия тех или иных решений перед саппортом. Я еще могу поверить, что тот сотрудник, с которым вы общались, свято верил, что разработчики "не шмогли", но это не обязательно так.

17 июн 14, 18:17 [16177840] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Гавриленко Сергей Алексеевич

a_voronin

Я думаю дело было в другом. Они по каким-то причинам решили, что нужно построить более правильную структуру хранения blob, но для обратной совместимости не трогать NTEXT. Главный момент, который я хотел озвучить на этом форме и я уверен, вы с ним согласитесь, это то, что сейчас в году 2014 настоятельно рекомендуется использовать NVARCHAR(MAX), а не NTEXT.

17 июн 14, 18:27 [16177876] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37139

a_voronin

Да, этот момент, безусловно, правильный. Но аргументы, почему так надо было сделать, вы привели, мягко говоря, спорные. Отсюда и весь сыр-бор.

17 июн 14, 18:32 [16177898] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

a_voronin
Они по каким-то причинам решили, что нужно построить более правильную структуру хранения blob,

Новые блобы не хранятся по-страничо теперь что ли ?
Или старые блобы не хранились по-страничо ?
Все как хранилось, так и хранится.

17 июн 14, 18:34 [16177912] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Glory

a_voronin
Они по каким-то причинам решили, что нужно построить более правильную структуру хранения blob,

Старые не хранились по-странично. В записи лежал указатель, а blob лежал в "специальном пространстве". Вот здесь есть некая схема.

http://blogs.msdn.com/b/psssql/archive/2012/12/03/how-it-works-gotcha-varchar-max-caused-my-queries-to-be-slower.aspx

17 июн 14, 18:46 [16177954] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

a_voronin
Старые не хранились по-странично. В записи лежал указатель, а blob лежал в "специальном пространстве". Вот здесь есть некая схема.

Я столько раз уже офигевал в этом топике, что просто уже сказать нечего

Все данные в MSSQL хранятся по-странично

Unless the text in row option is set to ON or to a specific in-row limit, text, ntext, or image strings are large character or binary strings (up to 2 gigabytes) that are stored outside a data row. The data row contains only a 16-byte text pointer that points to the root node of a tree built of internal pointers. These pointers map the pages in which the string fragments are stored. For more information about the storage of text, ntext, or image strings, see Using text and image Data.

You can set a text in row option for tables that contain LOB data type columns. You can also specify a text in row option limit, from 24 through 7,000 bytes.

Similarly, unless the large value types out of row option is set to ON, varchar(max), nvarchar(max), varbinary(max), and xml columns are stored, if it is possible, inside the data row. If this is the case, the SQL Server Database Engine tries to fit the specific value if it can, and will push the value off-row otherwise. If large value types out of row is set to ON, the values are stored off-row and only a 16-byte text pointer is stored in the record.

17 июн 14, 18:51 [16177974] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

o-o
Guest

a_voronin
Старые не хранились по-странично. В записи лежал указатель, а blob лежал в "специальном пространстве". Вот здесь есть некая схема.

ну а сейчас что, не ложится что-ли указатель на корень дерева BLOB-а?
если значение сходу превышает 8000 байт?

Storage of MAX-Length Data

SQL Server 2005 and SQL Server 2008 give us the option of defining a variable-length field
using the MAX specifi er. Although this functionality is frequently described by referring only
to varchar(MAX), the MAX specifi er can also be used with nvarchar and varbinary. You can
indicate the MAX specifi er instead of an actual size when you define a column, variable, or
parameter using one of these types. By using the MAX specifier, you leave it up to SQL Server
to determine whether to store the value as a regular varchar, nvarchar, or varbinary value or as
a LOB. In general, if the actual length is 8,000 bytes or less, the value is treated as if it were one
of the regular variable-length data types, including possibly overflowing onto row-overflow
pages. However, if the varchar(MAX) column does need to spill off the page, the extra pages
required are considered LOB pages and show the IAM_chain_type LOB when examined using
DBCC IND. If the actual length is greater than 8,000 bytes, SQL Server stores and treats the
value exactly as if it were text, ntext, or image. Because variable-length columns with the MAX
specifier are treated either as regular variable-length columns or as LOB columns, no special
discussion of their storage is needed.

т.е. вкратце, вся разница только в том, что используя varchar(max),
серверу предоставлен выбор, хранить ли значение как обычный varchar (если влазит)
или сразу как BLOB.

17 июн 14, 19:03 [16178032] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Glory

a_voronin
Старые не хранились по-странично. В записи лежал указатель, а blob лежал в "специальном пространстве". Вот здесь есть некая схема.

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

http://msdn.microsoft.com/en-us/library/ms173530.aspx
If a text, ntext, or image string is larger than the specified limit or the available space in the row, pointers are stored in the row instead. The conditions for storing the BLOB strings in the row nonetheless apply: There must be enough space in the data row to hold the pointers.

Надо делать эксперимент, чтобы посмотреть, уберёт ли она проблему Slot Does Not Exist на большом кол-ве параллельных транзакций. В любой случае почему Support Microsoft не предложил мне тогда включить эту опцию?

17 июн 14, 19:05 [16178039] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

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

Фейспалм.

17 июн 14, 19:06 [16178042] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

o-o

a_voronin
Старые не хранились по-странично. В записи лежал указатель, а blob лежал в "специальном пространстве". Вот здесь есть некая схема.

Может быть они всё-таки пофиксили проблему в районе 2008-2010 года. Опять же надо проверить.

17 июн 14, 19:07 [16178043] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]
o-o Guest	prooflink for Storage of MAX-Length Data
17 июн 14, 19:10 [16178056] Ответить \| Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Я провел эксперимент на SQL 2012. проблема не устранена.

Вот шаги для вопросизведения
1) Создать БД TEST, выставить Recovery Model Simple
2) Выполнить скрипт

USE [TEST]
GO

CREATE TABLE X
(ID INT IDENTITY (1,1) NOT NULL ,
T TEXT NOT NULL )
GO
sp_tableoption N'X', 'text in row', 'ON'
GO

3) Запустить в SSMS четыре скрипта параллельно в разных окнах

WHILE 1 = 1
BEGIN 
INSERT INTO [dbo].[X]
           ([T])
     VALUES
           (REPLICATE(NEWID(), 10000))
END

WHILE 1 = 1
BEGIN 
	UPDATE [dbo].[X]
	SET [T] = REPLICATE(NEWID(), 10000)
	WHERE (X.ID + DATEPART(second, GETDATE())) % 20 = 0
END

WHILE 1 = 1
BEGIN 
	DELETE FROM [dbo].[X]
	WHERE (X.ID + DATEPART(second, GETDATE())) % 60 = 0
END

WHILE 1 =1
BEGIN 
	DECLARE @X TABLE 
	(
	T TEXT NOT NULL )

	INSERT INTO @X
	SELECT T 
	FROM [TEST].[dbo].[X] (NOLOCK) 
END

Получаем в четвертом скрипте

(15526 row(s) affected)

(15289 row(s) affected)

(15011 row(s) affected)

(14859 row(s) affected)

(14808 row(s) affected)

(14753 row(s) affected)

(14579 row(s) affected)

(14488 row(s) affected)

(14429 row(s) affected)

(14349 row(s) affected)
Msg 601, Level 12, State 3, Line 8
Не удалось продолжить просмотр с NOLOCK вследствие перемещения данных.

если убрать NOLOCK, то проблемы нет

17 июн 14, 19:32 [16178105] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Glory
Member

Откуда:
Сообщений: 104760

a_voronin
если убрать NOLOCK, то проблемы нет

Фейспалм в квадрате.
Я читаю грязные данные и со всей ответственностью заявляю, что это баг. Нет, это - БАГ.

17 июн 14, 19:34 [16178109] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

a_voronin
Member

Откуда: Москва
Сообщений: 4807

Glory

a_voronin
если убрать NOLOCK, то проблемы нет

Фейспалм в квадрате.
Я читаю грязные данные и со всей ответственностью заявляю, что это баг. Нет, это - БАГ.

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

17 июн 14, 19:40 [16178118] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]
a_voronin Member Откуда: Москва Сообщений: 4807	Факт в следующем, если сделать тоже самое, но на 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
17 июн 14, 20:32 [16178208] Ответить \| Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

invm
Member

Откуда: Москва
Сообщений: 9633

a_voronin
А почему оно должно падать? Оно может что-то прочитать или не прочитать.

И какие же данные должны возвращаться в этом случае?

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

17 июн 14, 20:33 [16178212] Ответить | Цитировать Сообщить модератору

Re: Поиск по полю с типом text [new]

Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37139

a_voronin

Glory
пропущено... Фейспалм в квадрате. Я читаю грязные данные и со всей ответственностью заявляю, что это баг. Нет, это - БАГ.

Да....

Открываем хелп и читаем:

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.

17 июн 14, 20:39 [16178225] Ответить | Цитировать Сообщить модератору

Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все

Все форумы / Microsoft SQL Server

Ссылка на сообщение

Ссылка (включая название темы)

Ссылка (URL)