Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Хорошо, можно того мы с вами лично не будем больше устраивать такую острую полемику? Мы с вами не сработались, давайте примем это как данность. Можно я будут общаться с другими без вашего вмешательства. Без ваших комментариев, "это бред", "проверьтесь у доктора". |
||||
17 июн 14, 17:30 [16177595] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Заведите себе свой форум и там общайтесь.
Все просто - не пишите бред, и не услышите, что это бред. Если у вас были проблемы с определенными запросами, то не надо писать про глючный тип данных. Надо так и написать - вот при таких-то условиях, появляется вот это. |
||||
17 июн 14, 17:35 [16177626] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Можно вы сами будете соблюдать такие правила форума Запрещается: публикация грубых, оскорбляющих и унижающих сообщений. Рекомендуется: Быть взаимно вежливыми и уважать других участников форума. |
||||||
17 июн 14, 17:43 [16177667] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
И чем же я вас грубо оскорбил или унизил ?
Как вы думаете, слово "выпендривается" - оно вежливое и уважительное ? А в контексте со словом "опять" говорит ли об уже многократном применении слово "выпендривается" |
||||
17 июн 14, 17:46 [16177684] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Предложение сходить к доктору мне видится выходящим за рамки дозволенного. Если вам не нравиться слово "выпендривается", я готов уважИть вас и от него воздержаться. Мы может на этом придти к согласию? |
||||||
17 июн 14, 17:50 [16177705] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Чем же ? Как я уже сказал, вы на меня не производите впечатление серьезного и адектваного человека. Отсюда и совет обратится к специалисту. Сам я вам диагноз не ставил.
Мне пофиг. Это не дает вам индульгенцию на все ваши следующие сообщения. |
||||
17 июн 14, 17:55 [16177734] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37139 |
|
||||
17 июн 14, 18:06 [16177793] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Да, я так решил, что "что новый функционал был разработан именно потому что не смогли исправить старый." Именно после разговора с 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] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37139 |
|
||
17 июн 14, 18:17 [16177840] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Я думаю дело было в другом. Они по каким-то причинам решили, что нужно построить более правильную структуру хранения blob, но для обратной совместимости не трогать NTEXT. Главный момент, который я хотел озвучить на этом форме и я уверен, вы с ним согласитесь, это то, что сейчас в году 2014 настоятельно рекомендуется использовать NVARCHAR(MAX), а не NTEXT. |
||||
17 июн 14, 18:27 [16177876] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37139 |
|
||
17 июн 14, 18:32 [16177898] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Новые блобы не хранятся по-страничо теперь что ли ? Или старые блобы не хранились по-страничо ? Все как хранилось, так и хранится. |
||
17 июн 14, 18:34 [16177912] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Старые не хранились по-странично. В записи лежал указатель, а 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] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Я столько раз уже офигевал в этом топике, что просто уже сказать нечего Все данные в 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] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
ну а сейчас что, не ложится что-ли указатель на корень дерева 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] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Вот это сообщение было по делу. Но включение этой опции не гарантирует отсутствие ссылки на отдельное хранилище строк. К тому же надо знать, что эту опцию надо включать. Это фича для продвинутых людей. 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] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Фейспалм. |
||
17 июн 14, 19:06 [16178042] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Может быть они всё-таки пофиксили проблему в районе 2008-2010 года. Опять же надо проверить. |
||||
17 июн 14, 19:07 [16178043] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
prooflink for Storage of MAX-Length Data |
17 июн 14, 19:10 [16178056] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Фейспалм в квадрате. Я читаю грязные данные и со всей ответственностью заявляю, что это баг. Нет, это - БАГ. |
||
17 июн 14, 19:34 [16178109] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
А почему оно должно падать? Оно может что-то прочитать или не прочитать. Но с какого ... оно должно валиться с ошибкой. |
||||
17 июн 14, 19:40 [16178118] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
ЗЫ: Открою вам страшную тайну - ошибка 601 не имеет к блобам никакого отношения и может возникать при сканировании таблиц, где их нет. |
||
17 июн 14, 20:33 [16178212] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37139 |
Открываем хелп и читаем:
|
||||||
17 июн 14, 20:39 [16178225] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |