От персонала на Техопедия, 22 февруари 2017 г.
Отнемане: Домакинът Ерик Кавана обсъжда управлението на базата данни с д-р Робин Блур, Дез Бланчфийлд и Бин Чау на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре, госпожи и господа. Здравейте и добре дошли отново. Това е сряда, това е четири часа източно време и за последните няколко години това означава, че е време за горещи технологии. Точно така, това е нашето шоу с нашите приятели Techopedia - Techopedia.com. Вижте ги онлайн. Те получават чудовищен трафик, 1, 5 милиона уникални посетители месечно. Това е много уеб трафик. Темата днес, „Мечтата на DBA: откриване и управление в околната среда.“ Да, наистина, това е голям проблем, особено за по-големите организации. Има слайд за вашето наистина и достатъчно за мен, ударете ме в Twitter @eric_kavanagh, аз винаги се опитвам да се върна назад и да участвам в разговор там.
Отново говорим за технологиите на базата данни днес и наистина можем да разберем какво се случва в широк пейзаж от екземпляри от база данни. Както много от вас знаят, след като започнете да разраствате организацията си, получавате много повече от тези случаи навън и запазването на тези неща може да бъде малко интересно предизвикателство. Всъщност, спомням си преди няколко години, имах страхотен разговор с човек, който беше директор по управление на данните за кабинета на CIO в Министерството на отбраната. И аз му разказвах всички тези интересни неща, проведохме този страхотен разговор и му разказах моята история за лобирането за прозрачност във федералните разходи, а той се засмя и той каза: „О, значи е вашата къща, където трябва да изпратя следващия удари с дрон хищник. “Той каза:„ Прозрачност във федералните разходи? Дори не знам колко лицензи на Oracle имам тук. ”Когато чух това, наистина успях да преценя мащаба на предизвикателството, с което се сблъскват някои организации.
В наши дни има много интересни инструменти - ще чуем за един днес - за разбиране на това какво лети наоколо, но дори преди 20 години това беше наистина сериозно предизвикателство. Когато става въпрос за организации с размер DOD, можете просто да си представите, че ако се справите с това, ще спестите много пари, ще спестите много време, ще решите някои проблеми с управлението; приключвате с решаването на множество предизвикателства наведнъж, ако правите този вид правилно. Ще научим за това днес.
Имаме собствен д-р Робин Блур, главен анализатор на The Bloor Group. Имаме Дез Бланчфийлд, нашият учен по данни, който се обажда отдолу, Сидни, Австралия. А Binh Chau, старши продуктов мениджър на IDERA, също е на линия.
Ние правим #HOTTECH като хештег - не се колебайте да туитвате по време на шоуто. И ние разчитаме на вас момчета за добри въпроси, така че, моля, не се срамувайте: задавайте въпроси по всяко време, използвайки Q&A компонента на вашата конзола за уебкаст или този прозорец за чат, независимо от това. И с това ще го предам на д-р Робин Блур. Нека да му предам ключовете на WebEx. Там отива и го отнемайте.
Д-р Робин Блур: Добре. Е, ето, да преминем към първия слайд. В Италия ги наричат Станлио и Олио, Лоръл и Харди. През 90-те години, когато всички се тревожиха за 2000-та година, аз участвах в редица проекти от 2000-та година. И аз отидох - нека да ги наречем голяма застрахователна компания - и те откриха, че имат над 500 приложения, за които не знаеха, че съществуват в мейнфрейм. Те правеха опис на мейнфрейм. Е, в онези дни обкръжението на мейнфрейм беше много по-добре обгрижвано от всичко, което се появи по-късно, искам да кажа, просто няма въпрос за това.
Бях наистина зашеметен и разговарях с хора от организацията и те казаха, че няма централен изчерпателен … няма човек, отговорен да знае тази информация. Те никога не са вземали описи на активите си. И база данни е актив в несигурни условия, защото съдържа данни и ценни данни. Колко случая е въпросът и всъщност къде са те? Това е просто „Какво е база данни?“ И причината мисля така, базата данни е шкаф, в който хвърляте данни. И наскоро разговарях със сайт, в който имаше хиляди случаи на Oracle. Е, Oracle е база данни, че ако я използвате по някакъв сложен начин, тя изисква DBA.
Някак ме попитаха за това и те отговориха, че, за, мисля, че става въпрос за седем или осем DBA в цялата организация. И аз казах, знаете, „Кой се грижи за останалите хиляди инстанции?“ И те казаха: „Е, наистина какво се случва там е, че хората просто го използват като файлова система. Имаме редица бази данни, които са в големи клъстери, където ефективността наистина има значение и те имат DBA, които постоянно стоят над тях. И тогава имаме хиляди други бази данни, за които никой не се грижи изобщо. "И аз ги попитах точно колко бази данни и те излязоха с въпроса:" Е, последният път, когато Oracle го одитираха. "Те не направиха одити сами, знаете, което е нещо интересно.
Но, знаете, има причини за използване на база данни. База данни реализира модел на данни. Той е там за споделяне на данни: може да управлява множество едновременни заявки за данни, да внедрява модел на защита, съвместим ли е с ACID, е еластичен или може да бъде настроен да бъде устойчив, нали знаете. Това е причината да имаме бази данни. Но, знаете, не е необичайно да срещате сайтове с хиляди екземпляри SQL Server или Oracle и повечето от тях просто се използват като файлови системи. И така защо наистина да създадете нов екземпляр?
Знам от екипите на програмисти, че ако създават ново приложение, те го изграждат в силоз, така че всяко ново приложение ще има отделна база данни. Не е задължително да се опитват да направят слой от данни от неща - не мисля, че това е добра практика. Но там отново знаете, ако имате много сложна среда, става много, много трудно да опитате и да съберете всички бази данни, които са свързани помежду си по отношение на наличието на данни в тях, където има отношения. Инстанциите се създават за реплики.
Знаете, можете да имате горещи стендбайли или реплики за целите на наличността, но също така имате реплики или полуреплики в маркерите за данни. И след като бе представен светът на хранилището на данни, възниква въпросът за това, колко много данни са били там, а хората просто ги използват като файлове за клониране, изваждайки данни от хранилището на данни и не особено се грижи за ефективността му в смисъл, че те просто ще направят като по подразбиране изпълнение. Повечето от тези хора вероятно дори не са знаели, че всъщност можете да настройвате бази данни. Виждал съм дизайни, които са разделили данните в отличителни купища с цел разпространение.
Знаете, често получавате тази ситуация на репликация, при която имате множество депа в една организация и всеки от тях има бази данни и всяко е частица от централна база данни. Получавате случаи на заточване. Лоши дизайнерски решения - видях някои наистина причудливи дизайни да се осъществяват по отношение на бази данни, в които хората са създали отделни бази данни без основателна причина. И както отбелязах, базите данни са файлови системи.
И тогава има тестови и разработващи среди, които трябва да бъдат изправени и паднали, но всички те се считат за случаи на база данни и всички, между другото, трябва да имат сигурност и всички останали неща, които базата данни се надява. Съображения за инстанции - натоварването на базата данни може да бъде оптимизирано само за конкретен случай. Ако наистина се интересувате от постигане на абсолютно най-добрата производителност, това не означава непременно да ви предостави подобен вид оптимизация.
Има причина да не създавате фалшиви случаи на данни. Смесените натоварвания в същата база данни като контрапункта могат да доведат до лоша производителност - особено забележимият от OLTP и големият трафик на заявки просто не се смесват, никога не се смесват и вероятно никога няма да се смесват. Обикновено е най-добре да консолидирате база данни на ниво сървър, а не да имате няколко VM. Но VM осигуряват изолация; при някои хора е дизайнерско решение да се изолират данни от други данни, така че, ако знаете, ако това приложение не успее или ако тази база данни не успее, това не сваля моето приложение.
Проблемът с това, разбира се, е, че в крайна сметка се натъквате на следващата точка, която е такса за лиценз на база данни. Те варират, но аз видях, че таксите за лиценз на базата данни се превръщат в критерий за дизайн, защото някой не е искал да разбие определен брой и следователно хората, които проектират системи слабо, просто поради начина, по който работи лиценза на базата данни. И там е другото: ако започнете да консолидирате всичките си бази данни, заслужава да се отбележи, че DBA са скъпи. Това не е толкова лесно нещо.
Един прост изглед на света - а това наистина е последният слайд - има слой данни, има транспортен слой и има обработващ слой. И целият хардуер седи под това. Всъщност не е възможно да оптимизирате слоя данни, без да знаете какво точно има в него и защо.
И като го кажа, ще предам на моя приятел отдолу, Дез Бланчфийлд.
Дез Бланчфийлд: Благодаря ти, Робин. Нека просто подредя мишката си тук. И така, днес ще ни разкажа няколко анекдота, защото това е огромна тема и бих могла да прекарам две седмици с маркер на бяла дъска, като се забавлявам, защото имах близо три десетилетия нагоре и спадове в това пространство,
Но първо, ментална визуална картина. Когато се замисля за предизвикателството, за което говорим днес - и по същество, говорим за растеж на базата данни, репликация и разпръскване и всички предизвикателства, които идват с това - исках просто да поставя тази картина на гигантски дъб в нашия ум. Това са известни красиви дървета, те започват като мъничко жълъд, но те растат до тези бехемоти. И когато го правят, те са много големи и разхвърлени. И както можете да видите от това изображение, като визуална метафора, ако искате, знаете, клоните отиват навсякъде и след това клонки слизат от тези и оставя в края на тези и те са във всички случайни, хаотични форми, и това е просто малкото, което можем да видим над земята.
Някак си мисля за такива като данни вътре в базата данни, а отдолу има структура от корени и те използват всякакви направления. Но изглежда много чисто и разумно на повърхността на земята там, където е хубаво и плоско, но реалността е, че е също толкова луда под земята, колкото и над земята; просто не го виждаме. И аз често използвам това, когато започвам да мисля за това как да опиша предизвикателството, за което говорим днес, от организации от борда до техническите специалисти, за да се опитам да ги накарам да визуализират какво всъщност се случва в техните организации. Тъй като е толкова лесно да погледнете екрана на компютъра и да видите тези красиви полета от редове и колони и да си помислите: „Разбрахме го, не е голяма работа“. Но това изобщо не е така. И така в този момент обикновено удрям този един ред, казвайки, че базите данни в съзнанието ми са като жълъди, нали знаете, те започват да се размножават и растат, но преди да го знаете, имате гора от гигантски дъбови дървета и следователно визуалното.
И така, два анекдота само за споделяне на сценарий, който израсна извън контрол и просто не можеше да бъде коригиран, а след това още един, който направи подобно нещо, но беше в състояние да бъде поправен, и ще подчертая ключовия момент от днешната дискусия около това как стигнахме до това.
Първият беше сценарий, при който CIO с най-големи намерения с течение на времето неволно причиняваше едно от най-неочакваните и нежелани развръзки, които просто прерастваха извън контрол. Това беше сценарий, при който правителствена организация с хиляди служители, много технически здрав персонал, изискваше достъп до нейните системи и инструменти, с които да могат да започнат да си сътрудничат и да автоматизират голяма част от своите процеси. Те искаха да се измъкнат от хартиените формуляри и искаха да създават онлайн системи, искаха да събират данни и да ги проследяват и да ги наблюдават и да ги отчитат и да ги представят обратно на своите връстници.
И има всякакви неща, има неща от хората, които се обръщат към офисите си, влизат и влизат за целите на сигурността през целия път до това кой е поръчвал какво в кафенето по време на обяд. И така, добронамереният CIO реши, че Lotus Notes е чудесна идея, тъй като той беше на поредица от семинари, а IBM беше свършил чудесна работа по въпроса и при правилния сценарий щеше да бъде чудесно решение. това е направено под контрол. Но това, което се случи, беше вместо да предадем Lotus Notes на екип от технически хора, които да внедрят в една среда и след това да изправят разумни инструменти и така нататък и да осигурят известен контрол и управление около него, което всъщност се случи, беше да бъде внедрен в стандарта работна среда, SOE, така че всеки десктоп ефективно се превърна в сървър.
И така, те осигуриха обучение и практически бележки и документация за целия този процес и изведнъж хората разбраха: „Да, имам Lotus Notes на работния си плот!“ Какво означава това, според вас? Е, това означаваше, че хиляди много технически умели служители бяха научени как да сценарират и пишат приложения, ефективно, в Lotus Notes, създават малки бази данни, които по същество приличат на електронни таблици, редове и колони и полета, и представят тези малки уеб интерфейси чрез Domino.
Ако исках да заснема информация за нещо, бих могъл просто да създам малка форма и в интерфейс тип електронна таблица, да го сложа във файл, да създам малко база данни на Lotus Notes зад него и да го представя като уеб приложение и да започна да събира информация. И това звучеше чудесно, докато не беше стартирало години и изведнъж се разбраха, някой се събуди и каза: „Ами оставете, защо има 10 000 нови приложения, базирани на база данни, които се появяват в LAN, и по-специално през последните 12 месеца? Какво се случва? ”Е, случилото се беше, че по същество дадохте на хората пистолет, той беше зареден и безопасността беше изключена, и, разбира се, те стреляха в крака.
И тук има този страхотен образ, който обикновено си представям в ума си на италиански художник, който прави това странно нещо, когато получава камион от сено и слама и е изхвърлен в средата на арт студио, а след това получава уредник на арт студиото да нахвърли произволно игла в средата му. И след това прекарва дни на живо на живо, на камера, минавайки през сламата, търсейки иглата в сено, както трябва. Докато в крайна сметка, след часове и дни, той го намира и скача нагоре-надолу и се вълнува. И така или иначе, италиански художник, какво можете да направите? Но е доста хумористично и ако някога сте го гледали онлайн или ако го гледате онлайн, ще го намерите много катастрофично.
Ето сценарий на кошмар, при който добронамереният технически човек даде на бизнесмените - много технически здрави бизнесмени - инструмент, който трябваше да улесни живота им. Но преди време имахме въпроси като кой ги архивира, кой ги следи и поддържа, къде са тези данни, в каква структура са данните, кой контролира схемите, какво, ако искам да създам друга версия, какви данни има в тези версии, мога ли да направя едно тестово пътуване за интегриране на тези неща?
Знаеш ли, можеш да си направиш собствени изводи как е минало, но не мина добре и можеш да си представиш, че само стотици терабайти данни, а не архивирани, седнали, ефективно, компютри или лаптопи на бюра, някои системи дори не са налични, тъй като хората не осъзнават, когато са изключили лаптопа в 5:30 и го заведоха вкъщи, за да вършат работа, която никой в LAN не може да стигне до това приложение. Не свърши добре. И много данни трябваше да бъдат почистени и ръчно манипулирани и върнати в разумна система; по-голямата част от него просто беше изтрита и отстранена, защото просто не можеше да се остави да се разпръсне допълнително.
Тогава вторият ми анекдот с неща на съвсем различно пътуване. Представете си сценарий, разполагате с разработчици, тестове, интеграции, системни интеграции, тестове за приемане от потребители, производство, възстановяване при бедствия, архивиране и резервно копие от едно до 99 и по-нататък, имате надстройки, кръпки и след това демонстрационни среди от от едно до 99 и повече. И изведнъж седите там и вървите: „Чакайте, какво става, задръжте, кой какво използва?“ Знаеш ли, това е кошмар, който потенциално чака да се случи.
Но при този сценарий това, което се случи, имах възможност да вляза в организация, която искаше да извлече бизнес единица за управление на богатството от основната си банкова платформа и да я отстоя като отделна организация, по същество стартиране в рамките на едно предприятие. Предизвикателството беше, да вземем нашия бизнес отдел за управление на богатството и всички хора и технологии и данни около него, да създадем стартъп в нашата собствена компания и да я извадим, за да може да работи на собствената си марка.
Това е световен лидер в банковото дело, което няма да посоча. Трябваше да извлечем самата бизнес единица за управление на богатството и всички неща около нея. И така, всичко в своята цялост, целият персонал, физическата инфраструктура и го преместете в ново офис пространство. Всички бизнес системи, целият софтуер, всички данни, цялото лицензиране, вие го наречете. Е, можете да си представите, че изглеждаше като малко кошмар, с който да започнете.
И за да кажем някакъв контекст, ние говорим за 78 системи в оригиналната банкова платформа, поддържаща около 14 основни продукта, което може да представлява около хиляда различни предложения. Използват се стотици и стотици бази данни на живо и когато казвам в употреба, трябваше да ги преместим на място, така че в петък следобед те ще бъдат в една среда, в понеделник се очаква да са някъде другаде и в събота и в неделя трябваше да имат това кръстосване, при което транзакции преминават от една система вляво, да речем, за да я визуализираме, към друга система отдясно.
Около 15 000 клиенти с безброй записи всеки и кошмар на ETL, тъй като никоя от 78 системи от едната страна не беше съпоставена със системи от другата страна. Имахме напълно нова банкова платформа, нови системи, нов софтуер, нови бази данни и нова схема. И така, метаданните, полетата, редовете, колоните, записите, таблиците, вие го наречете, нищо не съвпада. Има 14 различни екипа за активно развитие, по един за всеки продукт. И когато изградихме тази среда, установихме, че по времето, когато имахме тест за разработка, интеграция, интеграция в системи, тестване за приемане от потребители, производство, възстановяване при бедствия, демонстрационни копия, архивиране, надстройки, кръпка - дори пропуснах едно - обучение, например и образование, имаше 23 версии на всяка от тези среди за всеки екип за развитие.
Сега, сядаш там и изведнъж кръвта ти започва да се извива и кожата ти изстива, а косата ти стои - това никога не може да свърши добре. Ами се оказва, че всичко завърши много добре, защото първото нещо, което направихме, преди дори да стартираме дизайна на технологичното внедряване, беше, че отидохме и получихме правилните инструменти. И използвахме инструменти, и не непременно хора, а хора, шофиращи инструменти. Използвахме инструменти за картографиране на данните, използвахме инструменти за картографиране на базите данни, в които живееха, картографирахме всички метаданни, схемите и чак до редове, колони, записи и полета.
Разбрахме от какво идваме и след това свързахме това с картата на това, което въвеждаме, доколкото изглеждаше извънплатната банкова платформа, и имахме корелация „един към един“. И всичко, което падна по средата, създадохме стая с данни, в която щяхме да преминем и ръчно да ги картографираме. Но преди да извършим каквото и да е внедряване и настройка на тези среди в новия свят, ние се уверихме, че всеки един запис, всяка отделна таблица, всяко поле, всеки ред, всяка колона, всяка база данни и всички метаданни около него, всички разрешения и контроли бяха картографирани от едно към едно. И ние не помръднахме нито едно нещо, докато тази корелация не беше направена.
И така, ETL парчето премина от кошмар до сравнително безболезнен процес на валидиране на контролите и процесите, които се следват. И бихме могли да правим това редовно, почти на час. Правихме преход от производство на стария свят към нови среди на разработка, тест, интеграция и т.н. в новия свят. И в деня, в който отидохме на живо, след петмесечен процес, за да отидем на живо след месец с тестовете и след това след шест месеца беше онлайн и активен, имахме само един проблем, а проблемът беше, че някой забрави паролата си и трябваше да се нулира. Това беше единственият проблем и по същество създаде около час стрес на хората, които мислят, че нещо се е объркало - оказа се, че паролата изтече и те забравиха какво е и трябваше да я нулират.
Можете да си представите този сценарий, в сравнение със средата на Lotus Notes, където някой имаше големи намерения, но не мислеше през предизвикателството, и следващото нещо, което трябваше да направим и да опитаме да картографираме всички тези данни и по-голямата част от тях трябваше да бъде отписана и това беше просто голяма загуба на време и усилия, ресурси и морал. Към сценарий, при който, когато е правилно планиран и правилно направен и е изпълнен по подходящ начин с правилните инструменти, постигнахме страхотен резултат.
И така тази точка ме отвежда към този един ред - преди да се предам на нашия сътрудник, за да поговорим за това, което IDERA трябва да реши това много предизвикателство - е, че в днешния свят, където все повече системите се задвижват от бази данни, това не е просто нишесте, а за мен е факт, необходимост е, че интелигентните инструменти са, според моя опит, единственият начин за управление на откриване на данни, управление на данни в мащаба и скоростта, с която се движим.
И ако е направено правилно, като вторият анекдот, който току-що споделих с надежда, илюстриран, това може да бъде много безболезнен и много безпроблемен процес. Не само в нови проекти, но обхващайки текуща среда и гарантирайки, че по всяко време и ден можете да проследявате и проследявате какво се случва във вашата организация, каква база данни има, какви версии на базата данни използвате и кой какво използва.
За тази цел ще предам на нашия сътрудник от IDERA и с нетърпение очаквам да чуя какво могат да предложат на масата и как биха решили това много предизвикателство.
Бин Чау: Страхотно, благодаря, Дез. Можете ли да ме чуете добре? Добре, благодаря. Здравейте всички, аз съм Бин Чау с IDERA. Днес ще говоря малко за продуктите, които сме нарекли SQL Inventory Manager и говори за откриването и възможността да инвентаризирате вашите екземпляри и бази данни на SQL Server там и да се справите с това, което имате в околната среда и говори за някои други неща, за които Dez и Робин говориха по отношение на разпространението на базата данни и нуждата от данни в наши дни.
С това, ето някои съображения, които сте чували, мисля, анекдотично през двете приказки, които Дез описваше. Но всъщност днес има толкова много нужда от данни и бизнес групи, както и бизнес групи там, които въртят своите собствени приложения и сървъри, особено със SQL Server, нали? Тъй като можете лесно да въртите SQL Express версия или BI услуги, че в много организации се случва просто разширяване на SQL, от малки до големи.
Много пъти DBA не са наясно, че някой е решил да стартира, знаете, да създаде инстанция, а не просто да поставя база данни на съществуващ екземпляр. Те не са наясно с тези неща, докато потенциално не възникне проблем и някой да се обади на DBA: „О, не, моето приложение спря да работи, не е в състояние да се свърже с база данни, какво става?“ И знаете ли, когато DBA пита някои въпроси, които откриват: „Хей, този не беше на нашия радар, не го бяхме наясно.“
Друг е лицензионните разходи, нали? Лиценз за Microsoft SQL Server: по начина, по който работи, не се изисква да имате конкретен ключ за този брой случаи, които имате. Можете да внедрите и след това да направят одит. Знаеш ли, те правят одит по-късно и вид откриват колко лицензи всъщност се нуждаят. И така, ако правят одит и не сте запознати с непознатите сървъри, това може да доведе до скъп одит. И така, доброто нещо е да разполагате с инструмента или да имате инвентар преди време, за да знаете колко струва вашето лицензиране и да можете не само да знаете, но и да го управлявате.
И тогава това, за което току-що говорих, ако не сте наясно със сървър много пъти, ако нещата вървят добре, всичко е наред, но единственият път, когато сте наясно с нещо, е когато има проблем. И така, че това може да доведе до прекъсвания на производството или може би сървърът не се поддържа и не получи патч на този сървър и това създава проблем.
Някои от въпросите, с които DBA трябва да се занимава всеки ден е, че те се сблъскват, знаете, те биха могли да бъдат административни или стратегически, но някои неща като Microsoft току-що пуснаха критичен кръпка на системата, колко системи там ще се нуждаят от тази нова кръпка? Кой ще бъде повлиян от време на престой, ако трябва да сваля системата, за да я кръпка? Как мога лесно да стигна до тази информация? Трябва ли да влизам в електронна таблица? Трябва ли да влизам в множество системи, за да открия това? Трябва ли да се свържа с различните бизнес групи, за да получа този списък? Наистина е трудно да го разделиш.
Друг добър е в общи линии, някой идва заедно и казва, имам нужда от нова база данни. Това ще изисква размер X и трябва да има толкова голям капацитет и тогава те искат да знаят, къде мога да го поставя. Без да знаете какво има във вашия пейзаж, е трудно да им кажете, добре, можем да го поставим тук, тук или тук. Трябва да отидете и да направите своите ръчни проверки, които са необходими, за да го направите. И ние говорихме за одита, а също и за нелоялния сървър.
Ако имате измамен сървър там, не знаете в какво състояние се намира, дали е архивирано, дали има всички свои лепенки. Понякога може да не осъзнаете тези неща, докато не възникне проблем, което би било лошо.
Това са вид на всички предизвикателства, въпроси, с DBA всеки ден в ден, какво ги хвърля. И така, исках да ви представя SQL Inventory Manager, който е продукт, който имаме там. Прави няколко неща. Той прави откритие, което по същество е вид излизане във вашата среда, за да видите какви SQL Server са там във вашата среда. И тогава може също така да открие автоматично, така че по принцип, след като стартирате откритие, можете да го настроите да излиза навън всеки ден или седмично - каквото и да е време, за да откриете нови случаи там.
След това можете да го накарате автоматично да регистрира тези случаи, за да можете да започнете да ги наблюдавате и да проверите тяхното състояние и след това можете да започнете да каталогизирате и инвентаризирате тези случаи, така че да имате добър поглед върху вашия пейзаж на SQL Server. Какво има там, какво е производството, какво е развитието, какво е възстановяване след бедствия, кое е по-малко критично и знаете, какви приложения работят върху тях. Можете също така да получавате сигнали за това кога нещата, когато проверката на здравето се проваля, така че по принцип, ако сървърът изпадне или както и за редица допълнителни неща, можете да се самоинструментирате.
Ерик Кавана: Ставаш малко мек, само за да знаеш.
Бин Чау: Съжалявам, по-добре ли е това? Това, което искам да направя, е да ви преведа през демонстрация, да ви покажа какво прави. Изчакайте секунда, нека първо да споделя екрана си. Вие виждате ли уеб интерфейса? Това е интерфейсът на SQL Inventory Manager. Екранът, който ви показвам тук, това е уеб базиран интерфейс. Екранът, който ви показвам тук, е нашият изглед на данни за база данни. Отгоре виждате, че сме различни. Така че „откритият“ е основно всички случаи, които са открити в мрежата. И това, което ще ми покаже, е основно.
Ерик Кавана: Започваш да се разпадаш само малко. Може да искате да сложите телефона и да го поставите на високоговорителя. Продължавай.
Binh Chau: Този екран на Discovery ще ви покаже всичко, което Мениджърът на инвентаризацията е открил във вашата мрежа. Тук е открито като 1 003 сървъра. И ще ви каже версията, изданието, ако може да го намери, кога е открито и как е открито. Да речем например, аз избирам да игнорирам някои от тях, което означава, че знаете, може би искам да игнорирам изданието за програмисти, защото те не са толкова важни за мен, защото те са просто издание за програмисти; Мога да избера да игнорирам тези и ще ги поставя в раздела Игнориране, така че следващия път, когато пусна Discovery, няма да ми го показва отново. Сега мога да попълня да направя автоматична регистрация или мога да се регистрирам ръчно.
И така тук съм избрал да наблюдавам шест инстанции. И тук е влязъл в системата и ще извършва периодични проверки на тези, а след това има множество проверки, всичко тук от, знаете, той проверява на всеки 30 секунди, за да види дали сървърът е нагоре или надолу и ви дава вид преглед на какво е това състояние. По принцип тук ми казва, че имам един сървър, който е долу и тези пет, които са нагоре. Също така ми казва какви издания на сървъра, броя на базите данни, състоянието на базите данни, всяка допълнителна инвентаризация или метаданни около този сървър. Мога да стигна и до изгледа Licensing от тук. Тук ми дава част от информацията за лицензиране на Microsoft, която ми е необходима, ако исках да изпреварвам получаването на обща или обобщена информация преди одита на Microsoft.
Ето броя на ядрата, броя на гнездата, възможният ядрен лиценз, който беше нещо, което Microsoft въведе от 2012 г. Това беше нашето мнение. Нашата страница с обзор, това е вид на страницата, която ще отворите. Това ще ви покаже здравните проверки или препоръките, които има, като в момента ми казва, че имам девет бази данни, които нямат текущо архивиране. Мога да щракна там, за да сляза до подробностите за кои са тези бази данни и мога да вляза и да предприема действия по тях, ако се наложи. Той ми казва всички основни бази данни по размер, топ бази данни по активност. Мога да кликнете върху конкретния сървър и да получа повече подробности за него.
Ерик Кавана: Докато това се търкаля, това, което ни показвате тук, е способността да виждате наистина всичко, което е свързано с мрежата, нали така?
Бин Чау: Точно така. Това показва всичко, което съм избрал да наблюдавам, използвайки Inventory Manager. Това е SQL Server, той ми показва тук всички приложения, които са свързани със сървъра. Отново мога да вляза във всички бази данни, които са свързани на този сървър. Тук можех да маркирам нещата. Мога да създам маркер за този конкретен сървър, независимо дали е точен домейн или не. Имаме клиенти, които го използват, като те искат да маркират производствените си сървъри или дълговите си сървъри и тогава могат да получат пълен отчет за нещата. Когато преминавам към раздела Администрация, така мога да стартирам Discovery. И Discovery основно ще излезе и да се натъкне на вашата мрежа и да намери всички SQL Server във вашата среда.
Ето, имам този точен домейн, който е наш домейн и го настроих да казвам, знаете, че в този конкретен домейн използвайте този конкретен потребителски акаунт на Windows, за да направите откриване и искам да направите пълно сканиране. Мога също да избера, за да посоча „Само сканирайте този конкретен поддомейн“ или „Само сканирайте родителя.“ Но в този случай тук казах да извършите пълното сканиране. Ето различните видове сканиране, които мога да използвам и ако го запазя, и в общи линии това е работа, която мога да настроя. В момента е изключен, което означава, че трябва да ръчно провеждам тези сканирания. Но ако исках, бих могъл да го определям ежедневно, знаете ли, да работя ежедневно. Или ако реша да не го изпълнявам ежедневно - прекалено много - мога да кажа да изпълнявам работата седмично на определена дата и час.
И тогава Автоматична регистрация тук, ако това е включено, това, което би направило е, че всеки път, когато намери нов сървър, автоматично ще го регистрира в Inventory Manager, така че да мога да го наблюдавам. Ако има някакво издание, което искам да изключа, като например, не ми пука за Express или издание за разработчици, тъй като те са среда за разработка, тогава просто щракнете върху тези тук и какво ще направи е просто казва всеки След като намеря нещо ново, просто ще го добавя към Inventory Manager, за да можете да го наблюдавате, стига да не е издание за разработчици или експреси.
И ето къде мога да задавам таговете, така че например, ако имам производствени сървъри, бих могъл да отида тук и да маркирам тези сървъри. Бих могъл да маркирам база данни или сървър със специфичен син маркер, така че например мога да кажа, че този AO_NODE трябва да има продуктов маркер. И по този начин, ако се наложи лесно да стигна до сървъра, мога да изляза тук и да кликна върху продуктовия маркер и той ще ме отведе веднага до тези два сървъра. Това е изгледът ни на Explorer и това се показва от Собственика, но бих могъл да кажа и чрез маркер Instance, също и по бази данни и мога да разширя това, за да видя какви са те.
Друга полезна функция, която изградихме, че хората наистина харесват тук, е възможността да гледат какво управлявате чрез Inventory Manager и да виждате на какво ниво на кръпка се намират. По принцип тук ми казва, че шестте сървъра, които съм управлявал в моите инструменти, независимо дали има налична актуализация за Microsoft и дали версията, на която съм включена, независимо дали се поддържа или не, и поддръжката статус. Ако исках да разбера повече за тази конкретна корекция, мога да щракна върху нея и тя ще ме свърже със статията от Microsoft по отношение на това, за което става въпрос и дали да ги адресирам. Можете да експортирате този списък, ако искате, така че можете да кажете: „Ей, трябва да свързвам може би три от тези сървъри този уикенд, а останалите три на по-късна дата.“
Списък за съставяне - така че има списък, който проверява, за да види, че вашата версия е актуална. Можете да излезете и да изтеглите този списък, за да сте сигурни, че е актуален и имате най-новия списък, с който да го сравните. Друга отлична характеристика на инвентара, която хората харесват, е възможността да добавят не само тагове, но и възможността да добавят персонализирани полета за инвентара. Знаете, ако искате да добавите поле тук, за да маркирате база данни например, да речем, че искам да го маркирам на ниво база данни. Отдел, този отдел и тази база данни, бих могъл да го направя от различен тип: отворен край, вярно / невярно или списък за избор.
И бих могъл да кажа, знаете, това е HR, маркетинг, научноизследователска и развойна дейност, финанси. И това, което прави тук, е основно, след като можете да маркирате тези неща, можете да извадите някои данни оттук, които казват колко капацитет използва всяка база данни и след това можете да започнете да родите, нараства ли и има ли смисъл да да заредите тези отдели?
Друго нещо е, ако знаете, ако трябва да стартирате поддръжка, като знаете кой е в тази база данни, можете да знаете с кого да се свържете, за да ги уведомите: „Ей, трябва да стартирам поддръжка този уикенд, вашите бази данни ще бъдат офлайн“, и така нататък. Друга полезна функция е полето за търсене тук, което хората харесват. Много пъти DBA се питат за база данни или приложение или сървър, в зависимост от това кой говори с тях, е трудно да се разбере къде точно се намира. Това, което бихте могли да направите тук, е, че може да не знаете къде живее базата данни, но бихте могли просто да го въведете. Бих могъл просто да напиша таблото за управление на IDERA и то ще изтегли няколко бази данни и къде те седят, за да можете лесно да получите за тези. И след това тя изтегля допълнителна информация за тях: техния размер, размер на дневника, дали някога е имал резервно копие, в какъв режим на възстановяване е, ако искам да добавя някакви маркери за него. В този инструмент има много различни функции, знаете, това е инструмент за инвентаризация, но това е инструмент за инвентаризация, който е много специфичен за SQL Server и за DBA.
Тъй като, предполагам, има допълнителни неща, които DBA биха искали да имат достъп или вид, за да получат добър поглед върху това как изглеждат средата и пейзажът им в техните бази данни. Можете също така да се абонирате, да конфигурирате SMTP сървъра и да настроите абонамент, за да предупредите за себе си или за всички потребители тук. Ще спра с това и ще се върна към презентацията. И последният слайд тук е просто оглед на архитектурата. Това е уеб конзола, която работи на вградени Tomcat Web Services.
Имаме някои услуги за събиране и услуги за управление, които поставяме в хранилище, а услугите за управление излизат и изпълняват Discovery във вашите различни екземпляри на SQL Server. На сървърите на монитора ви нищо не е инсталирано. Имаме задания, които се изпълняват периодично, които просто събират данни за него, така че основно дали е нагоре или надолу, колко данни се използват, какви са другите версии на хората. Е, това е всичко.
Ерик Кавана: Да, нека да ви попитам - ще задам няколко въпроса и тогава съм сигурен, че Робин и Дез имат и такива - просто от любопитство, когато някой влезе да направи одит, да кажем Microsoft, са те използват този инструмент или предполагам, че имат някои собствени инструменти, които използват?
Бин Чау: Да, вярвам, че използват собствени инструменти. Работата е там, че този инструмент е инструмент за инвентаризация, така че той е актуален по отношение на, знаете, защото той има задачата да излиза и непрекъснато да събира информация за вашите сървъри, ще изтича там и по всяко време ще разполагате с актуална информация, всъщност за това как се променят нещата, както знаете, еднократни отчети, които може да получите от Microsoft, за да кажете, че това е броя на сървърите, които имате, това са версиите, които имате,
Ерик Кавана: Да, любопитен съм за Откритие. И така, когато някой купи този инструмент и започне да го използва, как всъщност се случва откриването? Това беше нещо, за което споменах по-рано, с други думи, докосвате ли мрежата, за да видите кои сигнали летят там, които изглеждат като екземпляри от база данни, и след това ги каталогизирате и след като маркирате екземпляр от база данни, който следиш ли? Предполагам, че има нещо като ping, което прави всеки толкова често и ако пада, например, така знаете, че е надолу. Така ли работи нещата?
Бин Чау: Да. Искам да кажа, че след като включите Discovery, той излиза в мрежата ви и имаме няколко различни сканирания, за да излезем там, но това, знаете ли, е сканиране на браузъра и сканиране в регистъра. Прави различни сканирания, за да види какъв компютър е там и след това прави проверка: имате ли SQL сървъри там или BI услуги там? И след това го връща обратно и го дърпа в инструмента и ви го показва: „Ей, ето всички неща, които открих.“
И тогава, ако бихте казали: „Искам да наблюдавам с помощта на този инструмент“, ще продължи да се проследява това и ще го пинг. Той има задачи да го пингва толкова често, за да каже: „Добре, проверете сега за това нещо“ - знаете ли, наличността на базата данни - проверете сега за историята на базата данни, проверете от страната на базата данни. Той изпълнява серия задачи, за да провери базата данни, която наблюдавате.
Ерик Кавана: Да, това е добре. И имаме въпрос от член на публиката. Знам, че вие разполагате с инструменти, които работят с различни технологии на базата данни, но този, по-специално, който показвате днес, това е само за SQL Server или покрива ли и други типове бази данни?
Бин Чау: В момента този конкретен инструмент обхваща SQL Server.
Ерик Кавана: Добре, това е добре. Е, нека го предам на Робин, сигурен съм, че има няколко въпроса, а след това може би се върна при Дез. Робин?
Д-р Робин Блур: Да, разбира се. Microsoft сравнително наскоро - някъде през 2006 г. - обяви SQL Server на Linux, но не мисля, че все още го е доставил. Просто се зачудих дали имате някакви коментари по този въпрос. Наясно ли сте с това? Играете ли с това?
Бин Чау: Да, ние сме. Ние планираме да включим това. Искам да кажа, хубавото на този инструмент е, че говорих с много клиенти, които са изградили свои собствени инструменти за дома, за да направят същото, но те трябва да са в крак с новите издания и версии, които Microsoft излиза с, но ние имаме нови версии и издания, влизаме в него рано, за да сме сигурни, че инструментът ще може да наблюдава и управлява новите издания. Така че, SQL в Linux е нещо, което планираме да добавим и предоставим, когато е налице - вярвам по-късно тази година.
Д-р Робин Блур: Да, това е интересно. Очаквате ли много от вашите клиенти действително да направят това? Искам да кажа, че SQL Server е много сложна база данни, в моя опит. Искам да кажа, знаете ли, че е дълго в зъба, вероятно е нещо, което трябва да се каже. Искам да кажа, знаете, оригиналната Sybase, от която произхождаше, всъщност беше доста опростена в много неща, които правеше. Но Microsoft добавя все повече и повече неща през годините. Всичко това ще бъде налично в Linux? Искам да кажа, ще съветвате ли клиентите си дали да правят тази миграция?
Бин Чау: Съжалявам, виждаме ли въпроса виждаме ли хората да искат това?
Д-р Робин Блур: Е, имайки предвид, че сте се забъркали с него, толкова ли е сложен в Linux, колкото и в Windows?
Бин Чау: Самият аз не съм играл с него, но това, което чух от колега, е, че всъщност е много наравно. Но аз лично не съм играл с новата версия на SQL на Linux.
Д-р Робин Блур: Добре. Прав ли съм да мисля, че просто сте поставили агенти на всеки SQL Server, който намерите? Така работи този инструмент?
Бин Чау: Не, ние всъщност не поставяме агенти. За този конкретен инструмент, частта с инвентара, ние всъщност не поставяме агенти там. Ние просто излезем и направим обаждане и проверим състояния по него. Едно хубаво нещо за този инструмент е, че той е без агент.
Д-р Робин Блур: Имате ли други инструменти на SQL Server, можете ли да ми напомните какви други продукти имате в този пакет, които се занимават със SQL Server?
Бин Чау: Да. Имаме SQL Diagnostic Manager. Това е инструмент за наблюдение и изпълнение. Той прави по-задълбочен анализ или диагностика и проверки на ефективността и здравето за вас от Мениджъра на инвентаризацията. Леката версия на тази проверка на здравето на Inventory Manager. Ние също имаме Compliance Manager и Secure, което е част от нашия пакет за сигурност. Основно ще ви каже кой има достъп до вашите данни, до какви данни имат достъп, защо и ще ви помогне при спазването и други указания за отчитане. Имаме SQL Safe, който е нашият инструмент за архивиране - той прави архивиране и възстановяване и това е хубаво.
Имаме и нашия Enterprise Job Manager, който просто следи работата ви. И тогава имаме инструмента Toolbox, които са набори от инструменти на администратора, както и набори от инструменти за сравнение, както и SQL Doctor. Набор от инструменти за администратори и набор от инструменти за сравнение, те са това, за което се сещам като швейцарски армейски нож. Те имат множество инструменти, за да помогнат на DBA да прави различни неща като, знаете, да проверява кръпки или да премества или клонира база данни. Но има 24 такива инструмента в тази кутия с инструменти.
Д-р Робин Блур: Значи хората, които се занимават с управление на запасите, обикновено ли са вече потребители на вашите други инструменти? Или този вид входна точка? Мога да си представя - искам да кажа, че можете да ми кажете дали имате някакви истории от войната - но мога да си представя, ако никога не сте управлявали инвентар в доста голям център за данни, опитът може да е доста отрезвяващ. Това ли намирате?
Бин Чау: Да. Искам да кажа, че имаме клиенти, които са запознати с инструмента от други набори от инструменти, но имаме клиенти, които идват да търсят подобен инструмент поради проекти, които имат. Един пример за това е, че има компания, която се е сляла с друга компания и е купила серия от компании и е необходимо да консолидира отпечатъка си на SQL Server, за да намали разходите си. И така те търсеха инструмент, за да излязат и да открият всичко, което имат, за да могат да започнат процеса как да консолидираме това.
Д-р Робин Блур: Точно така, разбирам. Предполагам, че това е доста често при сливанията, когато се замислите. Добре, ще предам на Дез, не искам да вземам цялото време. Вижте какви въпроси имаме от Австралия.
Дез Бланчфийлд: Благодаря, да, въпросите винаги са наопаки. Едно от нещата, което идва на ум, и разбирам това доста, знаете, компаниите не са съвсем сигурни къде да начертаят чертата кога да започнат да инвестират. Кога една организация - според вашия опит, като се има предвид, че сте в студена фаза - кога е подходящият момент да започнете да инвестирате в инструменти като този, за да гарантирате, че няма да изпаднете в неприятности? Правите ли го от първия ден, когато започнете да изграждате инфраструктурата на вашата база данни на новата организация или, както току-що очертахте, когато извършвате придобиване / сливане?
Или има определен мащаб, на който наистина трябва да бъдете? Имате ли нужда от 10 или 100 или 1000 бази данни? Какъв е вашият опит, що се отнася до пазара, с който се занимавате толкова дълго време, кога е подходящият момент да влезете в това пространство и вероятно, откъде да започнете? Как изглежда, когато започнете?
Бин Чау: Искам да кажа, мисля, че ако е много малка организация, може да нямате нужда от този инструмент, например, с една DBA или с няколко DBA. Когато започнете да получавате група от, не знам, три или четири DBA и може би от 50 до 100 сървъра, може да искате да започнете да правите нещо подобно. Предполагам, че когато вашата организация се разраства по-големи и просто бизнес хора, които са умели да искат, знаете, като този пример, който дадохте, те искат да инсталират приложенията и базите данни самостоятелно, но това е когато искате да имате този вид инструмент, защото по този начин можете да видите какво има там.
Но дори и в по-малка организация е хубаво да имате този тип инструмент, за да следите какво имате. Ако го разделите така, че да можете да кажете: „О, да, купих SQL 2012 за тази кутия, но в момента работи SQL 2008, защото имам приложение, което все още се нуждае от наследената версия.“ Помага да се използва този инструмент за инвентаризация просто за да се измъкнеш от управлението на множество електронни таблици, които могат да станат неясни.
Дез Бланчфийлд: Другият въпрос, който току-що следвах по въпроса: какви видове умения или ресурси трябва да планират организациите, когато стигнат до този мащаб? Случва ли се, че има определен набор от умения, от които наистина се нуждаете, или тип опит или произход или типът човек, който е най-подходящ за този вид предизвикателство? Или това е нещо, на което средният DBA или системният администратор или набор от умения за администратор на мрежа може да хвърли това? Наистина ли се нуждаете от остър островършен мозък или можете да вземете това доста бързо?
Бин Чау: Съжалявам, значи говорихте за набора от умения на човека?
Дез Бланчфийлд: Да, така че когато мислите за администратор на база данни, има определен набор от умения, които биха ви били необходими. Така че, когато излизате да наемате DBA, сами по себе си, за тази конкретна роля, когато мислите за типовете предизвикателства, за които говорихте тук, където използвате подобен инструмент, за да поддържате върха на картографирането и проследяването на бази данни, правейки откриващото парче и задействайки този конкретен инструмент, има ли нещо уникално в използването на инструмента и подхода към този тип предизвикателства или това е нещо, което средният DBA може да вземе доста бързо?
Бин Чау: Искам да кажа, мисля, че средният ви DBA може да вземе това бързо. Мисля, че е полезно да имате този тип инструмент, защото можете също така да го обърнете, защото е базиран на уеб. Можете да го дадете на други потребители в рамките на вашата организация. Можете да го дадете на програмист на приложения, който може да провери неговата конкретна база данни или сървър. Отнема някои от административните неща, които трябва да свърши DBA. Преди някой да се обади на DBA и да каже: „О, защо сървърът ми е нагоре или надолу?“ Сега те могат да получат достъп и да видят дали сървърите им са нагоре или надолу.
Dez Blanchfield: И каква среда би била необходима на средната организация, за да разгърне това? Има ли нужда от специализиран физически сървър или може да се направи на виртуална машина? Могат ли да го разгърнат в облачната среда? Какъв е общият отпечатък за разполагането на инструмента и само общото изпълнение на него? Колко тежко желязо е необходимо да работи паралелно с другите среди, които картографира?
Бин Чау: Да, може да се стартира на виртуална машина или компютър или сървър. Не е задължително да е специализиран сървър, а просто зависи от това колко сървъри наблюдавате. Ако имате по-голяма среда, може да помогнете да имате по-голям сървър, защото той събира много данни за SQL сървъра, който наблюдавате.
Дез Бланчфийлд: Точно така. Това е нещо, което бихте могли удобно да стартирате в облачния екземпляр и да създадете VPN обратно към вашата среда, или обемът на данните, който събира, вероятно е малко тежък за този тип употреба?
Бин Чау: Все още не сме го настроили да го пускаме към облака, за да го изпълним още в облака. Вероятно трябва да се изпълнява на prem.
Дез Бланчфийлд: И последен въпрос, ако мога: много от инструментите, които съм виждал в това пространство, особено когато го споменахте за един сценарий, когато някой е придобил компания или е имало сливане или нещо в този смисъл, или дори ако това е организация, която просто обединява бизнес единици, дали разумният сценарий за използване е, когато някой го разгръща на лаптоп и го отвежда в среда, за да картографира света като еднократно, или това е малко вероятно използван сценарий? По-скоро ли е случаят, че ще бъде там и просто завинаги оставен да работи?
Binh Chau: Този специфичен инструмент е по-скоро един вид, инсталиран на сървър и той се оставя да работи. По този начин можете да събирате информацията, от която се нуждаете, и да поддържате, предполагам, текущ опис на това, което имате. Това е за разлика от инструмента Map, тъй като инструментът Map е вид индивидуален, прескочете до порта, който ви трябва, направете това, което трябва да направите с него днес. Това е вид - приятната част за него е фактът, че можете да го маркирате, да дадете на хората достъп до него, за да проверят състоянието на техния конкретен сървър, тези, от които се интересуват.
Дез Бланчфийлд: Добре. Вероятно последният въпрос за мен и тогава ще се върна на Ерик за въпроси, които идват през прозореца на въпроси и отговори с присъстващите, тъй като днес имахме добра избирателна активност, един от любимите ми. Просто, за да приключите с това, какъв е процесът, за да получите ръцете си за това? Знам, че много ваши инструменти са достъпни за неща, които се опитват преди да купите. Къде трябва да отидат хората, за да научат повече за това онлайн, къде се намират на уебсайта, трябва ли да търсят изтеглянията и как изглежда пътуването, да направят доказателство за концепция или проба и да се запознаят с нея и да се запознаят с нея да се свържете и да го купите?
Бин Чау: Да. Можете да отидете на уебсайта на IDERA.com и можете да изтеглите двуседмична пробна версия безплатно. И ако ви харесва и искате да се свържете с нас, можем също така да насрочим демонстрация с един от нашите инженери, за да направим по-дълбоко гмуркане на инструмента.
Дез Бланчфийлд: Фантастичен. Е, много ви благодаря за това. Оценявам времето, за да поговоря с вас за това и въз основа на моя личен опит и съм сигурен, че говоря за Робин по този въпрос върху неговия опит през целия живот, мисля, че е дадено нещо, като нещо подобно в днешно време е изискване. Сега не можем да направим това ръчно, колкото и да се стараем; мащабът е просто твърде голям и нещата се движат твърде бързо.
Горещо препоръчвам на хората да направят точно това, да скочат на уебсайта на IDERA и да получат копие, с което да играят. Тъй като потенциалният риск за моя собствен опит с анекдотите, които споделих точно днес, може ли да премине от много лошо до много добро, ако имате правилните инструменти, но може да тръгне и по другия път, ако не го направите ' T. Ерик, обратно към теб.
Ерик Кавана: Да, просто поп за един последен въпрос към теб, интересен. Просто ми е любопитно да разбера какво виждате там, знаете ли, че облакът очевидно е все по-важен в наши дни - Amazon Web Services, но те не са единствените, Microsoft има цялото си предлагане Azure което изглежда набира пара. Любопитно ми е да знам, че един от присъстващите пише, че д-р Блуър направи интересен въпрос, че DBAs са скъпи и че проблемът с управлението, причинен или от измамник DBA, или от някой, който не прави това, което трябва да прави, може ли това да се реши чрез мигриране към облака. Просто ми е любопитно да знам, колко активност виждате? Виждате ли, че миграцията към облака се превръща в по-голям проблем за бизнеса или какво мислите за това като тенденция?
Бин Чау: Чувствам, че просто зависи от това в какъв проблем сте. Имам чувството, че някои индустрии казват: „Не, не мигрираме.“ Те може да не мигрират към обществен облак; може да гледат как да мигрират или мигрират своите неща в частен облак. Но след това виждам някои организации, които се интересуват, знаете ли, наистина се впускат по бързия път и вид на отиване към Amazon или Microsoft Azure. И тогава има някои хора, които казват: „Не, не мигрираме нашите данни“ или „Има само определени данни, които бихме мигрирали, но не и нашите критични.“ Мисля, че има три лагера.
Ерик Кавана: Да, това би имало смисъл. Искам да кажа, виждаме го все повече и мисля, че ще се движи в пристъпи и ще започне от доста време. И има обратна реакция към облака също. Хората се качват в услугите на Amazon Web Services - чухме това повече от няколко пъти - и в началото разходите са управляеми, а след това с течение на времето той просто се увеличава и след това сте някак си заседнали там. В много отношения облакът е просто друг център за данни, но най-малкото ще бъде интересно пътуване.
Е, хората архивират всички тези излъчвания в мрежата. Хоп онлайн на techopedia.com, за да разгледате пълен списък на всички неща, които правим. И разбира се, insideanalysis.com за най-новите. И с това ще се сбогуваме. И още веднъж ви благодаря за отделеното време и внимание. Благодарим за всички наши приятели в IDERA и ще говорим с вас утре, надяваме се, че нашата философия на данните завърши с уебкаст. Точно така, „Философия на данните“ е утре в четири часа източно. Надявам се да те видя там. Внимавайте, хора, чао.
