Souhlas s Marcem a Neznámým výše... 6 indexů v seskupeném indexu je příliš mnoho, zvláště v tabulce, která má pouze 14 sloupců. Neměli byste mít více než 3 nebo 4, pokud ano, řekl bych 1 nebo možná 2. Možná víte, že seskupený index je skutečná tabulka na disku, takže když je vložen záznam, databázový stroj jej musí seřadit a umístěte jej na seřazené uspořádané místo na disku. Neklastrované indexy nejsou, podporují vyhledávací „tabulky“. Moje VLDB jsou rozmístěny na disku (CLUSTERED INDEX) podle 1. bodu níže.
- Snižte svůj seskupený index na 1 nebo 2. Nejlepšími volbami pole jsou IDENTITA (INT), pokud nějakou máte, nebo pole data, do kterého se pole přidávají do databáze, nebo jiné pole, které je přirozený způsob, jakým jsou vaše data přidávána do databáze. Jde o to, že se snažíte uchovat tato data na konci tabulky... nebo je mít rozložená na disku tím nejlepším (90%+) způsobem, jakým budete záznamy číst. Díky tomu nedochází k žádné reorganizaci nebo že je potřeba pouze jeden zásah, aby se data dostala na správné místo pro co nejlepší čtení. Ujistěte se, že jste odebraná pole vložili do indexů bez klastrů, abyste neztratili účinnost vyhledávání. NIKDY jsem na své VLDB nevložil více než 4 pole. Pokud máte pole, která se často aktualizují a jsou zahrnuta ve vašem seskupeném indexu, OUCH, dojde k reorganizaci záznamu na disku a NÁKLADNÉ fragmentaci.
- Zkontrolujte faktor plnění na svých indexech. Čím větší je číslo faktoru plnění (100), tím plnější budou datové stránky a stránky indexu. V závislosti na tom, kolik záznamů máte a kolik záznamů vkládáte, změníte fillfactor # (+ nebo -) vašich indexů bez klastrů, abyste povolili výplňový prostor při vkládání záznamu. Pokud změníte svůj seskupený index na sekvenční datové pole, nebude to na seskupeném indexu tolik záležet. Pravidlo palce (IMO), 60-70 faktor plnění pro vysoký zápis, 70-90 pro střední zápis a 90-100 pro vysoké čtení/nízký zápis. Snížením vašeho fillfactoru na 70 to bude znamenat, že na každých 100 záznamů na stránce se zapíše 70 záznamů, což ponechává volné místo 30 záznamů pro nové nebo reorganizované záznamy. Zabere více místa, ale rozhodně nepřekoná nutnost každou noc ODFRAGOVAT (viz 4 níže)
- Ujistěte se, že v tabulce existují statistiky. Pokud chcete zamést databázi a vytvořit statistiku pomocí "sp_createstats 'indexonly'", SQL Server vytvoří všechny statistiky na všech indexech, které stroj nashromáždil jako vyžadující statistiku. Nevynechávejte však atribut 'indexonly', jinak přidáte statistiky pro každé pole, to by pak nebylo dobré.
- Zkontrolujte tabulku/indexy pomocí DBCC SHOWCONTIG a zjistěte, které indexy jsou nejvíce fragmentovány. Nebudu zde zacházet do podrobností, jen vím, že to musíte udělat. Poté na základě těchto informací změňte faktor plnění nahoru nebo dolů ve vztahu ke změnám, které indexy zažívají, a jak rychle (v průběhu času).
- Nastavte plán úloh, který se bude provádět online (DBCC INDEXDEFRAG) nebo offline (DBCC DBREINDEX) na jednotlivých indexech a defragmentovat je. Varování:Nedělejte DBCC DBREINDEX na této velké tabulce, aniž by to bylo během údržby, protože to stáhne aplikace ... zejména na CLUSTERED INDEX. Byli jste varováni. Testujte a testujte tuto část.
- Pomocí prováděcích plánů zjistěte, co existují SKENOVÁNÍ a FAT PIPES, a upravte indexy, poté defragmentujte a přepište uložené procesy, abyste se těchto horkých míst zbavili. Pokud ve svém prováděcím plánu vidíte ČERVENÝ objekt, je to proto, že v tomto poli nejsou žádné statistiky. To je špatné. Tento krok je spíše „uměním než vědou“.
- Zapněte dobu mimo špičku a spusťte AKTUALIZACE STATISTIKY S FULLSCAN, abyste dotazovacímu modulu poskytli co nejvíce informací o distribucích dat. V opačném případě provádějte standardní AKTUALIZAČNÍ STATISTIKY (se standardním 10% skenováním) na stolech během týdne nebo častěji, jak uznáte za vhodné s vašimi pozorováními, abyste se ujistili, že motor bude mít více informací o distribucích dat, aby je mohl efektivně načíst.
Omlouvám se, že je to tak dlouhé, ale je to nesmírně důležité. Dal jsem vám sem jen minimum informací, ale hodně pomůžu. Existují určité vnitřní pocity a postřehy, které se týkají strategií používaných těmito body, které budou vyžadovat váš čas a testování.
Není třeba přecházet do edice Enterprise. Udělal jsem to však, abych získal funkce, o kterých jsme mluvili dříve s rozdělením. Ale udělal jsem PŘEDEVŠÍM proto, abych měl mnohem lepší možnosti vícevláknového zpracování s vyhledáváním a online DEFRAGOVÁNÍM a údržbou... V Enterprise edici je to mnohem lepší a přátelštější s VLDB. Standard edition nezvládá dělat DBCC INDEXDEFRAG také s online databázemi.