От персонала на Техопедия, 26 май 2016 г.
Отнемане: Домакинът Ерик Кавана обсъжда управлението на базата данни и откриването на инстанции с Робин Блор, Дез Бланчфийлд и Бълет Манале в последния епизод на Hot Technologies.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре дами и господа. Добре дошли отново. Казвам се Ерик Кавана. Нещата са горещи. Тук нещата се нагряват. Не знам какво става. О, така е, време е за горещи технологии. Да, наистина се казвам Ерик Кавана. Можете да ме намерите в Twitter @eric_kavanagh. Това е шоуто, предназначено да говори за горещото на пазара. Днес заглавието, „Ключове към кралството: Управление на SQL Server с динамично откриване.“ Добри неща. Има наистина твоя. Добре, тази снимка беше от преди няколко години. Няма да лъжа, сега изглеждам малко по-възрастен, но това е добре.
Така че, ние говорим за това как технологиите и SQL Server са наистина, наистина, наистина, много горещи. Днес имаме цял куп съдържание, така че ще го предам веднага. Изчакайте, ето тук. Там са нашите говорители. И Робин Блур отива на първо място.
Робин Блур: Да, наистина. Презентацията ще влезе в дълбочина в управлението на базата данни, така че просто мислех, че ще премина през управление на базата данни или, знаете ли, лабиринт на базата данни, за да вкарам хората в духа на това. Аз бях DBA, предполагам, че бихте могли да кажете, че преди около 20 години съм бил консултант по бази данни и нещото, което всъщност ме изненадва в базите данни, е, че не много се е променило. Много неща се промениха по отношение на скоростта, по отношение на обемите от данни и подобни неща, но голяма част от тях всъщност остават много подобни на това, което се е случвало преди.
Според мен база данни е организирано разширяващо се събиране на данни, което може да бъде оптимизирано за специфични натоварвания и да предостави възможности за управление на данни. Той се появи предимно, защото ако искате да управлявате данни във файлове, това беше ужасно трудна работа. И идеята да съберем парче софтуер, който би направил почти всичко, от което се нуждаете от него, отне почти мигновено, щом имахме случаен достъп до мейнфреймите на IBM през 70-те години.
Релационната база данни е изобретена през 70-те години и възникна по отношение на прототипи през 80-те години и видът си добива сцепление на пазара от началото на 90-те години нататък. И релационните бази данни все още са изключително доминиращи в популярността. Ако четете пресата, ще чуете страшно много неща, казани за тези - SQL бази данни, а наскоро има страшно много шум за графичните бази данни. И тези са интересни, ако искате, но всъщност все още са в най-новите номера на продажбите, релационните бази данни имат 95% от пазара. И Microsoft SQL Server, който днес ще обсъдим в дълбочина, е вторият най-популярен за Oracle.
Нещото в релационните бази данни, което ги прави необичайни по отношение на двигателите, каквито са, е, че те могат да работят както в OLTP, така и при заявки натоварвания. Трябва да ги настроите по различен начин, ако ще правите това, но всъщност те са в състояние и на двата вида натоварване. Едната от тях е кратки случайни транзакции, а другата от тях - дълги заявки, обхващащи много данни. Алтернативно, базата данни NoSQL и графичната база данни са главно за анализи и те нараснаха сравнително наскоро. NoSQL дойде на първо място и графиката започна малко да се сцепва в последно време. NoSQL може да се използва за транзакционни дейности, но графиките почти никога не се използват за транзакционни дейности. Причината попаднах на статистика, която всъщност мисля, че е на поне десет години, която казва, че повечето компании имат поне три, всъщност цифрата е била 3, 5, различни марки бази данни, ако погледнете техния опис на софтуер.
Но реалността е, че повечето компании се стандартизират върху конкретна база данни. И повечето компании са се стандартизирали или на SQL Server и Oracle като двете най-популярни за, ако желаете, стандартни бази данни. И използват алтернативите само при изключителни обстоятелства, когато например получават софтуерен пакет, който се нуждае от друга база данни или след някои от големите цели за анализ на данни, които са се появили.
Имаме и, ако желаете, намеса на Hadoop. Hadoop по един или друг начин се превърна в повече от файлова система, но все още не е база данни. Въпреки това има SQL, който седи над върха му. Но доказателствата там са, че всъщност не се заменят или някъде близо до заместване на релационните бази данни, които са спечелили сърцата и умовете на света. И причината за това наистина е, че тези релационни бази данни отнеха двадесет години, всъщност повече от двадесет години, за да станат толкова добри, колкото са. И вие не просто изграждате машина за заявки или SQL двигател, която наистина е ефективна за много малко време. Просто не се случва.
И така заключението на този слайд е, че базите данни са стратегически и те се развиват, стават по-добри. И това със сигурност е било при Oracle и Microsoft SQL Server. Вероятно, малко от вас се сещат за дните, когато за първи път се появиха бази данни, но аз го направих, тогава бях момче. Първоначалната идея беше, че ще има единна база данни и това беше концептуална идея, която абсолютно никога не се корени. Имаше опит на IBM с AS / 400 действително да има файлова система, базирана на база данни, но и тази не доминираше. Оставате с факта, че базите данни естествено се фрагментират. Всъщност естествено имате няколко екземпляра. Има проблеми с мащабируемостта. Базата данни е мащабирана само до определен размер, признаваме, че размерът се увеличава с годините, но те имаха ограничения.
И имаше проблеми с натоварването, като основният проблем с натоварването беше, че OLTP натоварванията и големите заявки натоварвания просто не са съвместими помежду си. И беше невъзможно да се изгради двигател, който би направил това. В какво се сблъскваме, което е нещо интересно, наскоро попаднах на сайт, който имаше над хиляда различни екземпляра на Oracle. Не мога да си спомня колко точно DBA са имали, но ако всъщност сте разговаряли с тях за това колко от тези бази данни са били наблюдавани от DBA, това беше нещо като десет. По принцип използваха базата данни като шкаф и просто хвърляха данни в нея, защото поне имахте схема и тя беше по-организирана, отколкото някога би била файлова система, но никой не правеше нищо друго, освен да й даде конфигурация по подразбиране и да я настрои хлабав.
Не съм сигурен дали това е добра идея. Странно ми звучи, защото според мен винаги, когато работех с бази данни, се изискваше присъствие на бази данни и трябваше по един или друг начин да знаеш какво точно се случва там. И страшно много системни взаимозависимости означават, че определени видове нива на услуги абсолютно трябва да бъдат изпълнени, или в противен случай имате проблеми.
Наскоро се заговори, попаднах на различни бази данни, които твърдят, че се самонастройват. Тези, които са магазини с колони, които са създадени за трафик на заявки, до голяма степен се самонастройват, защото има много два варианта, които трябва да вземете по отношение на индексите. Но освен тази конкретна област, базите данни трябва да бъдат настроени. И те трябва да бъдат настроени, определени релационни бази данни, главно защото страшно много транзакции включват присъединяване. Присъединяването е скъпа дейност. Ако не поставите правилните индекси на правилното място, след това присъединяването отнема непосилни количества време, когато не се налага.
Понастоящем самонастройващите се бази данни, но той съществува само в тези области, където работните натоварвания са добре известни. И моят опит е, че повечето компании използват много малко DBA и това е така, защото са скъпи. И затова е по-добре, ако можете да редувате това, което прави DBA. Това са дейности на DBA, както ги разбирам. Те правят инсталация, конфигуриране и надграждане на бази данни. Надграждането, между другото, не е непременно тривиална дейност. Причината да обновите база данни, имам предвид правилото, с което винаги съм работил, не го докосвайте, ако работи, и ако ще надстроите база данни до някаква конкретна нова версия, правите го в тестов режим първо и след това надграждате всичко. Все още се занимавате с една и съща версия. Но всъщност много сайтове, на които попаднах, не се случва това. Има, да речем, доста добра степен на ентропия. Управлението на лицензите е проблем, зависи от това какъв лиценз имате. ETL и репликация на данни.
Един от триковете с базата данни е, ако имате натоварване на заявката, което трябва да бъде разделено, можете да създадете два екземпляра и да копирате и това често се прави там, където хората използват репликата като горещо архивиране, ако е необходимо. Тогава планирането на съхранение и капацитет, това е част от дейността на DBA, защото, разбира се, данните нарастват и трябва да проследите това. И тогава трябва да планирате различни хардуерни надстройки или хардуерни подобрения. Има отстраняване на проблеми, което е болезнено занимание за повечето DBA. Където нещо се обърка и архивирането не работи точно перфектно и тогава трябва да запретне ръкави и да слезе и да опита да възстанови нещата от лог файлове. Това се случва по-често, отколкото мисля, добре, спомням си, че това се случи, но бях извън играта поне десет години, но си спомням това да се случва по-често, отколкото бихте очаквали някога. Мониторингът и настройката на ефективността са просто вид биещо сърце на DBA работа. Но има и сигурност по отношение на управлението на достъпа, архивирането и възстановяването, създавайки софтуерни тестови системи, които разумно успоредно ще изпълняват жива система. И всички неща от жизнения цикъл на данните. Така че, според мен, списъкът на DBA е списъкът с работни места, освен всичко останало, което може да бъде помолено да правят. Оперативна динамика. В крайна сметка целостта на данните и управлението на ниво услуга са основната отговорност на DBA. И обикновено са критични. И това е всичко, което имам да кажа. Отивам да предам на Дез.
Дез Бланчфийлд: Благодаря ви много. Ще ме заведем на едно малко забавно, анекдотично пътешествие наоколо защо цялата тема, която днес е свързана и е по-критична от всякога. Не толкова отдавна бях включен в проект, при който мигрирахме държавна платформа, която се използва за регистрация на лицензи и регистрация на превозни средства и цял набор от неща около тази тема, от платформата на Fujitsu mainframe, която управлява нещо, наречено A + Addition, което е операционна система Solaris или с други думи Unix, работеща с Oracle и вършеща много добра работа. И гледката беше, че това нещо остарява и беше време да го преместите в нещо друго. Забавлявахме се много Unix на мейнфрейм и той беше много стабилен и много сигурен и достатъчно странно SDL платформата и беше абсолютно светкавично бърз. Но мъдростта беше, че беше време да сляза от мейнфрейм и да се преместим.
Това значително предизвикателство за картографиране на всички системи и бизнес логика и SQL среда за базите данни отдолу и разглеждане на начина, по който ще архитектираме и проектираме нов дом за него. И в крайна сметка го преведохме на едно от тези неща, което вече е на няколко години, но един от най-горния край на Sun rack системата Starfire сървъри. И това вероятно са едни от най-големите калай, които можете да закупите на планетата, които всички живеят в една голяма кутия и симетричен многопроцесорен сървър. Това беше система от среден клас в нашия свят. Той управлява Unix и управлява Oracle изначално и гледката беше: „Какво може да се обърка?“ Е, оказва се, много.
Например, по онова време, а ние не говорим за много отдавна, трябваше да преминем през много ръчен процес, за да открием какво е в мейнфрейм платформата и да се пренесем. По-специално действителната среда на базата данни и логиката на SQL. И така, мнението беше, че това ще бъде доста пряк ход Oracle-to-Oracle, движение от база данни към база данни; цялата бизнес логика ще се натъкне, по-голямата част от бизнес логиката е написана във вградени заявки и задействания и колко трудно би могло да бъде? Но нещо, което трябваше да отнеме месеци, в крайна сметка отне не много година. Физически и ръчно да преминете през всяка част от Unix в мейнфрейм средата, да откриете къде са били всички бази данни и колко инстанции са били изпълнявани и какво е работило в тези инстанции и това е нетривиално упражнение и ние в крайна сметка го изпълняваме три пъти само за да сме сигурни, че сме заловили всичко. Защото всеки път, когато си мислехме, че сме изкопали толкова дълбоко, колкото ни се наложи, под повърхността се оказа, че има още.
Другото предизвикателство, което имахме беше кои случаи се изпълняват и в какво състояние? Това среда за развитие ли е? Тестова среда ли е? Това ли е част от процеса на интеграция? Системна интеграция ли е? UAT ли е, тестът за приемане от потребителя? Това ли е производство? DR среда ли е? Тъй като страхотното нещо за мейнфреймите е, че можете да изградите тези малки виртуални среди, които всички ние приемаме за даденост сега и да движите нещата наоколо. И вие трябва да се справите дали този човек прави разработка и тестване на производствен клас, или извършва производство, има ли реални потребители на това? Помнете, че това нещо прави издаване в реално време на шофьорски книжки и регистрация на автомобили и неща, които наистина имат значение за живота на хората.
И отне много време, за да стартираме резервни копия за това нещо, така че всъщност нямахме прозорец за поддръжка, за да вземем нещата офлайн и да видим какво се е случило. Нямаше такова нещо като пренасочване. Имахме предизвикателството не просто да намерим кои инстанции се изпълняват и къде и за кого, но след това трябваше да разработим кои версии на кои инстанции се изпълняват. И тук почти загубих сюжета си. Когато започнах да осъзнавам, че имаме две или три версии на производствената среда, преминаващи през различни нива на тестване и имаше много малко по пътя на инструментите и систематичните подходи към това. Ние буквално трябваше да се задълбочим в кода и в работещия екземпляр и в някои случаи да поемем риска да вземем нещо офлайн за малко. Стигнахме до дъното на всичко това, картографирахме го и беше много ръчен процес, както казах. И най-накрая направихме цялата смяна на ETL, изхвърляйки го от едно място и го преместваме на друго и като цяло работи. И бяхме като, добре е функционално, много сме доволни от това.
Но след това се натъкнахме на редица много сериозни солидни тухлени стени. По-специално открихме проблеми с производителността. И разумното мислене на деня беше, добре, че премина към по-голям, по-добър, по-бърз и по-твърд хардуер, няма причина защо трябва да се представя лошо на приложението на ниво база данни, така че нека започнем да търсим другаде. Така напълно реинженерирахме мрежата два пъти. Всеки рутер, всеки превключвател, всеки кабел, в някои случаи преминавахме от Ethernet към фибри, обновихме софтуера, закърпихме се, получавате изглед. По същество реконструирахме мрежата два пъти, мислейки, че това са проблеми с производителността. И изглеждаше и усещаше, че е така. Преминахме през различни системи за сигурност, различни защитни стени. Ние закърпихме операционната система. Премествахме неща от едно изчислително острие в друго. И прекарахме значително време, разглеждайки частта от инфраструктурата.
И тогава разбрахме, че когато прекъснахме сървърите и пуснахме някои други приложения върху него, мрежата работи добре. Така че започнахме да дърпаме операционната система. Същият проблем. Но интересното е, че мрежовото ниво и нивото на операционната система, инструментите бяха там, всъщност беше сравнително лесно да сравним и тестваме и да докажем, че всяко от тези парчета работи. Но дори и тогава, на Solaris в средния клас на хардуерната платформа SPARC, инструментите просто не бяха налице, за да започнем да диагностицираме средата на базата данни. Нали знаете, картографиране дали сме въвели всички инстанции в. И така трябваше всъщност да изградим собствени инструменти и да напишем някои и да седнем, независимо дали това е в самите инструменти на базата данни на родните езици на скриптове, или дали става въпрос за поредица от скриптове за черупки или в някои случаи куп програми на С.
Най-накрая се задълбочихме в някои много интересни въпроси, при които логиката под SQL слоя, самите двигатели на базата данни, се оказа, че когато нещо е изградено по определен начин за нещо, което се изпълнява на версията на мейнфрейм на Oracle, е преместено в Solaris на SPARC версия Oracle не веднага транспонира същото изпълнение. Така че това беше доста болезнено пътешествие за нас на първо място, просто го направихме и намерихме всичко, но сега трябваше да го диагностицираме на новата производствена система и отново това нещо извади миграция на стойност около месец до близо година. И просто се свеждаше до факта, че нямахме инструментите наоколо. Бягайки наоколо, правейки неща като опит да картографирате метаданни.
В един момент почти решихме, че се нуждаем от дъска на Ouija, защото по този начин ще бъде по-лесно само да се насочи и да се напъне. Прости неща, като разберете кой е имал достъп до старите системи и защо са имали такъв достъп. И който се нуждаеше от достъпа до новия и потвърждаване, да накара някой да излезе и потвърди това и да го картографира. Дори нещо толкова просто, колкото размерът на базата данни не беше съвместим в двете платформи. Трябваше да изградим инструмент, за да направим това и да направим сравнение между колко голяма е базата данни в тонаж, в сурови мегабайти или терабайти на System A спрямо System B. и да се потопим в повече подробности около производителността и изпълнителната среда. Отново трябваше да изгради нови инструменти. Просто не е имало нито един извънбранни за нас.
И получавате цялото това съобщение от това, когато стигнахме до края, за да стартираме нещата и го направихме стабилен, всяко негово парче беше много ръчен процес, единственият начин да можем да автоматизираме нещо е, ако изградим нов инструмент или нов скрипт. И ако разполагахме с наличните днес инструменти, животът щеше да е толкова по-лесен и много по-добър. И щяхме да спестим милиони от този проект. Но мисля, че това, за което ще говорим днес, е фактът, че инструментите са налични сега и те правят живота много по-лесен. Много от клопките все още остават. Откриване на базите данни, които са там и кои инстанции се изпълняват какво. В какво състояние са те. Колко са тичащите? Защо тичат. Дали те вървят добре. Подкрепяни ли са?
Това са всичко, което по много начини можем да приемем за даденост сега с правилните инструменти. Но в този конкретен анекдот имаше период, както казах, когато това беше нещо, заради което много от нас загубиха много коса, вероятно отнехме петнайсет години от живота си и оплакваме факта, че инструментите не са били сега, И с нетърпение очаквам да чуя много повече за това от нашия гост днес, Булет. Така че с това, Бълет, ще предам на вас и с нетърпение очаквам да чуя как сте решили този проблем.
Bullett Manale: Добре. Звучи страхотно. Ерик, позволете ми да поема тук с слайдовете и да поговорим малко, наистина бързо, за Idera, компанията, преди да влезем в самия продукт. Точно като FYI, това е вид портфолио от различни продукти, които имаме на разположение.
Ерик Кавана: Аудиото ви е доста горещо, така че ако използвате слушалки, просто го издърпайте малко нагоре.
Bullett Manale: Няма проблем. Това по-добре ли е?
Ерик Кавана: Това е много по-добре. Отнеси го.
Bullett Manale: Добре. Затова днес ще се съсредоточим върху Управителя на инвентара, който очевидно е приведен в съответствие с много от тези теми, които обсъждаме. Просто искам да ви разкажа малко за това как този продукт е попаднал там, където се намира. Започнахме да гледаме ежедневно с нашата продуктова линия, разполагаме с инструмент за мониторинг на ефективността, наречен Diagnostic Manager. Имаме инструмент за управление на съответствие. И така, много различни инструменти около SQL Server и неизбежно винаги задаваме въпроса за лицензионни цели: "Какъв е броят на случаите, които понастоящем управлявате в рамките на вашата организация?" И интересното беше, че никога не успяхме да получим категоричен отговор по въпроса. Всъщност нямаше значение с кого си говорил. Винаги беше някакъв вид: „Ами ние мислим, че е около този номер“. Такива неща винаги идваха и тогава ще трябва да преминем през този процес, за да разберем какво точно е, че те искаха да лицензират по отношение на случаите, които управляваме.
Явно разбрахме наистина бързо, че изглежда има някаква болка, свързана с тази с много DBA. Очевидно като DBA едно от нещата, за които те носят отговорност, е да знаят това, тъй като едно от нещата, които трябва да направят, е да се притесняват от техните лицензионни споразумения, в нашия случай с Microsoft и SQL Server. Очевидно имат много други различни области, за които отговарят, но това е една от тези, които са нещо като голям брой билети по отношение на DBA какви са вашите общи отговорности. С това стигнахме до извода, че се нуждаем от инструмент, който улеснява DBA, за да може наистина да разбере това число. Тъй като имате SQL разпръскване, ако искате да го наречете така и това се случва по редица различни причини. Не може да има толкова много контрол около това кой инсталира софтуера и подобни неща.
И най-лошото, което може да се случи, е някой да вземе ръце на копие на SQL Server, да го инсталира, да започне да работи с него без никакво знание на някои от другите организации или отдели в компанията, а след това следващото нещо, което знаете, може би данните не се архивират и такива видове неща, които биха могли да се случат. Където сега имате друг проблем, където имате ситуации, в които действително ще загубите критични данни, защото не знаете, че екземплярът дори съществува на първо място.
Едно от нещата, които трябваше да направим, е да кажем, да разберем частта от откритието. И след това да може да организира и управлява тази информация, която събираме по логичен начин, който има смисъл въз основа на това, което прави бизнесът. И тогава очевидно от това да можеш да вземаш решения около тази информация и да можеш да правиш такива неща. Точно там инструментът стартира и откъде идва. Мога да ви кажа, че при разговори с DBA редовно това, което всъщност имаме, е проблемът да не знаем колко инстанции имат.
И е смешно, защото терминът не можете да управлявате това, което не можете да измерите, винаги предлагаше инструменти за ефективност, които имаме, като SQL Diagnostic Manager, но наистина не можете да управлявате нищо, ако не знаете това „Своето” дори там на първо място. Така че това също е голяма част от този инструмент, който е способен просто да знае, че е там.
Сега в тази бележка, говорейки с някои от по-големите организации или фирмени магазини със SQL Server, интересното, което открихме с много момчета, с които разговаряхме, е, че те всъщност са задали време през годината, където те всъщност са ходили физически от едно място на друго, за да се опитат да определят как изглежда това число. Можете да си представите като DBA, че получавате доста добра сума пари за физическо ходене от една машина на друга в някои случаи, което беше изненадващо това, което бихме чули от някои доста големи компании, които няма да посоча. Но един интересен момент, че две седмици в годината може да се изразходват за извършване на подобни видове упражнения, само за да разберат дали броя на техните лицензи е правилен.
Всичко това е свързано с този инструмент и как помага, но начинът, по който се обърнахме към него, беше чрез способността да се направи откриване въз основа на редица характеристики на SQL Server. И така, първият въпрос е на какво насочвате или към какво се опитвате да погледнете отначало? Начинът, по който го направихме, беше да кажем да го направим по IP обхват или можем да го направим чрез членството в самия домейн по отношение на компютрите, които са членове на домейна. Ето как се обърнахме към тази част, само за да можем да кажем, че това е областта, върху която искаме да се съсредоточим по отношение на откритието.
И тогава другата част от това се основава на тези характеристики, портовете и други неща, ключовете на регистъра на WMI и тези видове неща, можем да съберем и да проверим, че SQL вероятно работи и се инсталира в този екземпляр или в тази конкретна среда. Очевидно е много по-добър метод от метода на маратонките или метода за експресни маратонки. Хубавото е, че цялата тази информация, която събираме за инстанцията, се съхранява в хранилище и тя може да се променя, докато се променя средата. Не става въпрос само за „Хей, има инстанция, ето списък, който намерихме“, но това е DBA или човекът, който управлява инстанциите, да може да определи дали искат да направят тази част от инвентара, и след това кога това не е част от инвентара, за да може да извади този екземпляр. И така те имат жизнения цикъл на целия процес на екземпляра на SQL Server, за да бъдат наистина лесно разбрани в инструмента.
След като открихме случаите, какво да правим след това? Другото нещо е много информация за инстанцията, не искам да се налага да го получавам ръчно и да го поставям в електронна таблица или подобни неща. И това е нещо, което беше интересно при разговорите с DBA за процеса на инвентаризация и лицензиране, е, че ще се изненадате с колко DBA, с които разговарях, когато ги попитате: „Как поддържате своите запаси?“ И ние говорим с DBAs, което е наистина ироничната част от него, че те го поддържат и проследяват в статична електронна таблица на всички неща. Както казах, много е иронично, когато мислиш за това за минута. Но това беше в много случаи и все още се случва с много организации как те управляват това. Как поддържат това. Това е главно копие на електронна таблица в Excel, която се разнася наоколо и трябва да се актуализира редовно.
Това са нещата, които бяха предизвикателство и така, като регистрирате този екземпляр и го направите част от инвентара, можете да направите това и да вземете информацията. Можете да го автоматизирате, независимо дали става част от инвентара, версията, изданието, другите неща, които можете да направите с него, можете да добавите ръчно може би този списък или таблицата на Excel, която имате. Можете да го импортирате в този инструмент, наречен SQL Inventory Manager. Ако вече имате начална инстанция, за която смятате, че сте доста уверени, можете да импортирате тези копия и след това да направите тази част от своя управляван инвентар в продукта. След като имаме инстанцията и веднъж разберем, че тя е там, тя става, добре, имаме много информация, която можем да използваме, като знаем, че този случай е там, като излезем и съберем тази информация.
И много информация ще е необходима за повече от само лицензионни цели. Голяма част от него може да се използва за очевидно просто да знае къде се намират нещата, да може да търси тази информация, след като е получена. Но основните неща са сървърът, самият хардуер. Да можеш да разбереш каква машина е, може би моделът или производителят, паметта, обема на паметта, независимо дали става въпрос за физическа или виртуална машина и особено броя на физическите гнезда или ядра и процесори и тези видове неща.
По отношение на броя на ядрата, особено при SQL Server, знаейки начина, по който правят лицензирането си, е изчисление на основни сега в по-новите версии на SQL, което става наистина важна част от него и не е всичко, което имате да изляза и всъщност да отида да копаеш. След като инстанцията бъде идентифицирана, ние можем да предоставим тази информация и да я извадим и да ви позволим да я прегледате и разберете и очевидно може да се възползвате от нея.
Следващият слой надолу е в инстанцията, което очевидно имате много различни от екземпляра на SQL Server, независимо дали е стандартен или корпоративен или дори експресен по този въпрос, или безплатната версия на SQL Server. Да можеш да разбереш и какви приложения са обвързани с този екземпляр и това може да стане автоматично. Да можеш да разбереш настройките на конфигурацията и тези видове неща, както и друга информация, която е свързана с инстанцията на самия SQL Server.
След това стигате до действителната база данни и виждате настройките за конфигурация, количеството пространство, обвързано с тези данни, където се намира, всички тези неща се попълват автоматично и така това е огромен спестяване на време. И още веднъж, тъй като динамично излиза и ежедневно идентифицира нови случаи, това е живо нещо, което имате по отношение на инвентара си. Това е целта на продукта да го направи по този начин, да го направи нещо, което динамично се променя.
След като цялата тази информация стане достъпна за нас и можем да извлечем всички тези данни, тогава наистина има смисъл да започнете да създавате в някои случаи свои собствени метаданни, свързани с тези случаи, и че тези метаданни могат да бъдат създадени по такъв начин се приравнява към начина, по който правите бизнес.
Така че, ако имате вашите инстанции, групирани по географско местоположение, или по собственици на приложения, или от собственици на DBA или каквото и да е, това може да е от гледна точка на това как искате да групирате тези екземпляри, как логично искате да осмислите тези случаи, тогава има вид на две области в инструмента, които ще ви дадат тази възможност.
Първата е способността да се създаде маркер за екземпляр или маркер. Което по същество създава асоциация към сървъра, инстанцията или базата данни, така че да можете да създавате изгледи и да отговаряте на въпроси, които могат да се появяват ежедневно, което наистина ви помага да се справите с това, което имате, какво управлявате и как искате да продължите напред с тази информация.
Другото, което имаме, е нещо, наречено поле за инвентаризация или персонализирани полета за инвентаризация и те са по-специфични за вида отрязъци от информация, в които можете да разгледате, например слоя база данни, в който бих могъл да реша да добавя падащ списък, който има всички DBA и мога да посоча кой е отговорен за тази база данни в зависимост от този тип ситуация или каквото и да е, в каквато и база данни да се намира, който и да е отговорен за нея, да може да избере това, така че да знам, че те са отговорните и много лесно само като ровите в инвентара.
Така тези части от информация стават много ценни, особено ако имате голяма среда, защото тя просто ви помага да осмислите тази информация и да знаете какво имате и как го правите.
Така че нека да продължа напред и да премина към следващия слайд тук. Това, което ви показвам сега, е, че цялата тази информация, която събираме, цялата тази информация и данни, които събираме и прилагаме метаданни, за да ви даде възможност да вземате много по-лесни и бързи решения, когато става въпрос за увеличете лицензите си с Microsoft при лицензирането на корпоративния обем или софтуерната застраховка с Microsoft.
Това ви прави наистина лесно да направите това, а не да се налага, да трябва да правите много ръчно събиране на данни, много ръчно събиране на тази информация, което наистина като цяло го прави много по-добър процес. Така че това е един от мандатите на продукта, някой път да улеснят DBAs да вземат тези решения около лицензирането.
Сега другото нещо, което, като разговаряме с DBAs, открихме и научихме наистина бързо, е това - и това е нещо като връщане към това, което беше обсъдено по-рано - може да имате 300 екземпляра в средата си на SQL Server, но наистина може да има само подмножество от тези, които наистина се наблюдават и управляват от традиционен тип инструмент за мониторинг на ефективността.
Така че, ако отидете и действително седнете с DBA и си кажете: „Вижте, знаем, че имате тези 20 екземпляра или 10 екземпляра от 300-те, които се наблюдават с този инструмент, предназначен да следи това и да съответства на вашите SOA и да получавате сигнали и всички онези хубави неща ", това открихме също, че ако попитате:" Тогава добре какво ще кажете за тези други 280 случая, които имате? Имате ли грижа за тях? "И те го правят, грижат се за тях, но просто не искат непременно да инвестират, за да наблюдават тези на нивото на дълбочина, което може да се направи с тези случаи срещу тези 10 или 20 наистина, наистина критични случаи на продукти.
Така че другата част на уравнението с този инструмент е, че той също така помага от гледна точка на възможността да се уверите, че на базово ниво сте обхванати от гледна точка на здравето, например. Сега няма да ви кажа дали имате задънена улица или коя е жертвата на задънената улица. Не е да стигнете до това ниво на самите сесии и детайлите на заявките. Но в същото време тепърва ще ви уведомяват, че, ей сървъра надолу или хей обемът се запълва или трябва да направите резервни копия на базата данни, това е важна част от това да бъдете DBA.
Така че тези неща определено все още са важни и затова с този вид инструменти той е направил начин да имате уловка за вашите наистина критични случаи, които са много, много си струва да бъдат обвързани с тях, ако отидат надолу трябва да знаете веднага. Те могат да имат по-високото ниво на наблюдение и да могат да правят такива неща, докато с това ще могат да избират всякакви нови екземпляри, които се добавят към околната среда, и да се уверят, че те се отчитат и също така правят уверете се, че тези основни нива на здравни проверки се формират.
Така че накратко това е всичко, което представлява SQL Importory Import Manager. Сега ще ви покажа демонстрация на това. Преди да направим това, просто бързо ви показвам, че това е слайдът за архитектура тук и просто за да покажем това, екземплярите на SQL, които управляваме, можем да открием всичко от SQL 2000 чак до новото версии на SQL.
Така че можем да направим това, без изобщо да се налага да разполагаме агенти в самите инстанции. Правим го чрез услуга за събиране и ще излезем и ще съберем тази информация и я поставим в хранилище, а след това от предния край на конзолата на Tomcat уеб услугата ще можем да взаимодействаме с тези данни и да я преглеждаме. Така че това е доста проста архитектура.
Продължавам напред и превключвам и всъщност ни вкарват в самия продукт, за да можете да усетите как да го разберете, как да работи. Така че най-добрият начин да направите това е първо да ви запознаем със самия интерфейс в това е вид табло, което разглеждаме тук.
Виждам броя на случаите в момента, когато имам управление, не е чак толкова много. Но аз също нямам цял център за данни в задния си джоб. Така че имам около шест случая, които виждаме тук. Сега, когато каза това, аз съм, това, което ще правя, е да разгледам процеса на откриване и да покажа как ще работи.
Сега първото нещо, което бихте направили, е в секцията за администрация, която можете да определите как бихте искали да откриете вашите случаи. Бихте могли да поставите тази информация тук и за пореден път, което може да стане чрез редица IP адреси. Можете да насочите към домейн или поддомейн и да бъдете в състояние само на онези машини, които са членове на този домейн, да могат да извършват тези проверки, за които бихте могли да изберете редица различни видове характеристики, когато SQL работи, за да провери.
След това, след като сте направили това и можете да го автоматизирате да се изпълнява ежедневно, за да отидете и да съберете тези данни. Можете също така да можете да го направите на ad hoc основа, ако е необходимо. Но след като започнете това, този процес на откриване, тогава това, което ще започнете да виждате е, когато преминете към изгледа на екземплярите тук. Имате раздел „Откриване“ и раздел „Откриване“ ще ни покаже онези случаи, които бяха открити наскоро. Така че в нашия случай тук имаме номер. Това, което ще продължа напред, е да продължа напред и да добавя този, който ще използваме като пример. Значи това е случай в Чикаго в случая, нали? Ще продължа напред и ще добавя този екземпляр към моя инвентар.
Добре и тук ще ме разгледат няколко неща. Просто ще продължа напред и ще видите, че можем да зададем идентификационните данни. Моите пълномощия трябва да са добри там. Ще продължа напред и ще забележите, че мога да възложа собствеността върху това, ако искам. Мога да посоча и местоположение. Сега вече може да се добави и самото местоположение и очевидно ще си спомня, че следващия път наоколо.
Още веднъж мога да свържа маркери към това по отношение на метаданните и как бихме искали да поставим тези екземпляри на SQL, по-специално този, в кои кодове искаме да го поставим. Така че имаме някои текущи тагове, популярни тагове, така че можем да разгледаме куп различни тагове, които може би вече съм включил. Просто ще избера някои от тях на случаен принцип и можем да приложим това.
Така че сега, когато продължа напред и добавям това към инвентара. Сега, когато е добавен, сега ще видим, че се показва под този управляван изглед и така можете да го видите изброен тук. Знаете, знаете, че това е първата стъпка и това, което току-що ви показах, беше начинът, по който ще добавяте главно тези случаи, когато преминавате ежедневно. В някои случаи може да кажете, че знаете какво, ако това е корпоративно издание на SQL сървър, автоматично искам да го добавя към моя инвентар? Не е необходимо ръчно да отида и да избера да го направя.
Джоселин: Ще ви прекъсна съвсем бързо. Не виждаме вашата демонстрация.
Bullett Manale: Не си?
Джоселин: Не.
Bullett Manale: Ами това не е добре, нека видим.
Ерик Кавана: Ако отидете в горния ляв ъгъл, щракнете върху старт, щракнете върху него.
Bullett Manale: А, добре.
Ерик Кавана: А сега направете екран за споделяне.
Bullett Manale: Съжалявам за това. Мда.
Ерик Кавана: Това е наред. Добър улов там, продуцент Джоселин.
Bullett Manale: Добре, така ли е по-добре? Виждате ли го сега?
Робин Блур: Да, наистина.
Bullett Manale: Добре, така че нека просто да ви преведем там, където бяхме истински бързо. Имаме откритите случаи, които сме имали и по-рано. Току-що добавих инстанцията Чикаго и това, което виждате сега, е вече изброено тук. Забележете, че вече е изтеглена много допълнителна информация. Ако щракнете върху самия екземпляр, вие ще започнете да виждате всички видове информация, която вече събрахме за този екземпляр. Сега ето списък на всички бази данни, които са там. Можем да видим разбивка на базите данни по размер и по активност, по отношение на това кои имат най-голям размер и активност.
Още веднъж можем да ви кажем веднага прилепите кои приложения виждаме да се изпълняват в този екземпляр въз основа на работното натоварване, което виждаме да работи в инстанцията. Така че е хубаво да можете да правите това автоматично. Не е нужно да влизам и да обвързвам заявлението с инцидента. Въз основа на това, което виждаме, можем да го попълним. Сега, ако искате ръчно да добавите приложение, можете абсолютно да го направите. Но това е просто хубав начин да можете да покажете връзката на инстанцията с базата данни или, съжалявам, към приложението.
Ще забележите също, че от дясната страна на екрана имаме незабавно обобщение, а отдолу имаме обобщение на сървъра. Така че тук говорим за ключовите части информация, като знаем версията, а не само, знаете ли, SQL Server 2012, но действителният номер на версията, който, включително и ни казва какви актуални корекции са свързани с него, какви пакети услуги са обвързани с него, може да е много важно да знаете. Очевидно изискването за памет е важно. Всичко подобно, независимо дали е клъстерирано, цялата тази информация, не е нужно да я внасям - тя вече се събира и събира и след като установим, че е открит екземпляр, това ще бъде част от нашия опис.
Другото, което ще видите тук - и то ще ви покаже - е под този изглед на инстанция. Имаме тези атрибути, за които говорих по-рано, персонализираните атрибути, които могат да се добавят. Така че можем да добавим отворен вид текстови полета, можем да правим да / не по отношение на, знаете ли, милиард избори. Дори можем да правим падащи списъци. Можете да направите това в случай на базата данни или на ниво сървър.
След това, ако превъртим малко надолу, можем да видим цялата свързана информация със самия сървър. Значи знаете, че всички подобни неща очевидно са наистина, много полезни, защото всичко е събрано и събрано и то е там за нас, веднага след като вземем това решение, за да го направим част от нашия инвентар. Тук можем да покажем някои от разликите по отношение на процесорите, броя на логическите спрямо физическите, колко памет. Така че наистина получавате наистина добра и богата информация, без да се налага да вършите много работа.
Сега, както казах, другата част към това е, че събираме тези данни в инстанция на ниво сървър. Ако дори се спуснем до базата данни, можем да видим, че много от тези неща са разбити и за нас. Така че, ако отида в моето хранилище за съответствие, в този случай бих могъл да кажа, добре знаете, че това се справя с a, това е база данни за съответствие, в която ниво на съответствие или регулаторно изискване е свързано и може да бъде, да речем, SOX съответствие или PCI съответствие. Така че мога да избирам кои бази данни имат кое съответствие, свързано с тях, което трябва да попълня или да се уверя, че поддържам по отношение на това регулаторно изискване.
Така че този вид неща се оказаха много полезни за DBA, защото има място, на което те могат централно да отидат, за да запазят лесно всички тези свързани метаданни в обкръжението си и те могат да направят това, както казах, да съответства на техния бизнес, тъй като те " правите, като начина, по който правят бизнес. Така че, ако разгледаме всички неща досега това, което видяхме, очевидно имате доста добър преглед на инстанцията, ако проучвам.
Мога също да търся, така че казах да потърсим това хранилище за съответствие в инвентара си. Тогава това, което ще видите тук, е, че мога да търся тези неща и да мога да ги идентифицирам. Казвам това - не съм сигурен какво, бутонът ми за работа не работи там. Добре. Да видим, нека опитаме отново. Ето. Така че тогава ще бъдем в състояние да видим разбивка на това, с което виждаме нещо, с което спазваме, и аз мога да разгледам в него и да го видя и от тази гледна точка. Така че имате наистина бърз и лесен начин да ровите в тези данни.
Както вече споменахме, имате много различни начини за създаване на метаданни срещу сървъра и базата данни. Другата част към това е да можете да се възползвате от това по начина, по който сте го групирали, и по начина, по който сте го свързали. Преминаваме към изглед на изследователя, можем да направим точно това. Можем да кажем, че искам да направя броя на базата данни по местоположения. Така че броят на базите данни на всяко място на средите, които поддържам. Или може би това се основава на собственика, който притежава инстанциите, които имам там, по отношение на може би брой екземпляри. Така ще можем да видим това. Така получавате наистина добър и лесен начин да рисувате тези снимки за вас въз основа на какъвто и да е въпрос, който се опитвате да отговорите по това време.
Тогава това, което разполагате с тази информация, е създадено по начина, по който сте искали, ние можем да я експортираме в PDF или различни формати, за да можем да я използваме и изпращаме до нашите колеги или да правим каквото е необходимо там. Значи знаете, че бихте могли да правите такива неща. Да се върнем към - загубих ли го? Ето. Добре, така да се надяваме, че това има смисъл по отношение на това, за което говорих досега. Сега, когато данните, които сме събрали, всичко това очевидно е наистина жизненоважно поради редица причини - лицензиране и какво ли още не.
Последният нещо, което само трябва да споменем, е, че тук преминаваме към този раздел за администрация. Тук също можете да конфигурирате своя имейл и вашето предупреждение и да бъдете в състояние да сте сигурни, че за нещата, които бихте искали наистина да знаете, можете да настроите и тези неща. Така че можем да настроим известия по имейл, можем да настроим възможността да включваме някои неща и да изключваме определени неща и след това да можем да определим кой ще получава тези имейли и като се абонираме за тези сигнали, можем да свържем кого бихме искали да бъде, който би искал да знае за тези видове неща.
Но както казах по-рано, това е наистина приятен начин да направите, поне да имате спокойствие, за да знаете за целия си случай на SQL на предприятието - какво е това, което имате, и също така да се уверите, че работи оптимално, дори ако не го направите t, не са взели решение да направят инвестиция за тежък инструмент за наблюдение на ефективността, който да управлява този инстанция. Това ще ви обхване, защото това е много достъпен начин да излезете навън и в много случаи да можете да правите тези описи и да можете да направите един вид на много широк вид общо ниво на мониторинг, за да сте сигурни, че имам това спокойствие и знам какво се случва.
Така че да се надяваме, че има смисъл в начина, по който сме го описали и ви го показахме. Предполагам, че от тази гледна точка мога да продължа напред и да го предам назад и можем да поговорим още малко.
Ерик Кавана: Това звучи страхотно. Значи Робин? Дез? Някакви въпроси?
Робин Блур: Ами имам въпроси. Всъщност е много интересно, искам да кажа, че просто исках да направя коментара, че почти навсякъде съм бил, не само сред DBA, но сред момчета в мрежата, сред момчетата за съхранение, сред момчетата за управление на виртуални машини, те ' преработете всички електронни таблици.
Ерик Кавана: Точно така.
Дез Бланчфийлд: Вие някак си знаете, че това е, някак си знаете, че това е наред, докато числата започнат да се движат. Когато числата започнат да се движат, знаете, че те ще влязат в беда. Така че въпросът сега ме интересува и знам, че ще ви е трудно да отговорите, но какво, ако отидете на място, където те нямат нищо подобно за работа с електронни таблици, така че нека предположим DBA са много умни момчета и така нататък и т.н., какъв ROI мислите, че бихте получили от прилагането на нещо подобно? Имате ли някакви фигури по този въпрос или някакви указания за това?
Bullett Manale: Трудно е да се каже каква е възвръщаемостта на инвестициите, защото средата ще бъде малко по-различна. Очевидно е, че колкото по-голямо е предприятието, толкова по-голяма е средата, очевидно толкова повече ще бъде възвръщаемостта на инвестициите, ако сега използват, знаете, ръчни методи.
Знам, че съм разговарял с редица - когато казвам големи организации с хиляди и хиляди служители, а също вероятно и с хилядите случаи - където имам хора, където им покажа това и те казват, че това ще отнеме две седмици от времето ми назад. Това съм ми казвал повече от веднъж. Така че е трудно да се каже по отношение на действителната сума в долара от покупка, но е значително, когато имате среда.
Както казах, това е доста последователно, хората, с които говоря, водят тези неща в електронна таблица. Така че това е просто много, много субективно нещо, защото всяка среда е малко по-различна по отношение на начина, по който правят лицензирането си и как правят лицензирането си с Microsoft е друга част от това, което е фактор. Но ако им се налага да правят истински прозорци всяка година или на всеки три години, мисля, че три години, максимум за Microsoft, че ще го направят, те искат да се изповядвате поне на всеки три години.
Тогава знаете значението му и това, знаете, че това е просто нещо, което прави много по-лесно. Тъй като това е динамично нещо, което винаги се променя, то дава малко по-голяма валидност и от гледна точка на това, което гледате стихове, добре, че всъщност не сме актуализирали електронната таблица за шест месеца или година. Така че колко често актуализирате електронната таблица е друг въпрос, за да разберете, че отговорът на ROI.
Дез Бланчфийлд: Да, искам да кажа, SQL лицензиране, лицензирането на това е просто проклет кошмар, но е особено кошмар, тъй като лицензирането не е същото между Microsoft и Oracle и всички останали, които правят там неща с база данни. Ако всъщност съхранявате нещата в електронни таблици, което обикновено е това, което всъщност се случва, знаете, че времето за лицензиране идва преди да го осъзнаете в действителност и всъщност нямате данни, ако знаете какво имам предвид, лесно да стигнете до тази информация.
Както и да подчертаете, динамично е и нямам идея лично, защото всъщност никога не съм трябвало да преговарям с Microsoft, така че нямам идея, но вероятно има бази данни, които хората доста често свалят данните от теста, тествайки среда и предполагам, че те са трън в твоя страна, ако правиш лиценз. Това ти ли си-?
Bullett Manale: Да, да. Такъв е случаят, защото много пъти тези неща се забравят и тогава започваме да се опитваме да разберем, добре, добре, добре, имаме основно лицензиране, което трябва да разберем броя на ядрата за всеки от тези случаи и аз не Не знам, що се отнася до стандартите на това, което купувате хардуер разумно, може да закупите доста добър хардуер, тогава ако не използвате този хардуер по начина, по който той трябва да бъде използван, тогава преплащате, защото сте плащането на основните цени, когато тези ядра не се използват, така че да се превърне в проблем.
Така че, всяка версия на SQL има различен начин, по който се прилага лицензирането, което дори прави малко объркващо. Така че имате някои предизвикателства около това и затова това е голяма част от причината тази информация да е много полезна, защото можем да ви кажем коя версия е, можем да ви кажем очевидно броя на ядрата, които имате, ако това са по-стари версии на SQL това беше ценообразуването на сокета, но все още очевидно можем да покажем това. Така че просто, това го прави много по-опростен от рутината, през която трябва да преминете, когато дойде време да се оправдаят тези неща.
Дез Бланчфийлд: Едно нещо, което ми идва на ум, о, извинявай,
Робин Блур: Добре е, отивате в Дез, щях да задам евентуален ирелевантен въпрос.
Дез Бланчфийлд: Просто нещо наистина бързо, докато сте по темата, която сте в момента - виждаме много повече приемане на облачни среди и ако работим в нашия собствен център за данни, в нашата собствена среда, те обхождат и намират, откривайки нещата е сравнително лесно.
Как ние, как да се справим със сценария, в който може да имаме три набора от данни, два облака и видимостта в тези среди е разширявана и често в края на тръбата или VPN има набор от данни. Има ли далеч, за да открием от предния край или трябва да започнем да отваряме портове, за да можем да сканираме в определени среди между вид облак и извън помещения, където работи тази платформа?
Bullett Manale: Да, щеше да има някакво внимание по отношение на пристанищата. Така че, за съжаление, бих искал да кажа, че ще пробие всички тези среди, но има някои различни опции, които бихте могли да направите с това. Очевидно е, че ако правите нещо като Amazon EC2, всичко, което наистина би ви трябва, е достъпът до тази среда чрез вашата свързаност, ако приемете, че портовете ви са отворени и след това ще можете да посочите вашите IP адреси или вашия домейн, свързан с това и може да започне колекцията и започват откриването.
Така че, в тези видове среди това наистина не е проблем; това е по-специфичните типове среди като RDS и където просто получавате самата база данни, където ще бъде малко по-трудно да видите и откриете този тип информация.
Дез Бланчфийлд: Следователно следвайки това, има бази данни и бази данни. Така например, добрите стари времена просто да имам много, много голям двигател на базата данни като анекдота, който споделих отпред, където е само една масивна платформа и всичко, което прави, е да предостави база данни. Днес базите данни са вградени във всичко, всъщност има два или три от тях, които просто работят в телефона ми зад приложения.
Какви предизвикателства срещате със сценарии, в които имате среда, идваща от Lotus Notes, с приложения зад тях, SharePoint с базата данни в различни интернет и т.н.? По същество всичко се захранва от база данни в задната част. Какви неща виждате там и с какви предизвикателства се сблъсквате хората, които просто се опитват да картографират тези видове светове и какво прави вашият инструмент за тях?
Bullett Manale: Ами искам да кажа, че това, което казахте - всичко се нуждае от база данни сега, така че много пъти има много вероятно, има много бази данни, които се въвеждат в средата, която самите DBA дори не са наясно, защото не е много трудно да се инсталира SQL сървър в околната среда, най-общо казано.
Този инструмент също така идентифицира неща като експресни бази данни, така че безплатните версии на SQL Server. Доста смешно, когато отидете да говорите с DBA, за пореден път не получавате последователен отговор по отношение на това дали се интересуват от безплатните бази данни, които са там. Много от тези приложения, за които говорите, ще използват безплатната версия на базата данни. Но самите организации ще имат различно отношение по отношение на това кой е отговорен за тази база данни, в зависимост от това с кого говорите.
Някои DBAs, с които говоря, мога да се сетя за последния път, когато бях в SQL Server PASS, който е в Сиатъл, вие задавате въпроса „Имате ли грижа за експресните си бази данни?“ И беше около петдесет и петдесет. Някои от хората искаха да знаят за тях като DBA, защото смятат, че те са част от техните отговорности, дори тези изразени бази данни, които все още могат да съдържат критична информация; те все още трябва да преминат през процеса на архивиране и все още трябва да се уверят, че всички неща работят от гледна точка на здравето им. Но само знанието, че те съществуват, е също толкова важно, ако не и по-важно.
Докато другата половина от хората са: „Хей, ние не сме отговорни за тези бази данни и всичко, което те поставят върху тях, се пази от човека, който ги е инсталирал.“ Но бих казал, че като цяло това, което вие каза, че всичко в днешно време има свързано с него приложение, което само допринася повече за сложността и объркването на необходимостта да се инвентаризира тази информация.
Дез Бланчфийлд: Да, видях някои, правителствените сайтове вероятно са ми любими, но по-често, отколкото не, виждам в корпоративна среда сега къде е, както казахте, че хората забравят дори аз, когато инсталират нещо като SharePoint или като самообмен, така че знаете, че те идват с безплатна версия, просто вградена, защото те искат, знаете, инсталирайте го бързо и не се притеснявайте, че трябва да отидете и да закупите лицензиране.
Тогава той става голям и тогава някой започва да се оплаква от производителността и те са като: „Това е само стария ви сървър, вашето хранилище, вашата мрежа, каквото и да е“ и тогава DBA се обажда и те са като: „Е, ти“ просто сте натъпкали всичко в тази безплатна версия на базата данни, която не е това, което трябва да изпълнявате тази голяма. "
Особено когато имате сценарии като Project Manager и Office се изпълняват стотици, ако не и хиляди проекти в голямо предприятие или корпорация и те използват SharePoint с Microsoft Project Server и те изхвърлят всички свои PMO неща в тази база данни. Но в предния край приличат, добре, че това е просто уеб интерфейс. Но наистина има бази данни и бази данни.
Bullett Manale: Да.
Дез Бланчфийлд: И така, какви са те, една от първите стъпки, които хората тук предполагам, има няколко въпроса, които бихме могли да искаме да внесем от публиката. Един от първите въпроси е откъде започват хората? Каква е първата естествена стъпка за тях: „Добре, трябва да направим анонимната версия на Алкохолиците?“
Имаме повече бази данни, отколкото знаем какво да правим. Какъв е естественият вид стъпка, като те да отидат: „Добре, трябва да се заемем с това нещо и да започнем да бягаме?“ Дали те просто изстудяват пуйка или по-късно наистина трябва да стартират малки и просто да натрупат опит около картографирането на средата си ?
Bullett Manale: Ами мисля, че това каза, че трябва да набележат околната среда. Сега Microsoft предлага безплатен инструмент за това, Инструментът за планиране на оценка на Microsoft, това е безплатен инструмент, но е статичен. Ти правиш откритието и това е всичко. Получавате списък на нещата, които са там. Взехме това и казахме виж, нека направим крачка по-нататък, нека направим откритието, нека намерим какво има и нека го поставим в хранилището и нека го направим така, че да е динамично и да можем да го добавим, премахнете от него.
Но като цяло най-голямата първа стъпка е, че мисля само да разбера, направете откритието. Независимо дали това означава да изтеглите нашия продукт пробно, можете да го изтеглите и да го изпробвате в продължение на 14 дни и можете да посочите вашата среда и да направите колекцията.
Сега, ако вече имате електронна таблица с куп тази информация там, че сте донякъде уверени, че тази информация е правилна, вие също имате възможността да харесате импортирането в CSV, която се разпространява с цялата тази информация и да направите тази част от това, което вие вече имам. Но по отношение на намирането на това, което не знаете, единственият начин да направите това е ръчно да излезете, да го направите или да имате инструмент, който търси този тип неща като този. Това е решението, което ще трябва да вземете в даден момент, е: „Опитвам ли се да автоматизирам това откритие или поне да получа добра основа на това, което първо е там и след това може би се притеснявате за някои изключения?“ Но за в по-голямата си част вероятно имате нужда от инструмент.
Дез Бланчфийлд: Така че бързо. Къде отиват хората, за да започнат това? Те удрят вашия уебсайт? Как да достигнат и да започнат бързо това?
Bullett Manale: Ако отидете на Idera, IDERA.com, ще видите, а аз всъщност мога просто да го покажа наистина бързо. На уебсайта на Idera ще отидете на продукти, ще отидете на диспечера на инвентара. Ще видите линк за изтегляне тук. Вие просто определяте коя конструкция искате да инсталирате на 64 или 32 битова и това ще ви задвижи и можете да започнете откриването си от там.
Robin Bloor: Фантастична и страхотна, страхотна презентация, много ви благодаря.
Bullett Manale: Благодаря.
Ерик Кавана: Имаме няколко въпроса от публиката и ще ги изпратим по имейл, защото днес трябва трудно да се спрем, но Bullett, отново, чудесна работа на демонстрацията, страхотна работа от нашия продуцент, хващайки, че не е било ' t показва.
Bullett Manale: Съжалявам за това.
Ерик Кавана: Не, това са добри неща, ти даваш видимост в сърцевината на бизнеса, нали? Тъй като бизнесът управлява данни и вие давате видимост чак до сърцевината. Така че няма повече ръчно вълнообразни неща; сега можете всъщност да насочите към нещата и да разрешите това. Толкова добре за вас.
Bullett Manale: Благодаря.
Робин Блур: Но беше чудесно да го видя и на живо, между другото, добре направено.
Ерик Кавана: Да, ще архивираме тази уебкаст за по-късно гледане и след това ще се надяваме, че след час или два първоначалният архив се издига понякога е малко по-дълъг от това, но ще бъдем сигурни, че ще оставим хората зная. С това ще ви пуснем, хора. Благодаря отново за посещението в инструктаж, всъщност ние сме горещите технологии. Ще те догоним следващия път. Внимавайте, чао-чао.
