Ами ако сте се натоварили да внедрите или надстроите до нов SQL Server за по-добро изживяване за клиентите си — и те се оплакват, че нещата всъщност са по-лоши?
Няма ли да бъдете огорчени, ако скочите през всички тези бизнес и технически обръчи, за да постигнете по-добра производителност на SQL Server, и след това не го направите?
Може би трябваше да проведете някои тестове за производителност на SQL Server, преди да влезете в производството. Тогава щяхте да знаете дали представянето ви ще се подобри, ще остане същото или, най-лошото, ще спадне.
Но поне нямаше да бъдете неприятно изненадани.
Мостът за производителност на SQL Server, който всички преминаваме
Независимо дали става въпрос за превключване от друга база данни към SQL Server или надграждане от по-стара версия на SQL Server към по-нова, в крайна сметка трябваше да преминете моста за производителност.
„Наистина ли ще работи по-добре от преди?“ попита шефът ви.
„О, разбира се“, казахте. „С виртуализацията на данни в SQL Server 2019 можем да изпълняваме заявки без преместване или репликиране на данни. Има и автоматична настройка с Intelligence Query Processing за увеличаване на заявките. Данните ще излетят от сървърите." Бяхте толкова уверени, че написахте „FLY“ с главни букви.
И така, как бихте могли да тествате ефективността си по-добре?
4 начина за тестване на производителността. . .
Брент Озар, невероятен SQL Server maven, ви казва как да проверите производителността на нов SQL Server:
- лесният начин, сравняване на времето преди и след при пълно архивиране и CHECKDB
- лесният, но грешен начин, със синтетично натоварване и TPC-C в HammerDB
- по-трудният начин, тестване на отделни заявки със sp_BlitzCache, неговия скрипт за анализ на кеша на плана
- наистина трудният начин, изпълнявайки същите заявки, които изпълнявате в производството
Но както Брент пояснява, наблюдението на производителността на вашия SQL сървър и установяването, че тя е спаднала с X процента е само началото; все още трябва да разберете откъде идва ударът.
Това означава да търсите тенденции в данните за ефективността през цели седмици и месеци, а не само през последните няколко часа.
Колкото повече точки от данни и история имате, толкова по-добра картина можете да съберете за това какво се случва вътре, под и около вашата среда на SQL Server.
И колкото повече изчисления можете да хвърлите на всички тези данни, толкова по-бързо можете да ги анализирате.
Мониторинг на производителността на SQL Server:Звучи като работа за облака
да. Това е работа за облака, единственото място, където можете да мащабирате достатъчно, за да събирате и анализирате всички тези данни за широка, дълбока картина на това как SQL Server изразходва ресурси. И как е изразходвал тези ресурси с течение на времето. Например:
- В определени часове от деня или месеца често изпълняваните заявки трябва да четат от диск, вместо от буферния кеш, който е копие в паметта на наскоро използвани страници от база данни. Трябва ли да разпределите повече памет за вашия буферен кеш? Можете ли да отделите още памет за него?
- Същото за продължителността на живота на страницата. Ако е ниско, това вероятно е, защото SQL Server изхвърля страниците от буферния кеш твърде често и трябва да изпълнява търсения от хранилище, вместо от памет. Това пречи на производителността.
- Максималното време за изчакване за вход/изход става ли твърде голямо? Как е в тенденция? Това е намек, че I/O устройството може да е наситено.
- Колко време е опашката на процесора сега? Колко време е обикновено? Твърде много нишки, които постоянно чакат, могат да показват претоварване на процесора.
- ЦП работи ли спрямо ограниченията, които сървърът ви може да поеме? Ами ако вече не можете да мащабирате сървъра? Ако сте сигурни, че вашите заявки са добре настроени и другите ви системни ресурси са достатъчни, може да се наложи да добавите сокет за физически хардуер или vCPU към вашите виртуални машини.
- Фрагментираните индекси са бавни индекси, но вие не знаете, че те са виновникът, докато не проверите нивата на фрагментация. Виждането на ефектите от реорганизирането и възстановяването с течение на времето може да ви помогне да поставите надежден процес на поддръжка на индекса.
Намирането на проблеми като тези във всички ваши локални и облачни бази данни става по-лесно и по-бързо, когато можете да наблюдавате производителността на вашия SQL сървър от облака. Най-хубавото е, че можете да наблюдавате от всяко място в известната галактика, когато всички изчисления, съхранение и анализ са в облака и сте само на няколко щраквания във всеки браузър.
Започнете да тествате производителността на SQL Server в облака
В Quest никой не трябва да ни казва два пъти, че нашите клиенти искат облачни инструменти, независимо дали за миграция в облак, мониторинг на производителността или Office 365. Ние правим повече от нашите продукти достъпни като облачни предложения, защото технологиите и пазарите ги дърпат там.
И така, как провеждате тестване на производителността на вашите нови или надстроени SQL сървъри?
- Изпълнявам CHECKDB.
- Пускам HammerDB.
- Изпълнявам инструментите на Brent Ozar.
- Тествам с производствени натоварвания.
- Хвърлям заровете и чакам, докато потребителите се оплакват.
- Имам хора, които правят това вместо мен.
- Използвам Spotlight Cloud от Quest. Вие също трябва.
