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

Откуда:
Сообщений: 3422
khourshed
WEBPROJECT_COMPONENT_ID через newid() генерился.
Ну, все. Будет размываться очень быстро, ибо вставка идет не в хвост, а в произвольные страницы. Не очень понятно, правда, почему вставка 5% записей так сильно его фрагментировала, при том что у вас там якобы 20% свободного места...

Кстати, а план-то у вас нормальный. Индекс прекрасно используется.

Не очень понимаю, где у вас там фрагментация вылезает. Приведите sys.dm_db_index_physical_stats, что ли...
12 фев 13, 13:42    [13913704]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а можете показать cpu / reads / writes / duration для плохого и хорошего выполнения?
12 фев 13, 13:44    [13913719]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Ennor Tiegael
Кстати, а план-то у вас нормальный. Индекс прекрасно используется.


шанс небольшой, но не удивлюсь, если "внезапно" запрос начинает по 100500 записей возвращать
тупо расклад по данным такой
а, возможно, нам план не тот показывают и в "плохом" раскладе там скан а не сик + букмарк
12 фев 13, 13:45    [13913731]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
khourshed
Member

Откуда:
Сообщений: 93
Ennor Tiegael,

автор
Ну, все. Будет размываться очень быстро, ибо вставка идет не в хвост, а в произвольные страницы. Не очень понятно, правда, почему вставка 5% записей так сильно его фрагментировала, при том что у вас там якобы 20% свободного места...

Кстати, а план-то у вас нормальный. Индекс прекрасно используется.

Не очень понимаю, где у вас там фрагментация вылезает. Приведите sys.dm_db_index_physical_stats, что ли...


DECLARE @db_id SMALLINT;
DECLARE @object_id INT;
declare @index_id int
SET @db_id = DB_ID(N'ViewCacheDb'); 
SET @object_id = OBJECT_ID(N'cms_tblViewCache');
select 
	@index_id=index_id
	from
	sys.indexes
	where name = 'IX_CheckSum'

        SELECT         
        * 
        FROM 
        sys.dm_db_index_physical_stats (@db_id, @object_id, @index_id, NULL , 'DETAILED') st 



database_idobject_idindex_idpartition_numberindex_type_descalloc_unit_type_descindex_depthindex_levelavg_fragmentation_in_percentfragment_countavg_fragment_size_in_pagespage_countavg_page_space_used_in_percentrecord_countghost_record_countversion_ghost_record_countmin_record_size_in_bytesmax_record_size_in_bytesavg_record_size_in_bytesforwarded_record_countcompressed_page_count
152157511571NONCLUSTERED INDEXIN_ROW_DATA300304878049185466666667984824922411720985900294329316NULL0
152157511571NONCLUSTERED INDEXIN_ROW_DATA31504156587348653398400272727NULL0
152157511571NONCLUSTERED INDEXIN_ROW_DATA3201112125030887600272727NULL0


Сейчас в таблице меньше записей так как транкейт делал вчера
12 фев 13, 14:46    [13914240]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
khourshed
Member

Откуда:
Сообщений: 93
database_idobject_idindex_idpartition_numberindex_type_descalloc_unit_type_descindex_depthindex_levelavg_fragmentation_in_percentfragment_countavg_fragment_size_in_pagespage_countavg_page_space_used_in_percentrecord_countghost_record_countversion_ghost_record_countmin_record_size_in_bytesmax_record_size_in_bytesavg_record_size_in_bytesforwarded_record_countcompressed_page_count
152157511571NONCLUSTERED INDEXIN_ROW_DATA300.3048780491854.6666666798482.4922411720985900294329.316NULL0
152157511571NONCLUSTERED INDEXIN_ROW_DATA315041.5658.7348653398400272727NULL0
152157511571NONCLUSTERED INDEXIN_ROW_DATA3201112.125030887600272727NULL0


табличка верхняя некорректно запятые показывает ... сорри
12 фев 13, 14:49    [13914256]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
khourshed
MasterZiv,

автор
Так вообще в таком случае какой смысл с фрагмент ацией бороться


Вы мне предлагаете каждые 3 часа индекс ребилдить?


