От персонала на Техопедия, 30 ноември 2016 г.
Отнемане: Домакинът Ерик Кавана, заедно с д-р Робин Блур, Дез Бланчфийлд и Bullett Manale на IDERA обсъждат запитвания и как тяхната ефективност може да има далеч ефект.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Дами и господа, здравей и добре дошли отново. В сряда е четири часа източно време, а тези дни това означава, че е време за горещи технологии! Да, именно. Днес говорим за готини неща. Разбира се, аз съм вашият домакин, Ерик Кавана. Заглавието на днешното шоу е „Ключът към ефективната анализа: Бързо връщащи се запитвания.“ Точно така, хора, всички искаме бързо. Кой не иска бързо? Има слайд за твоето наистина и достатъчно за мен. Удари ме в Twitter, @eric_kavanagh. Ще се радвам да се свържа с вас там и да проведем разговор в социалните медии. Може да е забавно, просто не говорете за политика.
Годината гореща. Тази година говорихме за различни аналитични въпроси и една от днешните теми наистина е само основна за свършването на работата. Спомням си, че вероятно преди пет или шест години за първи път чух някой да използва израза „разговаряйте с вашите данни“ и въпреки че може да звучи малко нахално, въпросът е, че ако не можете да имате итеративен опит с вашите данни, ако не можете бързо да промените вашите заявки, да изпращате нови заявки, бързо да получавате отговори, тогава не провеждате разговор с вашите данни и целият аналитичен процес е съкратен. Това не е добре.
Когато провеждате разговор с вашите данни, това означава, че сте в състояние да вървите напред-назад и според мен това е, когато намерите прозрението. Защото много рядко ще излезете с перфектното запитване за първи път. Освен ако не сте Моцартът на аналитика - и съм сигурен, че човек е там - ще трябва да прекарате известно време в модифициране, добавяне на някакво измерение, опитвайки се да прецизирате това, което търсите,
Защото, отново, това не са изключително мрачни среди, с които се занимаваме в света на аналитиката; имаме работа с много трудни среди и много сложни и многоизмерни среди. И така цялата идея на уебизлъчването днес е да се говори за това как да се даде възможност за подобно итеративно взаимодействие с вашите данни.
Имаме три презентатори. Разбира се, в Hot Technologies, за разлика от Briefing Room, имаме двама анализатори; всеки от тях дава първо участие, след това гостът влиза, представя своята презентация, а ние имаме нещо като кръгла маса. И вие, нашата публика, можете да играете голяма роля в това. Моля, не се срамувайте; изпращайте вашите въпроси по всяко време. Използвайте панела за въпроси и отговори, ако можете, в противен случай панелът за чат е наред; Ще се опитам да наблюдавам и двете по време на шоуто. И ние ги записваме, така че ако сте пропуснали нещо или искате да го споделите с колегите, върнете се по-късно. Публикуваме ги в Techopedia.com, а също и в InsideAnalysis.com.
И с това ще въведа умните хора. Ще го предам на д-р Робин Блур. Нека да му дам ключовете, да смени презентатора и ето там. Робин, отнеси го.
Робин Блур: Добре. Благодаря за това интро. Преди около месец и половина имах чат с разработчик, който всъщност е DBA. Той всъщност не е DBA - той е бил DBA в определена компания и е единственият човек, който всъщност може да накара заявките да се изпълняват. Но се разболява от това, защото той наистина е, той всъщност е доста умен разработчик. Така той си тръгна.
И той така или иначе трябва да прави по няколко дни всеки месец за тях, защото не можеха да намерят някой, който да заеме неговото място и нямаха представа какво прави базата данни или как изобщо да я настройва. И аз някак си мислех за това и просто, знаете ли, те всъщност нямаха ИТ отдел, но този човек ги подкрепяше. Всъщност през повечето време се занимаваше с работата на DBA.
За сложни бази данни - Oracle, SQL Server, DB2, всички онези големи, скъпи - настройката на база данни е трудна работа. Това също е сигурна работа. И причината, наистина, защото казвам, че това е, че това е променящ се пейзаж. Ще се спра на това. Знаете ли, релационните бази данни - обикновено голямата картина е, релационните бази данни все още доминират по популярност. Те вероятно ще доминират дълго време напред. Да, сега има други бази данни, които получават повече ефирно време, но, знаете, когато всъщност гледате какво се случва там, Oracle прави повечето от него, Microsoft SQL Server е на второ място и в облака се случват различни неща, които може да предизвика предизвикателство. Те са големите гиганти в играта. И това са базите данни, които можете да използвате както за OLTP, така и за действително натоварване на хранилището на данни. Обикновено алтернативите се използват главно в аналитична среда и тогава обикновено се определя от данните, защо да изберем това, а не релационно. Най-често хората не го правят.
Компаниите са склонни да се стандартизират в една база данни. Наскоро попаднах на компания, която имаше над 5000 екземпляра на Oracle. И аз някак, човекът, с когото разговарях от тази компания, някак ги попитах за DBAs. Те казаха, че имат около 10 DBA и около 30 бази данни се грижат. И останалото, Oracle просто се използва като крайна система като цяло. Имаше много малък стрес върху данните от приложенията, които ги използват. Но това просто ме изуми - 5000 екземпляра на Oracle.
И между другото, те имаха лиценз за собственост на Oracle. Е, знаете, корпоративен лиценз, очевидно. Но те имаха и други бази данни, защото понякога, знаете ли, приложенията идват с предпочитана база данни. Не беше като Oracle беше единственото нещо. И си струва да споменем, че нито Hadoop, нито Spark всъщност са база данни и ще изминат доста време, преди да придобият това, за което мисля като правило за база данни. Добре е за връзки с данни, разбира се.
С дейностите на DBA - вероятно Bullett може да каже много повече за това от мен - но просто ще ги пробягам. Това са нещата, за които съм склонна да мисля, какво прави DBA. Те инсталират, конфигурират, надграждат, правят управление на лицензи. Те вършат много ETL и репликация по един или друг начин. Те правят планиране за съхранение и капацитет. Правят отстраняване на неизправности или са част от екипа за отстраняване на неизправности. Мониторингът и настройката на производителността са почти голяма част от тяхната дейност, но всички тези други неща не са малко, нали знаете. Сигурност, те са отговорни за архивирането и възстановяването. Те трябва да бъдат включени в софтуерните тестови системи и те могат да бъдат включени в жизнения цикъл на данните.
Производителност. Когато бях един от тези момчета. Когато работех и настройвах бази данни, така го разбрах, знаете ли? Има CPU и по един или друг начин в наши дни, процесорът е почти бездействащ, тъй като би бил един от другите два или th - Е, едно от другите тесни места всъщност би причинило проблема. Памет, раздробяване и фрагментиране, или дисково, или дисково или изходно насищане на диска, понякога мрежови режийни, ако работиш в множество възли на мрежата и всъщност можеш да попаднеш в някакво заключване.
Но това беше светът, както го видях. Наскоро разгледах Oracle и броя параметри на настройка, които има в Oracle. Беше над 300. Знаеш ли, и ако всъщност мислиш за това, DBA, който наистина знае какво прави, трябва да има някаква идея защо изобщо ще се забъркваш с някое от тях. Значи, това е сложна работа, знаете, и е по-сложна от това.
Знаете, в момента имаме CPU, но вие имате … процесорите вече съществуват, графичните процесори на процесора или с FPGA на процесора. Така че има един вид кръстосване на това, което всъщност се случва в процесора. Процесорите станаха многоядрени преди много време; всъщност вече не настройвах бази данни, когато това се случи. Нямам идея каква разлика има всъщност, сега като се замисля.
Имаме, знаете, 3D Xpoint и PCM на IBM се появяват като допълнителен слой памет и имаме SSD дискове, но знаете ли, те заместват въртящата се ръжда. Но SSD дисковете могат да варират в скоростта. С толкова много можете да имате паралелен достъп и това ги кара да вървят невероятно бързо - близо до скоростта на RAM. И имате всички паралелни хардуерни архитектури.
И това е всичко, знаете, разходите падат, което е наистина хубаво нещо, но това е всичко, което правите - знаете, ако вземете следващото издание на база данни и след това започнете да го внедрявате на машини, дори някои от това, всъщност сте изгубили всяко чувство на червата, което може да имате за начина на поведение на данните, защото латентностите са просто много, много различни. И тук знаете, имате четири слоя, а не три слоя за съхранение.
Проблеми с базата данни. Получавате ентропия на базата данни - разпространяващите се случаи са много често срещани. Базите данни се използват като шкафове, което всъщност беше този пример, който дадох. Много малко бази данни се самонастройват, а тези, които твърдят, че се самонастройват, всъщност не са толкова добри, нали знаете. Но другото е, че много малко бази данни са правилно настроени. Трудна работа е да можеш да балансираш натоварванията. Искам да кажа, че когато мислите за база данни, какво може да прави база данни за период от 24 часа, натоварването може да е много, много различно. Базата данни трябва да има особено истински склад за данни.
И следователно, настройката, която не е тривиална материя, знаете, защото това, което правите, е настройка на параметри, които трябва да се погрижат за цял набор от натоварвания за даден момент от време. Това е трудна работа. И SQL трябва да бъде настроен специално за SQL JOIN. Те могат да бъдат изключително, знаете, отнемат ресурси. И ако базата данни има материализирани изгледи, за да бъда честен, трябва да проучите използването на тези, защото те ще направят всичко да върви невероятно по-бързо. И това изисква някой, който разбира натоварванията и разбира SQL трафика и така нататък и така нататък.
И повечето компании използват много малко DBA - много скъпи. Познавам доста големи компании с, например, трима момчета, знаете, голям брой случаи. Наистина, те струват много, това е трудна работа по отношение на сложността. Те се нуждаят от инструменти.
И мисля, че това е всичко, което имам да кажа. О да. Нека предадем на Dez, да видим какво има да каже Dez.
Дез Бланчфийлд: Благодаря ти, Робин. Това е мащабна тема. Ще продължа към нещата, които мисля, че са ефективно ежедневните предизвикателства, пред които сме изправени. Тъй като нека си признаем, има цяла библиотека от книги, написани по тази тема. Кой не е ходил в техническа книжарница и е открил стени и стени от книги, написани само на общата тема за работата на базата данни и настройката на базата данни и мониторинга. А понякога това е чудесен начин да убиеш време.
Общата тема: получаване на заявки за ефективност. Има редица различни части на организацията, които изпотяват тази тема - на вашето ниво на крайния потребител, по мое преживяване, знаете, хората просто изпитват производителност, че нещата са бавни. Въртящите се колела отнемат известно време, за да се върнат запитванията. В противоположния край на спектъра имате хора от инфраструктурата и мрежата и съхранението, които биват пребивани от специалисти по бази данни, защото нещата не вървят толкова добре, колкото очакват. И това е много широк спектър, според моя опит, нещата, които могат да повлияят на живота ни в този спектър.
Ако се замислите, от физическото нагоре, знаете, просто компютърното пространство. Има памет, знаете ли, RAM, ако искате - дисково пространство, мрежа и всички битове около това. В това пространство ние имаме, знаете, тя съхранява мисълта, че, да речем, че, знаете, по-добре е да използвате суров диск или JBOD и просто, знаете, да издигнете възможно най-бързо диска и да пуснете база данни подредете слоя за защита на данните. Други хора са големи почитатели на RAID, излишния масив от евтини дискове, и имат различни религиозни преживявания с RAID 0, 1, 3, понякога 5 и 6 различни видове ивици или репликиране на диск, в случай че твърдият диск се провали. Дори на ниво съхранение и инженерно ниво, все пак имаме хора, които имат различни гледни точки и опит относно производителността, по видове съхранение.
Независимо дали става въпрос за директно прикачени дискове и самите сървъри, или дали е свързан през фибро канал с някаква форма на мрежа за съхранение, независимо дали това е памет, монтирана от сървър някъде чрез iSCSI, или е Ethernet, например. И това е преди дори да стигнете наистина до слоя на базата данни, където, знаете, видовете неща, които приемаме за даденост - знаете, просто поддържайки това, както Ерик очерта, знаете, как наричаме разговора с вашите данни, Просто можем да идентифицираме модели и смислени модели, за които смятаме, че можем да започнем да се гмуркаме и да търсим проблеми с производителността.
И това е много широка тема, така че аз ще се гмурна в две области, където според моя опит, вложеното време и енергия и усилия получават добри резултати. Така че, нека бързо да прескоча до първото от тях. И аз само шеговито тръгнах да търся снимка на нещо, което имаше скелет отвътре и кожа отвън, но блокът Lego вероятно беше най-малко ужасен. Но в много отношения така си представям и мислено представям предизвикателството, с което се сблъскваме понякога с аналитични платформи и бази данни, които ги подкрепят. И това е, че вие наистина само като потребител и краен потребител или дори разработчик често виждате слоя кожа на фурнира, но всъщност това е скелетът отдолу - това наистина е проблемът, върху който трябва да се съсредоточите.
Знаеш ли, че в този случай, когато мислим за нещата, които могат да повлияят на ефективността на базата данни и аналитика в резултат на този конкретен ден, постиженията на производителността, основната инфраструктура и просто наблюдението на тази основна инфраструктура, както както очертах само преди малко вашия диск и памет и процесор. И както подчерта д-р Робин Блур, предизвикателствата сега във виртуализацията и нещата, които се случват в самите чипове, и производителността до основно ниво, както и количеството памет, което сега се влага във всеки чип във всяко ядро. Това са много технически предизвикателства, на които трябва да се обърне внимание на ежедневния човек.
Поддържане на мониторинга на заявките. Знаеш ли, едно от предизвикателствата около мониторинга на заявките и опашките за заявки е например - искам да кажа, SQL като език и инструментите на базата данни, които се използват около инструментите за анализи, са много мощни и по-специално SQL като език. Но с тази сила и простота идва и в много случаи и това е, че ако не е приложение, което прави едно и също нещо отново и отново, написано от добър разработчик и забелязано от добър DBA, може да бъдете хора, които правят неструктурирани заявки.
И проблемът в това е, че е доста лесно да научите малко SQL и да започнете да правите заявки, но в резултат на това не е задължително да имате всички умения и опит и знания, за да знаете дали правите добро или лошо нещо да се направи базата данни. Така че непрекъснатото изпълнение на една и съща голяма, широка, грешна може просто да свали сградата. Продължаването на мониторинга на заявките е интересно предизвикателство.
Само следене на времената за реакция до това какво прави платформата и какво получават потребителите. Отново знаете, без правилните инструменти това не е нещо, което просто интуитивно гледате на нещата и си мислите: „О, мрежата работи бавно“ или „Паметта на потребителя не работи добре“ или „Индексите се представят лошо "Или" са подуване на корема. "
И тогава, знаете, как да стигнете до момента, в който вие, след като видите проблем с него, как го разглобявате и разединявате и се справяте с цялото предизвикателство за лошо структурирани заявки? И знаете ли, че това е ad hoc запитване, че някой работи на ръка, или това е инструмент за анализиране с предния панел на таблото, който се представя лошо, защото задава въпросите по грешен начин или е просто наистина, наистина лошо написано парче код?
И след това, правийки този итеративен път, Ерик каза в настройката първоначално, знаете, просто итеративно преминаване отново и отново и отново и фина настройка на тези работни процеси. Знаеш ли, какви работни процеси изпълнявам, как се изпълняват, колко често те работят, какъв код работи срещу тях, къде се изпълняват срещу него в процесора и паметта и диска и мрежата? Да, това е просто наистина, наистина техническо предизвикателство.
И тогава нирвана, която хората търсят в този свят, като същевременно се измества от историческа анализа и настройка на производителността и сигнализира за вашата среда, което е чудесно да видите, защото може да получите план в бъдеще за нея, ако знаете защо нещата вървят бавно вчера сутринта в девет часа. Но това не ви помага в момента и не помага на плана ви да върви напред.
Мисля, че планирането на капацитета и оразмеряването и мащабирането и настройката, така че знаете, мисля, че има тенденция, която наблюдаваме сега, където има промяна в много големи среди, където хората имат големи платформи за бази данни и широко разпространени среди на база данни от историческо предупреждение и планиране до предупредително предупреждение и планиране, където те искат да знаят какво се случва в момента и да могат да планират това да продължи напред. Или ни свърши паметта и ще ни свърши памет в следващия час и какво можем да направим за това? Какво планиране на капацитет можем да направим в реално време?
Извинете ме. Стига се дотам, че, знаете ли, само цялото предизвикателство за откриването на тези препятствия пречи по същество на това, което ние наричаме анализа на течности, и превръщайки това в норма във вашата организация. Както можете да видите, това е нетривиално предизвикателство за, знаете, просто ежедневните страхотни, немити маси. И все още е нетривиално предизвикателство за дори по-разумните технически.
Знаеш ли, ако е трудно за простосмъртните, как да направим това нещо възможно? Защото, знаете, повечето от това са неща, които редовните потребители не могат да разрешат, а ние може да имаме някои специални инженери на бази данни, разработчици на бази данни, разработчици на кодове, програмисти, но те все още трябва да могат да разделят средата. Трябва да се разделят, знаете, проблеми като хората, които използват повторно код.
Знаеш ли, едно от най-лошите неща, които съм виждал в това пространство около постиженията на производителността в аналитичните платформи при много големи разгръщания на инфраструктурата на сървъра на бази данни, са хората, които вземат парче код, парче SQL или открадната процедура, която те не направиха ' не пишат и те не знаят дали това е добър или лош код и просто го използват повторно, защото това им дава желания резултат. Но се оказва, че може би е било просто нещо, написано в движение, за да се получат един или два резултата, като доклад - някой бързаше.
И така хората използват сложен код, който не са написали, и просто го шамарят в разработка на приложение, без да знаят, че всъщност наказват задния край. Дори само да наблюдавам това постижение и да гледам откъде идват запитванията и да пробиваш, това, разбира се, е ежедневно предизвикателство.
Основни поведенчески неща като предварителни данни за поетапно изпълнение, където е възможно. Нещата, които само изпитват, ви учат само като изтриване на индекси, ако ще извършвате групов внос, а след това преиндексирате, така че индексите да не се поддържат, когато дърпате в терабайти данни. Знаеш, че без подходящите инструменти това е почти невъзможно да се види, защото не знаеш, че индексът е забит.
Оптимизирането на индексите редовно е нещо като 101, но какво ще кажете, когато правите групов внос или, знаете, да създадете таблица за заявки, ако някой наистина направи голямо запитване? Знаеш, че това може да бъде голям хит на производителността и отново, ако не следиш, нямаш инструменти, за да видиш това, този вид се случва на заден план и не знаеш как да се справиш с него,
Ограничаване на заявките само до броя на колоните, от които се нуждаете - искам да кажа, че звучи наистина основно, но отново, ако не можете да го видите, не знаете, че се случва, а след това просто се случва на заден план и ви боли, към теб.
Знаейки кога и къде да използвате временни таблици, създаване на големи изтривания и актуализации. Отново всички много прости неща, но без тази видимост, без инструментите за това, те просто седят на заден план и продължават да ви нараняват и просто продължавате да хвърляте повече памет или процесор в среда на базата данни, за да получите по-добра ефективност на платформата за анализи, когато наистина би трябвало да можете да проучите подробностите за това, което ви боли, и да се обърнете към това конкретно нещо. И тогава, знаете ли, неща като ограничения на чуждестранни ключове и как да намерите това, как изобщо знаете, че това е проблем?
Това ме довежда до извода на моя основен момент тук и това е, че знаете, че ежедневно виждаме тези проблеми навсякъде. И тъй като средата на базата данни става все по-голяма и все по-широка и както подчерта д-р Робин Блур тук, ние получаваме все по-сложни екологични модели с времена за бази данни.
А след това и необходимостта от интегриране в някои от големите платформи за данни като Hadoop и Spark, които се появяват, и все повече и повече в даден момент. Според мен трябва да намерим по-добри начини и конкретни инструменти, за да изпълним интелигентно тази работа на платформата в реално време и анализа и диагностика. Защото това струва в реално време и реални пари и неудовлетвореност за крайните потребители и реални долари, ако не започнем да стигаме до инструментите за гмуркане в тези неща.
И с това ще предам на нашите приятели от IDERA, защото вярвам, че те имат добра история, за да разкажат как може да успеем да разрешим този проблем.
Bullett Manale: Звучи добре. Благодаря ви много и ще продължа напред и ще изритам нещата. Тук имам и няколко слайда, и нека да продължа напред и да изведа това. Някои от тях ще прескочим доста бързо.
Само за да ви запозная, аз съм директор на отдела за продажби тук в IDERA и затова това, което правим е доста редовно да говорим с DBA за болките и предизвикателствата, които имат, специфични за, в много случаи, наблюдение на ефективността и подобни неща, очевидно. И ние чуваме много от тази публика и затова мисля, че мога да споделям част от информацията, която получавам от тях редовно, която ще има смисъл. Ще прескоча няколко от тях, защото не мисля, че те са истински свързани с разговора.
Знаеш ли, имам свой списък тук за отговорностите на DBA - прилича много на списъка на Робин и мисля, че е доста последователен. Мисля, че когато говорите с администратор на база данни, все пак е винаги - нали знаете, те са в някои от тези области повече от други и няма рима или причина за това, просто зависи от средата.
Чувате доста по-широк, широк спектър от неща, които хората искат да могат да правят. И много пъти хората, които искат тези неща, не го правят - те ще поискат от тях, а в някои случаи започвате да проучвате това, което наистина искат, и тогава ще разберете, че те наистина търся повече. Те наистина искат повече информация от това, което първоначално смятат, че им е необходима, и когато започнете да пробивате в инструмента, мисля, че точно там можете да започнете да казвате, че водят разговор с данните.
И мисля, че това е наистина интересна фраза и има много смисъл от гледна точка на възможността да се каже, да, добре, ако имате лоша заявка, какво всъщност е лоша заявка? Това е въпрос, който изразходва много четене или запис или процесор? Може да е един, който работи много, може и един, знаете, това е, както казахте, лошо написано.
По отношение на начина, по който ние идентифицираме това, има редица начини, които ще видите по отношение на нашия продукт, продуктът на Diagnostic Manager, който показваме DBA, че те могат да постигнат това. И той е истински гъвкав и мисля, че това е едно от най-големите неща - трябва да имате инструмент, който ще ви помогне при тези проблеми с производителността, дали средата на всеки е малко по-различна.
И ще има много, знаеш, нужди и може би дори неясни изисквания по отношение на мониторинга, така че трябва да имаш нещо гъвкаво и нещо, което ще работи и да може да съответства на средата, която опитваш се да управляваш. Знаеш ли, и аз имам много от тези примери - няма да преглеждам всеки един от тях, но имаш нужда от нещо, което можеш да въртиш напред-назад между една част от данни и друга, и аз ще говорете за това, когато влезем малко в продукта и ще ви покажем това и по отношение на това как го правим.
Но другото, което според мен по отношение на всеки добър инструмент за анализ е, знаете, има някои основни неща, които наистина търсите. Очевидно първо и най-важното не искате инструмент, който ще създаде собствени проблеми при изпълнението в името на изпълнението. Когато казвам да събираме данните без разходи, не говоря за разходите по отношение на, знаете, парични разходи, а по отношение на разходите по отношение на режийните разходи и разходите по отношение на количеството ресурси, които ние ще използвам в името на изпълнението. Определено искате нещо там, което ще помогне.
Имате нужда от нещо, което ще бъде в състояние да вземете данните, които търсите, специфични за проблемите, с които се сблъсквате в рамките на всеки ден, и може да има някои неща, които не са ви нужни и които не искате “ не искам и няма смисъл да събирате тези данни, ако няма да съобщавате някога за тях или ще имате някакви нужди около опита да управлявате тези данни. Например по отношение на метаданните, свързани с ефективността.
Знаеш ли, добър пример е, че няма нужда да бъда предупреден, ако услугата за разпределен транзакционен координатор в SQL е отпаднала, ако не искам тя да се изпълнява на първо място. Така че не ме предупреждавайте, не събирайте данните срещу нея - не ми трябва тази информация. Така че истинското значение е възможността да включвате и изключвате тези неща.
Възможността също така, след като го съберете, да имате достъп до тях доста бързо - не е нужно, знаете, да пускате и масажирате данните, да манипулирате данните - да можете да го правите бързо и ефективно. И тогава след като разполагате с данните, очевидно е наистина важно да можете да го разберете.
Това е мястото, където с нашия - с, като например, продукта Diagnostic Manager, който днес ще ви покажа малко - този продукт, знаете, бих искал да ви кажа, че този продукт ще заменете и бъдете DBA в кутия. Реалността е, че изисква известни познания за това какво е вашата среда и какво се опитвате да постигнете. Очевидно е да имаш някакво очевидно разбиране на ролята на самата DBA.
Това, което се опитваме да направим, е да се образоваме чрез помощта и чрез други методи. Но винаги ще искате да свържете това, очевидно, с някакъв тип нива на опит или с някой, който има някакви познания какво да прави, след като получат данните. И възможността да има човек, който може да зададе правилните въпроси на даден продукт и да проведе този разговор с данните, очевидно е от ключово значение. И тогава очевидно е в състояние да осмисли данните.
След като разполагам с информацията, мога да разбера това на правилните хора. Моите разработчици, моят оперативен екип - който и да е, може да се наложи да се интегрирам с други продукти, като имам куки, за да мога да го направя. Това са реално важни неща. И тогава, очевидно, не на последно място, ако трябва да знам повече, да мога да го направя. Независимо дали означава да включите още малко, за да бъдете събрани, или дали това означава да отидете малко по-задълбочено в данните. Надявате се, че с инструмент, който ще бъде, знаете, че помагате за ефективността, вие получавате всички неща, които са ви необходими, за да можете да отговорите на тези въпроси.
Единственото нещо, което не съм сложил тук, което смятам, че вероятно си струва да отбележим, е, че ви трябва инструмент, който ще ви помогне да разграничите кое е нормално и кое не е нормално. И мисля, че това е голямо, защото, знаете, има много продукти за предупреждение и неща, които са навън, но ако получавате сигнал и сигналът е фалшив сигнал, това не ви носи никаква полза ; Това е повече загуба на време и ще намали ефективността ви повече, отколкото ще им помогне. Знаете, това са някои неща, които бих имал предвид.
Когато говоря за продукта, за който обвързвам всички тези неща с пакета продукти на IDERA, това е продуктът Diagnostic Manager, който мисля, че той има основните характеристики в това, което говорим тук, по отношение на базата данни настройка и изпълнение и мониторинг и подобни неща.
Хората търсят мониторинг на ниво предприятие; те искат да имат достъп, да могат в един екран да знаят, че нещата работят така, както трябва да бъдат. Или искат да могат, очевидно, ако има проблем, да видят къде е проблемът и след това да могат да се справят с него. Наистина голяма част от, според мен, това, което хората търсят с тези типове начини, по които наистина можете да усъвършенствате представянето си.
Другото нещо, което очевидно върви заедно с това, е, че не мога просто да работя в настоящето и трябва да мога да се връщам през периоди от време, независимо дали това означава да гледате заявки, които се изпълняват лошо или дали това означава, вие знаете, гледайки начина, по който самият VM на хоста се е държал по отношение на ресурсите. Всички тези неща, които трябва да можете да правите и няма да седите там и гледате конзолата си 24 часа в денонощието, 7 дни в седмицата.
Ако сте на почивка или ако сте посред нощ, или каквото и да е, трябва нещо, което ще може да се върне назад във времето с вас, за да можете да кажете какво става в инстанцията в времето, когато имахме проблем. И възможността да направим това, още веднъж, ефикасно и бързо и да бъде в състояние да се впусне в него определено е важно парче от гледна точка на тази дискусия. И бих казал, че вероятно това е едно от по-важните неща по отношение на това, което хората търсят. Винаги търсят този прозорец в миналото, защото това е наистина im - Знаеш ли, не искаш да седиш там и да чакаш нещо да се случи отново.
Следващото нещо в списъка е наистина просто обвързване с това, за което говорихме по-рано, със самото изпълнение на заявката. И ще ви покажа няколко различни примера в продукта Diagnostic Manager, как правим това, което, сигурно в края на деня, ще ви предостави много възможности около самите запитвания по отношение на какво искате да се съберете.
По отношение на това дали се интересувате от заявки, които причиняват болка в ресурсите, консумация на процесор или консумация на I / O. Независимо дали става въпрос за заявки, които отнемат дълго време, или заявки, които по принцип може да не са най-лошите обидни по отношение на производителността, но могат да се изпълняват толкова често, че самата честота на самото изпълнение може да бъде проблем. И очевидно възможността да забележите тенденции във времето и с тези заявки е важна част от него.
Има много различни начини, по които можем да направим това в този продукт и мисля, че очевидно това е наистина важно парче за повечето DBA. И дори да нямате собствени вътрешно разработени приложения, все пак е хубаво да можете да отидете до своите доставчици на софтуер и да кажете: „Хей, знаете ли какво? Знаеш ли, два часа следобед всеки ден, когато тази работа излита “, или каквото и да е, „ Това е приложението ви, което причинява това и ние трябваше да го оправим. “Така че дори и да нямате пълно контрол върху самия код, все още е хубаво да се знае кога възникват проблеми.
И тогава, знаете ли, другата част просто очевидно е по-активна. Да можеш да бъдеш първият, който знае, умееш да разбираш кога възниква проблем. За да не можете да бъдете първият, който знае, за да можете да го коригирате, но в много случаи, когато имате нужда, е нещо, което ще бъде в състояние да автоматизира отговор, в много случаи също. Можете, например, да знаете, вместо да получавате имейл, казвайки: „Ей, трябва да поправите това“, ако съм на среща или ако съм, знаете, на пътя или каквото и да е аз Правя, очевидно е много хубаво да мога да кажа, че имам нещо на мястото си, което ще може да се справи с това по автоматизиран начин.
И ако не е адресирано по автоматизиран начин, най-малкото можете да бъдете първият, който знае, за да можете да предприемете коригиращи действия или да се свържете с някой, който може. И така, това очевидно са важни парчета, за да знаете, тези видове проблеми, които може да срещнете по отношение на мониторинга на вашите машини и вашите инстанции и самата анализа.
Сега говорих за това по-рано, което е гъвкавостта на нещата. Не мога да подчертая това достатъчно, бидейки способен да кажа, разбирате, ако има нещо, което не се следи, да имам функционалност в продукта, за да можете да добавяте тези неща към да бъдат наблюдавани. И в смисъл с примера на Diagnostic Manager, очевидно, знаете, WMI броячи, броячи, броячи на SQL Server, можете да създадете свои собствени заявки.
Можете дори да знаете, че ако искате да изтеглите данните от вашата vCenter среда или от вашата Hyper-V среда, в резултат на анкетата, която се провежда и може да го правите редовно и издърпайте тези данни и бъдете в състояние да ги видите. И още веднъж, завъртете от едно място на друго, докато разглеждате тази информация.
Това са видовете неща, които от гледна точка на това, което виждам хората да питат, когато говорят за инструмент, който ще им помогне по отношение на настройката и производителността - продуктът, който ще ви покажа само в на второ място е Diagnostic Manager и той поддържа всичко от 2000 г. чак до 2016 г. Той е специфичен за SQL Server и затова следим как управляваме тези неща. Няма агенти на самите инстанции, които наблюдават инстанция.
Това се връща към събирането на информацията с малко разходи, че, знаете, опитахме очевидно повече да събираме тази информация, да не използваме и много ресурси, нали? Опитваме се да използваме нещата, които SQL Server вече ни предоставя и да ги подобряваме, независимо дали става дума за динамични изгледи на управление или дали това са разширени събития или какъв е случаят от гледна точка на самата колекция. Да бъдем в състояние да използваме тази информация и да я подобрим е един от нашите мандати.
Сега, ако разгледате това наистина бързо, няма да преразглеждам архитектурата твърде много подробно, но имам резервно хранилище с всички наши исторически данни, които можете да управлявате и можете да съхранявате толкова дълго, колкото ти искаш. Можете дори да изберете типа информация, която искате да запазите, и за колко дълго. Това се връща към това, като се събират съответните данни и се оставят ненужните данни. Ако искате да запазите заявките в продължение на пет дни, които са основни и след това запазете сигналите си в продължение на две години, това зависи от вас и това е напълно вашият прерогатив да можете да направите това.
Редица различни конзоли с този продукт. Имате уеб-базирана версия, имате и дебела клиентска версия. И така това е да имате гъвкавост да прескачате браузър и да виждате какво се случва или ако имате лаптоп, където имате инсталиран специален клиент, един от тези подходи би работил за вас.
Сега това, което бих искал да направя, е да направя бърза демонстрация. И бих посочил - връщам се към този друг слайд тук - който имаме, току-що добавихме, точно като БЮР за онези, които са запознати с продукта, имаме ново предложение, което е Diagnostic Manager Pro. Професионална оферта, която включва и нещо, което наричаме анализ на натоварването.
И наистина става въпрос за възможност за интерактивен преглед на много големи периоди от време и преминаване от този, знаете, 30-дневен изглед към пет минути минутен изглед с около три щраквания. И да сте в състояние да видите шипа в производителността или проблема в тесното място, което може да бъдете в състояние да знаете, бихте могли да видите на много високо ниво и да пробиете до много ниско ниво. И особено, че и днес това е ново за продукта.
Но това, което искам да направя, е просто вид първо начало и искам да поговорим малко за това въртене и връщане напред-назад. И аз изведох пример и ще споделя на екрана си тук. И, да видим … Ето и ние. Моят екран. И ме уведомете, момчета, че можете да го видите.
Ерик Кавана: Ето.
Bullett Manale: Там всичко е наред? Добре. И така, това, което гледате в момента - а това е продуктът на Diagnostic Manager - и просто исках да ви дам един вид демонстрация на високо ниво за това, което се случва тук. В този конкретен пример това, което правим е, че ви показваме заявките, които са свързани с чакания. И така, когато говоря за възможността да се върна напред-назад, да се пробие по-дълбоко и да се върти, това е - този изглед тук е добър пример за това. Мога да отида от изглед на времева линия, както виждаме тук, който ще се покаже сега. В нашия случай разглеждаме самите чакания и категориите на самите чакания. Можем да видим изявленията, които са обвързани с тези чакания, можем да видим приложенията.
Забележете, че е на изглед на времева линия тук, така че мога да идентифицирам тази информация линейно на базата на момента, когато проблемът се е случил, но след това отново, ако искам просто, още веднъж да се завъртя и казвам: „Знаеш какво това от различна гледна точка, „нека продължим напред и да разгледаме това от гледна точка на„ Искам да видя запитванията или чаканията или приложенията, които ми причиняват най-много болка, и да ги класирам. “И това е, което ние„ ще видим чрез „заявка чака по продължителност.“ Сега виждаме самите приложения, които ми причиняват най-много болка или чакания.
И тогава, ето частта, която наистина е най-важната част, е в състояние да изолира тези неща. Виждам, че това приложение NoSQL започва от тук. Това ми причинява доста време за изчакване, а и 25-те секунди време за изчакване в рамките на този 30-минутен прозорец, в който сме пробутани. След това мога да изолирам това приложение и виждам изявленията в този случай, които пряко засягат този конкретен случай.
И така това е само един пример за това, как бихте могли да идентифицирате тясно място, да можете да класирате информацията, като сте в състояние да поставите приоритет на проблемите, които трябва да бъдат решени първо. Това са всичко, което трябва да вземете под внимание. Знаеш, че можеш да коригираш проблеми през целия ден, но ако коригираш проблемите, които са в дъното на списъка, които трябва да бъдат коригирани, значи губиш времето си. Имате възможни разходи, свързани с това.
Ще ви дам още един пример и това е малко по-различен пример. Вместо конкретно да посочвате проблем или да насочвате към дадена област, вие също се нуждаете от инструмент, който ще може да ви помогне в широк смисъл, за да можете да кажете: „Ей, имали ли сме някакви проблеми?“ Или „Дали има неща, които мога да направя, за да подобря представянето? “и да имам нещо задкулисно, да гледам какво става. И в този случай това може да бъде свързано с конфигурацията; това може да бъде свързано с, знаете, начина, по който се управлява здравето на самата инстанция. И също очевидно нещата с изпълнението.
Ако отида на този бутон Анализ тук, нещото, което ще ви покажа, е, че в рамките на този продукт имаме и своеобразно проактивно изброяване на неща, които могат да бъдат изпълнени в класиран формат, който по същество ще ви даде представа в нещата, които вероятно ще ви доведат до повишаване на ефективността ви в този случай или увеличаване на здравето на този инстанция. И е в класиран формат, в смисъл, че имате тази способност да видите кои са по-склонни да подобрят ефективността си, специфична за определен тип проблем, който е идентифициран.
И така, когато гледам тези неща и ги идентифицирам, не само виждам, че имам проблем, а в много случаи имам и скрипт, който може да бъде изграден автоматично, за да коригира този проблем. Но в много от тези случаи имаме и външни връзки, които ще реферират вида на проблема, който срещаме, и тогава защо даваме и тази препоръка, така че получавате този образователен аспект на нещата. Което, за пореден път, мисля, че е много важно, когато говорите за, знаете, коригиране на проблеми.
Не искам просто да следвам сляпо тези препоръки, искам да разбера защо се правят тези препоръки. И може би съм старши DBA, който се занимава с това от 30 години и имам нужда от нещо, което ще трябва, да знаете, да проверите - или да поставите точките и да пресечете тези, в случая - или може би съм младша DBA и Имам нужда от малко помощ по отношение на разбирането на тези проблеми, тъй като те се случват и защо тези препоръки се правят.
Както казах, просто ще ви преведа през няколко различни части на продукта. Този инструмент е, нали знаете, съществува от 2004, 2003 г. И наистина има много разработки, вложени в него, много информация, така че няма смисъл да се опитвам да ви покажа всичко тук. Но мисля, че едно от нещата, което си струва да се отбележи е, че когато влезем и започнем да говорим за всички неща, които можете да наблюдавате, и всички неща, за които можете да предупредите, отново, връщайки се към тази гъвкавост на нещата, ето списък на всички елементи, които наблюдаваме.
Сега, това не означава непременно, че искам да считам, че тези неща са в състояние на предупреждение, ако излязат от удари по отношение на прага, така че можете да включите и изключите тези неща. Това се връща към това: „Ей, трябва само да правя определени неща с определени показатели. Трябва само да знам, че предупреждавам за определени проблеми. ”И да бъда в състояние да се уверим, че няма да ви наситеме с куп лъжливи позитиви. Имате не само възможността да включвате и изключвате тези неща, но в много случаи ще забележите, че ние също предоставяме тази лента на нормалност, както е свързана с всеки показател. Така че, ако гледам на тази конкретна, в случая базова линия, бих забелязал, че прагът вероятно е по-висок там, където са в момента.
От другата страна на монетата е, ами ако имам екземпляр на SQL, където проследявам някои показатели и тези показатели, поради каквато и да е причина, праговете, които съм задал, са неправилни? С други думи, праговете са далавера в средата на мястото, където всъщност седи основната линия, което означава, че ако имам сигнал, свързан с този праг, вероятно ще получавам сигнал за нещо, което е нормално събитие. И така, в подобни ситуации можем да ви дадем това разбиране и отвсякъде.
За всички показатели в този конкретен случай виждам онези прагове, които вероятно ще покажат фалшив положителен резултат по отношение на това какво е нормално и кое не. Това ще бъде нещо, което би се считало за нещо нормално за използване от паметта и ако исках да увелича този праг, бих могъл, но това е идеята с базовите линии.
И страхотното нещо за продукта Diagnostic Manager от гледна точка на самите базови линии е способността да се задават множество базови линии. И може да попитате: „Защо бих искал да го направя?“ И отговорът е, добре, ако имате прозорец за поддръжка, който работи от, да речем, в полунощ до 4 часа сутринта, където наистина облагате ресурсите си, наистина използваме ресурсите колкото е възможно повече, тогава искаш да можеш отново да се преместиш и искаш да се преместиш малко и да кажеш: „Виж, ще променим праговете си за това.“ И всъщност можем динамично да коригираме нашите прагове, в зависимост от това, в каквато и основна линия се намираме, в зависимост от времето на деня или деня от седмицата и т.н., че това е така. Така че след това динамично ще коригира тези прагове за нас.
Нека направим крачка отново. След като идентифицираме тези прагове, след като преминем и по отношение на настройка на сигнали и известия и запознаване с тези ситуации, които могат да се случат, отново, тук е от първостепенно значение гъвкавостта. Искате да можете да сигнализирате в конкретни ситуации. В други ситуации може да искате да изпратите имейл до някой друг, може да искате да стартирате скрипт на PowerShell, може да знаете, че списъкът продължава.
Може би бих искал да се интегрирам с нещо чрез SNMP капан или дори директно с, например, SCOM. Въпросът е, че имате гъвкавостта да го направите и можете да задавате каквито и да е условия, които да гарантират, независимо дали става дума за много широкообхватно състояние - знаете, моят процесор и памет или каквито и да е ресурси - във всички мои случаи или може би имам много специфичен тип неща, които искам да наблюдавам, защото, когато открия, че сме в нарушение, искам да изпълня много специфичен и насочен сценарий към този проблем. Това е мястото, където бихте могли да правите такива неща вътре в продукта Diagnostic Manager, просто, знаете, по отношение на предупреждението и уведомяването и да бъдете гъвкави от тази гледна точка.
Сега, няма да премина през всички аларми и всички тези добри неща. Исках да говоря за докладите. И още веднъж, да можете да вземете информацията и да използвате тези данни по много различни начини - и това отново се връща към разговора с вашите данни. И много хора, когато за първи път видят този продукт, си мислят: „О, добре, ще имам инструмент, който ще ме предупреди при проблеми. Това е, от което се нуждая. "И реалността е, нуждаят ли се от този инструмент, но другата страна на това е, ако наистина - те също се нуждаят от инструмент, който да им помогне да вземат решения, и те могат да използват тази информация, която ние сме събиране в името на представянето, а също и в името на алармата, за да може да ви помогне да вземате решения по пътя, движейки се напред.
Знаеш ли, добър пример са прогнозите ми за растеж в базата ми. Ако имам конкретна база данни, която се разраства, мога да насоча към тази база данни или дори множество бази данни, за да мога да видя какви са темповете на растеж. Не ви показваме на базата на това, което знаете, какво е днес; ще го прогнозираме въз основа на миналия растеж, който преживяхме.
Ако имам няколко бази данни тук - които случайно имам, представете си това - бих могъл да вляза и да кажа: „Нека вземем последната, знаете ли, годишна стойност на данните, нека да ги съпоставим по месец и по извадка. процент от месеци, нека да продължим напред и да видим какъв растеж ще видим през следващите три години, или 36 единици. “В този случай можем много бързо да отговорим на този въпрос. Сега, опитайте се да направите това сами, нали? Опитайте се да го направите за толкова време, колкото аз го направих сам. Ще ви отнеме известно време.
Сега, за да подчертаем още повече това, нека вземем още един доклад, който е моят доклад за най-добрите сървъри. Представете си, че имам сто производствени инстанции, които в случая не го правя. Но ако някой дойде при мен и каже: „Имам нужда да ми кажете - ние ще поставим тази нова база данни там за това страхотно ново приложение; това ще промени всичко, както го знаем; това ще направи живота толкова прекрасен. О, между другото, самата база данни ще бъде наистина I / O интензивна, или ще бъде интензивна процесора, или наистина интензивна памет … ", каквото и да е попълване на празното, искам да да мога да видя от всички мои производствени инстанции, къде има смисъл да поставям тази база данни? И мога да класирам всички мои случаи един срещу друг от гледна точка на условния тип, независимо дали става въпрос за процесор, памет, диск или какъв е конкретният случай. И така, смисълът тук е да можете да отговорите на този въпрос бързо и ефикасно и да вземете правилното решение, а не да гадаете кога го правите - всичко това очевидно е наистина важно и имате нужда от нещо, което ще ви помогне.
И когато говорим за аналитичност, тя може да варира от всичко подобно на това, за което говорим с планирането на капацитета, до, знаете ли, сигнали, които ежедневно се изпълнявате, които биха могли да се справят с процесора, както както и очевидно самите запитвания, дали има блокиране и така нататък и така нататък.
Друг пример за това би бил, ако отида тук в административния раздел тук - всъщност го връщам обратно, алармиращия раздел тук - да питам депозитаря на историческата ни информация за неща, които са се случвали в миналото. Имах ли блокиране, което се случи в моята производствена среда? Не знам, нека разберем.
Мога да се върна към моя продуктов етикет и мога да кажа за всички мои производствени случаи, като се има предвид период от време, за всеки показател, който искам да идентифицирам. Ако влязох в състояние на предупреждение, в нашия случай, да кажем блокиране чрез броене, а не за секунди блокиране, и мога да се върна и в този случай няколко месеца, ако трябва - или в този случай случай, един месец - и виждам това блокиране. Виждам кога е започнал, мога да видя кога е приключил и мога да проверя всеки от тези интервали на издърпване, ако трябва, за да видя спецификата на блокиращия инцидент в себе си. Трябва да можете да имате нещо, което е много бързо, да можете да намерите това, от което се нуждаете и търсите, а не да въртите много цикли, за да го направите. И така, мисля, че това също е важно.
Последното нещо, което искам да ви покажа - и да ви покажа този продукт, продуктът на Diagnostic Manager - е дали, както споменах преди, влязохме и добавихме още един компонент към нашия SQL Diagnostic Manager Професионална оферта И това е компонентът Анализ на работното натоварване. И това е уеб-базирана версия на това, в случая, който ви показваме тук. Но смисълът тук е, че това ви позволява да разгледате наистина широк период от време или много специфичен период от време, и от, знаете, няколко щраквания са в състояние да видите кода, пряко свързан с проблеми, които може да са се случили,
Като пример за това, ако гледам четириседмичен изглед, тук мога да видя, точно тук, всички шипове по отношение на базите данни и работата на тези бази данни и където видяхме активност за изчакване в тези бази данни. Сега и можете да видите, ако виждам шип тук, ползата от този инструмент само е в състояние да подчертае тази малка лента точно там. И тогава, когато правя това, всички неща тук се променят. Бихме могли да видим базите данни, щяхме да можем да видим, че всички команди са обвързани с това, което се намира зад тази лента.
Същото нещо, ако казах: „Нека разгледаме последните четири часа“, а не последните четири седмици. Все още мога да го направя. Все още мога да подчертая този период от време и след това оттук - ето още веднъж, тук са моите основни точки - всички тези неща тук мога да свържа. Най-горните SQL изявления, виждам онези заявки, в този случай, които предизвикват изчаквания, свързани с консумацията на процесора. Само като пробивам в тях, мога да видя онези заявки, свързани тук - whoops - и също така мога да видя програмите и какво ли още не е свързано с това.
Тук получавате много представа и не само това, но можете да видите, когато слезете до командното ниво, това ще ви каже нещата. Ще ви каже дали вижда тежки оператори, след което можете да видите плановете за изпълнение. Това отнема малко време, защото е доста обширно да се зареди този. Но смисълът тук е, че имате много различни начини да прегледате данните, да видите какво точно търсите, а след това очевидно ще можете да предприемете действия от там, както трябва, така че и този предприема по-дълго, отколкото обикновено, така че ще го оставя на това.
И така с казаното, ще го предам обратно. И да се надяваме, че това беше добра демонстрация на рода на нещата, за които говорихме. И както казах, самият продукт, който използвахме, за да дадем тези примери, съществува доста дълго време и затова много други неща бихме могли да поговорим и да ви покажем, но ако това е нещо, което представлява интерес от вас, винаги можете да излезете на нашия уебсайт и да го изтеглите и да си поиграете с него.
Ерик Кавана: И аз обичам, че показвате цялата тази подробност. Ако се върнете няколко екрана - дори този екран е доста добър. Тъй като има толкова много различни начини да се визуализира какво всъщност се случва и мисля, че това е един от по-недооценените аспекти на изчислителната техника в наши дни. Това със сигурност е база данни, в много отношения имам тази шега, казвам: „Все още се учим да говорим силиций.“ Все още се учим да разбираме как да виждаме какво се случва и до вас, беше много добре прието, трябва да проведете този разговор с данни, за да разберете по-добре какво става, защо нещата вървят бавно, защото има толкова много възможни проблеми. И, разбира се, IDERA има редица различни продукти, един от които са старите прецизни продукти, които смятам, че могат да бъдат допълващи това.
Но може би Робин, ще ти го предам за няколко въпроса, а след това Дез, няколко въпроса от теб и тогава може би някой от публиката, не се срамувай. Изпратете ги сега.
Bullett Manale: Робин, не спираш ли да спиш ?
Робин Блур: Да. Добре е, просто се свалям от заглушаване. Трябва да кажа, невероятно е - нещото, което всъщност ме впечатли като най-драматично за този инструмент, защото наистина - особено като се има предвид фактът, че е съвсем очевидно, че цяла поредица от измерения, в които просто не сте влизали - нещата, които всъщност, Мисля, че най-впечатляващо е това, трябва да е наистина много добър начин за обучение на DBA. Знаеш ли, така е - така че когато за пръв път се захванеш с работа с база данни и всъщност не знаеш много за това, което всъщност се случва в база данни, всъщност е наистина много трудно да разбереш. Така че това се използва много, специално за обучение? Бих го използвал.
Bullett Manale: Да. Искам да кажа, че когато казвате обучение, имате предвид нещо като тренировка в ход като нещо като DBA, нали? От гледна точка на…
Робин Блур: Да, да, да, да. Учебно средство. Знаеш ли, а.
Bullett Manale: Да, бих си помислил със сигурност, че това е така и още повече, че ние добавихме това, компонента Analyse, който ви показвахме по-рано, който съдържа всички препоръки, които са обвързани с него. Но мисля със сигурност, че ще намерите, в рамките на помощта и много различни области в продукта, той ви предоставя, знаете ли, много поглед. Много информация.
И реалността е, както казах, можете да използвате това, ако не сте DBA. Вероятно ще се окажете, че правите някои търсения с Google и подобни неща, само до общото знание за това, което имат повечето DBA, но можете да ги свържете и определено ще ви помогне по отношение на: „Ей, знаете, хей какво това нещо, наречено фрагментиране? “или„ Защо тази заявка се изпълнява 6 000 пъти? “Искам да кажа, защото тези неща ще ви бъдат изведени и те ще надуят, а вие ще ги видите. Ще видите, че сте, знаете, кое е нормално и кое не. Ще видите нещата, които шипят и нещата.
Като правило се опитваме да настроим това нещо като, по отношение на най-добрите практики. Така че, когато го насочите към инстанция, това ще ви покаже нещата, които са идентифицирани като извън най-добрите практики. Имам предвид, разбира се, знаете, реалността е, че най-добрите практики са най-добри практики и не винаги са реални практики. Но, знаете ли, той ще ви покаже хората, които са извън хората, дори от началната точка, че го инсталирате и ще го насочи към инстанция.
И тогава от там можете да продължите напред, тъй като трябва непременно да коригирате проблемите и да идентифицирате дали това наистина е проблем или нещо, което обикновено се случва ежедневно. И тогава, защото имате много информация, която да помогнете и препоръките, да, абсолютно.
Robin Bloor: Добре. И още един въпрос - но съм сигурен, че отговорът на това е много бърз - е, че имате задълбоченост, за да отидете право до индивидуалното запитване и отделен момент във времето и да погледнете от това измерение, .
Bullett Manale: Разбира се, да. В зависимост от това, което искате да направите, можете да погледнете едноминутен период от време или да прегледате тридневен прозорец на времето или, знаете ли, триседмичен прозорец на времето. И знаете, както казах, зависи от това как искате да погледнете данните, а също и какво искате да съберете. В някои случаи ние събираме само заявките, които достигат праг, който сте идентифицирали. В други случаи можем да съберем, знаете, всяка заявка, която предизвиква изчакване.
Но вие също имате способността да кажете: „Вижте, онези прагове, които идентифицирах, може би е само за писане, или може би е само за четене, или може би просто за процесор.“ Така че, ако приемем, че е надминал този праг, тогава това е какво искате да събирате. Тогава каквато и да е време, което искате да погледнете, ще можете да видите онези заявки, които са обидни, въз основа на това, което смятате за обидно.
Имате много различни начини да разгледате данните. Можете да го погледнете в консолидиран изглед, за да видите, знаете ли, заявките, които - колко задкулисни заявки започнаха, срещу, знаете, всеки един инцидент от тази заявка започва, за да гледате модел, ако искате ще, за да видим дали непрекъснато се влошава.
Но за да отговорите на вашия въпрос, определено можете да посочите каквото и време да пожелаете. Имате това нещо, наречено „Браузър на историята“ - и аз го използвах малко по-малко - но по принцип какъвто и да е моментът, който сте избрали, независимо от деня в календара, който сте избрали, можете да отидете директно до този момент.
В момента гледам на 15 ноември в 19:05 и можем да разгледаме конкретни запитвания. Ако имах такива, които се изпълняват лошо, като се има предвид този период от време, ще можем да разгледаме подробностите за сесията, специфични за този период от време, за да видим какви сесии се изпълняват. Искам да кажа, че тук има цял набор от данни и, както казах, всъщност най-трудната част е може би 30 минути игра с конзолата и намиране как да направите това.
Но след като разберете, че по-голямата част от данните тук са в тази лента и са разделени от тези раздели, и всеки раздел има свой набор от динамично променящи се бутони, които се появяват всеки път, когато щракнете върху него, след това дали гледате реално- време или неща, които се случиха миналата седмица, това е същият процес. По същество гледам точно сега 15 ноември, но мога също толкова лесно да гледам в реално време само като щракна върху този бутон. И аз ще взаимодействам с данните по същия начин.
Но за да отговоря на вашия въпрос, да, има много различни начини за преглед на историческа информация и това се отнася и за самите запитвания.
Робин Блур: Разбирам. Много е впечатляващо. И ми харесва факта, че прозорците се синхронизират, въпреки че това е нещо доста необходимо във всичко, което се занимава с данни в реално време в днешно време.
Bullett Manale: Да. Сигурен.
Робин Блур: Ето само информация, на която всъщност не знам отговора. Тъй като вашите оферти - SQL Server и облакът, можете ли да посочите облака под Ratio?
Bullett Manale: Можете. Можете да насочите това под облака. Когато действително добавите копия, ще ви попита дали е RDS или Azure. Сега ще има някои ограничения, базирани на това, което ни е изложено от облака, така че може да има - има малка разлика по отношение на това, което можем да наблюдаваме, просто защото инструменталното оборудване, в някои случаи, не е няма да се съберем на базата на това, което Microsoft излага.
Сега, ако това е нещо като, знаете, инфраструктура като платформа, като, знаете, или EC2 или нещо подобно, това изобщо не е проблем. Получаваме всичко. И както работим с Microsoft, така и с Amazon; работим за разкриването на тази информация по-подробно. Но абсолютно да, ние поддържаме тези среди.
Робин Блур: Добре, това е интересно. Е, ще предам на Дез, който съм сигурен, че ще ви хвърли въпроси от друга посока.
Bullett Manale: Добре.
Дез Бланчфийлд: Благодаря. Имам две много бързи за вас. Мисля, знаете, първото е, везните, знаете, мисля, че едно от нещата, което ме поразява е, че общата тема на представлението е нещо, за което мислим, когато станем много големи, много големи, много мащабни и широки и терабайти от данни. Гледайки демонстрацията, ми се стори, че това е нещо, което всъщност се отнася дори и за много малките среди, нещо като просто получаване на хитове на производителността.
Какъв вид разпространение виждате в усвояването на това и мислите ли, че това е, знаете ли, мислите ли, че това е инструмент, който има добро, знаете - според мен го прави, така че мисля, че е да - но просто искам да видя какво виждате. По-малките организации водят едни и същи разговори и търсят инструмент за това, или наистина това е нещо в по-големия край на града?
Bullett Manale: Смешно е - това е добър въпрос. Това е малко съчетание, но бих казал, че имаме много малки клиенти. И когато казвам малки клиенти, имам предвид, знаете ли, покупки от един до пет екземпляра, които да лицензират за управление. Сега, в някои случаи те могат да имат 30 екземпляра на SQL и те наистина се интересуват само от петте наистина, много важно, за да инвестират в инструмент като този, за тези пет инстанции.
Но реалността е, че дори и по-малките магазини имате шепа SQL сървъри там. В повечето случаи, или в много случаи, този малък магазин е много, много зависим от тези бази данни, защото знаете какво правят. И така те не го правят, не могат да го пуснат. Не могат, знаете, трябва да имат инструмент.
Другата страна на тази монета е, че в някои от тези по-малки магазини те нямат специални DBA, така че човекът, който е най-умният човек в стаята или по-техничният човек в стаята, се оказва назначен DBA. И така, в тази ситуация те определено търсят някаква помощ и този инструмент очевидно ще им помогне и в това отношение.
За по-големите ви среди, тъй като мисля, че Дез го спомена - или Робин, не съм сигурен - но, знаете, по-големите среди, ще се изненадате колко БДБ имат, искам да кажа, говорите огромен брой случаи на SQL и имате буквално шепи DBA, които имат задачата да отговарят за тях. И така от тази гледна точка тези момчета, знаете ли, търсят някаква помощ, тъй като нямат ресурсите в достатъчна степен, за да им помогнат наистина и така инструмент ще помогне да компенсира част от това.
И така виждаме и това доста, където, знаете, имате трима момчета, управляващи 200 екземпляра. И така можете да си представите логистиката на това, ако нямате подобен инструмент, да се опитате да разберете кога дори има проблем. Няма да е проактивен начин, мога да ви уверя. Толкова се надяваме, че това отговаря на вашия въпрос. Да.
Дез Бланчфийлд: Да, така е. Това ме удари - и мисля, че Робин го намекваше - но, знаете, това обещание, което описвате, когато сте направили демонстрацията, искам да кажа, те не са изключителни за много големи среди. Знаеш ли, че можеш да купиш обща платформа извън рафта, която е предназначена за едно нещо и да я поставиш в споделена среда за база данни за нещо друго и това просто ще накаже цялата среда.
Другото, което ме порази - не е толкова въпрос, а само наблюдение, но аз ще го насоча към въпрос, все пак - и това е, че знаете, когато организациите вече са инвестирали в своята инфраструктура и платформа и тяхната база данни, сървърите и инфраструктурата около тях, и те ще купят продукт, какъвто и да е той - HR, ERP, BI инструмент - те вече са направили доста голяма инвестиция.
Какъв отговор виждате, когато провеждате разговор с хора и те разбраха, че имат проблем с представянето, но сега смятат, че трябва да направят още една инвестиция, за да стигнат до него? Има ли момент, в който те осъзнаят, след като го демонстрират, че те това нещо като не-мозъчен и това не е толкова много стъпка на продажбите, но е по-скоро епифания. Просто знаете, „Веднага ще се възползваме от това.” За разлика от това да се налага да продавате продукта? Струва ми се, че се продава сама, а ROI просто скача от страницата.
Bullett Manale: Да, и това е смешно, вие казвате, че защото много пъти ще се случи е, че някой, като DBA или дори представителите на продажбите, ще дойде и ще каже: „Ей, тези момчета искат да вижте, като, ROI лист на това. "И по-скоро като, нещо на хартия, което бихме им изпратили. И демонстрацията винаги е 10 пъти по-добра, особено е, можете да го направите със самите DBA, защото -
Дез Бланчфийлд: Да.
Bullett Manale: Както казахте, продуктът се продава сам. Наистина е трудно да поставите ROI върху лист хартия и да кажете: „Добре, колко кликвания обикновено DBA използва, знаете, щракнете за един час?“, Тъй като се отнася до архивирането, знаете или какъв е случаят., ти знаеш? А опитвайки се да го сложа на лист хартия, наистина е трудно да се направи това. Но когато вземете някого и им покажете продукта, и той го види, точно това сте казали.
Хората осъзнават стойността на това. Защото не само това им помага да разберат и да вземат по-добри решения, но и това е, това помага, знаете ли, те да не са лошият човек. Те могат да бъдат първите, които знаят; те могат да коригират проблема, преди изобщо да се установи, че е имало проблем.
Другата част от това е, че знаете като DBA, независимо дали е, знаете, реална или възприятие - и мисля, че е възприятие - вие притежавате проблеми с представянето, наистина. Вие сте човекът, който насочва пръста към вас, когато производителността намалее, а реалността е, че може да е този, който наистина причинява проблема.
Имайки инструмент, който да мога да кажа: „Ей, това не е моят проблем, аз трябва да мога да заведа това на програмиста и те трябва да коригират това“ или, знаете ли, по тези линии. Хубав начин е да имате нещо в арсенала си, за да можете да кажете: „Тук е истинският проблем.“ Знаеш ли?
Дез Бланчфийлд: Да. Последното за вас и нещото, което ме впечатлява, гледайки на това, докато минавахме през него, беше, че често, когато мислим за проблеми с представянето, сме склонни да внесем специални умения. Те идват с 20-годишен опит, гледат го и те са нещо, знаете ли, класическата шега на човека, който влиза в инженерния магазин и има мъничко малко чукче и удря машината на правилното място и след това казва, „Това е поправка от 15 000 долара“ и хората отиват: „Ние не плащаме за това“, знаете, защото това е пет минути от работата. И той казва: „Е, за пет минути работа са били необходими 15 години опит, за да се поправят и това ви спести милиони.“
На мен ми се струва, че знаете, че има среден процес, хората преминават през това нещо, казвайки: „Добре, внесете специалните умения, отстранете проблема, той ще изчезне.“ Но това, което са направили тогава, е те просто са сложили лента за помощ, нали? За разлика от сценария, при който от това, което виждам тук, къде, когато това става, да, те може би са адресирали някои проблеми с представянето, които са смятали, че преживяват, но ми се струва, точно тогава, за да има това 24 / 7 вида, знаете, набор от очи, които наблюдават околната среда в реално време.
Наистина в крайна сметка се измъквате от сценария на това, че DBA се събуждат в четири сутринта, защото текат доклади. Така ли е - и може би това е риторично - но случаят ли е, че хората бързо преминават от търсенето да инвестират в даден продукт, за да го накарат да реши конкретен проблем, но тогава той обикновено просто става част от ДНК?
Bullett Manale: Да, и това варира от място на място, но искам да кажа, имам някои хора, които първоначално са закупили продукта, например през 2006 г., и те са били на три различни работни места в различни компании, и те са влезли и когато отидат в следващата компания, те популяризират това като нещо, за да получат, защото имат работен процес. И го наречете така, мразя да го наричам така, но, знаете, този работен процес включва този продукт и те са свикнали с него ежедневно и това им помага, и затова не искат научете нещо ново.
Но абсолютно. Искам да кажа, че повечето пъти караме хората да изтеглят този продукт, а не защото имат бюджет и че излизат и казват: „Ей, добре, имаме този бюджет за ефективност, трябва да направим доказателство за концепция и трябва да се намесим и да разберем, да направим оценка и всичко това. ”Обикновено това, което се случва е, че имат проблем в инстанция на SQL и търсят помощ за поправете този проблем. Те отиват и изтеглят нашия инструмент, те отстраняват проблема и след това осъзнават, че това, самият инструмент ще направи повече от просто да отстрани проблема, който са имали по това време, че това всъщност ще им помогне да подобрят цялостната производителност и не позволявайте на други проблеми да се случват, движейки се напред. И това е сигурно. И определено можете да продължите да използвате този инструмент за непрекъснато настройване на околната среда, защото винаги ще можете да виждате не само това, което се е случило в момента, но и какво се е случило миналата седмица, миналия месец, миналата година и да сравните това с онова, което ще се случи утре. Ти знаеш? Такива неща.
Дез Бланчфийлд: Да.
Bullett Manale: Така че със сигурност.
Дез Бланчфийлд: Перфектно. Значи споменахте, споменахте за нещо - аз просто ще завъртя, преди да се върна на Ерик, за да затворя. Едно от нещата, които винаги ме интересуват, е, знаете, как хората се хващат за това? Споменахте, изтеглете го. Какво е 30-секундното обобщение за това как те получават ръцете си, получават копие, въртят го и си играят с него и какво може да им трябва инфраструктура, само за да получат инстанция.
Bullett Manale: Значи това ще бъде, отидете на IDERA (idera) .com. IDERA.com е компанията и ако посетите този уебсайт - и всъщност мога да ви го покажа тук - не знам дали все още споделям екрана си, но ако отидете на страницата „Продукти“, отидете на „Диагностика“ Връзка към мениджър, ще има малък бутон за изтегляне и можете просто да изтеглите компилацията, след като попълните вашата информация. Ще ви помолят за 32- или 64-битовото изграждане, а вие тръгвате към състезанията, както се казва.
Дез Бланчфийлд: И дали ще работи на лаптоп, за да може някой да играе с него или трябва някъде да го зареди на сървър?
Bullett Manale: Не, не. Всъщност това, което ви показах днес, всичко вървеше от моя лаптоп. Сега моят лаптоп има 32 гига и 8-ядрен процесор, но все пак е лаптоп. Но не е задължително да имате толкова ресурси, за да отговорите на вашия въпрос. Самата оценка е добра за 14 дни, но вие сте повече от добре дошли да я дадете на по-дълго изпитание. Ако просто ни се обадите, можем да го свържем, ако желаете.
Дез Бланчфийлд: Мисля, че това трябва да бъде нещо, което трябва да се отнеме, защото определено ще го направя. Мисля, знаете ли, че от външния вид на нещата ми се струва не-мозъчен човек, който да го изтегля и да играе с него. Вероятно отидете в някоя от вашите среди и просто вижте какво можете да видите, защото подозирам, че - подобно на всичко, което съм виждал във фона на база данни през последните 20+ години, което ме състарява - след като видите, какво има под качулка, невероятно е това, което осъзнавате, че можете да поправите бързо и просто да получите малки печалби в производителността.
Страхотно, благодаря за демонстрацията. Наистина беше страхотно. Благодаря за цялото време за обсъждане на въпросите.
Bullett Manale: Заповядайте. Благодаря за-
Dez Blanchfied: Ерик, ще ти върна обратно.
Ерик Кавана: Да, имаме наистина добър въпрос от страна на члена на публиката. Ти си говорил за това във вашата презентация, а аз всъщност туитах за това, защото беше толкова страхотен цитат. Казахте, че не искате да използвате инструмент за наблюдение на производителността, който се отразява негативно на вашето представяне.
Bullett Manale: Правилно. Това е вярно. Това е важна част от инструмент за мониторинг на производителността, не създава ли проблеми с производителността. Абсолютно вярно.
Ерик Кавана: Точно така. Е, това е като онези потънали - това е като антивирусните програми, които могат просто да предизвикат хаос в системите. Искам да кажа, че използвах редица различни технологии за излъчване, където антивирусната програма стартира и ще пресече потока ви. Така че се случват неща, които не очаквате, но въпросът е свързан с конкретния коментар, който сте направили. И какъв вид хитове за изпълнение виждате? Това е два процента, пет процента ли е, един процент ли е? Имате ли номера, които можете да хвърлите към нас?
Bullett Manale: Е, искам да кажа, предизвикателството с този въпрос е, че знаете, част от дискусията, за която говорихме по-рано. Мога да ви дам - обикновено е около един до три процента, за да отговоря на вашия въпрос. Но има още обяснение, което според мен би се изисквало, което е, ние ви предоставяме много начини да можете да кажете на инструмента какво искате да наблюдавате, нали? И така се връща към това. Е, може би искам да взема извадка от всяка заявка, която се изпълнява. Така че искам да имам достатъчно гъвкав инструмент, за да мога да го включа, за да мога да го видя.
И така, част от тази гъвкавост включва, знаете ли, разходите за това са. Ако трябва да събера повече данни, защото искам извадка от всяка заявка, която се изпълнява в последните, знаете, 20 минути, мога да го включа и може да го направи. И така, но като цяло, да, един до три процента е това, което виждаме, по отношение на режийните разходи. Но това ще варира и по-голямата част от това ще зависи от вашите неща, които включвате и изключвате, по отношение на вашите прагове, колко данни искате да съберете, интервалите си за гласуване, всички подобни неща, свързани с че.
Всъщност, ако излезете пред самия екземпляр, който управлявате, едно от нещата, които ще видите е, имаме множество интервали на анкетите, които можете да посочите. И това е просто защото искаме да знаете, не е нужно да проверявам всеки - Ако искам да направя проверка на сърдечния ритъм на инстанция, няма нужда да оправям процесора и всичко останало заедно с него, ако искам ' Правя го на всеки 20 секунди. Така че имате няколко интервала на гласуване, които можете да зададете.
Също така, както казах, имате и вашия мониторинг на заявките, който можете да посочите. And this can be done for each instance independently, so you can really cater to that specific instance in terms of what you want to monitor. For my wait statistics and wait monitoring, I can turn that on or off. And I can tell it to capture everything, I can tell it, you know, what I want to capture and when I want to capture it. So a lot of that will also– You have to take into consideration what you're doing, in terms of what you're telling the tool to monitor.
But generally speaking, what I would say, is, like I said, around one to three percent is what we see. We've been selling this tool a long time – since, like I said, about 2003 or 2004 – and we've got thousands of customers, so I can assure you that, you know, we don't have– we try our best not to cause performance problems in the name of performance.
Eric Kavanagh: Yeah, that's really good information. I just thought that was a brilliant quote because, you know, again, you don't want to defeat the purpose of what you're trying to accomplish, right?
Bullett Manale: Exactly.
Eric Kavanagh: And I appreciate Robin's question, too; this really is an excellent platform for helping DBAs understand the many different aspects and dimensions and layers of what we're talking about. And I think the concept of conversation with your data is highly appropriate here, because, to your point earlier, you're not gonna figure it out on the first try, usually. You need to spend some time looking at the data, looking at historical data, doing that synthesis in your mind. And that's the job of the human, right? The job of the profession that sits back there and takes heat from the business on a fairly regular basis, to get that job done and to keep the trains running on time, right?
Bullett Manale: Absolutely.
Eric Kavanagh: Well, folks, this has been another fantastic event. If any question you asked was not answered, by all means, let me know. Send an email to . We do archive all these events, so you can always go to InsideAnalysis.com to find the archive, or go to our partner, Techopedia.com. If you look on the right-hand side of their page, you will see Events, and the webcasts listed there. If you click on More Events, you can see all of the webcasts that we do listed there, past, present and future.
And with that, we're going to bid you farewell. We've got five more webcasts for the rest of this year, folks. We may schedule one more. But otherwise, it's going to be on to 2017. The ed cal is out. Let us know, and if you have someone that wants to showcase their technology, send an email to .
With that, we're gonna bid you farewell, folks. Thanks again for your time and attention, we'll talk to you next time. Пази се. Bye-bye.
