От персонала на Техопедия, 19 април 2017 г.
Отнемане: Домакинът Ерик Кавана обсъжда прогнозите с д-р Робин Блур, Рик Шърман и Bullett Manale от IDERA.
Трябва да се регистрирате за това събитие, за да видите видеоклипа. Регистрирайте се, за да видите видеото.
Ерик Кавана: Дами и господа, привет още веднъж и добре дошли в сериала на Hot Technologies в мрежата! Казвам се Ерик Кавана, ще ви бъда домакин на днешния уеб семинар, наречен „Спестяване на време, пари и проблеми с оптимални прогнози.“ „Курсът пропуснах първата част от заглавието там, „ Най-добрите планове за планове “. винаги говорете за това в това предаване. И така, Hot Technologies, разбира се, е нашият форум за разбиране на това, какви са някои от готините продукти в света днес, светът на корпоративните технологии, какво правят хората с тях, как работят, всички подобни забавни неща.
И темата днес, както предполагам, се занимава с прогнозиране. Наистина се опитвате да разберете какво ще се случва във вашата организация. Как ще зарадвате потребителите си, независимо какво правят? Ако правят анализ, ако вършат реална работа, те се сблъскват с реални клиенти с транзакционни системи, какъвто и да е случаят, искате да разберете как вашите системи работят и какво се случва, и това е, което ние ' ще говоря днес. Това е нещо смешно, защото прогнозирането не е нещо, което обичам да правя, защото съм суеверен, както мисля, че ако прогнозирам твърде много, ще се случат лоши неща, но това съм само аз. Не следвайте моето ръководство.
Ето, тук са нашите презентатори днес, вашите наистина в горния ляв ъгъл, Рик Шърман набира от Бостън, приятелят ни Bullett Manale от IDERA и самият ни д-р Робин Блур. И с това ще го предам на Робин и само напомням на хората: Задавайте въпроси, не се срамувайте, обичаме добри въпроси, днес ще ги изпратим на нашите водещи и други. И с това, Робин, отнеси го.
Робин Блур: Добре, добре, тъй като аз съм в полевата позиция, както се казва, мислех, че днес ще разкажа SQL история, защото това е фонът за това, което ще продължи дискусията и неминуемо няма да се сблъска с защото Рик не се фокусира върху това и няма да се сблъска с това, което Рик има да каже. Така че, SQL историята, има някои интересни неща за SQL, защото тя е толкова доминираща. Вижте, това е печатна грешка, SQL е декларативен език. Идеята беше, че можете да създадете език, на който да поискате това, което искате. И базата данни щеше да разбере как да го получи. И всъщност е разработено доста добре, но има редица неща, които си струва да се каже за това, последствията от основаването на цялата ИТ индустрия на декларативен език. Потребителят не знае или не се интересува от физическата организация на данните и това е хубавото на декларативния език - той ви отделя от всичко това и дори се притеснявате от него - просто поискайте каквото искате и базата данни ще отиде и ще го вземе.
Но потребителят няма представа дали начинът, по който структурира SQL заявката, ще повлияе на производителността на заявката и това е малко недостатък. Виждал съм заявки, дълги стотици и стотици редове, които са само една SQL заявка, знаете, започва с „select“ и просто продължава и продължава с под-заявки и така нататък и така нататък. И всъщност се оказва, че ако искате определена колекция от данни от база данни, можете да поискате от нея по много различни начини с SQL и да получите същия отговор, ако имате някакво запознаване с данните. Така че една SQL заявка не е непременно най-добрият начин да поискате данни и базите данни ще отговорят съвсем различно според SQL, който сте поставили в тях.
И така, SQL всъщност влияе на производителността, така че хората, които използват SQL, това е вярно за тях, вярно е и за SQL програмистите, които използват SQL, и те са още по-малко вероятно да мислят за въздействието, което ще имат, защото по-голямата част от фокуса им е всъщност върху манипулирането на данни, а не върху получаването и поставянето на данни. Същото се отнася и за BI инструментите, виждах SQL, който, ако желаете, изтръгва от BI инструменти на различни бази данни и трябва да се каже, че много от това е, добре, не бих искал ' не пиша SQL заявки по този начин. Някой е създал, ако искате, малко моторче, че каквито и да са параметрите, той ще изхвърли SQL и отново, че SQL не е задължително да е ефективен SQL.
Тогава реших, че ще спомена несъответствието на импеданса, данните, които програмистите използват, са различни от данните, докато се сортират. Така че, DMS съхранява данни в таблици, организираният обектно-ориентиран код са предимно кодери, в днешно време програмират обектно-ориентирана форма и те подреждат данни в структурите на обектите, така че не преобразува една в друга. Така че, е необходимо да се преведе от това, което програмистът смята, че данните са тези, които базата данни мисли какви са данните. Което изглежда, че трябва да сме направили нещо нередно, за да е така. SQL има DDL за дефиниране на данни, има DML - език за обработка на данни - изберете, проектирайте и се присъединете, за получаване на тези данни. Сега има много малко математика и много малко неща, базирани на времето, така че това е несъвършеният език, въпреки че трябва да се каже, че е удължен и продължава да се разширява.
И тогава получавате проблема със SQL бариерата, който винаги е по-прав от диаграмата, тъй като много хора задаваха въпроси по аналитични причини, след като получат отговора на условията за данни на въпроса, искат да зададат друг въпрос. Така че, това се превръща в нещо диалогово, добре, SQL не е бил изграден за диалози, а е бил създаден да пита какво искате всички наведнъж. И някак си струва да знаете това, защото има някои продукти, които всъщност изоставят SQL, за да направят възможно разговора между потребителя и данните.
По отношение на ефективността на базата данни - и този вид се разпространява във всичко - да, има процесор, има памет, има диск, има мрежови режийни разходи и има проблем със заключването на повече от един човек, който иска да използва изключително данните в даден момент точка във времето. Но има и лоши SQL обаждания, има страшно много, което може да се направи, ако всъщност оптимизирате SQL по отношение на производителността. И така, фактори за изпълнение на базата данни: лош дизайн, лош дизайн на програма, съвпадение на натоварването липсва, балансиране на натоварването, структура на заявките, планиране на капацитета. Това е ръст на данните. И с няколко думи SQL е удобен, но не се самооптимизира.
Като каза това, мисля, че можем да предадем на Рик.
Ерик Кавана: Добре, Рик, да ти дам ключовете от колата на WebEx. Отнеси го.
Рик Шерман: Добре, страхотно. Ами благодаря Робин, тъй като започнахме в началото на презентацията, графиката ми все още е доста скучна, но ще продължим с нея. Така че, аз съм съгласен с всичко, за което Робин говори от страна на SQL. Но това, върху което сега искам да се съсредоточа малко, е търсенето на данни, което ще преминем много бързо, предлагането както в инструментите, използвани в това пространство, или нуждата от инструментите в това пространство.
Първо, във всяка статия, която четете, има нещо, свързано с големи данни, много данни, неструктурирани данни, идващи от облака, големи данни навсякъде, които можете да си представите. Но растежът на пазара на база данни непрекъснато се наблюдава при SQL, релационна база данни вероятно от 2015 г., все още е 95 процента от пазара на база данни. Първите три продавачи на релации имат около 88 процента от пазарния дял в това пространство. И така, все още говорим, както Робин говори, за SQL. И всъщност, дори ако търсим платформата Hadoop, Hive and Spark SQL - която синът ми, който е учен по данни, използва през цялото време - със сигурност е доминиращият начин хората да стигнат до данните.
Сега от страна на базата данни има две широки категории на използване на бази данни. Единият е за оперативни системи за управление на бази данни, така че планиране на взаимоотношенията между предприятията, управление на взаимоотношенията с клиентите, ERPs на Salesforce, Oracles, EPIC, N4s и т.н., на света. И това, има голямо количество и разширяващо се количество данни, които се намират в хранилища на данни и други системи, базирани на бизнес разузнаване. „Защото всичко, независимо от това къде и как е заснето, съхранявано или осъществявано транзакции, в крайна сметка се анализира и затова има огромно търсене и увеличаване на използването на бази данни, особено релационни бази данни на пазара.
Сега, ние имаме търсенето, имаме огромни количества данни. И всъщност не говоря само за големи данни, говоря за използването на данни във всички видове предприятия. Но ако придружим това, че от страна на предлагането, за хората, които могат да управляват тези ресурси, първо трябва да имаме някакъв недостиг на DBA. Според Бюрото по трудова статистика от 2014–2024 г. работните места на DBA ще нарастват само с 11 процента - сега това са хора, които имат DBA длъжности, но ще говорим за това на секунда - срещу 40- плюс процент от годишното пространство за растеж на данните. И имаме много DBA; средно същото проучване говори за средната възраст е доста висока в сравнение с други ИТ професии. И тогава имаме много хора, които напускат терена, като не е задължително да се пенсионират, а да се прехвърлят в други аспекти, да преминат в управление или каквото и да е.
Сега част от причината да напуснат е, че работата на DBA продължава да става все по-трудна и по-трудна. Първо, ние имаме DBA, които сами управляват много различни бази данни, физически бази данни, разположени навсякъде, както и различни видове бази данни. Това може да е релационно или може да е друга база данни, типове база данни също. Но дори и да е релационно, те биха могли да имат всеки един, два, три, четири различни доставчици, които всъщност се опитват да управляват. DBA обикновено се включват след проектирането на базата данни или приложението. Робин говори за това как се проектират бази данни или приложения, как се проектира SQL. Е, когато говорим за моделиране на данни, ER моделиране, разширено ER моделиране, моделиране на размери, усъвършенствано моделиране на модела, каквото и да е, обикновено приложни програмисти и разработчици на приложения проектират с тяхната крайна цел - те не проектират за ефективността на самата структура на базата данни. Така че имаме много лош дизайн.
Сега не говоря за доставчиците на приложения за търговски предприятия; обикновено имат ER модели или разширени ER модели. Това, за което говоря е, че има много повече бизнес процеси и приложения, които се изграждат от разработчиците на приложения във всяка компания - тези не са непременно проектирани за ефективност или ефективност на внедряването. А самите DBA са преуморени и понякога носят 24/7 отговорност, те продължават да получават все повече и повече бази данни. Мисля, че това малко се е случило с това, че хората не разбират съвсем точно какво правят или как го правят. Тяхната малка група и хората просто продължават да мислят: „Ами всички тези инструменти са толкова лесни за използване, можем просто да продължаваме да хвърляме все повече и повече бази данни за натовареността им“, което не е така.
Което ни води до непълно работно време и случайни DBA. Имаме ИТ екипи, които са малки и те не могат непременно да си позволят специален DBA. Сега това важи за малкия и средния бизнес, където разширяването на приложенията за бази данни и бази данни е избухнало през последното десетилетие и продължава да се разраства. Но това е и при големите корпорации, които обикновено отдавна съхраняват данни, анализират бизнес анализа. Преди много време използвахме специални DBA за тези проекти; никога повече не получаваме посветен DBA. Ние сме отговорни за проектирането на базата данни, което е добре, ако е някой, който има опит. Но като цяло DBA са разработчици на приложения, те често поемат тази роля като част от работната си част, те нямат официално обучение в нея и отново, проектират я за своите крайни цели, те са не го проектирайте за ефективност.
И има голяма разлика между дизайна и разработката, спрямо внедряването и управлението. Така че, ние имаме "пени мъдър, лири глупав", с малко прасенце там, прескачайки да получим необходимите умения и ресурси в проектите. Мислейки, че всички са от „Отмъщение на нервите“, моята малка снимка там. Сега, що се отнася до това, от което хората се нуждаят, затова имаме разширяващо се използване на бази данни и данни в SQL. Ние имаме ограничен брой DBAs - хора, които са квалифицирани и експертни в тези настройки и проектиране, управление и разполагане на ситуации. И ние имаме все повече и повече на непълно работно време или случайни DBAs, хора, които не са били официално обучение.
И така, кои са някои от другите неща, които също навлизат във въпроса за това, че тези бази данни също не се настройват или не се управляват? Първо, много хора приемат, че самата система от бази данни разполага с достатъчно инструменти, за да се управлява. Сега инструментите стават все по-лесни и по-лесни за правене - проектиране и разработка - но това е различно от правилното проектиране и доброто управление, планирането на капацитета, мониторинга и т.н. за внедряване. Така че, първо, хората приемат, че разполагат с всички необходими инструменти. Второ, ако сте непълно работно време или случайно DBA, не знаете какво не знаете.
Предполагам, че съм забравил някои от изразите там, така че много пъти просто не разбират какво дори трябва да разгледат в дизайна или когато управляват или работят с базите данни. Ако това не е вашата професия, тогава няма да разберете какво трябва да направите. Трето, е, че SQL е идеален инструмент, така че Робин говори за SQL и колко лошо SQL понякога е конструиран или често е конструиран. И също така един от моите любимци наднича в съхранението на BI данни, миграцията на данни, пространството за инженеринг на данни е, че вместо да използват инструменти, хората имат склонност да пишат SQL код, съхранявани процедури, дори ако използват скъп инструмент за интегриране на данни или скъп инструмент за BI, те често го използват просто за стартиране на съхранени процедури. Така че значението на разбирането на дизайна на база данни, на изграждането на SQL, става все по-важно.
И най-накрая има този силозен подход, при който отделните хора разглеждат отделни бази данни. Те не гледат как работят приложенията и си взаимодействат помежду си. Те също така наистина често разглеждат базите данни спрямо приложенията, за които ги използват. И така, натовареността, която получавате в базата данни, е от съществено значение за дизайна, критична за настройката й, критична за опит да разберете как да планирате капацитет и т.н. Така че, гледайки гората от дърветата, хората са в плевелите, разглеждайки отделните таблици и бази данни и не разглеждайки цялостното взаимодействие на тези приложения в работното натоварване.
И накрая, хората трябва да разгледат ключовите области, които трябва да разгледат. Когато планират да управляват бази данни, те първо трябва да помислят за, да разработят някои показатели за ефективност, ориентирани към приложението, така че те трябва да разгледат не само как е структурирана тази таблица, как тя е особено моделирана, но как се използва? Така че, ако имате корпоративно приложение, което се дължи в управлението на веригата за доставки, ако приемате поръчки извън мрежата, ако правите BI - каквото и да правите - трябва да погледнете кой го използва, как работят използвайки го, какви са обемите на данни, когато това ще се случи. Това, което наистина се опитвате да търсите, са времената на чакане, защото независимо от всичко, всички приложения се преценяват по колко време отнема да се свърши нещо, независимо дали става въпрос за човек или просто за обмен на данни между приложения или процесори. И какви са тесните места? Така че често, когато се опитвате да отстранявате грешки, разбира се, наистина се опитвате да погледнете какви са истинските тесни места - не непременно как да настроите всичко, но как да се отървете и да преместите производителността до времето за изчакване и производителност - каквото трябва да разгледате.
И наистина трябва да отделите заснемането на данни, транзакциите, аспектите на трансформацията в базата данни, заедно с анализите. Всеки от тях има различни модели на дизайн, всеки от тях има различни модели на използване и всеки от тях трябва да бъде настроен по различен начин. Така че, трябва да помислите как се използват тези данни, кога се използват, за какво се използват и да разберете какви показатели за ефективността и кои са основните неща, които искате да анализирате, свързани с това използване. Сега, когато гледате да наблюдавате изпълнението, искате да разгледате самите операции на базата данни; искате да разгледате и двете структури от данни, така че индексите, разделянето и други физически аспекти на базата данни, дори структурата на базата данни - независимо дали това е ER модел или модерен модел, колкото и да е структурирана - всички тези неща оказват влияние върху производителността, особено в различните контексти на анализите за улавяне на данни и трансформациите, които се случват.
И както Робин спомена от страна на SQL, разглеждането на SQL, който се управлява от тези различни приложения в тези бази данни, и настройването му е от решаващо значение. И като гледам общото натоварване на приложенията и инфраструктурната среда, в която работят тези бази данни и приложения. Така че, мрежите, сървърите, облакът - каквото и да работят, също гледат на въздействието, което тези приложения и тези бази данни имат в този контекст, всички те имат взаимодействие, за да могат да настройват базата данни.
И накрая, когато разглеждате инструменти, искате да можете да разгледате трите различни вида анализи, свързани с това. Искате да разгледате описателен анализ: какво се случва и къде, свързани с базата данни и производителността на приложението. Искате да имате способността да правите диагностична анализа, за да разберете не само какво се случва, но и защо се случва, къде са задръстванията, къде са проблемите, какво работи добре, кое не работи добре? Но да сте в състояние да анализирате и разгледате проблемните области, за да се справите с тях, било то за дизайн или каквото трябва да направите.
И най-накрая, най-агресивният или проактивен тип анализ е всъщност да се направи някакъв прогнозен анализ, моделиране на прогнозна аналитика, каквото и да е. Знаем, че базата данни и приложенията работят в този контекст, ако увеличихме капацитета, ако получим повече потребители, ако правим повече пропускателна способност, каквото и да правим, можем да проектираме какво, как и къде ще въздейства върху базата данни, приложенията, ни позволява да планираме и да разберем проактивно, къде са тесните места, къде могат да страдат времената на чакане и какво трябва да направим, за да поправим нещата. Така че ние искаме да имаме инструменти, които да могат да прилагат показателите за ефективност, да следят изпълнението, както при тези три типа анализ. И това е моят преглед.
Ерик Кавана: Добре, позволете ми да го предам - между другото това са две страхотни презентации - нека да го предам на Булет Манале, за да го взема от там. И хора, не забравяйте да задавате добри въпроси; вече имаме добро съдържание. Отнеси го, Бълет.
Bullett Manale: Звучи добре. Благодаря, Ерик. И така, много от казаното от Рик и Робин, очевидно съм съгласен със 100 процента. Бих казал, че издърпах този слайд нагоре, защото смятам, че е подходящ, не знам за онези от вас, които са фенове на „A-Team” още през 80-те, Джон Ханибал Смит имаше поговорка, че винаги е кажете: „Обичам го, когато планът се сглоби“ и мисля, че когато говориш за конкретно SQL Server, именно там се фокусираме, което е продуктът, за който ще говорим днес, SQL Diagnostic Manager, това определено е едно от онези неща, които трябва да имате; трябва да можете да използвате данните, които имате, и да можете да вземате решения от тези данни, а в някои случаи не търсите решение; търсите нещо, което да ви каже кога ще изчерпват ресурси, кога ще ви свършат ресурси, кога ще имате затруднение, такива неща.
Не става въпрос само за наблюдение на конкретен показател. Така че с Diagnostic Manager едно от нещата, които прави много добре, е да ви помогне по отношение на прогнозирането и разбирането, специфично за натоварванията и днес ще говорим за много от това. Инструментът е насочен към мениджъра на данни, DBA или действащия DBA, така че много от нещата, за които Рик споменаваше, действащата DBA е толкова вярна. В много случаи, ако не сте DBA, ще има много въпросителни, които ще имате, когато дойде време за управление на SQL среда, неща, които не знаете. И така вие търсите нещо, което да ви помогне, да ви преведе през този процес и също да ви образова в процеса. И така, важно е инструментът, който използвате за тези видове решения, да ви даде някаква представа за причините, поради които се вземат тези решения, не е просто да ви каже: „Ей, направете това.“
Тъй като аз съм действащият DBA, в крайна сметка може да бъда пълноценният DBA с действителния опит и знания, които да подкрепят това заглавие. Така че, казано, когато говорим за администратор на база данни - аз винаги първо показвам този слайд, защото DBA има някои различни роли и в зависимост от организацията, с която сте, ще трябва да имате, те ще варират от едно място на друго - но обикновено винаги ще бъдете по някакъв начин отговорен за вашето хранилище, за вашето планиране на това хранилище и разбиране за предвиждане, трябва да кажа, колко място ще отидете за да се нуждаете, независимо дали е за вашите архиви или за самите бази данни. Ще трябва да разберете и оцените това.
Освен това ще трябва да можете да разбирате и оптимизирате нещата според нуждите си, и докато преминавате през мониторинга на околната среда, очевидно е важно да правите промени, тъй като те са необходими въз основа на неща, които промяна в самата среда. Така че неща като броя на потребителите, неща като популярността на приложенията, сезонността на база данни, всички трябва да се вземат предвид, когато правите прогнозата си. И тогава, очевидно гледайки на други неща по отношение на възможността да предоставяте докладите и необходимата информация, тъй като е свързана с вземането на тези решения. В много случаи това означава да се направи сравнителен анализ; това означава да можете да разгледате конкретно показател и да разберете каква е стойността на този показател с течение на времето, така че можете да предвидите къде ще се движи напред.
Така че много от инструмента, който Diagnostic Manager прави, има тези възможности и хората го използват всеки ден, за да могат да правят неща като прогнозиране, и тук съм поставил определението за планиране на капацитета. И това е доста широко и всъщност доста неясна дефиниция, която е само процесът на определяне на производствения капацитет, необходим на една организация, за да отговори на променящите се изисквания към своите продукти, и в края на деня, това е наистина за това: за възможността да приемате информация, която имате по някакъв или друг начин, и да вземате тази информация и да вземате решения, които да ви помогнат да продължите напред, докато напредвате през жизнения цикъл на вашите бази данни. И така, видовете неща, които са причините, поради които хората трябва да правят това, очевидно са на първо място и най-вече, в повечето случаи, за да спестят пари. Бизнесът, очевидно, че това е основната им цел да печелят пари и да спестят пари. Но в процеса наред с това, това също означава да сте в състояние да сте сигурни, че престоят ви няма престой. И да бъдете в състояние да сте сигурни, че смекчавате всеки шанс за прекъсване, затова го предпазвайте да не се случи, с други думи, да не чакате това да се случи и след това да реагирате на него.
Освен че можете да увеличите цялостно производителността на вашите потребители, превръщането им в по-ефективни, така че да можете да правите повече бизнес, очевидно е ключовото тук, така че това са типовете неща, които като DBA или някой, участващ в прогнозирането или капацитета планирането ще трябва да бъде в състояние да проникне през информацията, за да може да взема тези решения. И като цяло, това очевидно ще ви помогне да премахнете отпадъците, не само по отношение на парите, но и по отношение на времето и по отношение на просто като цяло ресурси, които биха могли да се използват за други неща, вероятно. Така че, да можете да премахнете тези отпадъци, така че да нямате възможни разходи, които са обвързани със самите отпадъци.
И така, с казаното, какви са въпросите, които получаваме, специфични за човека, който е DBA? Кога ще ми свърши пространството? Това е голямо, не само колко пространство изразходвам сега, но кога ще изчерпвам, въз основа на тенденциите и миналата история? Същото нещо с действителните екземпляри на SQL, базите данни, кои сървъри мога да консолидирам? Ще сложа някои от виртуалните машини, какъв смисъл има по отношение на кои бази данни ще консолидирам и в кои случаи на SQL трябва да пребивават? На всички тези видове въпроси трябва да може да се отговори. Защото в повечето случаи, ако сте DBA или действате DBA, ще го консолидирате някъде в кариерата си. В много случаи ще правите това непрекъснато. Така че, трябва да можете да вземате тези решения бързо, а не да играете игри за отгатване, когато става въпрос за това.
Говорихме за тесните места и къде ще се появят по-нататък, за да можем да предвидим това за пореден път, вместо да чакаме да се случат. Така че очевидно всички тези неща, за които говорим, имат смисъл в смисъл, че разчитате на исторически данни, в повечето случаи да можете да генерирате тези препоръки или в някои случаи да можете сами да формулирате решения, за да мога да изляза с тези отговори. Но ми напомня за това, когато чуете радиореклами за някой, който продава ценни книжа или нещо подобно, винаги е „миналото представяне не е показателно за бъдещи резултати“ и подобни неща. И същото важи и тук. Ще имате ситуации, в които тези прогнози и тези анализи може да не са 100 процента правилни. Но ако имате работа с неща, които са се случвали в миналото и известни, и сте в състояние да вземете и да направите „какво, ако“ с много от тези видове въпроси, които ще се натъкнете, е много ценно и това ще ви отведе много по-далеч от играта на познаене.
Така че, тези видове въпроси очевидно ще се появят, така че как се справяме с много от тези въпроси с Diagnostic Manager, на първо място имаме възможности за прогнозиране, като можем да направим това в базата данни, както и на масата като задвижване или силата на звука. За да мога да кажа не само: „Хей, ние сме пълни с пространство“, но шест месеца от сега, две години от сега, пет години от сега, ако бюджетя за това, колко място за кола ще отида за да имате нужда от бюджет? Това са въпроси, които ще трябва да задам и ще трябва да мога да използвам някакъв метод за това, а не да гадая и да вдигам пръста си във въздуха и да чакам да видя по какъв начин духа вятърът, което е много пъти, за съжаление, начинът, по който се вземат много от тези решения.
В допълнение към това, да мога - изглежда, че слайдът ми се е отрязал малко по малко - но е в състояние да предоставя някаква помощ под формата на препоръки. И така, едно е да можеш да ти покажеш табло, пълно с показатели и да можеш да кажеш „ОК, ето всички показатели и къде се намират“, но след това да можеш да направиш някои или да имаш някакво разбиране за какво да правя, въз основа на това е друг скок. А в някои случаи хората са достатъчно образовани в ролята на DBA, за да могат да вземат тези решения. И така в инструмента имаме някои механизми, които ще ви помогнат, които ще ви покажем само за секунда. Но да бъде в състояние да покаже не само каква е препоръката, но и да предостави известна информация защо се прави тази препоръка, а след това и на всичкото отгоре, в някои случаи да бъде в състояние да създаде сценарий, който автоматично автоматизира коригирането на този въпрос също е идеално.
Преминаването към следващия тук, което ще видим, това е като цяло казано разбиране до ниво на метриката какво е нормално. Не мога да ти кажа какво не е нормално, ако не знам какво е нормално. И така, имайки някакъв начин да измериш това е ключово и трябва да можеш да вземеш под внимание множество видове области, например - или трябва да кажа времеви рамки - различни групи сървъри, като можеш да правиш това динамично, от тревожна гледна точка, с други думи, по време на средата на нощта, по време на прозореца за поддръжка, очаквам моят процесор да работи на 80 процента въз основа на цялата поддръжка, която продължава. Така че, бих могъл да искам да увелича праговете си по-високо, през тези времеви рамки спрямо може би по средата на деня, когато не се занимавам с толкова активност.
Това са някои неща, които очевидно ще бъдат екологични, но неща, които можете да приложите към управляваното, за да може да ви помогне да управлявате тази среда по-ефективно и да я улесните. Другата област очевидно е в състояние просто да предостави докладите и информацията, за да може да отговори на тези видове въпроси „какво ако“. Ако току-що направих промяна в средата си, искам да разбера какво е това въздействие, така че да мога да приложа същата промяна към други инстанции или други бази данни в моята среда. Искам да мога да имам информация или боеприпаси, за да мога да направя тази промяна с известно спокойствие и знаейки, че това ще бъде добра промяна. И така, да мога да направя това сравнително отчитане, да мога да класирам моите случаи на SQL, да мога да класирам моите бази данни един към друг, да кажа: „Кой е най-високият ми потребител на процесор?“ Или кой от тях взема най-дълго време условия на изчакване и подобни неща? Така че много от тази информация ще бъде налична и с инструмента.
И тогава, не на последно място, е просто цялостна способност, че се нуждаете от инструмент, който ще бъде в състояние да се справи с каквато ситуация идва по вашия път и така какво имам предвид под това, ако имате голяма среда с много случаи, вероятно ще се сблъскате със ситуации, в които трябва да изтеглите показатели, които традиционно не са показатели, които DBA би искал дори да наблюдава в някои случаи, в зависимост от конкретната ситуация. И така, като имате инструмент, който можете, това е разширяемо, за да можете да добавяте допълнителни показатели и да можете да използвате тези показатели в същата форма и начин, по който бихте ги използвали, ако използвате външна кутия метрична, например. Така че, да можеш да пускаш отчети, да можеш да сигнализираш, основна линия - всички неща, за които говорим - също е ключова част от това да можеш да правиш това прогнозиране и да го правиш, така че да получиш отговорите, които търсиш да бъде в състояние да взема тези решения, движейки се напред.
Сега по начина, по който Diagnostic Manager прави това, ние имаме централизирана услуга, група услуги, която работи, събира данни срещу случаи от 2000 до 2016 г. И тогава това, което правим, е да вземем тези данни и да ги поставим в централно хранилище и след това онова, което ще правим с тези данни, очевидно е, че правим много, за да можем да дадем допълнителна информация. Сега, в допълнение към това - и едно от нещата, които не са тук - имаме ли и услуга, която работи посред нощ, която е нашата услуга за прогнозен анализ, и това прави някакво трошене и помага да разберем и да ви помогне като DBA или действащ DBA, за да можете да отправяте тези видове препоръки, за да можете да предоставите известна информация по отношение на базовите линии.
И така, това, което бих искал да направя, и това е само бърз пример за архитектурата. Голямото поемане тук е, че няма агенти или услуги, които всъщност седят в инстанциите, които управлявате. Но това, което бих искал да направя, е всъщност да ви отведе до приложението тук и да ви даде бърза демонстрация. И нека просто да изляза и да направя това. И така, кажи ми, мисля, Ерик, виждаш ли това ОК?
Ерик Кавана: Разбрах го сега, да.
Bullett Manale: Добре, така че ще ви преведа някои от тези различни части, за които говорих. И по същество нека да започнем с вида на нещата, които са по-скоро по отношение на ето нещо, което трябва да направите, или тук е нещо, което е момент от време в бъдещето и ние ще ви дадем някаква представа за това. И това е в състояние наистина да предвиждам - или би трябвало да кажа динамично предвиждам - неща, както се случват. В случая с доклади едно от нещата, които имаме в инструмента, са три различни отчети за прогнозиране. И в случая, например, на прогноза за база данни, какво вероятно бих направил, ако мога да предвидя размера на база данни за определен период от време, и ще ви дам само няколко примера за това, Така че, ще взема моята база данни за одит, която е доста интензивна за I / O - има много данни. Имаме, да видим, ще направим това тук и нека просто изберем базата данни за здравеопазването тук.
Но въпросът е, че не просто виждам какво е пространството в това, аз съм в състояние да кажа: „Вижте, нека да вземем данни за миналата година“ - и ще намеря малко тук, Наистина нямам данни за една година, имам данни за около два месеца - но тъй като тук избирам примерна норма от месеци, ще мога да предвидя или прогнозирам в това в случай, че следващите 36 единици, тъй като нашата извадкова норма е настроена на месеци - това е единица, е месец - и тогава бих могъл, след това да мога да пусна доклад, който да ми покаже къде бихме очаквали бъдещия ни растеж, за тези три бази данни. И можем да видим, че имаме различна степен или разлика между трите различни бази данни, по-специално от количеството данни, което те използват в исторически план.
Можем да видим, че тук данните от данни представляват историческите данни и тогава линията ще ни предоставя прогнозата, заедно с числата, които да я подкрепят. Така че можем да направим това на ниво таблица, можем да го направим дори на ниво задвижване, където мога да предвидя колко големи ще получат моите дискове, включително точките на монтиране. Бихме могли да прогнозираме този вид информация, но за пореден път, в зависимост от честотата на извадката, ще ми позволя да определя колко единици и къде вземаме това, което искаме да прогнозираме. Забележете също, че имаме различни видове прогнози. Така получавате много възможности и гъвкавост, когато дойде време за извършване на прогнозата. Това е едно нещо, което ще направим, всъщност да ви дадем конкретна дата и ще можем да кажем „Ей на тази дата, тук бихме могли да предвидим растежа на вашите данни.“ В допълнение към това обаче можем да ще ви предоставим други мнения, които са свързани с някои от анализите, които извършваме в извънработно време и услугата, когато се изпълнява. Някои от нещата, които прави, е, че се опитва да предвиди нещата, които вероятно ще се случат, въз основа на историята на това, когато нещата са се случвали в миналото.
Така че можем да видим тук, всъщност една прогноза ни дава известен поглед върху вероятността да имаме проблеми през цялата вечер, базирани на неща, които се случват отново в миналото. Така че, очевидно това е чудесно, особено ако не съм DBA, мога да разгледам тези неща, но още по-добре, ако не съм DBA, е този раздел за анализ. И така, преди това да е тук в инструмента, ние щяхме да преминем и да покажем продукта на хората и те ще бъдат „Това е чудесно, виждам всички тези числа, виждам всичко, но не знам какво да правя“ (смее се) „В резултат на това.“ И така това, което имаме тук, е по-добър начин да можете да разберете, ако ще предприема действия, за да помогна за изпълнението, ако ще предприема действия дори помогнете за здравето на моята среда, да мога да имам класиран начин за предоставяне на тези препоръки, както и полезни съвети за информация, за да науча повече за тези препоръки и всъщност да имам дори външни връзки към някои от тези данни, които ще ми покажат и заведете ме с причините, поради които се правят тези препоръки.
И в много случаи може да предостави скрипт, който да автоматизира, както казах, отстраняването на тези проблеми. Сега, част от това, което правим тук с този анализ - и ще ви покажа, когато вляза да конфигурирам свойствата на този случай, и отивам в секцията за конфигурация на анализа - имаме много различни категории, които са изброени тук, и част от това, ние имаме оптимизация на индекси и заявки. Така че ние оценяваме не само самите показатели и подобни неща, но и неща като натоварванията и индексите. В случая тук всъщност ще направим някои допълнителни хипотетични анализи на индекси. Така че това е една от онези ситуации, в които не искам, в много случаи не искам да добавям индекс, ако не се налага. Но в някакъв момент има някакъв тип прекъсване, където аз казвам: „Е, таблицата стига до размера или видовете заявки, които се изпълняват в рамките на натоварването, има смисъл сега да добавите индекс. Но не би имало смисъл може би шест седмици преди това. "Така че това ви позволява динамично да придобиете тази представа за нещата, които вероятно, както казах, ще подобрят производителността на базата на това, което се случва в околната среда, какво се случва в рамките на работните натоварвания. и да правиш такива неща.
И така тук получавате много добра информация, както и възможността да оптимизирате тези неща автоматично. Така че, това е друга област, в която бихме могли да помогнем по отношение на това, което наричаме прогнозен анализ. Сега, в допълнение към това, трябва да кажа, имаме и други области, които според мен просто като цяло се поддават на това да ви помогнат да вземате решения. И когато говорим за вземане на решения, отново, когато можем да разгледаме исторически данни, ни дава известно разбиране, за да ни отведе до мястото, където трябва да бъдем, за да подобрим представянето.
Сега, едно от нещата, които можем да направим, е да имаме основен визуализатор, който ни позволява да избираме избирателно каквато и да е метрика, която бихме искали - и нека да намеря достойно тук - ще използвам SQL CPU, но въпросът е вие може да се върне през много седмици, за да нарисувате тези снимки, за да видите кога са вашите хора, за да видите най-общо къде тази стойност попада в периодите от време, през които събираме данни. И тогава, в допълнение към това, ще забележите също, че когато излезем към самия действителен екземпляр, ние имаме възможността да конфигурираме основните си линии. И базовите линии са наистина важна част от това да можеш да автоматизираш нещата, както и да можеш да бъдеш уведомен за нещата. И предизвикателството, както повечето DBAs биха ви казали, е, че вашата среда не винаги работи еднакво през целия ден, срещу вечерта и какво ли не, както споменахме по-рано в примера с периодите на поддръжка, когато ние имат високи нива на процесор или каквото и да се случва.
Така че в случая тук, с тези действителни базови линии, можем да имаме няколко базови линии, така че може да имам базова линия например, това е по време на моите часове за поддръжка. Но можех също толкова лесно да създам основна линия за моите производствени часове. И смисълът на това е, когато влезем в екземпляр на SQL и всъщност имаме тези множество базови линии, тогава бихме могли да предвидим и да можем да извършим някакъв тип автоматизация, някакъв вид корекция или просто предупреждение като цяло, различно специфични за онези прозорци на времето. И така, едно от нещата, които ще видите тук, са тези базови линии, които генерираме, използват историческите данни, за да предоставят този анализ, но по-важното е, че мога да променя тези прагове статично, но също така мога да ги автоматизирам динамично. Така че, когато се появи прозорецът за поддръжка или трябва да кажа, че се появи основният прозорец за поддръжка, тези прагове автоматично ще превключат специфично на натоварванията, с които се сблъсквам през този период от време, или може би в средата на деня, когато моите товари са не толкова, когато натоварването не е толкова въздействащо.
Така че, това е нещо друго, което трябва да имате предвид по отношение на основната линия. Очевидно е, че те ще бъдат наистина полезни за вас, що се отнася до разбирането на това, което е нормално, и да сте в състояние да разберете, ангажирайте се, когато ще ви липсват и ресурси. Сега, другото нещо, което имаме в инструмента, това ще ви помогне да вземате решения, в допълнение базовото обучение и възможността да задавате сигнали около тези базови линии и праговете, които създавате динамично, е както казах по-рано, просто да мога да пускам безброй отчети, които ми помагат да отговарям на въпроси за случващото се.
Така че, например, ако имах 150 екземпляра, които управлявам - в моя случай не го правя, така че трябва да играем играта на преструвки тук - но ако имах всички мои производствени инстанции и трябваше да разбера къде е областта, върху която имам нужда от внимание, с други думи, ако ще имам само ограничен период от време за извършване на някакъв вид администрация, за да подобря ефективността, искам да се съсредоточа върху ключовите области. И така, с казаното, бих могъл да кажа: „Въз основа на тази среда, класирайте моите инстанции един срещу друг и ми дайте това класиране по спорове.“ Така че дали става въпрос за използване на дискове, използване на памет, дали чака, дали е време за реакция, аз съм в състояние да съпоставя - или трябва да кажа ранг - тези случаи един срещу друг. Очевидно екземплярът, който е в горната част на всеки списък, ако е един и същ екземпляр, това вероятно е нещо, върху което наистина искам да се съсредоточа, защото очевидно отново е в горната част на списъка.
Така че, имате много отчети в инструмента, които ви помагат по отношение на класирането на средата на ниво инстанция; можете да направите това и на ниво база данни, където мога да класирам моите бази данни една спрямо друга. В частност на праговете и областите, които мога да задавам, дори мога да настроя подметки тук, ако искам, да се съсредоточа само върху конкретни бази данни, но смисълът е, че мога да сравня моите бази данни по същия начин. Освен това, що се отнася до другите видове сравнителен анализ и големият в този инструмент, е основният анализ, който имаме. Така че, ако превъртите надолу до изгледа на услугата тук, ще видите, че има отчет за статистически данни за базовата линия. Сега този отчет очевидно ще ни помогне да разберем не само какви са стойностите на показателите, но за конкретен случай бих могъл да изляза и за която и да е от тези показатели да мога да разгледам всъщност основните показатели за тези показатели.
Така че, каквото и да е, като процент или каквото и да мога да изляза и да кажа: „Нека видим основната линия за това да е изчезнала през последните 30 дни“, в този случай ще ми покаже действителните стойности спрямо базовата линия и Бих могъл да взема някои решения, използвайки тази информация, очевидно, така че това е една от онези ситуации, при които това ще зависи от въпроса, който задавате по това време. Но това очевидно ще ви помогне за много от тези въпроси. Бих искал да кажа, че имаме един доклад, който върши всичко и е нещо като лесния доклад, където натискате и натискате бутона и той просто отговаря на всеки въпрос „какво ако“, на който някога бихте могли да отговорите. Но реалността е, че ще имате много атрибути и много опции, за да можете да избирате от тези падания, за да можете да формулирате тези въпроси „какво ще стане“, които търсите,
Така че много от тези доклади са насочени към възможността да отговорят на тези видове въпроси. И така, наистина е важно също тези отчети и в допълнение, всички неща, които вече ви показахме в инструмента, както споменах преди, като имате гъвкавост да включвате нови показатели, които да се управляват, дори да можете да създавате броячи или SQL заявки, които са включени във вашите интервали за гласуване, за да можете да ми помогнете да отговоря на тези въпроси, че може би извън кутията, която не очаквахме да наблюдаваме, можете да добавите тези неща. И тогава ще можете да правите всички същите неща, които току-що ви показах: изходно ниво, пускане на отчети и създаване на отчети от този показател и да можете да отговаряте и да правите много от тези различни видове неща, които ви показвам тук.
Сега, в допълнение към това - и едно от нещата, с които очевидно се сблъскваме доста напоследък, е - първо това беше, всеки прелиства или преминава към VM. И сега имаме много хора, които се отправят към облака. И има много въпроси, които възникват около тези видове неща. Има ли смисъл да се премествам в облака? Ще спестя ли пари, като се преместя в облака? Ако бих поставил тези неща на виртуална машина, на машина с общ ресурс, колко пари мога да спестя? Очевидно ще възникнат и тези видове въпроси. Така че много от тези неща имайте предвид, с Diagnostic Manager можем да добавяме и изтегляме от виртуализираните среди както на VMware, така и на Hyper-V. Можем също така да добавим случаи, които са извън облака, така че вашите среди като Azure DB, например, или дори RDS, можем да изтегляме показатели и от тези среди.
Така че има много гъвкавост и много възможност да отговорим на тези въпроси, тъй като е свързано с онези други видове среди, към които виждаме хората да се отправят. И все още има много въпроси около тези неща и тъй като виждаме хората да консолидират тези среди, те ще трябва да могат да отговорят и на тези въпроси. Така че, това е доста добър преглед, бих казал, на Diagnostic Manager, тъй като е свързан с тази тема. Знам, че се появи темата за бизнес разузнаването и ние също имаме инструмент за бизнес разузнаване, за който не говорихме днес, но той също ще ви даде представа по отношение на отговорите на тези видове въпроси, тъй като се отнася до вашите кубчета и всички тези различни неща. Но да се надяваме, че това е добър преглед, поне по отношение на това как този продукт може да помогне с формулирането на добър план.
Ерик Кавана: Добре, добри неща. Да, ще го изхвърля на Рик, ако той все още е там. Рик, някакви въпроси от теб?
Рик Шерман: Да, така че първо, това е страхотно, харесва ми. Особено харесвам разширяването до VM и облаците. Виждам, че много разработчици на приложения смятат, че ако е в облака, няма нужда да го настройват. Така-
Bullett Manale: Да, все пак трябва да плащаме за това, нали? Все още трябва да плащате за всичко, което хората пускат в облака, така че ако той работи лошо или ако предизвиква много CPU цикли, трябва да плащате повече пари, така че не е, нали все още трябва да измервате тези неща, абсолютно.
Рик Шерман: Да, виждах много лоши дизайни в облака. Исках да попитам, ще се използва ли и този продукт - знам, че споменахте BI продукта и имате много други продукти, които си взаимодействат помежду си - но бихте ли започнали да търсите производителността на SQL, индивидуалните запитвания в този инструмент? Или ще бъдат други инструменти, които ще бъдат използвани за това?
Bullett Manale: Не, това би, абсолютно. Това е едно от нещата, които не покрих и имах предвид, е частта от заявките в него. Имаме много различни начини да идентифицираме ефективността на заявките, независимо дали тя е свързана, по-специално да чакаме, както виждаме на този изглед тук, или дали е свързана с консумацията на ресурси на заявки като цяло, има цял брой начини да анализираме заявките производителност. Независимо дали е продължителност, процесор, I / O и още веднъж, можем да разгледаме и самите натоварвания, за да дадем някаква представа. Можем да предоставим препоръките в раздела за анализ и също така имаме уеб-базирана версия, която предоставя информация около самите заявки. Така че мога да получа препоръки за липсващи индекси и възможност за преглед на плана за изпълнение и всички подобни неща; също е способност. Така че, абсолютно, можем да диагностицираме запитвания по седем начина до неделя (смее се) и да бъдем в състояние да предоставим тази представа по отношение на броя на екзекуциите, било то потреблението на ресурси, чаканията, продължителността и всички толкова добри неща.
Рик Шерман: Добре, страхотно. И тогава какво е натоварването на самите инстанции с целия този мониторинг?
Bullett Manale: Добър въпрос. Предизвикателството с отговора на този въпрос е, зависи ли, то е като всичко друго. Много от това, което предлага нашия инструмент, той предоставя гъвкавост и част от тази гъвкавост е да го кажете какво да събира и какво не да събира. Така например, при самите заявки, не е нужно да събирам информация за чакане, или мога. Мога да събирам информация, свързана със заявки, които надвишават времетраенето на изпълнение. Като пример за това, ако трябваше да вляза в монитора за конфигуриране на заявките и бих казал: „Нека променим тази стойност на нула“, реалността е, че всъщност просто инструментът прави инструмента да събира всяка заявка, която се изпълнява и това всъщност не е дух на това защо е там, но като цяло, ако искам да предоставя пълна извадка от данни за всички заявки, бих могъл да го направя.
Така че, това е много относително какви са вашите настройки, най-общо казано, извън кутията. Това е някъде от около 1–3 процента режийни разходи, но има други условия, които ще се прилагат. Зависи и от това колко заявки към порта се изпълняват във вашата среда, нали? Зависи и от метода за събиране на тези заявки и каква версия на SQL е. Така че, например, SQL Server 2005, ние няма да бъдем в състояние да изтеглим от разширени събития, докато така бихме изтеглили от следа, за да направим това. Така че би било малко по-различно от гледна точка на начина, по който ще продължим да събираме тези данни, но това каза, както казах, вече около 2004 г. предполагам с този продукт. Това е от доста време, имаме хиляди клиенти, така че последното, което искаме да направим, е да имаме инструмент за мониторинг на ефективността, който създава проблеми с производителността (смее се). И така се опитваме да се избягваме от това, доколкото е възможно, но като цяло, около 1–3 процента е добро правило.
Рик Шерман: Добре, и това е доста ниско, така че това е страхотно.
Ерик Кавана: Добре. Робин, някакви въпроси от теб?
Робин Блур: Съжалявам, бях на заглушаване. Имате възможност за множество бази данни и ме интересува как, защото можете да разгледате множество бази данни и следователно можете да знаете, че по-голяма база от ресурси е възможно да бъде разделена между различни виртуални машини и така нататък и така нататък. Интересува ме как хората всъщност използват това. Интересува ме какво правят клиентите с това. Защото това ми изглежда, добре, със сигурност, когато се забърквах с бази данни, нещо, което никога не съм имал под ръка. И винаги бих разгледал един случай по някакъв смислен начин във всеки даден момент от време. И така, как хората използват това?
Bullett Manale: Най-общо казано, вие говорите като цяло само за самия инструмент? Как го използват? Искам да кажа, като цяло става въпрос за възможността да има централна точка на присъствие на околната среда. Като имат спокойствие и знаят, че ако се взират в екран и виждат зелено, те знаят, че всичко е добре. Това е когато проблемите се случват и очевидно повечето случаи са от гледна точка на DBA, много пъти тези проблеми се случват, когато са пред конзолата, така че можете да бъдете уведомени веднага щом проблемът се случи. Но в допълнение към това, да можеш да разбереш кога проблемът се случва, да можеш да стигнеш до сърцето на информацията, която им предоставя някакъв контекст по отношение на това защо се случва. И това е, струва ми се, най-голямата част: да бъдем активни по отношение на това, да не сме реактивни.
Повечето от DBAs, с които разговарям - и не знам, това е добър процент от тях - за съжаление все още са в реактивния тип среда; те чакат потребител да се свърже с тях, за да им каже, че има проблем. И така, виждаме много хора, които се опитват да се откъснат от това и мисля, че това е голяма част от причината, поради която хората харесват този инструмент е, че той им помага да бъдат активни, но също така им дава прозрение за случващото се, какъв е проблемът, но в много случаи това, което намираме най-малко - и може би това само DBA-та ни казват това - но DBAs, схващането е, че винаги е техен проблем, дори ако разработчикът на приложения е написал приложението които не са го написали правилно, те са тези, които ще поемат вината, защото те взимат това приложение в своите системи или сървъри и тогава, когато работата е лоша, всички сочат към DBA казва: "Ей, ти си виновна."
Така че този инструмент много пъти ще бъде използван, за да помогне по отношение на вземането на решение на DBA да каже: „Ей, тук е проблемът и не съм аз.“ (Смее се) Трябва да подобрете това, независимо дали става дума за промяна на заявките или каквато и да е тя. В някои случаи тя ще попадне в кофата им по отношение на тяхната отговорност, но поне да имат инструмента, за да могат да им помогнат да разберат това и да знаят това, и да го правят своевременно, очевидно е идеалният подход.
Робин Блур: Да, повечето от сайтовете, с които съм запознат, но мина доста време, откакто съм бил там, разглеждах различни сайтове с много бази данни, но най-вече това, което използвах, беше, че ще има DBA, които се съсредоточиха върху шепа бази данни. И това биха били базите данни, че ако някога спаднат, това ще бъде истински голям проблем за бизнеса и т.н., и така нататък. И другите, просто ще събират статистика от време на време, за да видят, че не им е останало пространството и изобщо никога няма да ги гледат. И докато правехте демонстрацията, аз гледах това и разсъждавах добре, по един или друг начин, вие разширявате, просто като предоставите нещо подобно за бази данни, които често са, никой не се интересува твърде много, защото те имат растеж на данни, те също имат растеж на приложения в пъти. Разширявате обхвата на DBA по доста драматичен начин. Така че всъщност е въпросът, дали с такъв набор от инструменти в крайна сметка ще можете да предоставите DBA услуга на всяка база данни, която е в корпоративната мрежа?
Bullett Manale: Разбира се, искам да кажа, че предизвикателството е, че както казахте много красноречиво, е като да има някои бази данни, за които се интересуват DBA, а след това има някои, за които не ги интересува толкова. И начинът, по който този конкретен продукт, начинът, по който е лицензиран, е на база инстанция. Така че, предполагам, че бихте казали, има праг, когато хората решат „Ей, това не е достатъчно критичен случай, че искам да го управлявам с този инструмент.“ Това каза, има и други инструменти, които правим предполагам, че това са повече, предполагам, че отговаря на тези по-малко важни случаи на SQL. Едно от тях би било като Мениджъра на инвентаризацията, където правим леки проверки на здравето спрямо инстанциите, но в допълнение към това, което правим, правим откриване, така че идентифицираме нови случаи, които са били въведени онлайн и след това, от този момент, като DBA мога да кажа: „Добре, ето нов екземпляр на SQL, сега Express? Това е безплатната версия или е корпоративна версия? “Това вероятно е въпрос, който искам да си задам, но второ, колко важен е този случай за мен? Ако това не е толкова важно, може би ще използвам този инструмент и да го правя, общо, това, което бих нарекъл общите проверки на здравето, в смисъл, че те са елементарните типове неща, за които се интересувам като DBA: Дали устройството се запълва ? Сървърът отговаря ли на проблеми? Основните неща, нали?
Докато при Diagnostic Manager, инструмента, който ви показвах, той ще стигне до нивото на заявките, ще влезе в препоръката на индексите, като погледнете плана за изпълнение и всички тези добри неща, докато това е основно фокусирано относно това кой притежава какво, какво притежавам и кой е отговорен за това? Какви сервизни пакети и горещи корекции имам? И моите сървъри работят с основните съставки на това, което бих считал за здравословен екземпляр на SQL? Така че за да отговоря на въпроса ви, има малко смесване. Когато имаме хора, които разглеждат този инструмент, те обикновено разглеждат по-критичен набор от инстанции. Това каза, ние имаме някои хора, които купуват всеки случай, който имат и го управляват, така че просто зависи. Но ви казвам, като цяло определено има праг на хората, които смятат, че средата им е достатъчно важна, за да има такъв инструмент за управление на тези случаи.
Робин Блур: Добре, още един въпрос, преди да го предам на Ерик. Впечатлението, което се получава, само от гледането на индустрията е, че базите данни все още имат живот, но всички данни се наливат във всички тези езера и така нататък и така нататък. Това наистина е hype, а hype никога не отразява реалността, така че ме интересува каква реалност възприемате там? Дали важните бази данни в една организация преживяват ли традиционното нарастване на данните, за което използвах 10% годишно? Или растат повече от това? Дали големите данни правят тези бази балони? Каква е картината, която виждате?
Bullett Manale: Мисля, че в много случаи наблюдаваме преместване на някои данни в онези други сегменти, където има по-голям смисъл, когато има достъпни други технологии. От скоро, някои от по-големите данни. Но тези бази данни, бих казал, е трудно да се обобщят в много случаи, защото всички са малко по-различни. Най-общо казано, виждам известни различия. Виждам, както казах, хората преминават към еластичните модели в доста случаи, защото искат да увеличат ресурсите, а не толкова в други области. Някои хора преминават към големите данни. Но е трудно да усетите възприятието, казвате, защото обикновено хората, с които говоря, имат традиционните бази данни и използват това в среда на SQL Server.
Това каза, бих казал по отношение на самия SQL, аз определено все още смятам, че той печели пазарен дял. And I think that there's a lot of folks that are still heading towards SQL from other places like Oracle, because it's more affordable and seems to be obviously, as SQL versions become more advanced – and you're seeing this with the more recent things that are going on with SQL, in terms of encryption and all of the other capabilities that are making it an environment or a database platform – that is obviously very mission critical capable, I guess. So, I think we're seeing that as well. Where you're seeing a shift, it's still happening. I mean, it was happening 10 years ago, it's still, I think, happening in terms of SQL Server, where the environment's growing and the market share is growing.
Robin Bloor: OK, Eric, I presume the audience has a question or two?
Eric Kavanagh: Yeah, let me throw one quick one over to you. It's a pretty good question, actually. One of the attendees is asking, will this tool tell me if a table may need an index to speed up the query? If so, can you show an example?
Bullett Manale: Yeah, so I don't know if I have one for a specifically adding an index, but you can see here, we have fragmentation recommendations here. I also just believe we just had and this was part of the Diagnostic Manager offering the web-based version, where it's telling me I have a missing index. And we can view those recommendations and it'll tell us the potential gain of that by indexing that information. The other thing I should just mention is that when we do the recommendations, for many of these, the script will be built for it. That one's not a good example, but you would be able to see, yes, the situations where an index – either a duplicate index, or the addition of an index – would improve performance, and like I said earlier, we do a lot of that through hypothetical index analysis. So, it really helps in terms of understanding the workload, to be able to apply that to the recommendation.
Eric Kavanagh: That's great stuff, and this will give me a good segue to the final comments here. Robin and I and Rick as well, have heard over many years now, there's talk about self-tuning databases. It's a self-tuning database! All I can tell you is: Don't believe them.
Bullett Manale: Don't believe the hype.
Eric Kavanagh: There may be some small little things that get done dynamically, but even that, you might want to check it out and make sure it's not doing something you don't want it to do. So, for quite some time, we're going to need tools like this to understand what's happening at the database level and like Robin said, data lakes are fascinating concepts, but there's probably about as much chance of them taking over as there is of there being a Loch Ness Monster anytime soon. So, I would just say again, the real world has a lot of database technology, we need people, DBAs, to look at this stuff and synthesize it. You can tell, you need to know what you're doing to make this stuff work. But you need the tools to give you the information to know what you're doing. So, bottom line is DBAs are going to be doing just fine.
And big thanks to Bullett Manale and our friends at IDERA. And of course, Rick Sherman and Robin Bloor. We do archive all of these webcasts, so hop online insideanalysis.com or to our partner site www.techopedia.com for more information on all that.
And with that, we'll bid you farewell, folks. Thanks again, we'll talk to you next time. Пази се. Чао чао.