НЕТ, и именно поэтому я тебе предлагаю перестать бороться с фрагментацией, и начать оптимизировать конкретные
планы конкретных запросов.
12 фев 13, 14:56    [13914312]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
Спасибо за объяснение.
Вопрос еще вот в чем. Почему кластерный индекс по PK не вылечил фрагментацию по IX_CheckSum как с int-ом.

Да потому что кластерный индекс не может вылечить фрагментацию.
И некластерный. Её вообще ничего не вылечит.


Но все равно, имея кластерный индекс даже по PK с NewSequentialId() мне кажется такой хрени не должно было быть с планом.


Какой херни с планом, покажи уже...
12 фев 13, 14:58    [13914331]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
khourshed
Ну вот, все -таки меня сомнения терзали не напрасно. После нормальной утренней нагрузки в 50 тыс запросов фрагментация индекса IX_CHECKSUM 98% при кластерном int-е

План запроса:
  |--Compute Scalar(DEFINE:([Expr1004]=isnull([ViewCacheDb].[dbo].[cms_tblViewCache].[INSTANCE_STATE_ID],{guid'B01ADD9F-F2DA-4ED8-AAE5-373A8B3EB4B7'})))
|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [ViewCacheDb].[dbo].[cms_tblViewCache].[ID]))
|--Index Seek(OBJECT:([ViewCacheDb].[dbo].[cms_tblViewCache].[IX_CheckSum]), SEEK:([ViewCacheDb].[dbo].[cms_tblViewCache].[WEBPROJECT_COMPONENT_ID]=[@pWebProjectId] AND [ViewCacheDb].[dbo].[cms_tblViewCache].[CHECK_SUM]=[@pCheckSum]) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([ViewCacheDb].[dbo].[cms_tblViewCache].[IX_cms_tblViewCache_Id]), SEEK:([ViewCacheDb].[dbo].[cms_tblViewCache].[ID]=[ViewCacheDb].[dbo].[cms_tblViewCache].[ID] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)

Состояние индекса:
fill_factornametablenameleaf_insert_countleaf_delete_countleaf_update_countleaf_allocation_countnonleaf_allocation_countrange_scan_countsingleton_lookup_countrow_lock_countrow_lock_wait_countrow_lock_wait_in_ms
80IX_CheckSumcms_tblViewCache546050069830270228110610115


Кластерный инт проблему не решил. Причем по другим индексам фрагментация осталась маленькой. Только IX_CheckSum затронуло. Производительность стала заметно хуже.



Нормальный план...
12 фев 13, 15:00    [13914348]     Ответить | Цитировать Сообщить модератору
 Re: Фрагментация индекса  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
khourshed , подвожу промежуточный итог:

  • О создании кластерного индекса забудь пока. С вариантами кластерный/некластерный и по каким полям не играйся.
  • забудь про фрагментацию. Забудь вообще такое слово. Фрагментацию обычно удаляют DBA, когда им делать нечего, но у них руки чешутся что-то сделать.
  • дай тормозящий запрос и его планы, когда запрос тормозит, и когда не тормозит.
  • Вместе с планами -- сколько записей вообще в таблице на момент, и сколько подходит по условию в where, если это более одной записи.
  • 12 фев 13, 15:05    [13914396]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    khourshed
    Member

    Откуда:
    Сообщений: 93
    MasterZiv,

    О создании кластерного индекса забудь пока. С вариантами кластерный/некластерный и по каким полям не играйся.
    забудь про фрагментацию. Забудь вообще такое слово. Фрагментацию обычно удаляют DBA, когда им делать нечего, но у них руки чешутся что-то сделать.
    дай тормозящий запрос и его планы, когда запрос тормозит, и когда не тормозит.
    Вместе с планами -- сколько записей вообще в таблице на момент, и сколько подходит по условию в where, если это более одной записи.
    


    Запись !всегда! одна возвращается. пара WEBPROJECT_COMPONENT_ID, CHECK_SUM уникальна. индекс уникальный.

    Сейчас записей 211,376 база расти будет еще два-три дня.

    Думаю надо дождаться полного заполнения и уже плясать от полной базы. Думаю нужно действительно начать плясать от тормозящих запросов и анализа их планов. Вернусь к теме через -2-3 дня, когда база побольше станет.

    Большое спасибо всем кто помогал.
    12 фев 13, 15:18    [13914502]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Ennor Tiegael
    Member

    Откуда:
    Сообщений: 3422
    khourshed,

    Судя по avg_fragmentation_in_percent = 0.304878049 на листовом уровне, вы его недавно перестраивали. Потому что три десятых процента - это не фрагментация. Ждите, когда начнет тормозить, и тогда снимайте статистику.

    И да, присоединяюсь к Crimean - сравните профайлером CPU и reads для быстрого и медленного выполнения. Может, мы все это время не там копаем.
    12 фев 13, 15:19    [13914511]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    khourshed
    Member

    Откуда:
    Сообщений: 93
    Ennor Tiegael,

    ok, спасибо
    12 фев 13, 15:28    [13914589]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Crimean
    Member

    Откуда:
    Сообщений: 13147
    Ennor Tiegael
    сравните профайлером CPU и reads для быстрого и медленного выполнения. Может, мы все это время не там копаем.


    и durations! если будут сохранены cpu, reads но подскочат durations - это укажет на совершенно другую проблему

    p.s.

    насчет "уникальности" - безусловно. но это не помешает оптимизатору поднять с диска "кучу мусора" для выполнения
    как бы глупо это не звучало, но, судя по обсуждению, проблема на текущий момент не из очевидных и не хочется убежать в сторону
    впрочем, данные профайлера это легко покажут
    12 фев 13, 16:49    [13915299]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 34705
    Crimean
    насчет "уникальности" - безусловно. но это не помешает оптимизатору поднять с диска "кучу мусора" для выполнения
    как бы глупо это не звучало, но, судя по обсуждению, проблема на текущий момент не из очевидных и не хочется убежать в сторону
    впрочем, данные профайлера это легко покажут


    Ребята, если у него все запросы точечные, то какой вообще мусор и почему ему фрагментация должна мешать ?

    Вообще тут ни при чём фрагментация, и кластерный индекс ни при чём.
    12 фев 13, 17:47    [13915767]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Crimean
    Member

    Откуда:
    Сообщений: 13147
    MasterZiv
    если у него все запросы точечные, то какой вообще мусор и почему ему фрагментация должна мешать ?

    Вообще тут ни при чём фрагментация, и кластерный индекс ни при чём.


    есть небольшой шанс. из-за букмарка. был бы индекс покрывающим для запроса - вопрос бы снялся
    в любом случае я пока склонен просто дождаться данных профайлера
    12 фев 13, 17:52    [13915808]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Crimean
    Member

    Откуда:
    Сообщений: 13147
    собрал модельку. табличка + индексы как описано + 0.5 ляма данных с достаточно дурацкими распределениями по WEBPROJECT_COMPONENT_ID
    план стабильный даже если совсем таблицу "разбарабанить" (до ФФ = 2%)
    "обмануть" оптимизатор и заставить его сканить - не очень получилось
    таки ждем данных профайлера
    12 фев 13, 19:06    [13916151]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Mikebond
    Member

    Откуда: Киев
    Сообщений: 32
    Исходя из своего опыта, могу сказать что при торможении пары "seek" + "Lookup", помогало добавление <полей которые возвращает лукап> в <include fields> индекса по которому происходит "seek". Причем на плане в профайлере этих тормозов, как правило, не видно.

    Цена попытки - время на перестроение индекса с инклудами + если не поможет,то время на <вернуть все на место>

    Мне помогало...

    Удачи!
    12 фев 13, 21:10    [13916651]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Mind
    Member

    Откуда: Лучший город на Земле
    Сообщений: 2322
    MasterZiv
    Ребята, если у него все запросы точечные, то какой вообще мусор и почему ему фрагментация должна мешать ?
    Вообще тут ни при чём фрагментация, и кластерный индекс ни при чём.
    +1
    Фрагментация оказывает ну очень минимальное воздействие на запросы с seek+lookup. Так что как тут уже советовали перестаньте искать проблемы там где их нет.

    Может тут вообще другие причины. Как предположение:
    Таблица вырастает до 12 ГБ, памяти мало, дисковая медленная, как следствие кэша не хватает чтобы всю таблицу держать в памяти, и каждый точечный запрос лезет на диск, а запросов в секунду очень много + еще и LOBы, вот и тормоза. Сложно правда тогда объяснить прирост производительности после дефрагментации. Может быть весь кэш вообще вымывается одной этой таблицей и все становится быстрее на какое то время?

    Короче, посмотрите нагрузку на память и диски, ну а также CPU, в моменты когда все плохо. Ну и заодно гляньте на топ самых тяжелых запросов по CPU и чтениям.
    13 фев 13, 02:36    [13917647]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Crimean
    Member

    Откуда:
    Сообщений: 13147
    просто для информации

    на модельке я доводил до ляма записей в указанной структуре с ФФ 2% (!)
    никаких проблем создать не смог. хотя старался
    13 фев 13, 13:47    [13920128]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    LenaV
    Member

    Откуда: USA
    Сообщений: 6796
    хорошо бы еще посмотреть wait type медленных запросов.
    13 фев 13, 20:52    [13922906]     Ответить | Цитировать Сообщить модератору
    Между сообщениями интервал более 1 года.
     Re: Фрагментация индекса  [new]
    dark_DBa_dmin
    Member

    Откуда:
    Сообщений: 105
    Решил не плодить темы, и поднять эту. Проблема такая же, но решения в теме так и не было.
    SQL 2008 R2.
    Есть запрос вида select c1, c2, c3... from table join -- on -- join - on -- join -- on -- where c1='value', c2='value' ... order by c1,c2,c3 desc
    В общем обычный запрос возвращающий данные о конкретном человеке с join к различным справочником, результат иногда, но оооочень редко может быть не одна строка (если были корректировки по этому человеку то это еще одна строка, именно для этого и нужен order by, чтобы выбрать последнию актуальную запись по этому человеку), но в 99% строка одна.
    Запрос работает с 4 таблицами, все не кучи, все предикаты поддерживаются индексом, и в идеале запрос выполняется меньше секунды, но буквально через пару часов начинает выполняться 15-20 секунд. Фрагментация индексов в которых храняться ФИО, ИНН и т.д. подлетает с нуля до сотни, profiler показывает для этого запроса (CPU - 13000, reads 3000000), перестраиваю все индексы время выполнения опять нормальное profiler показывает (CPU - 50, reads 150), через пару часов история повторяется.
    План запроса для "плохого" и "хорошого" запроса полностью одинаковый, даже предполагаемая стоимость.
    Таблица постоянно обновляется, за 6 минут кол-во записей прыгало в районе 200 000 (всего 3 000 000), а кол-во страниц в индексе с 14 500 увеличилось до 15 500.
    1 мар 16, 11:43    [18881338]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    AlanDenton
    Member [скрыт]

    Откуда:
    Сообщений: 1004
    Ни структуры таблиц, ни плана выполнения... о чем можно говорить? Статистику смотрели? Ожидания какие?
    1 мар 16, 11:46    [18881359]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    dark_DBa_dmin
    Member

    Откуда:
    Сообщений: 105
    AlanDenton
    Ни структуры таблиц, ни плана выполнения... о чем можно говорить? Статистику смотрели? Ожидания какие?


    Да я просто не могу план выложить, инет через терминал, буфер не сквозной, поэтому тока так :(
    Статистика пересчитана.
    1 мар 16, 11:47    [18881372]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    Владислав Колосов
    Member

    Откуда:
    Сообщений: 8821
    dark_DBa_dmin,

    автор
    Таблица постоянно обновляется

    От этого тормоза, а не от индексов.
    1 мар 16, 11:53    [18881400]     Ответить | Цитировать Сообщить модератору
     Re: Фрагментация индекса  [new]
    dark_DBa_dmin
    Member

    Откуда:
    Сообщений: 105
    Владислав Колосов
    dark_DBa_dmin,

    автор
    Таблица постоянно обновляется

    От этого тормоза, а не от индексов.


    И как это влияет?
    1 мар 16, 11:56    [18881420]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить