Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
есть 2 похожие таблицы в двух базах одна с общим размером полей 126 байт, вторая с общим размером 157 байт - поменены некоторые поля с iNT на BIGINT и добавлено 3 поля (int,decimal(18,2),timestamp) количество записей примерно одинаковое ~ 700 млн При этом размер данных(по sp_spaceused) в первой таблице 90GB а во второй 180GB В чем причина? Неужели из-за изменения длины записи в 2 раза увеличились занятые страницы ? |
15 фев 21, 10:16 [22280978] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||||
15 фев 21, 10:39 [22280985] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
в таблице изначально нарезаны столбцы bigint и добавлены 3 поля. Потом данные перелиты из старой таблицы в новую. Вопрос в том что общая длина полей выросла с 126 до 157 байт то есть на 25 % а размер данных в таблице вырос в 2 раза и против теоеретических 110-115 GB показывает 180 GB |
15 фев 21, 10:59 [22280989] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
К сообщению приложен файл. Размер - 11Kb |
15 фев 21, 11:32 [22280996] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8313 |
LexusR, разговор ни о чем, сравните структуру старой таблицы и новой, возьмите калькулятор и подсчитайте разницу. |
15 фев 21, 11:54 [22281008] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
уже посчитал - я же написал что старая структура 126 байт сумма размеров всех полей а новая 157 байт итого на 700 млн должно быть 110ГБ а sp_spaceused показывает размер данных (без индексов) 189ГБ |
15 фев 21, 12:10 [22281018] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
старая таблицаCREATE TABLE [dbo].[StateLetter]( [Id] [int] IDENTITY(1,1) NOT NULL, [Letter_Id] [int] NOT NULL, [StatusReasonLetter_Id] [int] NOT NULL, [Date] [datetime] NOT NULL, [DateActual] [datetime] NOT NULL, [Employee_Id] [int] NOT NULL, [StateDocument_Id] [int] NULL, [Hidden] [bit] NOT NULL, [First] [bit] NULL, [Amount] [int] NOT NULL, [BranchPrice] [numeric](18, 2) NULL, [Branch_Id] [int] NULL, [SuccessStatusReasonLetter_Id] [int] NULL, [PriceDelivery] [numeric](18, 2) NULL, [PriceReturn] [numeric](18, 2) NULL, [PriceNotice] [numeric](18, 2) NULL, [AmountReturn] [int] NULL, [Ord] [int] NULL, [Document_Id] [int] NULL, [Lat] [float] NULL, [Long] [float] NULL, [DISTANCE] [float] NULL, [DaysDelta] [int] NULL, CONSTRAINT [PK_LetterDocument] PRIMARY KEY CLUSTERED ( [Id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO |
15 фев 21, 12:45 [22281047] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
новая таблицаCREATE TABLE [dbo].[StateLetter]( [Letter_Id] [bigint] NOT NULL, [Id] [bigint] IDENTITY(1,1) NOT NULL, [Document_Id] [bigint] NULL, [StateDocument_Id] [bigint] NULL, [Branch_Id] [int] NULL, [Date] [datetime] NOT NULL, [DateActual] [datetime] NOT NULL, [Employee_Id] [int] NOT NULL, [StatusReasonLetter_Id] [int] NOT NULL, [SuccessStatusReasonLetter_Id] [int] NULL, [Hidden] [bit] NULL, [First] [bit] NULL, [Amount] [int] NULL, [BranchPrice] [numeric](18, 2) NULL, [PriceDelivery] [numeric](18, 2) NULL, [PriceReturn] [numeric](18, 2) NULL, [PriceNotice] [numeric](18, 2) NULL, [AmountReturn] [int] NULL, [Ord] [int] NULL, [Lat] [numeric](9, 6) NULL, [Long] [numeric](9, 6) NULL, [DISTANCE] [float] NULL, [DaysDelta] [int] NULL, [CalcStatusReasonLetter_Id] [int] NULL, [CalcPrice] [numeric](18, 2) NULL, [rowversion] [timestamp] NOT NULL, PRIMARY KEY CLUSTERED ( [Letter_Id] ASC, [Id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO |
15 фев 21, 12:45 [22281049] Ответить | Цитировать Сообщить модератору |
Sergey Syrovatchenko Member Откуда: Сообщений: 167 |
Эх... а как вы данные переливали в новую таблицу? Может банально фрагментация на новой таблице высокая потому и такие результаты. Вставляли с WITH(TABLOCK)? |
15 фев 21, 13:25 [22281075] Ответить | Цитировать Сообщить модератору |
Sergey Syrovatchenko Member Откуда: Сообщений: 167 |
Какие еще индексы у вас там есть? Кроме кластерных. Есть подозрение что таки еще что-то прячете :) |
15 фев 21, 13:44 [22281090] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5495 |
+ fill factor может быть разный |
15 фев 21, 14:35 [22281125] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
komrad, после заливки делал шринк базы с дефрагментацией. индексы есть и они разные , но я смотрю разницу по данным без индексов |
15 фев 21, 15:46 [22281194] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
komrad, EXEC sp_configure 'fill factor' ---- 100 на обоих серверах |
15 фев 21, 15:57 [22281198] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
name minimum maximum config_value run_value fill factor (%) 0 100 0 0 |
15 фев 21, 15:59 [22281200] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5495 |
это серверный лучше проверить в sys.indexes для ваших таблиц (index_id=1) |
||||
15 фев 21, 16:28 [22281224] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8700 |
А смысл? Он используется только при ребилде и начальном построении индекса К реальной заполненности страниц он имеет очень далекое отношение |
||||||||
15 фев 21, 16:31 [22281227] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8700 |
LexusR, гляньте на avg_page_space_used_in_percent в sys.dm_db_index_physical_stats c SAMPLED а лучше DETAILED !!!DETAILED вызовет полный скан таблицы включая нелистовые уровни |
15 фев 21, 16:59 [22281246] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
Вы были правы - в старой таблице 98.73922659% для index_id=1 а в новой 59.18146775% Как с этим бороться и надо ли ? |
15 фев 21, 18:50 [22281317] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
я имею в виду avg_page_space_used_in_percent в sys.dm_db_index_physical_stats |
15 фев 21, 18:52 [22281318] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8700 |
Как - ребилд. Нужно ли - это сложный вопрос. Из потенциальных плюсов такого низкого avg_page_space_used_in_percent - отсутствие расщепления при вставка в середину индекса (кластерного в вашем случае) Из потенциальных минусов - больший объем как на диске, так и в памяти. |
||||
15 фев 21, 19:03 [22281320] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
я так понимаю надо дефрагментацию кластерного индекса запустить или реиндексацию. Что быстрее сработает на 700 млн записей ? |
15 фев 21, 19:06 [22281323] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8700 |
Я не знаю, что в вашем понимании дефрагментация и реиндексация индекса Самый быстрый способ - это alter index rebuild |
||||
15 фев 21, 19:10 [22281326] Ответить | Цитировать Сообщить модератору |
LexusR Member Откуда: Novosibirsk Сообщений: 1887 |
запустил ребилд так как выгоды от отсутствия расщепления не будет. Вставка старых записей была с отключением автоинкремента а дальше будет работать автоинкремент и ключи будут монотонно возрастающие. А вот уменьшить объем памяти будет весьма полезно. Спасибо за советы. |
15 фев 21, 19:35 [22281334] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |