Винос: Ведучий Ерік Кавана обговорює управління базами даних та виявлення екземплярів з Робіном Блором, Дез Бланчфілдом та Буллеттом Манале в останньому епізоді Hot Technologies.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре пані та панове. Ласкаво просимо ще раз. Мене звуть Ерік Кавана. Речі гарячі. Тут нагріваються речі. Я не знаю, що відбувається О, це правильно, настав час гарячих технологій. Так, мене звати ще раз Ерік Кавана. Ви можете знайти мене на @eric_kavanagh. Це шоу, яке створене для того, щоб розповісти про те, що на ринку є гарячим. Заголовок сьогодні, "Ключі від Королівства: управління SQL сервером за допомогою динамічного відкриття". Там справді ваш. Гаразд, ця картина була з декількох років тому. Я не збираюся брехати, зараз виглядаю трохи старше, але це нормально
Отже, ми говоримо про те, як технології та SQL Server є насправді, дуже, дуже, дуже гарячими. Сьогодні у нас є цілий куточок вмісту, тож я зараз віддам його. Постаньте, ось ми і підемо. Є наші спікери. І Робін Блор йде першим.
Робін Блор: Так, справді. Презентація заглибиться в управління базами даних, тому я просто подумав, що я пробежуся через управління базами даних або, знаєте, лабіринт бази даних, щоб привернути людей до духу. Я раніше був DBA, я гадаю, ви можете сказати, що я був консультантом БД приблизно 20 років тому, і те, що насправді мене дивує в базах даних, - це те, що багато чого не змінилося. Багато чого змінилося з точки зору швидкості, з точки зору обсягів даних і подібних речей, але значна частина насправді залишається дуже схожою на те, що раніше.
На мою думку, база даних - це організований розширюваний збір даних, який можна оптимізувати під конкретні навантаження та забезпечити можливості управління даними. Він з'явився насамперед тому, що якщо ви хотіли керувати даними у файлах, це була жахливо важка робота. І ідея скласти частину програмного забезпечення, яке б зробило майже все, що вам потрібно для цього, зникло майже миттєво, як тільки ми отримали випадковий доступ до мейнфреймів IBM ще в 1970-х.
Реляційна база даних була винайдена в 70-х роках і почала існувати з точки зору прототипів у 80-х і набула свого роду тягу на ринку з початку 90-х років. А реляційні бази даних все ще залишаються надзвичайно домінуючими за популярністю. Якщо ви прочитаєте пресу, то почуєте дуже багато речей про них - баз даних SQL, і останнім часом дуже багато шуму щодо баз даних графіків. І це цікаво, якщо вам подобається, але насправді все ще в останніх числах продажів, реляційні бази даних мають 95% ринку. І Microsoft SQL Server, про який ми сьогодні поговоримо детально, є другим за популярністю Oracle.
Що стосується реляційних баз даних, що робить їх незвичними щодо двигунів, якими вони є, вони можуть працювати як на OLTP, так і на запит навантаження. Ви повинні налаштувати їх по-різному, якщо ви збираєтесь це робити, але вони насправді здатні до обох типів навантаження. Один з них - це короткі випадкові транзакції, а другий - довгі запити, що охоплюють багато даних. Альтернативно, база даних NoSQL і база даних графіків - це в основному аналітика, і вони зросли досить недавно. NoSQL з'явився першим, і останнім часом граф почав отримувати трохи тяги. NoSQL можна використовувати для транзакційних дій, але графіки майже ніколи не використовуються для транзакційних дій. Причина, я натрапив на статистику, яка насправді, на мою думку, становить щонайменше десять років, яка говорить про те, що більшість компаній має принаймні три, насправді ця цифра становила 3,5 різних баз даних, якщо подивитися на їх інвентар програмного забезпечення.
Але реальність полягає в тому, що більшість компаній стандартизуються на певну базу даних. І більшість компаній стандартизували або SQL Server, і Oracle, як дві найпопулярніші для, за своїм бажанням, стандартні бази даних.І вони використовують альтернативи лише у виняткових обставинах, коли, наприклад, отримують програмний пакет, який потребує іншої бази даних, або вони збираються після деяких великих цілей на аналітику даних, які вже існували.
Ми також отримали, якщо хочете, втручання Хадоопа. 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 Starfire. І це, мабуть, одна з найбільших жерсті, яку ви можете придбати на планеті, яка живе в одній великій коробці та симетричному багатопроцесорному сервері. Це була система середнього класу в нашому світі. Він керував Unix, і він керував Oracle споконвічно, і думка полягала в тому, що "що може піти не так?" Ну, виявляється, багато.
Наприклад, у той час, і про це ми не говорили давно, нам довелося пройти дуже ручний процес, щоб виявити, що було на платформі мейнфрейму, і переконатися в цьому. Зокрема, власне середовище бази даних та логіка SQL. Тож думка полягала в тому, що це буде досить простий хід Oracle-to-Oracle, перехід від бази даних до бази даних; вся бізнес-логіка натрапила б, більшість бізнес-логіки були написані у вбудовані запити та тригери, і наскільки це складно? Але щось, що повинно було зайняти кілька місяців, закінчилося не зовсім рік. Щоб просто фізично та вручну пройти кожну частину Unix в середовищі мейнфрейму, виявити, де були всі бази даних і скільки екземплярів запущено і що працює на цих екземплярах, і це було нетривіальною вправою, і ми закінчили це робити три рази, щоб переконатися, що ми все захопили. Тому що кожен раз, коли ми думали, що ми копали так глибоко, як нам потрібно, під поверхнею виявилося, що там більше.
Іншим завданням було те, які екземпляри працюють і в якому стані? Це середовище розвитку? Це тестове середовище? Це частина інтеграційного процесу? Це інтеграція систем? Це UAT, тестування прийняття користувача? Це виробництво? Це DR середовище? Тому що найважливіше в роботі мейнфреймів - ви можете створити ці маленькі віртуальні середовища, які ми зараз усі приймаємо як належне, і переміщувати речі. І вам доведеться попрацювати, це людина, яка займається розробкою і тестуванням виробничого класу, чи займається виробництвом, чи є в цьому реальні користувачі? Пам'ятаючи, що ця річ видає водійські посвідчення та реєстрацію автомобіля в реальному часі та речі, які дійсно мають значення для життя людей.
І потрібно було довго запускати резервні копії для цієї речі, тому у нас не було вікна технічного обслуговування, щоб вивезти річ в офлайн і подивитися, що сталося. Не було такого поняття, як його перепрограмувати. У нас також було завдання не просто знайти, які екземпляри запущені та де і хто для цього, але потім нам довелося розробити, які версії запущених екземплярів. І ось я майже втратив сюжет. Коли я почав розуміти, що у нас є дві-три версії виробничого середовища, які проходять різні рівні тестування, і інструментів та систематичних підходів до цього було дуже мало. Нам буквально довелося заглибитися в код і в запущений екземпляр, а в деяких випадках ризикуємо трохи зайнятись офлайн. Ми дійшли до низу всієї цієї речі, ми склали карту, і, як я вже сказав, це був дуже ручний процес. І ми нарешті здійснили всю зміну ETL, скинувши її з одного місця і перемістивши в інше і в цілому воно спрацювало. І ми були схожі, гаразд це функціонально, ми дуже задоволені цим.
Але потім ми зіткнулися з низкою дуже серйозних міцних цегляних стін. Зокрема, ми знайшли проблеми з продуктивністю. І розумне мислення цього дня було: ну, перейшло до більшого, кращого, швидшого та складніше апаратного забезпечення, немає причин, чому він повинен працювати погано в додатку на рівні бази даних, тому давайте почнемо шукати в іншому місці. Тож ми двічі повністю перепрофілювали мережу. Кожен маршрутизатор, кожен перемикач, кожен кабель, ми в деяких випадках переходили від Ethernet до оптоволоконних пристроїв, ми модернізували програмне забезпечення, ми латали, ви отримуєте представлення. Ми, по суті, двічі відновлювали мережу, думаючи, що це проблеми. І це виглядало і здавалося, що це було. Ми пройшли різні системи безпеки, різні брандмауери. Ми зафіксували операційну систему. Ми переміщували речі з одного обчислювального леза на інше. І ми витратили значну кількість часу на розгляд інфраструктури.
І тоді ми зрозуміли, що коли ми відключили сервери і запустили на ній інші додатки, то мережа працює просто чудово. Тож ми почали роз'єднувати операційну систему. Те саме питання. Але цікаво, що мережевий рівень та рівень операційної системи, інструменти були там, насправді нам було порівняно просто порівняння та тестування та доведення, що кожна з цих частин працювала. Але навіть тоді на апаратній платформі Solaris середнього класу на апаратній платформі SPARC інструментів просто не було для того, щоб ми почали діагностувати середовище бази даних. Ви знаєте, картографуючи, чи ми перенесли всі екземпляри впоперек. І тому нам довелося насправді створити власні інструменти, записати деякі і сісти, і чи це в рамках самих інструментів бази даних на рідних мовах сценаріїв, чи це серія скриптів оболонок або, в деяких випадках, купа програм C.
Нарешті ми поглибилися в кілька дуже цікавих питань, де логіка під шаром SQL, власне самими двигунами бази даних, виявилося, що коли щось було побудовано певним чином, щоб щось, що працювало на версії Oracle, було перенесено на Solaris на SPARC Версія Oracle не одразу перенесла ту саму продуктивність. Отже, для нас це було дуже болісною подорожжю, ми просто зробили це і знайшли все, але тепер нам довелося діагностувати його на новій виробничій системі, і знову ця штука виявила міграцію, яка коштувала місяць, майже до року. І просто зводилося до того, що у нас не було інструментів. Бігаючи, виконуючи такі дії, як спроба зіставити метадані.
У якийсь момент ми майже вирішили, що нам потрібна дошка Ouija, тому що це буде простішим способом просто навмання вказувати і смикатись. Прості речі, такі як з'ясування того, хто мав доступ до старих систем і чому вони мали такий доступ. А кому потрібен був доступ до нового і підтвердження, когось підписати та підтвердити, і це зробити карту. Навіть щось таке просте, як розмір бази даних, не відповідав обом платформам. Нам довелося створити інструмент для цього і провести порівняння між величиною бази даних в тонажі, в необроблених мегабайтах або терабайтах в системі A порівняно з системою 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-учасників я говорив, коли ви запитуєте їх: "Як ви підтримуєте свої запаси?" ми говоримо з DBA, що є дійсно іронічною частиною цього, що вони зберігають це і відстежують це в статичній таблиці всіх речей. Як я вже сказав, дуже іронічно, коли ти думаєш про це хвилину. Але це було у багатьох випадках, і все ж таки це стосується багатьох організацій, як їм це вдається. Як вони це зберігають. Це головна копія електронної таблиці Excel, яка розпливається навколо, і її потрібно регулярно оновлювати.
Це те, що було викликом, і тому, зареєструвавши цей примірник і зробивши його частиною інвентарю, ви можете це зробити і забрати інформацію. Ви можете його автоматизувати, чи не стає він частиною інвентарю, версія, видання, інші речі, які ви можете зробити з ним, ви можете вручну додати, можливо, той список або таблицю Excel, які у вас є. Ви можете імпортувати це в цей інструмент, який називається SQL Inventory Manager. Якщо у вас вже є початкова точка, коли ви вважаєте, що ви впевнені, ви можете імпортувати ці екземпляри, а потім зробити цю частину свого керованого інвентарю в продукті. Як тільки ми маємо примірник і як тільки дізнаємось, що він є, то це стає, добре, ми отримаємо багато інформації, яку ми можемо використовувати, знаючи, що цей примірник є, виходячи і збираючи цю інформацію.
І багато інформації буде потрібно для більше, ніж просто ліцензійних цілей. Багато з цього можна використати для того, щоб, очевидно, просто знати, де знаходяться речі, мати можливість шукати цю інформацію після її отримання. Але ключовим матеріалом є сервер, саме обладнання. Уміння зрозуміти, що це за машина, можливо, модель чи виробник, пам'ять, обсяг пам’яті, фізична чи віртуальна машина, особливо кількість фізичних розеток або ядер і процесорів, і такі речі.
Що стосується кількості ядер, особливо для SQL Server, то, як знати, як вони роблять своє ліцензування, - це основні розрахунки тепер у нових версіях SQL, що стає дійсно важливою його частиною, і це не все, що у вас є вийти і насправді піти копати. Після виявлення екземпляра ми можемо надати цю інформацію та витягнути її, а також дозволити вам її переглянути та зрозуміти, і, очевидно, можемо нею скористатися.
Наступний рівень внизу - це той екземпляр, який, очевидно, має багато різних екземплярів SQL Server, будь то стандартний, корпоративний або навіть експрес з цього питання, або безкоштовна версія SQL Server. Бути в змозі зрозуміти також, які програми прив’язані до цього примірника, і це можна зробити автоматично. Здатність зрозуміти параметри конфігурації та подібні речі, а також іншу інформацію, яка стосується екземпляра самого SQL Server.
Потім ви переходите до фактичної бази даних і бачите параметри конфігурації, об'єм місця, пов'язаний з цими даними, де вони знаходяться, весь цей матеріал автоматично заповнюється, і це надзвичайно економить час. І ще раз, тому що вона динамічно виходить і щодня ідентифікує нові екземпляри, це живе, що ви маєте з точки зору свого інвентарю. Саме така мета продукту полягає в тому, щоб зробити його таким чином, це зробити щось, що динамічно змінюється.
Тепер, коли вся ця інформація стає нам доступною, і ми зможемо перетягнути всі ці дані, тоді справді має сенс почати створювати в деяких випадках власні метадані, пов’язані з цими екземплярами, і ці метадані можна створювати таким чином, як вирівнюється до того, як ви ведете свій бізнес.
Отже, якщо у вас є примірники, згруповані за географічним місцеположенням, або за власниками додатків, або за власниками DBA або будь-яким іншим, це може бути з точки зору того, як ви хочете згрупувати ці екземпляри, як ви логічно хочете зрозуміти ці екземпляри, то вигляд з двох областей у інструменті, які нададуть вам таку можливість.
Перший - це можливість створити тег примірника або тегу. Що по суті створює зв'язок із сервером, екземпляром або базою даних, щоб ви могли створювати перегляди та відповідати на питання, які можуть виникати щодня, що справді допомагає вам зрозуміти, що ви маєте, чим ви керуєте і як ви хочете рухатись вперед за допомогою цієї інформації.
Інша річ, яку ми маємо, - це щось, що називається полями інвентаризації або спеціальними полями інвентаризації, і вони більш специфічні для виду деталей інформації, до яких ви можете ознайомитись, наприклад, рівень бази даних, який я міг би вирішити додати розкривний список, який має всі DBA, і я можу поставити, хто відповідальний за цю базу даних, залежно від типу ситуації чи будь-якої іншої бази, яка б база даних не була у тих, хто несе відповідальність за це, зможе вибрати це, щоб я знав, що вони несуть відповідальність і дуже легко просто занурившись в інвентар.
Таким чином, ці відомості стають дуже цінними, особливо якщо у вас є велике середовище, оскільки це просто допомагає вам осмислити цю інформацію і знати, що у вас є, і як ви це робите.
Тож дозвольте мені перейти до наступного слайду тут. Що я вам показую зараз, це те, що вся ця інформація збиралася, вся ця інформація та дані, які збирали та застосовували метадані, отримують можливість потім приймати набагато простіші та швидші рішення, коли справа стосується встановлення ліцензій у Microsoft в межах корпоративного обсягу ліцензування або страхування програмного забезпечення в Microsoft.
Це робить вас дійсно легким для цього, а не для того, щоб робити, робити багато ручного збору даних, багато вручну збирати ту інформацію, яка насправді просто загалом робить її набагато кращою для процесу. Таким чином, це один із мандатів продукту, коли-небудь полегшуючи DBA приймати ці рішення навколо ліцензування.
Тепер інша річ, яку ми, розмовляючи з DBA, виявили та дізналися дуже швидко, це те, що - і такий вид повернення до того, що було обговорено раніше - у вашому оточенні SQL Server може бути 300 екземплярів, але це справді лише підмножина з тих, що реально повністю контролюються та керуються за допомогою традиційного інструменту моніторингу продуктивності.
Отже, якщо ви йдете, і ви фактично сідаєте з DBA, і ви говорите: "Подивіться, ми знаємо, що ви отримали ці 20 екземплярів або 10 екземплярів із 300, які контролюються цим інструментом, призначеним для моніторингу цього і відповідності вашим SOA та отримуйте сповіщення та всі подібні добрі речі ", що ми також виявили, що якщо ви запитали:" Тоді добре, що з цими іншими 280 екземплярами, які у вас є? Вам це байдуже? "І вони роблять, вони дбають про них, але вони просто не хочуть обов'язково робити інвестиції для моніторингу тих, хто на рівні глибини, який можна зробити з цими екземплярами порівняно з тими 10 або 20 дійсно, дуже критично екземпляри продукту.
Отже, інша частина рівняння з цим інструментом полягає в тому, що він також допомагає з точки зору можливості переконатися, що на базовому рівні ви охоплені з точки зору здоров'я, наприклад. Тепер це не розповість вам, чи є у вас тупик чи хто є жертвою тупику. Не варто дійти до цього рівня самих сесій та деталей запитів. Але в той же час це все-таки дасть вам знати, що, ей, сервери зменшуються, або гучність заповнюється, або вам потрібно робити резервні копії бази даних, яка є важливою частиною DBA.
Тож такі речі, безумовно, все ще важливі, і тому з цим інструментом ви зробили так, щоб у вас є вигадка для ваших дійсно критичних екземплярів, які мають багато, багато чого варте, якщо вони йдуть вниз вам потрібно знати це відразу. Вони можуть мати вищий рівень моніторингу та можливість робити подібні речі, тоді як завдяки цьому вони зможуть підібрати будь-які нові екземпляри, які додаються до навколишнього середовища, і переконатися, що вони враховуються, а також переконайтеся, що вони формуються базові рівні перевірок здоров’я.
Тож у двох словах, про що керують менеджерами імпорту SQL Inventory. Тепер я збираюся показати вам демонстрацію цього. Перш ніж ми це зробимо, я просто начебто покажу вам, що це слайд архітектури тут, і просто щоб це показати, екземпляри SQL, які керували, ми можемо виявити все, починаючи від SQL 2000, аж до нових версій SQL.
Тож ми можемо це зробити, не маючи необхідності розгортати агенти до самих інстанцій. Ми робимо це через службу збору, і збираємося вивести та зібрати цю інформацію та помістити її у сховище, а потім із передньої консолі веб-служби Tomcat зможете потім взаємодіяти з цими даними та переглядати її. Тож його досить прямолінійна архітектура.
Я буду йти вперед і перемикатися і насправді залучати нас до самого продукту, щоб ви могли відчути його, розуміння того, як він працює. Тож найкращий спосіб зробити це - спочатку познайомити вас із самим інтерфейсом. Це така собі інформаційна панель, на яку тут дивилися.
Я бачу, що кількість примірників зараз, що я маю під управлінням, не дуже велика. Але я також не маю цілого центру обробки даних у задній кишені. Тож я отримав близько шести екземплярів, які ми бачимо тут. Тепер, сказавши, що я хочу зробити, це пройти процес відкриття і показати, як це буде працювати.
Тепер перше, що ви зробите, це в розділі адміністрації, ви можете вказати, як ви хочете виявити ваші примірники. Ви зможете вкласти цю інформацію сюди і ще раз, що можна зробити за допомогою ряду IP-адрес. Ви можете вказувати на домен або субдомен і мати змогу лише на тих машинах, які є членами цього домену, змогли виконати ті перевірки, на які ви зможете вибрати ряд різних типів характеристик, коли SQL, що працюють, перевіряти.
Тоді як тільки ви це зробите, і ви зможете автоматизувати його щоденно, щоб збирати і збирати ці дані. Ви також зможете це зробити на спеціальній основі за потреби. Але як тільки ви починаєте це, цей процес виявлення, то ви почнете бачити, коли переходите до перегляду екземплярів тут. У вас є вкладка «Відкрити», а вкладка «Відкрити» буде показувати нам ті випадки, які були нещодавно виявлені. Тож у нашому випадку тут є номер. Що я буду йти вперед і робити - це вперед і додати той, який збирався використовувати як приклад. Так це в цьому випадку є чиказький екземпляр, правда? Я збираюся йти вперед і додати цей екземпляр до мого інвентаря.
Добре, і це збирається пройти мене через пару речей тут. Я просто збираюся йти вперед, і ви побачите, що ми можемо встановити облікові дані. Мої повноваження мають бути хорошими. Я збираюся йти вперед, і ви помітите, що я можу призначити право власності на це, якщо хочу. Я також можу вказати місцеположення. Тепер також можна додати і саме місце розташування, і це пам’ятатиме, що наступного разу, очевидно.
Ще раз я можу пов’язати теги з цим з точки зору метаданих та того, як ми хотіли б помістити ці екземпляри SQL, зокрема цей, у ті відрізки, у які ми хочемо його вкласти. Отже, у нас є кілька поточних тегів, популярних тегів , тож ми можемо переглянути купу різних тегів, які я, можливо, вже включив. Я просто збираюся вибрати деякі з них навмання, і ми можемо застосувати це.
Тож тепер, коли я продовжую і додаю це до інвентарю. Тепер, коли його було додано, ми бачимо, що він відображається під цим керованим поданням, і ви можете бачити його в списку прямо тут. Отже, ви знаєте, що це перший крок, і те, що я вам щойно показав, - це спосіб, яким ви в основному додаватимете ці випадки, коли ви проходите щодня. У деяких випадках ви можете сказати, що ви знаєте, що якщо його корпоративне видання SQL-сервера я автоматично хочу додати це до мого інвентаря? Мені не потрібно вручну йти і вирішувати це робити.
Джоселін: Я збираюся вас перервати реально швидко. Ви не бачили вашу демонстрацію.
Bullett Manale: Ти не?
Джоселін: Немає.
Bullett Manale: Ну це не добре, давайте побачимо.
Ерік Кавана: Якщо ви переходите до верхнього лівого кута, натисніть кнопку "Пуск", натисніть на це.
Bullett Manale: Ага, гаразд.
Ерік Кавана: А тепер зробіть загальний екран.
Bullett Manale: Вибач за те. Так.
Ерік Кавана: Це нормально. Гарний вилов там, продюсер Джоселін.
Bullett Manale: Добре так, що краще? Ви бачите це зараз?
Робін Блор: Так, справді.
Bullett Manale: Добре, тож давайте начебто просто провести вас там, де ми були реально швидко. У нас були виявлені випадки, які у нас були раніше. Я щойно додав екземпляр Чикаго, і тому, що ви бачите зараз, це його тепер перелічено тут. Зауважте, це вже потягло багато додаткової інформації. Якщо натиснути на сам екземпляр, ви почнете бачити всі види інформації, яку ми вже зібрали про цей екземпляр. Тепер ось список усіх баз даних, які там є. Ми можемо побачити розподіл баз даних за розміром та за активністю, з точки зору того, які з них мають найбільший розмір та активність.
Ще раз, ми також можемо вам сказати, що ми бачимо, які програми ми бачимо запущеними в цьому екземплярі, виходячи з завантаженості, яку ми бачимо, що працює на екземплярі. Так що приємно мати можливість робити це автоматично. Мені не потрібно заходити і прив'язувати заявку до випадковості. На основі побаченого ми можемо це заповнити. Тепер, якщо ви хочете вручну додати програму, ви абсолютно можете це зробити. Але це просто приємний спосіб виявити асоціацію примірника до бази даних або, вибачте, із додатком.
Ви також помітите, що в правій частині екрана миттєвий підсумок, а внизу - підсумок сервера. Отже, тут говорили про ключові фрагменти інформації, знаючи версію, а не просто, знаєте, SQL Server 2012, але фактичний номер версії, який, у тому числі і повідомляє нам, які виправлення пов'язані з ним, які пакети послуг прив'язані для цього це може бути дуже важливо знати. Очевидно, що вимога пам'яті важлива. Все подібне, будь то кластеризована, вся ця інформація, я не мушу вносити її - її вже збирають і збирають, і як тільки ми виявимо, що її виявлений екземпляр, це буде частиною нашого інвентаря.
Інше, що ви побачите тут - і це вам покаже - його під цим поданням екземпляра. У нас є ці атрибути, про які я говорив раніше, спеціальні атрибути, які можна додати. Таким чином, ми можемо додати відкриті види полів, ми можемо зробити так / ні з точки зору, ви знаєте, мільярдів видів. Ми навіть можемо робити спадні списки. Це можна зробити в екземплярі бази даних або на рівні сервера.
Потім, якщо прокрутити трохи далі, ми зможемо побачити всю пов'язану інформацію з самим сервером. Тож ви знаєте, що всі подібні речі, очевидно, справді, дуже корисні, тому що його всі зібрані та зібрані та його там для нас, як тільки ми приймемо це рішення, щоб зробити його частиною нашого інвентарю. Тут ми можемо показати деякі відмінності щодо процесора, кількості логічних та фізичних, скільки пам'яті. Тож ти справді отримуєш дійсно добру та багату інформацію, не потребуючи багато роботи.
Тепер інша частина цього, як я вже казав, збирає ці дані на рівні сервера. Якщо ми навіть перейдемо до бази даних, ми можемо побачити, що багато цього матеріалу розбито і на нас.Тож якщо я перейду до свого сховища відповідності, то в цьому випадку я можу сказати: добре ви знаєте, що це стосується системи, це база даних відповідності, у якій рівень відповідності чи вимоги регулятора пов'язаний, і це може бути, скажімо, Відповідність SOX або PCI. Тож я можу вибрати, які бази даних мають відповідність їм, що мені доведеться заповнити, або переконатись, що я підтримую з точки зору цієї нормативної вимоги.
Таким чином, цей матеріал виявився дуже корисним для DBA, тому що там є місце, куди вони можуть зайти центрально, щоб легко зберегти всі ці пов'язані метадані у своєму оточенні, і вони можуть зробити так, як я вже сказав, відповідно до їхнього бізнесу, як це роблять. , як спосіб ведення бізнесу. Отже, якщо ми подивимось на всі речі поки що, що ми побачили, у вас, очевидно, є досить хороший огляд екземпляра, якщо я розглядаю його.
Я також можу здійснювати пошук, тому я сказав, що давайте шукатимемо сховище відповідності в моєму інвентарі. Тоді, що ви побачите тут, це те, що я можу шукати ці речі і вміти їх ідентифікувати. Я говорю це: Я не впевнений, що, мої кнопки переходу там не працюють. Добре. Подивимось, давайте спробуємо це ще раз. Там ми йдемо. Тож ми змогли б побачити розбиття того, де ми бачимо що-небудь з дотриманням, і я можу детально зрозуміти це і побачити це також з цієї точки зору. Таким чином, у вас є дійсно швидкий і простий спосіб вникнути ці дані.
Як ми вже згадували раніше, у вас є маса різних способів створення метаданих проти сервера та бази даних екземплярів. Інша частина до цього - це можливість скористатися цим способом, згрупувавши його та пов'язаний з ним спосіб. Ми переходимо до виду дослідника, ми можемо зробити саме це. Можна сказати, що я хочу зробити кількість баз даних за локаціями. Отже, кількість баз даних у кожному розташуванні середовищ, які я підтримую. Або, можливо, це базується на власнику, який володіє екземплярами, які я маю там, з точки зору, можливо, кількості примірників. Тож ми зможемо це побачити. Таким чином, ви отримаєте дійсно хороший і простий спосіб нафарбувати ці картинки для вас, грунтуючись на будь-якому питанні, на яке ви намагаєтесь відповісти в той час.
Тоді те, що ви маєте, щоб ця інформація створювалась так, як ви хотіли, ми можемо експортувати її у PDF або різні формати, щоб мати змогу використовувати її та нашим колегам або робити все, що нам потрібно там. Отже, ви знаєте, що зможете робити такі речі. Повернемось назад - я це втратив? Там ми йдемо. Так добре, сподіваємось, це має сенс з точки зору того, про що я говорив поки що. Тепер, коли ми зібрали дані, все це, очевидно, дійсно життєво важливо з ряду причин - ліцензування та багато чого іншого.
Останнє, що потрібно згадати, - ми переходимо до цього розділу адміністрації. Тут ви також можете налаштувати своє та ваше сповіщення та бути в змозі переконатися, що для речей, про які ви хочете насправді знати, ви також можете налаштувати ці речі. Таким чином, ми можемо налаштувати сповіщення, ми можемо налаштувати можливість увімкнути певні речі та вимкнути певні речі, а потім зможемо визначити, хто буде отримувати ці повідомлення, і підписавшись на ці сповіщення, ми можемо пов’язати, кого б ми хотіли бути, хто хотів би знати про такі речі.
Але, як я вже говорив раніше, це дійсно приємний спосіб зробити, принаймні мати загальний спокій, щоб знати про всі ваші екземпляри SQL підприємства - що це у вас є, а також переконайтесь, що його працює оптимально, навіть якщо ви цього не робите, не прийняли рішення інвестувати в інструмент для моніторингу продуктивності, який дуже важко вражає, щоб керувати цим екземпляром. Це охопить вас, тому що це дуже доступний спосіб виходу на вулицю, і для багатьох випадків можна робити ці запаси та мати можливість робити дуже широкий загальний рівень моніторингу, щоб переконатися, що ви отримав цей спокій і знаю, що відбувається.
Тож сподіваємось, що це має сенс у тому, як ми описали це та показали вам. Я думаю, що з цієї точки зору я можу йти вперед і повернути його назад, і ми можемо поговорити ще трохи.
Ерік Кавана: Звучить чудово. Так Робін? Дез? Які-небудь питання?
Робін Блор: Ну я отримав питання. Це дуже цікаво насправді спостерігати за цим, я маю на увазі, що я просто хотів зробити коментар, що майже скрізь я був не просто серед DBA, але серед хлопців у мережі, серед хлопців із сховища, серед хлопців з віртуального управління машиною, вони всі опрацювання електронних таблиць.
Ерік Кавана: Це вірно.
Dez Blanchfield: Ви наче знаєте, що це, ви начебто знаєте, що це нормально, поки цифри не почнуть рухатися. Коли цифри починають рухатися, ви знаєте, що вони потраплять у біду. Тож питання мене зараз цікавить, і я знаю, що вам буде важко відповісти, але що, якщо ви заходите в місце, де вони не мають нічого подібного там для роботи з електронними таблицями, тому давайте припускати DBA Ви дуже розумні хлопці і так далі і таке інше, яку рентабельність ви думаєте, що отримаєте від впровадження чогось подібного? Чи є у вас якісь дані щодо цього чи будь-які вказівки щодо цього?
Bullett Manale: Важко сказати, що таке рентабельність інвестицій, тому що середовища будуть дещо іншими. Очевидно, що чим більше підприємство, тим більше середовище, очевидно, тим більше буде рентабельність інвестицій, якщо вони зараз використовують, знаєте, ручні методи.
Я знаю, що я розмовляв з низкою - коли я кажу про великі організації з тисячами і тисячами працівників, а також, мабуть, і з тисячами випадків, - де я маю людей, де я їм це показую, і вони кажуть, що це займе два тижні мого часу назад. Ive говорив це мені не раз. Тому важко сказати з точки зору фактичної суми долара від покупки, але вона значна, коли у вас є умови.
Як я вже говорив, його досить послідовно, це люди, з якими я, більшість людей, з якими я розмовляю, зберігають ці матеріали в електронній таблиці. Тож його просто дуже і дуже суб'єктивна річ, тому що кожне середовище, дещо відрізняється з точки зору того, як вони роблять своє ліцензування та як вони роблять своє ліцензування у Microsoft, є ще однією частиною цього фактору. Але якщо їм доведеться робити справжні бажання щороку або кожні три роки, я думаю, що три роки, як максимум, для Microsoft, що вони скажуть, вони хочуть, щоб ви справджувались принаймні кожні три роки.
Тоді ви знаєте його значне і це, ви знаєте його просто щось, що робить набагато простіше. Оскільки його динамічна річ, яка завжди змінюється, вона дає трохи більше достовірності і з точки зору того, що ви дивитесь на вірші, і ми не оновлювали електронну таблицю за півроку чи рік. Тож як часто ви оновлюєте електронну таблицю - це ще одне питання, щоб зрозуміти, що це відповідь на рентабельність інвестицій.
Dez Blanchfield: Так, я маю на увазі ліцензування SQL, ліцензування цього - це просто проклятий кошмар, але особливо його кошмар, оскільки ліцензування не є однаковим між Microsoft та Oracle та будь-ким іншим, що робить там справи з базами даних. Якщо ви насправді зберігаєте речі в електронних таблицях, які, як правило, трапляються, ви знаєте, що час ліцензування настає ще до того, як ви насправді це усвідомлюєте, і у вас фактично немає даних, якщо ви знаєте, що я маю на увазі, щоб легко отримати цю інформацію.
У будь-якому випадку, як ви зазначаєте, його динамічність, і я особисто не маю уявлення, тому що я ніколи насправді не мав домовлятися з Microsoft, тому я не маю уявлення, але, мабуть, є бази даних, які люди досить часто знімають дані тестування, тестування середовища, і я б здогадуйтесь, що це шипи у вашій стороні, якщо ви робите ліцензування. Це ти-?
Bullett Manale: Так, так. Це так, тому що багато разів про цей матеріал забувають, і тоді ми починаємо намагатися розібратися, добре, добре, ми отримали основне ліцензування, що ми повинні з'ясувати кількість ядер для кожного з цих випадків, і я не знаю, з точки зору стандартів того, що ви купуєте апаратне обладнання, ви можете також придбати досить гарне обладнання, то якщо ви не використовуєте це обладнання так, як його слід використовувати, то ви переплачуєте, оскільки ви платите за основні ціни, коли ці ядра не використовуються, так що стає проблемою.
Отже, кожна версія SQL має інший спосіб застосування ліцензій, що навіть робить її трохи заплутаною. Тож у вас виникають певні проблеми навколо цього, і тому велика частина того, чому ця інформація є дуже корисною, оскільки ми можемо сказати вам, в якій версії вона є, ми можемо сказати вам, очевидно, кількість ядер у вас, якщо її старіші версії SQL це було ціноутворення на одну розетку, ми все ще можемо показати це, очевидно. Так що це просто, це робить набагато простішим рутина, яку вам доведеться пройти, коли настає час, щоб виправдати ці речі.
Dez Blanchfield: Одне, що мені спадає на думку, вибачте,
Робін Блор: Гаразд, ви їдете в Дез, я збирався задати, можливо, невідповідне питання.
Dez Blanchfield: Просто щось дуже швидко, коли ти зараз на темі, ти зараз - бачили набагато більше прийняття хмарних середовищ, і якби це працювало всередині нашого власного центру обробки даних, всередині нашого власного оточення, вони повзають і знаходять, виявляючи речі відносно просто. .
Як нам, як ми впораємося зі сценарієм, коли у нас може бути три набори даних, дві хмари, а видимість у цих середовищах розгорнута, і часто є набір даних у кінці труби або VPN. Чи є нам можливість виявити з переднього кінця чи нам потрібно, щоб почати відкривати порти, щоб ми могли сканувати певні середовища між різновидом хмари та поза приміщеннями, де працює ця платформа?
Bullett Manale: Так, було б певний розгляд з точки зору портів. Так що, на жаль, я б хотів сказати, що я можу пробити всі ці середовища, але є кілька різних варіантів, які ви могли б зробити з цим. Очевидно, що якщо ви робите щось на кшталт Amazon EC2, все, що вам справді знадобиться, - це доступ до цього середовища через ваше з'єднання, якщо припустити, що ваші порти відкриті, а потім ви зможете вказати ваші IP-адреси або ваш домен, пов’язаний із цим, і він може розпочати колекцію і розпочати відкриття.
Отже, його в таких середовищах це справді не проблема; це більш специфічні типи середовищ, такі як RDS, і де ти просто отримуєш саму базу даних, де її буде трохи складніше бачити та відкривати такий тип інформації.
Dez Blanchfield: Отже, випливаючи з того, що там було, є бази даних та бази даних. Так, наприклад, старі добрі часи, що мають дуже-дуже великий двигун бази даних, як той анекдот, яким я поділився на фронті, де є лише одна масивна платформа, і все, що він робить, - це надання бази даних. В наші дні бази даних вбудовані у все, насправді такі, як два-три з них, просто працюють у моєму телефоні за додатками.
Які проблеми ви стикаєтесь із сценаріями, коли у вас є середовище, що надходить від Lotus Notes, із програмами, що стоять за ними, SharePoint з базою даних в різних інтернетах тощо? По суті, все працює на базі даних на зворотному кінці. Які речі ви бачите там і з якими труднощами ви стикаєтеся, що люди просто намагаються скласти карту таких типів світів і що ваш інструмент робить для них?
Bullett Manale: Ну я маю на увазі, що справа в тому, що те, що ви сказали - зараз все потребує бази даних, тому багато разів є багато, мабуть, є багато баз даних, які вводяться в середовище, що самі DBA навіть не робили відомо про те, що не дуже складно встановити SQL-сервер, встановлений у середовищі, взагалі кажучи.
Цей інструмент також визначає такі речі, як експрес-бази даних, тому безкоштовні версії SQL Server. Досить смішно, коли ви знову розмовляєте з DBA, ще раз не отримуєте послідовної відповіді з точки зору того, чи вони піклуються про безкоштовні бази даних, які там знаходяться. Багато цих програм, про які ви говорите, використовуватимуть безкоштовну версію бази даних. Але самі організації будуть по-різному ставитися до того, хто відповідає за цю базу даних, залежно від того, з ким ви спілкуєтесь.
Деякі DBA, з якими я розмовляю, я можу подумати про те, коли я останній раз, коли я був у 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 біт, і це все ви отримаєте, і ви можете почати своє відкриття звідти.
Робін Блор: Фантастична та чудова, чудова презентація, дуже дякую.
Bullett Manale: Дякую.
Ерік Кавана: У нас є декілька запитань від аудиторії, і ці питання до вас, тому що нам сьогодні важко зупинити себе, але Буллетт, знову ж таки, чудова робота на демонстрації, чудова робота нашого продюсера, що він не показував.
Bullett Manale: Вибач за те.
Ерік Кавана: Ні, це хороші речі, ви бачите видимість в основі бізнесу, правда? Оскільки бізнес керує даними, і ви надаєте видимість прямо до основи. Тож більше немає ручних хвилястих речей; тепер ви можете фактично вказувати на речі і вирішувати це. Так добре для вас.
Bullett Manale: Дякую.
Робін Блор: Але було чудово побачити, що це теж до речі, молодець.
Ерік Кавана: Так, ми будемо архівувати цю веб-трансляцію для подальшого перегляду, і тоді ми сподіваємось, що вона буде сподіватися приблизно через годину-дві, початковий архів іноді збільшиться трохи довше, ніж це, але обов'язково повідомте про це людям. З цим збиралися відпустити вас, люди. Ще раз спасибі за відвідування інструктажу, насправді були «гарячими технологіями». Добре наздогнати вас наступного разу. Обережно, до побачення.