Need to dusscuss: Maximizing SQL Server Performance Through Defragmentation

BugsBunny

Hi All,prehistory: application vendor is trying to resolve performance problems and instead of looking at its own sql code brought this one to light:Maximizing SQL Server Performance Through DefragmentationThough it was proven to vendor that it's not the case (almost no fragmentation on app.db, tempdb and pagefile.sys), this particular thought crossed my mind several times before...given:-storage on HP SAN (relative only if there are some additional "low-level" defragmentation considerations, like here : "...но нужно выполнять reallocate раз в день..." which apparently is not that evident)-no scheduled downtime for maintence other than reboots after applying service packs (means that I can not stop server and copy datafiles back and forth to kill fragmentation)question:-has anyone seriously looked into that (situation of 5MB autoincreament for TB database doesn't count)?-did see any improvements?-what online defragmentation tools are used and(or) (not) recommended?Thanks in advance.
8 ответов

BugsBunny

up


BugsBunny

не работаем с подобным оборудованиемну и объемы у нас пока еще до терабайтов :)p.s.лучше все же дополнить вопрос переводом... кмк...


BugsBunny

не работаем с подобным оборудованием...
As I said, SAN was mentioned just in case if there is some specifics (which I'm not aware of since i'm not even allowed close to the SAN - I have to believe our sysadmins but "доверяй, но проверяй")
...ну и объемы у нас пока еще до терабайтов :)...
It not about the size either, it's about fragmentation: 1GB database might be more fragmented than the 1TB one or be more affected by one. BTW, fragmentation aside, I'm having more problems currently with in-house developed 130MB/20 users application than 1TB/500 users SAP's one. :(In a nutshell, a lot of "smart" ideas ranging from custom generated sequence numbers to dynamic sql. "Students" would be really proud :)
p.s.лучше все же дополнить вопрос переводом... кмк...
sorry... can not help hereOK, my personal opinion on that is unless one is a complete "SQL moron" (like 5MB increaments for fast-growing database) fragmentation shouldn't be a that big issue and possible defrag-related improvement should be estimated in more moderate numbers maxing aroung 10% (like mentioned here:EVA defragmentation)


BugsBunny

Файловая фрагментация - это беда бедных Если брать за пример системы, используемые в TPC, заметно, что файлы данных там лежат на RAW. Т.е. одним выстрелом убивают сразу двух зайцев ;)Сама же фрагментация мешает, если чтения не логические, т.е. у сервера мало памяти... Однако, можно обойтись и без RAW, если под каждый файл выделить свою партицию.С чем действительно согласен, так это с тем, что прирост производительности не будет сооразмерим с оптимизацией схемы и запросов :)


BugsBunny

Сама же фрагментация мешает, если чтения не логические, т.е. у сервера мало памяти...
Странноватая фраза, в приличной БД всегда присутствует некоторая доля физического чтения и это не показатель недостаточности памяти.2 BugsBunnyЕстественно, в теории фрагментация должна сказываться на производительности СУБД, хотя бы за счет того, что активно мешает эффективной работе механизмов prefetch самой СУБД и read-ahead контроллера дискового массива. На практике, никогда не боролся с дефрагментацией, потому-что, предвидя подобную проблему, всегда задавал файлам БД при создании заведомо большой размер, покрывающий рост БД на 2-3 года вперед. Насчет бОльшего прироста от оптимизации запросов также согласен.


BugsBunny

У меня база данных ~6 Гб, прямо сейчас с ней соединено ~600 пользователей. OLTP. База лежит на EMC CX300. 500 Мб write cache, остальное - около 70 Мб - read cache. Дефрагментация (dbcc dbreindex) производится регулярно. На дисках с данными и логом других файлов нет. Т.е. лог находится на своем LUN состоящем из физических дисков, данные - на другом LUN с другими дисками, и т.п. Эффект фрагментации тем не менее наблюдаю. Раз в несколько месяцев создается новая база с такой же схемой, туда DTS переливает данные из старой базы. После этого заметно улучшение производительности. Улучшение есть, но не очень значительное. Когда еще не было SAN - эффект был большой.


BugsBunny

Странноватая фраза, в приличной БД всегда присутствует некоторая доля физического чтения и это не показатель недостаточности памяти.
Разумеется, речь шла о превышении нормы физических чтений :) Простите, что не точно выразился...


BugsBunny

thanks everyone responded.nothing unexpected has been said:"Однако, можно обойтись и без RAW, если под каждый файл выделить свою партицию. " (Александр Гладченко ) is what we're usually trying to do for very big databases"заведомо большой размер, покрывающий рост БД на 2-3 года вперед" (WiRuc) - for other daitabases. It might not play well for VLDB due to initial cost"Раз в несколько месяцев создается новая база с такой же схемой, туда DTS переливает данные из старой базы." (andsm) - for 6GB db I would rather go with WiRuc approach, besides it's not a 24x7 approach and it might help with logical fragmentation but not a physical one.Thanks again.