Десетте най - добри проблеми с производителността на SQL Server 2005 за приложения за съхранение на данни и
Релационното съхранение на данни или натоварването с отчитане са малки и много големи транзакции. Тези приложения често са склонни да се възползват от натоварвания за четене (като приложения за подкрепа на решения, анализи и отчитане) с периодични изходи или групови изтегляния. Важно е да се имат предвид тези съображения, когато се разглежда значението на дизайна на базата данни, използването на ресурсите и производителността на системата. По-долу са критични тесни места за изпълнение или проблеми, които трябва да се избягват при изграждането и поддържането на хранилища за данни и приложения за отчитане.
Проблеми с дизайна на базата данни, ако ....
Извършват се излишни операции за сортиране. Ако е необходимо да се извършват едни и същи операции за сортиране отново и отново, тогава това може да се избегне, като се използват подходящите индекси.
Прекомерните относителни замествания на ID се извършват на неподредени таблици. Заместванията на самоличността означават, че са необходими допълнителни I/O за извличане на колони, които не са включени в използвания индекс. Това може да се избегне, като се използват неклъстерирани индекси, включени в обединението.
Намирането на ключ чрез клъстериране на ключ е подобно на присъединяването, но в XML Showplan това се нарича "търсене". Това може да се избегне, като се използват неклъстерирани индекси, включени в обединението.
Няма потенциално полезен индекс за колоните, участващи в съединението, което води до хеширано съединение. Можете да избегнете HASH JOINs, като създадете индекси в колоните за присъединяване.
Проблеми с използването на процесора ....
Ако сигналните изчаквания са> 25% от общото изчакване, тогава процесорът е пречка. Вижте динамичен изглед sys.dm_os_wait_stats за изчакванията на сигнала и общите изчаквания. Сигналът чака чака измерва времето, прекарано в опашката за изпълнение в очакване на процесора. Силно изчакване на сигнал показва затруднение на процесора.
Избягвайте ненужното повторно използване на плана. Повторното използване на плана за заявки е добро, ако заявката е идентична. Обаче параметризирането на заявка, за да позволи повторно използване на плана, има смисъл само ако резултатът от заявката (и междинните работни таблици) е същият като в първоначалния план. Ако размерът на набора от резултати се промени значително въз основа на различни стойности на параметрите, което е типично за хранилищата с данни, повторното използване на плана може да доведе до лоши резултати. Неподходящият план за заявка може също да доведе до по-дълго време за изпълнение на заявката и увеличено натоварване на паметта или I/O. Следователно в такива случаи цената за създаване на план е за предпочитане пред повторното му използване. За разлика от приложенията за бази данни на OLTP, заявки за хранилище на данни не винаги идентични по отношение на набори от резултати или оптимални планове за изпълнение.
Тесно място в подсистемата памет ....
Драматичен значителен спад в продължителността на живота на страницата. Складовите приложения (като големи транзакции) могат да претърпят значително намаляване на продължителността на живота на страниците. Това се дължи на голямо изчистване на кеш паметта. Вижте обекта на монитора за ефективност на SQL Server Buffer Manager.
Изчакващи заявки за предоставяне на памет. Вижте обекта Performance Monitor SQL Server Memory Manager в очакване на броя на заявките. Разпределението на големи количества памет е типично за приложенията за съхранение на данни. Добавянето на памет може да подобри ситуацията, в противен случай изпълнението не е възможно преди да се извърши разпределението на паметта.
Производителността на SQL кеша неочаквано или постоянно намалява. Капки или постоянно ниски нива на производителност на кеша могат да показват ниска памет или липсващи индекси.