За вкъщи: Водещият Ерик Кавана обсъжда управлението на базата данни и откриването на инстанции с Робин Блур, Дез Бланчфийлд и Бълет Манале в последния епизод на Hot Technologies.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре дами и господа. Добре дошли отново. Казвам се Ерик Кавана. Нещата са горещи. Тук нещата се нагряват. Не знам какво става О, това е правилно, време е за горещи технологии. Да, наистина се казвам Ерик Кавана. Можете да ме намерите на @eric_kavanagh. Това е шоуто, което е предназначено да говори за горещото на пазара. Днес заглавието, „Ключове към кралството: Управление на SQL Server с динамично откриване.“ Добри неща. Има наистина твоя. Добре, тази снимка беше от преди няколко години. Няма да лъжа, сега изглеждам малко по-възрастен, но това е добре.
Така че, говорим за това как технологиите и SQL Server са наистина, наистина, наистина, много горещи. Днес имаме цял куп съдържание, така че ще го предам веднага. Изчакайте, ето тук. Има нашите говорители И Робин Блур отива на първо място.
Robin Bloor: Да, именно. Презентацията ще влезе в дълбочина в управлението на базата данни, така че просто мислех, че ще премина през управление на базата данни или, знаете ли, лабиринт на базата данни, за да вкарам хората в духа на това. Аз бях 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. И обикновено са критични. И това е всичко, което трябва да кажа. Ще предам на Дез.
Dez Blanchfield: Благодаря ти много. Ще ни заведа на едно малко забавно, анекдотично пътешествие, защо цялата тема, която днес е свързана и е по-критична от всякога. Не толкова отдавна бях включен в проект, при който мигрирахме държавна платформа, която се използва за регистрация на лицензи и регистрация на превозни средства и цял набор от неща около тази тема, от платформата на 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 да вземат тези решения около лицензирането.
Сега другото нещо, което, като разговаряме с DBA, открихме и научихме наистина бързо, е, че - и неговият вид връщане към това, което беше обсъдено по-рано - може да имате 300 екземпляра в средата си на SQL Server, но има наистина само подмножество от тези, които наистина се наблюдават и управляват от традиционен тип инструмент за мониторинг на ефективността.
Така че, ако отидете и всъщност седнете с DBA и си кажете: „Вижте, знаем, че имате тези 20 екземпляра или 10 екземпляра от 300-те, които се наблюдават с този инструмент, предназначен да следи това и да съответства на вашите SOA и получавайте сигнали и всички тези добри неща “, което открихме също, че ако попитате:„ Тогава добре какво ще кажете за тези 280 екземпляра, които имате? Имате ли грижи за тези? “И те го правят, грижат се за тях, но просто не искат задължително да инвестират, за да наблюдават тези на нивото на дълбочина, което може да се направи с тези случаи срещу тези 10 или 20 наистина, наистина критични екземпляри на продукти.
Така че другата част на уравнението с този инструмент е, че той също така помага по отношение на възможността да се уверите, че на базово ниво сте обхванати от гледна точка на здравето на инстанцията. Сега няма да ви кажа дали имате задънена улица или коя е жертвата на безизходицата. Не е да стигнете до това ниво на самите сесии и детайлите на заявките. Но в същото време все пак ще ви уведоми, че, хей сървърите надолу или хей обемът се запълва или трябва да направите резервни копия на базата данни, това е важна част от това да бъдете DBA.
Така че тези неща определено все още са важни и затова с този вид инструменти той е направил начин да имате уловка за вашите наистина критични случаи, които са много, много си струва да бъдат обвързани с тях, ако отидат надолу трябва да знаете веднага. Те могат да имат по-високото ниво на наблюдение и да могат да правят такива неща, докато с това ще могат да избират всички нови екземпляри, които се добавят към околната среда, и да се уверят, че те са отчетени, както и да се уверят, че формират се основни нива на здравни проверки.
Така че накратко това са мениджърите за импортиране на SQL Inventory. Сега ще ви покажа демонстрация. Преди да направим това, просто бързо ще ви покажа, че това е слайдът за архитектура тук и просто за да покажем това, екземплярите на SQL, които се управляваха, можем да открием всичко от SQL 2000 чак до новите версии на SQL.
Така че можем да направим това, без изобщо да се налага да разполагаме агенти в самите инстанции. Правим го чрез услуга за събиране и ще излезем да съберем тази информация и я поставим в хранилище, а след това от предходната конзола на Tomcat уеб услугата ще може да взаимодейства с тези данни и да я преглежда. Така че неговата доста пряма архитектура.
Продължавам напред и превключвам и всъщност ни вкарват в самия продукт, за да можете да усетите за него, разбиране за това как работи. Така че най-добрият начин да направите това е първо да ви запознаем със самия интерфейс в това е вид табло, което разглеждахме тук.
Виждам броя на случаите в момента, когато имам управление, не е чак толкова много. Но и в задния джоб нямам цял център за данни. Така че имам около шест случая, които виждаме тук. Сега, това каза, Im, това, което Im ще направя, е да разгледам процеса на откриване и да покажа как ще работи.
Сега първото нещо, което бихте направили, е в секцията за администрация, която можете да определите как бихте искали да откриете вашите случаи. Бихте могли да поставите тази информация тук и за пореден път, което може да стане чрез редица IP адреси. Можете да насочите към домейн или поддомейн и да бъдете в състояние само на онези машини, които са членове на този домейн, да могат да извършват онези проверки, за които бихте могли да изберете редица различни видове характеристики, когато SQL се изпълняват, за да проверите.
След това, след като направите това и можете да го автоматизирате да се изпълнява ежедневно, за да отидете и да съберете тези данни. Можете също така да можете да го правите ad hoc, ако е необходимо. Но след като започнете това, този процес на откриване, тогава това, което ще започнете да виждате, е когато преминете към изглед на екземплярите тук. Имате раздел „Откриване“ и раздел „Откриване“ ще ни покаже онези случаи, които бяха открити наскоро. Така че в нашия случай тук имаме номер. Това, което ще продължа, е да продължа напред и да добавя този, който ще използвам като пример. Значи това е случай в Чикаго в случая, нали? Ще продължа напред и ще добавя този екземпляр към моя инвентар.
Добре и това ще ме разгледа през няколко неща тук. Просто ще продължа напред и ще видите, че можем да зададем идентификационните данни. Моите пълномощия трябва да са добри там. Ще продължа напред и ще забележите, че мога да възложа собствеността върху това, ако искам. Мога да посоча и местоположение. Сега и самото местоположение може да се добави, и не забравяйте, че следващия път наоколо, очевидно.
Още веднъж мога да свържа маркери към това по отношение на метаданните и как бихме искали да поставим тези екземпляри на SQL, по-специално този, в кои кодове искаме да го поставим. Така че имаме някои текущи тагове, популярни тагове , така че можем да разгледаме куп различни тагове, които може би вече съм включил. Просто ще избера някои от тях на случаен принцип и можем да приложим това.
Така че сега, когато продължа напред и добавям това към инвентара. Сега, когато е добавен, сега ще видим, че се показва под този управляван изглед и така можете да го видите изброен тук. Значи, вие знаете, че това е първата стъпка и това, което току-що ви показах, беше начинът, по който ще добавяте главно тези случаи, когато преминавате ежедневно. В някои случаи може да кажете, че знаете какво, ако неговото корпоративно издание на SQL сървър, аз автоматично искам да го добавя към моя инвентар? Не е необходимо ръчно да отида и да избера да го направя.
Джослин: Ще ви прекъсна наистина много бързо. Не видяхме демонстрацията ти
Bullett Manale: Ти не си?
Джослин: Не.
Bullett Manale: Ами това не е добре, нека видим.
Ерик Кавана: Ако отидете в горния ляв ъгъл, щракнете върху старт, щракнете върху него.
Bullett Manale: А, добре.
Ерик Кавана: А сега направете споделяне на екрана.
Bullett Manale: Съжалявам за това. Мда.
Ерик Кавана: Това е добре. Добър улов там, продуцент Джоселин.
Bullett Manale: Добре, така ли е по-добре? Виждате ли го сега?
Robin Bloor: Да, именно.
Bullett Manale: Добре, така че нека да ви разведем просто там, където бяхме истински бързо. Имаме откритите случаи, които сме имали по-рано. Току-що добавих инстанцията Чикаго и това, което виждате сега, е сега изброено тук. Забележете, че вече има много допълнителна информация. Ако щракнете върху самия екземпляр, ще започнете да виждате всички видове информация, която вече събрахме за този екземпляр. Сега ето списък на всички бази данни, които са там. Можем да видим разбивка на базите данни по размер и по активност, по отношение на това кои имат най-голям размер и активност.
Още веднъж можем да ви кажем веднага прилепите кои приложения виждаме да се изпълняват в този екземпляр въз основа на работното натоварване, което виждаме да работи в инстанцията. Така че е хубаво да може да прави това автоматично. Не е нужно да влизам и да обвързвам заявлението с инцидента. Въз основа на видяното можем да го попълним. Сега, ако искате ръчно да добавите приложение, можете абсолютно да го направите. Но това е просто хубав начин да можете да покажете връзката на инстанцията с базата данни или, съжалявам, към приложението.
Ще забележите също, че от дясната страна на екрана имаме незабавно обобщение, а отдолу имаме обобщение на сървъра. И така, в случая информираха ключови парчета информация, знаейки версията, а не само, знаете ли, SQL Server 2012, но действителният номер на версията, който, включително и ни казва какви актуални корекции са обвързани с него, какви сервизни пакети са обвързани за него може да е много важно да знаете. Очевидно изискването за памет е важно. Всичко подобно, независимо дали е клъстерирано, цялата тази информация, не е нужно да го внасям - вече се събира и събира, и след като установим, че откритият му екземпляр, това ще бъде част от нашия опис.
Другото, което ще видите тук - и това ще ви покаже - неговото под този изглед на инстанция. Имаме тези атрибути, за които говорих по-рано, персонализираните атрибути, които могат да се добавят. Така че можем да добавим отворен вид полета, можем да правим да / не по отношение на, знаете ли, милиард избори. Дори можем да правим падащи списъци. Можете да направите това в случай на базата данни или на ниво сървър.
След това, ако превъртим малко надолу, можем да видим цялата свързана информация със самия сървър. Знаете, знаете, че всички тези неща очевидно наистина са много полезни, тъй като всичките им събрани и събрани и това е там за нас, веднага след като вземем това решение, за да го направим част от нашия инвентар. Тук можем да покажем някои от разликите по отношение на процесорите, броя на логическите спрямо физическите, колко памет. Така че наистина получавате наистина добра и богата информация, без да се налага да вършите много работа.
Сега другата част от това, както казах, събира тези данни на ниво сървър. Ако дори се спуснем до базата данни, можем да видим, че много от тези неща са разбити и за нас.Така че, ако отида в моето хранилище за съответствие, в този случай бих могъл да кажа, добре знаете, че това се справя с a, това е база данни за съответствие, в която е свързано ниво на съответствие или регулаторно изискване и може да бъде, да кажем, SOX съответствие или PCI съответствие. Така че мога да избера кои бази данни имат кое съответствие, свързано с тях, че трябва да попълня или да се уверя, че поддържам по отношение на това регулаторно изискване.
Така че този вид неща се оказаха много полезни за DBA, защото там е мястото, на което те могат централно да отидат, за да запазят лесно всички тези свързани метаданни в обкръжението си и те могат да направят това, както казах, да съответства на бизнеса им, както правят. , като начина, по който правят бизнес. Така че, ако разгледаме всички неща досега това, което видяхме, очевидно имате доста добър преглед на инстанцията, ако проучвам.
Мога също да търся, така че казах, нека да потърся това хранилище за съответствие в инвентара си. Тогава това, което ще видите тук, е, че мога да търся тези неща и да мога да ги идентифицирам. Казвам това - Не съм сигурен какво, бутоните ми за работа не работят там. Добре. Нека видим, нека опитаме отново. Ето. Така че след това ще можем да видим разбивка на това, с което виждаме нещо, за спазването им и аз мога да разгледам в него и да го видя и от тази гледна точка. Така че имате наистина бърз и лесен начин да ровите в тези данни.
Както вече споменахме, вие имате много различни начини за създаване на метаданни срещу сървъра и базата данни. Другата част към това е в състояние да се възползвате от това по начина, по който сте я групирали и начина, по който сте свързани с нея. Преминаваме към изглед на изследователя, можем да направим точно това. Можем да кажем, че искам да направя броя на базата данни по местоположения. Така че броят на базите данни на всяко място на средите, които поддържам. Или може би това се основава на собственика, който притежава инстанциите, които имам там, по отношение на може би брой инстанции. Така ще можем да видим това. Така че получавате наистина добър и лесен начин да рисувате тези снимки за вас въз основа на какъвто и да е въпрос, който се опитвате да отговорите по това време.
Тогава това, което разполагате с тази информация, е създадено по начина, по който сте искали, ние можем да го експортираме в PDF или различни формати, за да можем да го използваме и на нашите колеги или да направим всичко необходимо там. Значи знаете, че ще можете да правите такива неща. Да се върнем към - загубих ли го? Ето. Добре, така да се надяваме, че това има смисъл по отношение на това, за което говорих досега. Сега, когато данните, които събрахме, всичко това очевидно е наистина жизненоважно поради редица причини - лицензиране и какво ли още не.
Последният нещо, което само трябва да споменем, е, че тук преминаваме към този раздел за администрация. Тук също можете да конфигурирате вашето и вашето предупреждение и да можете да сте сигурни, че за нещата, за които бихте искали наистина да знаете, можете да настроите и тези неща. Така че можем да настроим сигнали, можем да настроим способността да включваме някои неща и да изключваме определени неща и след това да бъдем в състояние да определим кой ще получава тези съобщения и като се абонираме за тези сигнали, можем да свържем кого бихме искали бъди, който би искал да знае за тези неща.
Но както казах по-рано, това е наистина приятен начин да направите, поне да имате спокойствие, за да знаете за целия си случай на SQL на предприятието - какво е това, което имате, и също така да се уверите, че то работи оптимално, дори и ако не го правите, не взеха решение да направят инвестиция за тежък инструмент за наблюдение на ефективността, който да управлява този инстанция. Това ще ви обхване, защото това е много достъпен начин да излезете навън и в много случаи да можете да правите тези описи и да можете да направите един вид на много широк вид общо ниво на мониторинг, за да сте сигурни, че имам това спокойствие и знам какво става.
Така че да се надяваме, че има смисъл в начина, по който сме го описали и ви го показахме. Предполагам, че от тази гледна точка мога да продължа напред и да го предам назад и можем да поговорим още малко.
Ерик Кавана: Това звучи страхотно. Значи Робин? Дез? Някакви въпроси?
Robin Bloor: Ами имам въпроси. Много интересно е всъщност да наблюдавам това, искам да кажа, че просто исках да направя коментара, че почти навсякъде съм бил, не само сред DBA, но и сред момчетата в мрежата, сред момчетата за съхранение, сред момчетата за управление на виртуални машини, те са всички работа с електронни таблици.
Ерик Кавана: Това е вярно.
Dez Blanchfield: Вие някак знаете, че това, вие знаете, че това е добре, докато числата започнат да се движат. Когато числата започнат да се движат, знаете, че те ще изпаднат в неприятности. Така че въпросът сега ме интересува и знам, че ще ви е трудно да отговорите, но какво, ако отидете на място, където те нямат нищо подобно за работа с електронни таблици, така че да предположим DBA са много умни момчета и така нататък и така нататък, какъв ROI мислите, че ще получите от прилагането на нещо подобно? Имате ли някакви фигури по този въпрос или някакви указания за това?
Bullett Manale: Трудно е да се каже каква е възвръщаемостта на инвестициите, защото средите ще бъдат малко по-различни. Очевидно е, че колкото по-голямо е предприятието, толкова по-голяма е средата, очевидно толкова повече ще бъде възвръщаемостта на инвестициите, ако сега използват, знаете, ръчни методи.
Знам, че съм говорил с редица - когато казвам големи организации с хиляди и хиляди служители, а също така вероятно и с хилядите случаи - където имам хора, където им показвам това и те казват, че това ще отнеме две седмици от времето ми назад. Това бях ми казвал повече от веднъж. Така че е трудно да се каже по отношение на действителната сума в долара от покупка, но значителната, когато имате среда.
Както вече казах, неговата последователност е хората, които аз, повечето хора, с които говоря, съхраняват тези неща в електронна таблица. Така че само неговото е много, много субективно нещо, защото всяка среда, малко по-различна по отношение на начина, по който правят лицензирането си и как правят лицензирането си с Microsoft, е друга част от това, което е фактор. Но ако им се налага да правите истински прозорци всяка година или на всеки три години, мисля, че три години на максимум за Microsoft, които са те, те искат да се сбъднете поне на всеки три години.
Тогава знаете значението му и това, знаете просто неговото нещо, което прави много по-лесно. Тъй като неговото динамично нещо, което винаги се променя, дава малко по-голяма валидност и по отношение на това, което гледате стихове, и ние наистина не актуализирахме електронната таблица за шест месеца или година. Така че колко често актуализирате електронната таблица е друг въпрос, за да разберете, че отговорът на ROI.
Dez Blanchfield: Да, искам да кажа, лицензирането на SQL, лицензирането на това е просто проклет кошмар, но особено негов кошмар, тъй като лицензирането не е същото между Microsoft и Oracle и всеки друг, който прави там неща от базата данни. Ако всъщност съхранявате нещата в електронни таблици, което обикновено е това, което всъщност се случва, знаете, че времето за лицензиране идва преди да го осъзнаете и всъщност нямате данни, ако знаете какво имам предвид, за да получите лесно тази информация.
Както и да посочвате, динамиката му и аз лично нямам идея, защото всъщност никога не ми се е налагало да преговарям с Microsoft, така че нямам никаква представа, но по всяка вероятност има бази данни, които хората често свалят тестовите данни, тестовата среда и аз бих предполагам, че те са трън в твоя страна, ако правиш лиценз. Това ти ли си-?
Bullett Manale: Да, да. Това е така, защото много пъти тези неща се забравят и тогава започваме да се опитваме да разберем, добре, добре, weve получиха основно лицензиране, че трябва да разберем броя на ядрата за всеки от тези случаи и аз не знам, от гледна точка на стандартите на това, което купувате хардуер разумно, можете също така да закупите доста добър хардуер, тогава ако не използвате този хардуер по начина, по който трябва да се използва, тогава преплащате, защото плащате за основните цени, когато тези ядра не се използват, така че се превръща в проблем.
Така че, всяка версия на SQL има различен начин, по който се прилага лицензирането, което дори прави малко объркващо. Така че имате някакви предизвикателства около това, така че това е голяма част от причината, поради която тази информация е много полезна, защото можем да ви кажем коя версия е, можем да ви кажем очевидно броя на ядрата, които имате, ако нейните по-стари версии на SQL това беше ценообразуването на сокета, но все още очевидно можем да покажем това. Така че просто, това го прави много по-опростен от рутината, през която трябва да преминете, когато дойде време да се оправдаят тези неща.
Dez Blanchfield: Едно нещо, което ми идва на ум, о, извинявай, отиди…
Robin Bloor: Добре е, отивате в Дез, щях да задам евентуално нерелевиран въпрос.
Dez Blanchfield: Просто нещо наистина бързо, докато сте по темата, която сте в момента - виждате много повече приемане на облачни среди и ако изпълнявате това в нашия собствен център за данни, в нашата собствена среда, те обхождат и намират, откриването на нещата е сравнително лесно. ,
Как ние, как да се справим със сценария, в който може да имаме три набора от данни, два облака и видимостта в тези среди се разширява и често има набор от данни в края на тръбата или VPN. Има ли далеч, за да открием от предния край или трябва да започнем да отваряме портове, за да можем да сканираме в определени среди между вид облак и извън помещения, където работят тези платформи?
Bullett Manale: Да, щеше да има някакво внимание по отношение на пристанищата. Така че, за съжаление, бих искал да кажа, че ще пробие всички тези среди, но има някои различни опции, които бихте могли да направите с това. Очевидно е, че ако правите нещо като Amazon EC2, всичко, от което се нуждаете, наистина е достъпът до тази среда чрез вашата свързаност, ако приемете, че портовете ви са отворени и след това ще можете да посочите вашите IP адреси или вашия домейн, свързан с това, и той може да започне събирането и да започне откриването.
Така че, в тези видове среди, това наистина не е проблем; това е по-специфичните типове среди като RDS и където просто получавате самата база данни, където ще бъде малко по-трудно да видите и откриете този тип информация.
Dez Blanchfield: Следователно, следвайки това, там са базите данни и базите данни. Така, например, добрите стари времена, че просто имам много, много голям двигател на базата данни като анекдота, който споделих отпред, където неговата единствена масивна платформа и всичко, което прави, е да предоставя база данни. Днес базите данни са вградени във всичко, всъщност тези като две или три от тях просто работят в телефона ми зад приложения.
Какви предизвикателства срещате при сценарии, в които имате среда, идваща от Lotus Notes, с приложения зад тях, SharePoint с базата данни в различни интернет и т.н.? По същество всичко се захранва от база данни в задната част. Какви неща виждате там и с какви предизвикателства се сблъсквате хората, които просто се опитват да картографират тези видове светове и какво прави вашият инструмент за тях?
Bullett Manale: Искам да кажа, че нещото в него е, че това, което казахте - всичко сега се нуждае от база данни, така че много пъти е много вероятно, има много бази данни, които се въвеждат в средата, която самите DBA дори не са направили наясно, защото не е много трудно да се инсталира SQL сървър в средата, най-общо казано.
Този инструмент също така идентифицира неща като експресни бази данни, така че безплатните версии на SQL Server. Доста смешно, когато отидете да говорите с DBA, за пореден път не получавате последователен отговор по отношение на това дали те се интересуват от безплатните бази данни, които са там. Много от тези приложения, за които говорите, ще използват безплатната версия на базата данни. Но самите организации ще имат различно отношение по отношение на това кой е отговорен за тази база данни, в зависимост от това с кого говорите.
Някои DBAs, с които говоря, мога да се сетя за последния път, когато бях в SQL Server PASS, който е в Сиатъл, вие задавате въпроса „Имате ли грижа за експресните си бази данни?“ И беше около петдесет и петдесет. Някои от хората искаха да знаят за тях като DBA, тъй като смятат, че те са част от техните отговорности, дори тези изразени бази данни, които все още могат да съдържат критична информация; те все още трябва да преминат през процеса на архивиране и все още трябва да се уверят, че всички неща работят от гледна точка на здравето им. Но само знанието, че те съществуват, е също толкова важно, ако не и по-важно.
Докато другата половина от хората са: „Хей, не бяха отговорни за тези бази данни и всичко, което те поставят, се пази от човека, който ги е инсталирал.“ Но бих казал, че като цяло това, което казахте, всичко е доста в днешно време има свързано с него приложение, което само допринася повече за сложността и объркването на необходимостта от инвентаризиране на тази информация.
Dez Blanchfield: Да, видях някои, правителствените сайтове вероятно са ми любими, но по-често не ги виждам в корпоративна среда сега къде е, както казахте, че хората дори забравят, когато инсталират нещо като SharePoint или като самообмен, така че знаете че те идват с безплатна версия, просто вградена, защото искат, знаете, инсталирайте го бързо и не се притеснявайте, че трябва да отидете и да купите лицензиране.
Тогава тя става голяма и тогава някой започва да се оплаква от производителността и прилича на: "Това е само стария ви сървър, вашето хранилище, вашата мрежа, каквото и да е" и тогава DBA се обажда и те са като: "Е, ти просто натъпкано всичко в тази безплатна версия на базата данни, която не е това, което трябва да изпълнявате тази голяма. "
Особено когато имате сценарии като Project Manager и Office изпълняват стотици, ако не и хиляди проекти в голямо предприятие или корпорация и те използват SharePoint с Microsoft Project Server и те изхвърлят всички свои PMO неща в тази база данни. Но в предния край те харесват, добре е просто уеб интерфейс. Но наистина има бази данни и бази данни.
Bullett Manale: Да.
Dez Blanchfield: И така, какви са те, една от първите стъпки, които хората тук предполагам, има няколко въпроса, които бихме могли да искаме да внесем от публиката. Един от първите въпроси е откъде започват хората? Коя е първата естествена стъпка за тях: „Добре, трябва да направим анонимната версия на Алкохолиците?“
Имаме повече бази данни, отколкото знаем какво да правим. Какъв е естественият вид стъпка, като те да отидат: „Добре, трябва да се заемем с това нещо и да започнем да бягаме?“ Дали те просто изстудяват пуйка или по-късно наистина трябва да стартират малки и просто да натрупат опит около картографирането на средата си ?
Bullett Manale: Ами мисля, че това каза, че трябва да картографират околната среда. Сега Microsoft предлага безплатен инструмент за това, инструментът за планиране на оценка на Microsoft, безплатен инструмент, но той е статичен. Ти правиш откритието и това. Получавате списък на нещата, които са там. Взехме това и казахме, че погледът позволява да направим крачка по-нататък, да направим откриването, да намерим какво има там и да го поставим в хранилището и да го направим така, че да е динамично и да можем да добавим към него, премахнете от него.
Но като цяло най-голямата първа стъпка е, че мисля само да разбера, направете откритието. Независимо дали това означава да изтеглите нашия продукт пробно, можете да го изтеглите и да го изпробвате в продължение на 14 дни и можете да посочите вашата среда и да направите колекцията.
Сега, ако вече имате електронна таблица с куп тази информация там, че сте донякъде уверени, че тази информация е правилна, вие също имате възможността да харесате импортирането в CSV, която се разпространява с цялата тази информация и да направите тази част от това, което вие вече имам. Но по отношение на намирането на това, което не знаете, единственият начин да направите това е ръчно да излезете, да го направите или да имате инструмент, който търси този тип неща като този. Това е решението, което ще трябва да вземете в даден момент, е: „Опитвам ли се да автоматизирам това откритие или поне да получа добра основа на това, което най-напред е там и след това може би се притеснявам за някои изключения?“ Но за повечето част вероятно имате нужда от инструмент.
Dez Blanchfield: Така че бързо. Къде отиват хората, за да започнат това? Те удрят вашия уебсайт? Как да достигнат и да започнат бързо това?
Bullett Manale: Ако отидете на Idera, I-D-E-R-A.com, ще видите, а аз всъщност мога просто да го покажа наистина бързо. На уебсайта на Idera ще отидете на продукти, отидете на диспечера на инвентара. Тук ще видите връзката за изтегляне. Направо определяте коя конструкция искате да инсталирате на 64 или 32 битова и това ще ви стане и можете да започнете откриването си от там.
Robin Bloor: Фантастично и страхотно, страхотно представяне, много ви благодаря.
Bullett Manale: Благодаря ти.
Ерик Кавана: Имаме няколко въпроса от публиката и добре тези към вас, защото днес трябва трудно да се спрем, но Bullett, отново, страхотна работа на демонстрацията, страхотна работа от нашия продуцент, хващайки, че това не беше показано.
Bullett Manale: Съжалявам за това.
Ерик Кавана: Не, това са добри неща, ти даваш видимост в основата на бизнеса, нали? Тъй като бизнесът управлява данни и вие предоставяте видимост чак до сърцевината. Така че няма повече ръчно вълнообразни неща; сега можете всъщност да насочите към нещата и да разрешите това. Толкова добре за вас.
Bullett Manale: Благодаря ти.
Robin Bloor: Но беше чудесно да го видя и на живо, между другото, добре направено.
Ерик Кавана: Да, ние ще архивираме тази уебкаст за по-късен преглед и след това ще я надяваме след около час-два, първоначалният архив се повишава понякога и малко по-дълго от това, но не забравяйте да уведомите хората. С това щяхме да те пуснат, хора. Благодаря отново, че посетихте инструктажа, всъщност бяха горещите технологии. Ами догонвам ви следващия път. Внимавайте, чао-чао.