Винос: Ведучий Ерік Кавана обговорює прогнозування з докторами Робіном Блором, Ріком Шерманом та IDERAs Bullett Manale.
Ви повинні зареєструватися для цієї події, щоб переглянути відео. Зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Шановні панове, привіт ще раз і вітаємо вас до веб-трансляції серії Hot Technologies! Мене звуть Ерік Кавана, я буду вашим господарем сьогоднішнього веб-семінару під назвою "Економити час, гроші та проблеми з оптимальними прогнозами". "Я, звичайно, пропустив першу частину заголовка," Найкращі планові плани ". Ми завжди говоримо про це на цьому шоу. Отже, Hot Technologies - це, звичайно, наш форум для розуміння того, що деякі круті продукти є сьогодні у світі, світ технологій підприємств, що люди роблять з ними, як вони працюють, і все таке цікаве.
І тема сьогодні, як я пропоную, стосується прогнозування. Дійсно ви намагаєтесь зрозуміти, що буде у вашій організації. Як ви збираєтеся підтримувати своїх користувачів щасливими, незалежно від того, що вони роблять? Якщо вони роблять аналіз, якщо вони роблять реальну роботу, вони стикаються з реальними клієнтами з транзакційними системами, незалежно від конкретного випадку, ви хочете зрозуміти, як працюють ваші системи і що відбувається, і про що добре говорити сьогодні. Це своєрідно смішно, тому що прогнозування - це не те, що я люблю робити, тому що я забобонний, як я думаю, якщо я занадто багато прогнозую, трапляться погані речі, але це тільки я. Не слідкуйте за моїм поводом.
Отже, ось наші сьогодні ведучі, ваші справді у верхньому лівому куті, Рік Шерман набирає номер з Бостона, наш приятель Буллетт Манале з IDERA і наш власний доктор Робін Блор. І з цим, я передавайте це Робіну і просто нагадуйте людям: Задайте питання, не соромтеся, ми любимо хороші запитання, добре викладіть їх сьогодні нашим ведучим та іншим. І з цим, Робіне, забирай це.
Робін Блор: Добре, що ж, так як я в полюсному положенні, як кажуть, я думав, що сьогодні я розповім історію SQL, тому що це фон для того, що дискусія триватиме, і вона неминуче не зіткнеться з тим, що Рік не зосереджується на цьому. , і не зіткнеться з тим, що має сказати Рік. Отже, історія SQL, є кілька цікавих речей про SQL, оскільки вона настільки домінуюча. Дивіться, це помилка, SQL є декларативною мовою. Ідея полягала в тому, що ви можете створити мову, якою ви будете запитувати те, чого хочете. І база даних розробила б, як її отримати. Насправді це було досить добре, але є ряд речей, про які варто сказати про це, наслідки базування всієї ІТ-індустрії на декларативній мові. Користувач не знає і не піклується про фізичну організацію даних, і це добре в декларативній мові - вона відділяє вас від усього цього, і навіть хвилюється з цього приводу - просто запитайте все, що вам потрібно, і базу даних піде і дістане.
Але користувач не має уявлення, чи спосіб їх структурування SQL-запиту вплине на ефективність запиту, і це трохи недоліки. Я бачив запити завдовжки сотень і сотень рядків, які є лише одним запитом SQL, ви знаєте, починається з "select" і просто продовжується і продовжується з підзапитів і так далі і так далі. І насправді виявляється, що якщо ви хочете певний збір даних із бази даних, ви можете попросити його різними способами з SQL і отримати таку саму відповідь, якщо ви начебто ознайомитесь з даними. Отже, один запит SQL - це не обов'язково найкращий спосіб запиту даних, а бази даних відповідатимуть зовсім інакше відповідно до SQL, який ви вводите до них.
І так, SQL насправді впливає на продуктивність, тому люди, які використовують SQL, його правда щодо них, також правда про програмістів SQL, які використовують SQL, і вони ще рідше замислюються про вплив, який вони матимуть, тому що більшість їх фокусується насправді полягає в маніпулюванні даними, а не в отриманні, передачі даних. І те ж саме стосується BI-інструментів, я бачив SQL, який, якщо вам подобається, видаляє з BI-інструментів різних баз даних, і треба сказати, що багато цього є, ну я б не писав запити SQL так як це. Його хтось створив, якщо вам подобається, трохи мотора, який би не було параметрів, він викине деякі SQL, і знову ж таки, що SQL не обов'язково буде ефективним SQL.
Тоді я подумав, що Id згадую невідповідність імпедансу, дані, які використовують програмісти, відрізняються від даних, що їх сортують. Отже, наші DMS зберігають дані в таблицях, організований об'єктно-орієнтований код - це в основному кодери, в даний час програмують об'єктно-орієнтовану форму і вони впорядковують дані в об'єктних структурах, тому він не відображає одне до іншого. Отже, є необхідність перевести з того, що програміст вважає, що дані, до того, що база даних думає, що це за дані. Що здається, ми повинні були зробити щось не так, щоб це було так. У SQL є DDL для визначення даних, у нього є DML - мова маніпулювання даними - вибирайте, проектуйте та приєднуйтесь для отримання цих даних. Зараз у них дуже мало математики та дуже мало часу, тому її недосконала мова, хоча, як слід сказати, її розширена та продовжена.
І тоді, ви отримуєте проблему SQL-бар'єру, яка завжди виразніше діаграми, але багато людей задавали запитання з аналітичних причин, як тільки вони отримали відповідь на умови запитання, хочуть задати інше запитання. Отже, це стає діалоговою річчю, ну, SQL не був побудований для діалогів, він був побудований для того, щоб запитати, що ви хочете, всі відразу. І це варто того знати, оскільки там є деякі продукти, які фактично відмовляються від SQL, щоб зробити можливою розмову між користувачем та даними.
Що стосується продуктивності бази даних - і цей вид поширюється на все - так, процесор CPU, theres пам'ять, theres диск, theres мережа накладних витрат і є проблема блокування більше однієї людини, яка бажає ексклюзивно використовувати дані в певний момент момент часу. Але є також погані дзвінки SQL, це дуже багато, що можна зробити, якщо ви фактично оптимізуєте SQL з точки зору продуктивності. Отже, фактори роботи бази даних: поганий дизайн, поганий дизайн програми, паралельність завантаженості роботи, відсутність балансування навантаження, структура запитів, планування потенціалу. Це зростання даних. І кількома словами, SQL є зручним, але він не самооптимізується.
Сказавши це, я думаю, ми можемо перейти до Ріка.
Ерік Кавана: Добре, Рік, дозволь мені передати вам ключі від машини WebEx. Відняти її.
Рік Шерман: Гаразд, чудово. Ну дякую Робін, як ми почали на початку презентації, моя графіка все ще досить нудна, але добре з цим. Отже, я погоджуюся з усім, про що Робін говорив на стороні SQL. Але на цьому я хочу трохи зосередитись - це попит на дані, які дуже швидко проходять, пропозиція як в інструментах, що використовуються в цьому просторі, чи потреба в інструментах цього простору.
По-перше, у кожній прочитаній статті є щось, що стосується великих даних, безлічі даних, неструктурованих даних, що надходять із хмари, великих даних скрізь, які ви можете собі уявити. Але зростання ринку баз даних постійно спостерігається за допомогою SQL, реляційна база даних, можливо, станом на 2015 рік, все ще становить 95 відсотків ринку баз даних. Три кращі реляційні постачальники мають близько 88 відсотків частки ринку в цьому просторі. Отже, як і раніше Робін говорив про SQL. Насправді, навіть якби шукали платформу Hadoop, Hive and Spark SQL - якою мій син, який є вченим даними, весь час використовує - це, безумовно, домінуючий спосіб для людей отримати доступ до даних.
Тепер на базі даних є дві широкі категорії використання баз даних. Перша - це система управління операційними базами даних, тому планування відносин з підприємствами, комплектування відносин із клієнтами, ERPs Salesforce, Oracles, EPIC, N4s тощо. Крім того, існує великий обсяг даних, що збільшуються в сховищах даних та інших системах, що базуються на бізнес-аналітиці. Тому що все, незалежно від того, де і як воно захоплюється, зберігається чи здійснюється транзакція, з часом аналізується, і тому виникає величезний попит та збільшення використання баз даних, особливо реляційних баз даних на ринку.
Зараз ми отримали попит, ми отримуємо величезну кількість даних. І я насправді не кажу лише про великі дані, я говорю про використання даних на всіляких підприємствах. Але супроводжуючи це тим, що з боку пропозиції, для людей, які можуть керувати цими ресурсами, ми спочатку маємо дефіцит DBA. За даними Бюро статистики праці, з 2014–2024 рр. Робочі місця DBA збільшаться лише на 11 відсотків - тепер це люди, які мають посади DBA, але добре говорять про це за секунду - проти 40-відсоткових відсотків щорічний простір зростання даних. І у нас багато DBA; в середньому те саме дослідження говорило про середній вік досить високий порівняно з іншими ІТ-професіями. І тоді у нас багато людей виходять з поля, не обов’язково виходячи на пенсію, а переходячи на інші аспекти, переходячи до управління, чи будь-чого іншого.
Тепер, частина причини, по якій вони залишають, полягає в тому, що робота DBA продовжується все важче і важче. По-перше, у нас є DBA, які керують багатьма різними базами даних, фізичними базами даних, розташованими всюди, а також різними типами баз даних. Тепер це може бути реляційним, а можуть бути й інші бази даних, типи баз даних. Але навіть якщо це стосується, вони можуть мати будь-якого одного, двох, трьох, чотирьох різних постачальників, якими вони насправді намагаються керувати. DBA зазвичай включаються після створення бази даних або програми. Робін розповів, як розробляються бази даних або програми, як розробляється SQL. Ну а коли говорили про моделювання даних, моделювання ER, розширене моделювання ER, моделювання розмірів, вдосконалене розмірне моделювання, що завгодно, як правило, програмісти прикладних програм та розробники додатків розробляють з метою їх кінцевої мети - вони не розробляють для ефективності самої структури бази даних . Тож у нас багато поганого дизайну.
Тепер я не кажу про продавців додатків для комерційних підприємств; зазвичай вони мають моделі ER або розширені моделі ER. Те, про що я говорю, - це набагато більше бізнес-процесів і додатків, які будуються розробниками додатків у кожній компанії - саме ті не обов'язково розроблені для ефективності та ефективності розгортання. А самі DBA перевантажені роботою, і вони несуть відповідальність 24/7, вони постійно отримують все більше і більше баз даних. Я думаю, що це зробило трохи з тим, що люди не дуже розуміють, що вони роблять, або як вони це роблять. Їх власна маленька група і люди просто думають: "Ну, всі ці інструменти просто такі прості у використанні, ми можемо просто продовжувати набирати все більше і більше баз даних на їх навантаження", що не так.
Це призводить нас до неповних та випадкових DBA. У нас є ІТ-команди, які невеликі, і вони не можуть дозволити собі виділити спеціальну DBA. Зараз це стосується малого та середнього бізнесу, де розширення програм та баз даних вибухнуло за останнє десятиліття та продовжує розширюватися.Але це також стосується великих корпорацій, як правило, тривалий і тривалий час займаються зберіганням даних, аналітикою бізнес-аналітики. Здавна ми отримували спеціальні DBA для цих проектів; ми ніколи більше не отримуємо виділених DBA. Відповідали за розробку бази даних, що добре, якщо її хтось, хто має досвід. Але в цілому, DBA є розробниками додатків, вони часто беруть цю роль як частину своєї роботи, вони не мають офіційного навчання в ній, і знову, вони розробляють це для своїх кінцевих цілей, вони не розробляють його для підвищення ефективності.
І є велика різниця між дизайном та розробкою, порівняно з розгортанням та управлінням. Отже, у нас є "копійки мудрі, нерозумні фунти", з маленькою скарбничкою, яка переходить до отримання необхідних навичок та ресурсів для проектів. Думаючи, що всі походять з "Помста бородавок", моя маленька картинка там. Тепер, що стосується того, що потрібно людям, то ми маємо все ширше використання баз даних і даних у SQL. У нас обмежена кількість DBA - людей, які є кваліфікованими та досвідченими в цих налаштуваннях, розробці та управлінні та розгортанні ситуацій. І у нас все більше і більше випадкових або випадкових DBA, людей, які не мали офіційного навчання.
Отже, які ще є інші речі, які також вступають у питання про те, що ці бази даних також не налаштовані, а також керуються ними? По-перше, багато людей припускають, що в самій системі баз даних є достатньо інструментів для управління ними. Тепер інструменти стають простішими та простішими - розробка та розробка - але це відрізняється від того, щоб зробити хороший дизайн та добре керувати, планувати потужність, моніторинг тощо для розгортання. Отже, спочатку люди припускають, що у них є всі необхідні інструменти. По-друге, якщо ти неповний або випадковий DBA, ти не знаєш, що ти не знаєш.
Я думаю, я забув деякі фрази там, так що багато разів вони просто не розуміють, що їм навіть потрібно дивитись в дизайні або коли вони керують або керують базами даних. Якщо це не ваша професія, то ви не збираєтесь розуміти, що вам потрібно робити. По-третє, це те, що SQL - це інструмент, що рухається, тому Робін говорив про SQL і про те, як погано SQL іноді будується або часто будується. А також одним із моїх вихованців, що займається зберіганням даних BI, міграцією даних, простором інженерії даних є те, що замість використання інструментів люди мають тенденцію писати SQL-код, що зберігаються процедури, навіть якщо вони використовують дорогий інструмент інтеграції даних або дорогий Інструмент BI, вони часто дійсно використовують його просто для запуску збережених процедур. Так що важливість розуміння дизайну баз даних, побудови SQL стає все більш важливою.
І нарешті, є такий силосний підхід, в якому ми маємо індивідуальних людей, які переглядають окремі бази даних. Вони не дивляться, як працюють програми та взаємодіють між собою. Вони також дійсно часто переглядають бази даних порівняно з програмами, для яких вони використовують. Отже, навантаження, яку ви отримуєте в базі даних, є критично важливою для дизайну, критичною в налаштуванні її, критичною при спробі розібратися, як планувати потужність тощо. Отже, дивлячись на ліс з дерев, люди перебувають у бур'янах , дивлячись на окремі таблиці та бази даних і не дивлячись на загальну взаємодію цих додатків у робочому навантаженні.
Нарешті, людям потрібно подивитися на ключові сфери, на які вони повинні дивитися. Коли вони планують керувати базами даних, їм потрібно спочатку подумати про те, розробити деякі показники продуктивності, орієнтовані на додатки, тому вони повинні дивитися не тільки на те, як структурована ця таблиця, як її моделюють, а як вона використовується? Отже, якщо у вас є корпоративна програма, що належить до управління ланцюгом поставок, якщо ви знімаєте замовлення в Інтернеті, якщо ви робите BI - що б ви не робили - вам потрібно подивитися, хто ним користується, як вони користуються ним, які обсяги даних , коли це станеться. Те, що ви насправді намагаєтеся шукати, - це терміни очікування, тому що незалежно від того, всі додатки оцінюються за тим, скільки часу потрібно, щоб щось зробити, будь то людина чи просто обмін даними між додатками чи процесорами. А які вузькі місця? Тому часто, коли ви намагаєтеся налагоджувати проблеми, звичайно, ви справді намагаєтесь подивитися на те, що є справжніми вузькими місцями - не обов’язково, як налаштувати все, але як позбутися та перемістити продуктивність до термінів очікування та пропускної здатності - що б не було вам потрібно подивитися.
І вам дійсно потрібно відокремити захоплення даних, транзакції, аспекти перетворень у базі даних разом з аналітикою. Кожен з них має різні шаблони дизайну, кожен з них має різні схеми використання, і кожен з них повинен бути налаштований по-різному. Отже, вам потрібно подумати про те, як ці дані використовуються, коли вони використовуються, для чого вони використовуються, і з’ясувати, які показники ефективності та які ключові речі, які ви хочете проаналізувати, пов’язані з цим використанням. Тепер, коли ви дивитесь на моніторинг продуктивності, ви хочете переглянути самі операції з базою даних; Ви хочете переглянути обидві структури даних, тому індекси, розділення та інші фізичні аспекти бази даних, навіть структуру бази даних - будь то модель ER чи розмірна модель, однак її структурованість - всі ці речі впливають на продуктивність , особливо в різних мінусах аналітики збору даних та трансформацій, що відбуваються.
І як згадував Робін на стороні SQL, дивлячись на те, що SQL управляється цими різними додатками в цих базах даних, і налаштування цього є критичним. А також дивлячись на загальну завантаженість програм та інфраструктурне середовище, на якому працюють ці бази даних та програми. Отже, що мережі, сервери, хмара - що б вони не працювали - також дивляться на вплив, який ці програми та ці бази даних мають у цьому контексті, все це взаємодіє з можливістю налаштування бази даних.
І нарешті, дивлячись на інструменти, ви хочете мати змогу розглянути три різних видів аналітики, пов'язаних із цим. Ви хочете переглянути описовий аналіз: що відбувається і де, пов'язане з базою даних та продуктивністю програми. Ви хочете мати можливість робити діагностичну аналітику, щоб визначити не тільки те, що відбувається, але чому це відбувається, де вузькі місця, де проблеми, що добре працює, а що не працює? Але вміти аналізувати та деталізувати проблематичні місця, щоб вирішити їх, будь то для дизайну чи того, що вам потрібно зробити.
І нарешті, найбільш агресивним чи ініціативним типом аналізу є фактично робити якийсь прогнозний аналіз, моделювання прогностичної аналітики, будь-що. Ми знаємо, що база даних та додатки працюють у цьому зв'язку, якщо ми збільшили потенціал, якщо ми отримаємо більше користувачів, якщо ми зробимо більше пропускної здатності, що б там не робилося, вміючи проектувати, що, як і де це вплине на базу даних, Програми дозволяють нам планувати та визначати, де саме є вузькі місця, де можуть страждати терміни очікування та що нам потрібно зробити, щоб виправити речі. Тому ми хочемо мати інструменти, які здатні реалізовувати показники ефективності, контролювати ефективність, як це роблять у цих трьох типах аналізу. І ось мій огляд.
Ерік Кавана: Гаразд, дозвольте передати це - до речі, це дві чудові презентації - дозвольте передати це Буллетту Манале, щоб забрати його звідти. І люди, не забувайте задавати гарні запитання; у нас вже є хороший зміст. Забирай це, Буллет.
Bullett Manale: Звучить добре. Спасибі, Еріку. Отже, багато того, що сказав Рік і сказав Робін, очевидно, я згідний на 100 відсотків. Я б сказав, що я підтягнув цей слайд вгору, тому що я думаю, що його підходить, я не знаю для тих із вас, хто є фанатами "команди" ще в 80-х, Джон Ганнібал Сміт завжди говорив: "Я люблю це коли план збирається ", і я думаю, що коли ви говорите про особливості SQL Server, саме на якому фокусувались, саме на продукт, про який сьогодні буде говорити, SQL Diagnostic Manager, безумовно, одна з тих речей, які ви повинні мати; ви повинні мати можливість використовувати дані, які у вас є, і вміти приймати рішення з цих даних, а в деяких випадках ви не шукаєте рішення; ти шукаєш щось, щоб сказати тобі, коли у когось вичерпаються ресурси, коли у тебе закінчуватиметься ресурси, коли у тебе буде вузьке місце, такі речі.
Йдеться не лише про моніторинг конкретної метрики. Отже, з діагностичним менеджером, одна з речей, яка дуже добре працює, - це допомогти вам у плані прогнозування та розуміння конкретних навантажень, і сьогодні вони збираються поговорити про багато. Інструмент орієнтований на менеджера даних, DBA або діючого DBA, тому багато речей, про які Рік згадував, діючу DBA так правдиво. У багатьох випадках, якщо ви не DBA, у вас буде багато знаків запитань, які ви матимете, коли настане час керувати середовищем SQL, те, чого ви не знаєте. І тому ви шукаєте щось, що допоможе вам, провести вас через цей процес, а також навчити вас у цьому процесі. Отже, важливо, щоб інструмент, який ви використовуєте для таких рішень, дав вам деяке розуміння причин, через які ці рішення приймаються, а не просто говорить вам: «Ей, роби це».
Оскільки я діючий DBA, врешті-решт я можу стати повноцінним DBA з фактичним досвідом та знаннями, щоб підкріпити цю назву. Отже, це було сказано, коли я говорив про те, що я буду адміністратором бази даних - я завжди на початку показую цей слайд, оскільки DBA має деякі різні ролі, і залежно від організації, з якою ти будеш, ти будеш відрізнятися від одне місце до іншого - але, як правило, ви завжди певним чином відповідаєте за ваше сховище, ваше планування цього сховища та розуміння передбачення, я повинен сказати, скільки місця вам знадобиться, чи то для ваших резервних копій, чи чи то для самих баз даних. Вам потрібно буде це зрозуміти і оцінити.
Крім того, вам потрібно буде вміти розуміти та оптимізувати речі за потребою, і, проходячи моніторинг навколишнього середовища, очевидно важливо, щоб ви вносили зміни в міру необхідності на основі речей, що змінюються в оточенні себе. Отже, такі речі, як кількість користувачів, такі як популярність програм, сезонність бази даних, все слід враховувати, коли ви робите прогнози. А потім, очевидно, дивлячись на інші речі з точки зору можливості надання звітів та необхідної інформації, що стосується прийняття цих рішень. У багатьох випадках це означає порівняльний аналіз; це означає, що ви зможете розглянути конкретний показник і зрозуміти, яке значення цього показника минуло з часом, щоб ви могли передбачити, куди він рухатиметься вперед.
Отже, що багато інструментів Diagnostic Manager має ці можливості, і люди користуються ним щодня для того, щоб робити такі речі, як прогнозування, і я поставив тут визначення планування потенціалу. І це досить широке і насправді досить розпливчасте визначення, яке є лише процесом визначення виробничих потужностей, необхідних організації для задоволення мінливих потреб у своїй продукції, і врешті-решт, це справді все, про що йдеться: її про можливість приймати інформацію, яку ви маєте так чи інакше, і приймати цю інформацію та приймати рішення, які допоможуть вам рухатись вперед під час просування по життєвому циклу ваших баз даних. І так, види речей, які є причинами, через які людям потрібно це робити, очевидно, перш за все, в більшості випадків, щоб заощадити гроші. Очевидно, що їх основна мета - це заробити гроші та заощадити гроші. Але разом з цим, це також означає можливість переконатися, що у вашому простої немає простоїв. І зможете переконатися, що ви пом’якшите будь-який шанс настання простою, тому не дайте йому початись, інакше кажучи, не чекати, коли це станеться, а потім реагувати на нього.
Очевидно, що, окрім того, що ви зможете загалом збільшити продуктивність своїх користувачів, зробіть їх ефективнішими, щоб можна було більше бізнесу робити, тому це типи речей, які, як DBA або хтось, хто бере участь у прогнозуванні чи спроможності планування повинна мати можливість проникнути через інформацію, щоб мати можливість приймати ці рішення. І тоді, загалом, це, очевидно, допоможе вам позбавити відходів, не лише відходів у грошах, а й з точки зору часу та з точки зору просто загальних ресурсів, які можуть бути використані для інших речей, можливо. Таким чином, можливість утилізувати ці відходи, щоб у вас не було можливих витрат, пов'язаних із самими відходами.
Отже, з урахуванням сказаного, які типи питань, які ми отримуємо, характерні для людини, яка є DBA? Коли мені не вистачить місця? Це велике, не тільки скільки місця я споживаю зараз, але коли я збираюся закінчитися, виходячи з тенденцій та минулої історії? Те ж саме з фактичними екземплярами SQL, базами даних, які сервери я можу консолідувати? Я збираюся поставити деякі з віртуальних машин, що має сенс з точки зору, в яких базах даних я збираюся консолідуватись і в яких екземплярах SQL вони повинні проживати? На всі ці типи питань потрібно відповісти. Тому що в більшості випадків, якщо ви DBA або діючий DBA, ви збираєтеся закріпити це десь у своїй кар'єрі. У багатьох випадках ви будете робити це постійно. Отже, вам потрібно вміти швидко приймати ці рішення, а не грати в здогадки, коли справа доходить до цього.
Ми говорили про вузькі місця та про те, де вони відбудуться далі, маючи можливість передбачити, що ще раз, замість того, щоб чекати, коли вони відбудуться. Отже, очевидно, що всі ці речі говорили, мають сенс у тому сенсі, що ви покладаєтесь на історичні дані, в більшості випадків, щоб мати можливість генерувати ці рекомендації або в деяких випадках вміти самостійно формулювати рішення, щоб мати можливість придумайте ці відповіді. Але мені це нагадує про те, що коли ви чуєте радіорекламу про те, хто продає цінні папери чи щось подібне, його завжди "минула робота не вказує на майбутні результати" та подібні речі. І те саме стосується і тут. У вас будуть ситуації, коли ці прогнози та ці аналізи можуть бути не стовідсотково правильними. Але якщо ви маєте справу з речами, що траплялися в минулому і відомими, і вмієте приймати і робити "що робити" з великою кількістю таких питань, на які ви збираєтеся зіткнутися, дуже цінне і це буде отримати вас набагато далі, ніж грати в здогадки.
Отже, ці типи питань, очевидно, збираються з'являтися, тому, як ми обробляємо багато цих питань з "Діагностичним менеджером", перш за все ми маємо можливості прогнозування, вміючи це робити в базі даних, за столом, а також диск або гучність.Щоб мати змогу не тільки сказати: "Ей, було багато місця", але через півроку, два роки з цього часу, п'ять років відтепер, якщо я буду на це бюджету, скільки мені потрібно місця для бюджету для? Це питання, які мені доведеться задати, і мені потрібно буде мати можливість використовувати якийсь метод цього, а не здогадуватися і піднімати мій палець в повітрі і чекати, куди вітер дме, що багато Часом, на жаль, багато таких рішень приймаються.
На додаток до цього, бути в змозі - схоже, що мій слайд там трохи відрізали, - але в змозі надати певну допомогу у вигляді рекомендацій. Отож, одне - це мати змогу показати вам інформаційну панель, сповнену метрик, і вміти сказати: «Добре, єресь усі показники та де вони перебувають», але потім мати можливість зрозуміти, чи мати певне розуміння, що робити робити, виходячи з цього - ще один стрибок. І в деяких випадках люди достатньо освічені в ролі DBA, щоб мати можливість приймати ці рішення. І тому у нас в інструменті є деякі механізми, які допоможуть у цьому, які добре покажуть вам лише за секунду. Але вміти показати не тільки, що таке рекомендація, а й дати деяке розуміння того, чому ця рекомендація робиться, а потім ще й поверх того, що в деяких випадках, насправді може створити сценарій, який автоматизує вирішення цього питання також ідеально.
Переходимо до наступного тут, що добре бачить, його просто загалом розуміння до рівня метрики, що це нормально. Я не можу сказати тобі, що не є нормальним, якщо я не знаю, що таке нормально. Отже, маючи певний спосіб виміряти це ключове значення, і ви маєте змогу враховувати різні типи областей, наприклад - або я повинен сказати часові рамки - різні групи серверів, здатні це робити динамічно, з іншими словами, під час мого вікна обслуговування я очікую, що мій процесор працює на 80 відсотків на основі всього технічного обслуговування. Отже, я можу захотіти підвищити свої пороги вище, за ті часові рамки порівняно, можливо, посеред дня, коли я не маю такої активності.
Це деякі речі, які, очевидно, будуть екологічними, але це те, що ви можете застосувати до того, чим керуєте, щоб допомогти вам ефективніше керувати цим середовищем та полегшити це. Інша область, очевидно, здатна просто загалом надавати звіти та інформацію, щоб мати змогу відповісти на такі типи питань "що робити". Якщо я щойно змінив своє оточення, я хочу зрозуміти, що це за вплив, щоб я міг застосувати цю зміну до інших екземплярів чи інших баз даних у моєму середовищі. Я хочу мати змогу мати деяку інформацію чи боєприпаси, щоб можна було змінити, спокійно і знаючи, що це буде хорошою зміною. Отже, будучи здатною робити цю порівняльну звітність, будучи рейтингом моїх примірників SQL, вміючи ранжувати мої бази даних один проти одного, щоб сказати: "Хто є моїм найвищим споживачем процесора?" Або який з них займає найдовше в умови очікування та подібні речі? Тому багато з цією інформацією також буде доступно разом із інструментом.
І, нарешті, але не менш важливо, це лише загальна здатність, що вам потрібен інструмент, який зможе впоратися з будь-якою ситуацією, яка підійде вам, і так, що я маю на увазі під цим, якщо у вас є велике середовище з великою кількістю наприклад, ви, мабуть, зіткнетеся з ситуаціями, коли вам потрібно витягувати показники, які традиційно не є метриками, які DBA хотів би навіть контролювати в деяких випадках, залежно від конкретної ситуації. Отже, маючи інструмент, який ви можете, тобто розширювати, мати змогу додавати додаткові показники та мати змогу використовувати ці показники в тій самій формі та способі, що ви використовували б їх, якщо ви використовували нестандартну скриньку метричні, наприклад. Отже, вміння запускати звіти, вміти оповіщати, базовий рівень - про все, про що говорили, - також є ключовою частиною того, що можна робити це прогнозування та робити його, щоб ви отримали відповіді, які шукаєте, щоб мати можливість зробити. ці рішення, рухаючись вперед.
Тепер, як це робить Diagnostic Manager, ми маємо централізовану службу, групу служб, яка працює, збирає дані від 2000 до 2016 екземплярів. І тоді, що ми робимо, ми беремо ці дані і вкладаємо їх у центральний сховище, і, очевидно, що ми добре робимо з цими даними, очевидно, чи робимо ми багато для того, щоб дати можливість зрозуміти подальше розуміння. Тепер, на додаток до цього - і одне з того, що тут не тут - це також у нас служба, яка працює посеред ночі, яка є нашою службою прогнозного аналізу, і це робить певну кількість хрускіт, і це допомагає зрозуміти і допомогти вам як DBA або діючий DBA, щоб мати змогу давати рекомендації щодо таких типів, щоб також можна було ознайомитись з базовими поняттями.
Отже, те, що я люблю робити, і це лише короткий приклад архітектури, велике вирішення тут - це не будь-які агенти чи служби, які насправді сидять у випадках, якими ви керуєте. Але те, що я люблю робити, - це насправді привести вас до програми тут і швидко демонструвати. І дозвольте мені просто вийти і зробити це. Отже, дайте мені знати, я думаю, Ерік, чи можете ви це бачити?
Ерік Кавана: Я зараз це зрозумів, так.
Bullett Manale: Гаразд, тому я збираюся вас провести через деякі з цих різних частин, про які я говорив. І по суті, давайте почнемо з тих речей, які знаходяться більше за те, що вам потрібно зробити, або ось щось таке, що має сенс у майбутньому і збирається дати вам деяке розуміння навколо цього. І це здатне реально передбачити - або я повинен сказати динамічно передбачити - речі, як вони відбудуться. Зараз, у випадку звітів, одним із речей, які ми маємо в цьому інструменті, є три різні звіти прогнозування. У випадку, наприклад, з прогнозом бази даних, що я, мабуть, зробив би, коли я міг передбачити розмір бази даних за певний проміжок часу, і я просто надам кілька прикладів цього. Отже, я збираюсь взяти мою базу даних аудиту, яка досить інтенсивна вводу / виводу - в неї надійде багато даних. Ми отримали, давайте подивимось, добре це зробити тут, і давайте просто вибрати базу даних охорони здоров’я тут.
Але справа в тому, що я не просто бачу, який простір знаходиться на цьому, я в змозі сказати: "Подивимося, давайте візьмемо дані про останні роки" - і я збираюся трохи подати сюди, я справді не маю років варті даних, я маю приблизно два місяці даних, але, оскільки я вибираю вибіркову норму місяців тут, я буду в змозі передбачити або прогнозувати в цьому випадку наступні 36 одиниць, оскільки наша вибіркова ставка встановлена місяцями - це підрозділ, є місяць - і тоді я зможу запустити звіт, щоб в основному показати мені, де ми очікуємо наше майбутнє зростання для цих трьох баз даних. І ми можемо бачити, що ми маємо різну ступінь різниці або відмінності між трьома різними базами даних, зокрема, за кількістю даних, які вони споживають за минулий час.
Ми можемо бачити, що точки даних відображають тут історичні дані, а потім рядки надають нам прогноз, а також цифри для резервного копіювання. Тож ми можемо це зробити на рівні таблиці, ми можемо це зробити навіть на рівні приводу, де я можу передбачити, наскільки великі будуть мої накопичувачі, включаючи точки монтажу. Ми зможемо спрогнозувати цей самий тип інформації, але ще раз, залежно від частоти вибірки, я дам змогу визначити, скільки одиниць і де брали те, що ми хочемо прогнозувати. Зауважте також, що у нас є різні типи прогнозів. Таким чином, ви отримуєте багато варіантів та гнучкості, коли настає час робити прогнозування. Тепер це одне добре, адже насправді ви дасте вам конкретну дату і зможете сказати: «Ей, в цю дату, саме тут ми могли б передбачити зростання ваших даних». На додаток до цього ми можемо надати вам з іншими відомостями, які пов'язані з деяким аналізом, який ми виконуємо в неробочий час та службою, коли вона працює. Деякі з речей, які він робить, це намагання передбачити те, що, швидше за все, станеться, виходячи з історії того, коли речі відбувалися в минулому.
Тож ми можемо побачити тут, насправді, прогноз дає нам деяке уявлення про ймовірність того, що ми матимемо проблеми протягом вечора, виходячи з речей, що вдруге траплялися в минулому. Отже, очевидно, що це чудово, особливо якщо я не DBA, я можу переглянути ці речі, але що ще краще, якщо я не DBA, це вкладка аналізу. Отже, перш ніж це було тут, в інструменті, ми б проходили і показували продукт людям, і вони були б "Це чудово, я бачу всі ці цифри, все бачу, але я не знаю, що робити" (сміється) " результат цього ". І тому те, що ми маємо тут, - це кращий спосіб ви зрозуміти, якщо я збираюся вжити заходів, щоб допомогти в роботі, якщо я збираюся вжити заходів, щоб навіть допомогти здоров'ю мого навколишнє середовище, маючи можливість надати такі рекомендації, а також корисні поради щодо інформації, щоб дізнатися більше про ці рекомендації та фактично мати навіть зовнішні посилання на деякі з цих даних, що покаже мене та приведе мене до причин, чому ці рекомендації зроблені.
І в багатьох випадках, будучи в змозі надати сценарій, який би автоматизував, як я вже сказав, виправлення цих проблем. Тепер, частина того, що робили тут з цим аналізом - і я вам показую, коли я заходжу, щоб налаштувати властивості цього примірника, і я переходжу до розділу конфігурації аналізу - у нас є багато різних категорій, які перераховані тут, і Частина цього у нас є оптимізація індексу та оптимізація запитів. Отже, оцінювали не тільки самі показники та подібні речі, але й такі речі, як завантаженість та індекси. У випадку, що насправді, робимо додатковий аналіз гіпотетичного індексу. Отже, це одна з тих ситуацій, коли я не хочу, у багатьох випадках я не хочу додавати індекс, якщо мені цього не потрібно. Але в якийсь момент є якась підказка, де я кажу: "Ну, таблиця набирає розмір або типи запитів, які виконуються в межах навантаження, має сенс зараз додавати індекс. Але це не мало б сенсу, можливо, за шість тижнів до цього. "Отже, це дозволяє вам динамічно зрозуміти те, що може, як я вже сказав, покращити продуктивність, виходячи з того, що відбувається в навколишньому середовищі, того, що відбувається в межах робочих навантажень, і робити такі речі.
І тому ви отримуєте тут багато хорошої інформації, а також можливість оптимізувати ці речі автоматично. Отже, це ще одна сфера, де ми могли б допомогти, з точки зору того, що ми називаємо прогнозним аналізом. Зараз, окрім цього, я маю сказати, у нас є й інші сфери, які, на мою думку, просто піддаються допомозі у прийнятті рішень. І коли ми говоримо про прийняття рішень, ми знову зможемо переглянути історичні дані, щоб зрозуміти, куди нам потрібно бути, щоб покращити ефективність.
Тепер, одна з речей, яку ми можемо зробити, - це візуалізатор базової лінії, який дозволяє нам вибірково вибирати ту метрику, яку ми хотіли б - і дозвольте мені знайти гідний тут - я збираюся використовувати процесор SQL, але справа в тому, що ви можете піти назад, однак через багато тижнів, щоб намалювати ці картинки, щоб побачити, коли перебувають ваші люди, що переживають, щоб побачити, де ця цінність падає протягом періодів часу, коли ми збирали дані. І тоді, на додаток до цього, ви також помітите, що коли ми виходимо до самого фактичного екземпляра, ми маємо можливість налаштувати наші базові лінії. А базові лінії - це дійсно важлива частина того, що можна автоматизувати речі, а також бути здатними отримувати сповіщення про речі. І завдання, як сказала б більшість DBA, полягає в тому, що ваше оточення не завжди працює однаково протягом дня, порівняно з вечором і тим не менш, як ми згадували раніше в прикладі з періодами технічного обслуговування, коли ми мати високий рівень процесора або все, що може статися.
Отже, у випадку з цими фактичними базовими рівнями ми можемо мати декілька базових ліній, тому я можу мати базовий рівень, наприклад, цей у мої години обслуговування. Але я міг так само просто створити базовий рівень для моїх виробничих годин. І справа в тому, що ми переходимо до екземпляра SQL і насправді мають ці декілька базових ліній, то ми могли б передбачити і змогти виконати якийсь тип автоматизації, якийсь тип виправлення або просто сповіщення загалом, по-різному специфічні для тих вікон часу. Отже, одна з речей, яку ви побачите тут, - це ці базові лінії, які ми генеруємо, використовують історичні дані для надання аналізу, але що важливіше, я можу змінити ці пороги статично, але я також можу автоматично їх автоматизувати. Отже, коли з’являється вікно технічного обслуговування, або я повинен сказати, базове вікно технічного обслуговування, ці порогові значення автоматично перемикаються на конкретні навантаження, з якими я стикаюсь протягом цього вікна часу, порівняно, можливо, в середині дня, коли мої навантаження не такі багато, коли навантаження не такі сильні.
Отже, це щось інше, що слід пам’ятати, з точки зору базової лінії. Очевидно, що вони стануть вам дуже корисними, з точки зору розуміння того, що є нормальним і здатного також зрозуміти, займайтеся, коли у вас також буде не вистачати ресурсів. Тепер, інший варіант, який ми маємо в цьому інструменті, - це допоможе вам приймати рішення, крім того, що визначає базові показники та можливість встановлювати сповіщення навколо цих базових ліній та порогів, які ви створюєте динамічно, - це, як я вже говорив раніше, я просто зможу запустити цілу безліч доповідей, які допомагають мені відповісти на питання про те, що відбувається.
Отже, як приклад, якби у мене було 150 екземплярів управління ім. У моєму випадку я цього не роблю, тому ми маємо тут грати у вигляд, - але якби у мене були всі мої виробничі екземпляри, і мені потрібно було зрозуміти, де ця область, яку я потрібно звернути увагу, іншими словами, якщо у мене буде лише обмежений час для виконання певного типу адміністрування для підвищення продуктивності, я хочу зосередити увагу на ключових областях. І тому, сказавши це, я міг би сказати: "Спираючись на це середовище, класифікуйте мої екземпляри один проти одного і дайте мені це рейтинг по розбіжності". Отже, чи буде його використання диска, використання пам'яті, чи його очікування, чи є час його реакції, я здатний співвіднести - або я повинен сказати, ранжирувати - ці випадки один проти одного. Очевидно, що екземпляр знаходиться у верхній частині кожного списку, якщо це той самий екземпляр, це, напевно, те, на що я дійсно хочу зосередити увагу, оскільки його, очевидно, ще раз у верхній частині списку.
Отже, у вас є багато звітів в цьому інструменті, які допомагають вам з точки зору ранжування середовища на рівні екземпляра; Ви можете це зробити і на рівні бази даних, де я можу класифікувати свої бази даних один проти одного.Зокрема, до порогів і областей, які я можу встановити, я навіть можу тут встановити підстановочні символи, щоб зосередитись лише на певних базах даних, але справа в тому, що я можу порівняти мої бази даних таким же чином. Крім того, що стосується інших видів порівняльного аналізу та великого в цьому інструменті, це базовий аналіз, який ми маємо. Отже, якщо прокрутити вниз до перегляду послуг тут, ви побачите, що є базовий звіт про статистику. Тепер цей звіт, очевидно, допоможе нам зрозуміти не тільки, що таке метричні значення, але для конкретного екземпляра я міг би вийти, і за будь-якою з цих показників я міг би насправді переглянути базові лінії цих показників.
Отже, як би там не було, як відсоток або що б я не міг вийти і сказати: "Давайте побачимо базову лінію для цього, яка вибула за останні 30 днів", і в цьому випадку вона покаже мені фактичні значення порівняно з базовою лінією і Я міг би прийняти деякі рішення, використовуючи цю інформацію, очевидно, тож це одна з тих ситуацій, коли це залежатиме від того, яке саме питання, про яке ви запитуєте в той час. Але це, очевидно, допоможе тобі з багатьох питань. Я б хотів сказати, що у нас був один звіт, який робить все це, і такий собі, як легкий звіт, де ви натискаєте і натискаєте кнопку, і він відповідає лише на кожне питання "що якщо", на який ви коли-небудь могли відповісти. Але насправді у вас буде багато атрибутів і безліч варіантів, щоб можна було вибрати з цих спадів, щоб мати можливість сформулювати ті питання "що робити", які ви шукаєте.
Тож багато цих звітів орієнтовані на можливість відповідати на ці типи питань. І тому важливим є також те, що ці звіти і, крім того, усі речі, які ми вже показали, ви показали в цьому інструменті, як я вже згадував раніше, маючи гнучкість вводити нові показники, якими можна керувати, навіть маючи можливість створювати лічильники, або SQL-запити, включені у ваші інтервали опитування, щоб можна було мені допомогти відповісти на ці запитання, що, можливо, з вікна, який ми не очікували моніторити, ви можете додати цю інформацію. І ви зможете робити все те саме, що я вам тільки показав: базову лінію, запускати звіти та створювати звіти за цією метрикою, і мати змогу відповідати та робити багато цих різних речей, які я вам тут показую.
Зараз, на додаток до цього - і одна з речей, яку ми, очевидно, зустрічаємось зовсім недавно, - спочатку це було, кожен перелітаючи або перемикаючись на ВМ. І зараз у нас з’явилося багато людей, які прямують до хмари. І є багато питань, які виникають навколо цих типів речей. Чи є сенс для мене переміщення до хмари? Я збираюсь економити гроші, перемістившись у хмару? Якби я розмістив ці речі на машині вільного зв'язку, на машині із загальним ресурсом, скільки грошей я можу заощадити? Ці види питань, очевидно, теж будуть виникати. Отже, багато з цього матеріалу майте на увазі, за допомогою Diagnostic Manager ми можемо додавати та витягувати з віртуалізованих середовищ як VMware, так і Hyper-V. Ми також можемо додавати екземпляри, які перебувають у хмарі, тому для ваших середовищ, таких як Azure DB, наприклад, або навіть RDS, ми можемо також виводити показники з цих середовищ.
Таким чином, існує велика гнучкість і багато можливостей відповісти на ці питання, оскільки це стосується тих інших типів середовища, до яких ми бачимо людей, куди прямують. І ще є багато питань навколо цього матеріалу, і, як ми бачимо, як люди консолідують ці середовища, їм потрібно буде відповісти і на ці запитання. Отже, це досить хороший огляд діагностичного менеджера, як це стосується цієї теми. Я знаю, що тема бізнес-аналітики з'явилася, і у нас також є інструмент для бізнес-розвідки, про який ми сьогодні не говорили, але він також надасть вам зрозуміти, як відповісти на ці типи питань, оскільки це стосується ваших кубів і всі ці різні речі, а також. Але, сподіваємось, це був хороший огляд, принаймні з точки зору того, як цей продукт може допомогти формувати хороший план.
Ерік Кавана: Гаразд, добрі речі. Так, я викину його на Ріка, якщо він все ще там. Ріку, якісь питання до тебе?
Рік Шерман: Так, так спочатку, це чудово, мені це подобається. Мені особливо подобається розширення візків та хмар. Я бачу, що багато розробників додатків думають, що якщо його у хмарі, то їм не потрібно його налаштовувати. Тому-
Bullett Manale: Так, ми все одно повинні платити за це, правда? Ви все ще повинні платити за все, що люди ставлять на хмару, тому якщо його погано працює або якщо це спричиняє багато циклів процесора, його більше грошей вам доведеться заплатити, так що його немає, вам все одно потрібно виміряти цей матеріал, абсолютно.
Рік Шерман: Так, я бачив у хмарі багато поганих конструкцій. Я хотів би запитати, чи буде цей продукт також використовуватися - я знаю, ви згадали про продукт BI і у вас є багато інших продуктів, які взаємодіють між собою, - але ви б почали дивитися на продуктивність SQL, індивідуальні запити в цьому інструменті? Або це були б інші інструменти, які були б використані для цього?
Bullett Manale: Ні, це було б абсолютно. Thats одна з речей, які я не покривав, і я мав на увазі, це частина запитів. У нас є багато різних способів визначити ефективність запиту, будь то пов’язаний з ним, зокрема, з очікуванням, як ми бачимо на цьому погляді, або, чи пов'язано це із споживанням ресурсів запитів в цілому, існує цілий ряд способів аналізу запитів. виконання. Незалежно від того, чи тривалість, процесор, введення / виведення та ще раз, ми також можемо розглянути самі робочі навантаження, щоб дати деяке розуміння. Ми можемо надати рекомендації в розділі аналізу, а також у нас є веб-версія, яка надає інформацію про самі запити. Тож я можу отримати рекомендації щодо відсутніх індексів та можливості перегляду плану виконання та всіх подібних матеріалів; це також можливість. Тож абсолютно ми можемо діагностувати запити на сім способів до неділі (сміється) і зможемо дати зрозуміти кількість покарань, будь то споживання ресурсів, очікування, тривалість і все таке добре.
Рік Шерман: ОК здорово. А потім яке навантаження на самі екземпляри при всьому цьому моніторингу?
Bullett Manale: Це гарне питання. Завдання відповіді на це питання полягає в тому, чи залежить це, як і все інше. Багато з того, що може запропонувати наш інструмент, він забезпечує гнучкість, і частину цієї гнучкості ви маєте сказати, що потрібно збирати, а що не збирати. Так, наприклад, із самими запитами мені не потрібно збирати інформацію про очікування, або я можу. Я можу збирати інформацію, що стосується запитів, що перевищують тривалість часу виконання. Як приклад цього, якщо я мав би зайти в монітор запитів налаштування, і я повинен був сказати: "Дозволяє змінити це значення на нуль", реальність полягає в тому, що в основному інструмент змушує збирати кожен запит, який працює, і це насправді не дух того, чому це там, але взагалі кажучи, якщо я хотів би надати повний зразок даних для всіх запитів, я міг би це зробити.
Таким чином, це дуже відносно того, що ваші налаштування, взагалі кажучи, поза рамкою. Її десь приблизно на 1–3 відсотки накладних витрат, але є інші умови, які застосовуватимуться. Це також залежить від того, скільки запитів на порт працює у вашому оточенні, правда? Це також залежить від способу збирання цих запитів та якої версії SQL це. Так, наприклад, SQL Server 2005 не мав змоги витягнути з розширених подій, тоді як для цього ми могли б витягнути зі сліду. Так, це було б дещо по-іншому з точки зору того, як ми б пішли збирати ці дані, але це сказало, як я вже казав, з цього продукту, мабуть, приблизно з 2004 року. Це вже давно, ми отримали тисячі клієнтів, тому останнє, що ми хочемо зробити, - це інструмент моніторингу продуктивності, який викликає проблеми з роботою (сміється). І тому ми намагаємось максимально уникати цього, але загалом кажучи, приблизно так 1–3 відсотки є хорошим правилом.
Рік Шерман: Добре, і це досить низько, так що надзвичайно.
Ерік Кавана: Добре. Робін, якісь питання до тебе?
Робін Блор: Мені шкода, що я був увімкнено. У вас є можливість функціонування декількох баз даних, і я зацікавлений у тому, як ви можете переглядати декілька баз даних, і тому ви можете знати, що більша база ресурсів, можливо, поділяється між різними віртуальними машинами тощо і так далі. Мене цікавить, як люди насправді цим користуються. Мене цікавить, що з цим роблять клієнти. Тому що це дивиться на мене, ну, звичайно, коли я возився з базами даних, те, чого я ніколи не мав під рукою. І я б коли-небудь розглядав один екземпляр будь-яким змістовним способом у будь-який момент часу. Отже, як люди цим користуються?
Bullett Manale: Взагалі, ти говориш про загалом лише про сам інструмент? Як вони користуються ним? Я маю на увазі, як правило, про те, щоб мати можливість мати центральну точку присутності довкілля. Маючи душевний спокій і знаючи, що якщо вони дивляться на екран і бачать зелений колір, вони знають, що все добре. Це коли проблеми трапляються, і, очевидно, більшість випадків з точки зору DBA, багато разів трапляються ці проблеми, коли вони знаходяться перед консоллю, так що можна отримувати сповіщення, як тільки проблема виникає. Але на додаток до цього, будучи здатним зрозуміти, коли проблема трапляється, вміючи дістати до суті інформацію, яка надає їм певні умови щодо того, чому це відбувається. І тому, на мою думку, найбільша частина: бути активними щодо цього, не бути реактивними.
Більшість DBA, з якими я розмовляю - і я не знаю, це хороший відсоток їх - на жаль, все ще знаходяться в реактивному середовищі; вони чекають, коли споживач звернеться до них, щоб сказати їм, що це проблема. І тому ми бачимо, що багато людей намагаються відірватися від цього, і я думаю, що це велика частина причини, чому людям подобається цей інструмент, це те, що він допомагає їм бути ініціативними, але це також дає їм уявлення про те, що відбувається , у чому проблема, але у багатьох випадках ми виявляємо щонайменше - і, можливо, про це говорять саме DBA, - але DBA, це сприйняття - це завжди їхня проблема, навіть якщо розробник програми, який написав заявку що не написав це належним чином, вони є тими, хто буде брати на себе провину, тому що вони беруть це додаток у свої системи чи сервери, і тоді, коли продуктивність погана, всі вказують на DBA, що каже: "Ей, це ваша вина".
Таким чином, цей інструмент багато разів буде використовуватися для того, щоб допомогти з точки зору того, щоб DBA сказала: "Гей, саме тут проблема полягає, і це не я". (Сміється) Нам потрібно покращити це, будь то зміна запитів чи все, що це може бути. У деяких випадках вони потраплять у їхнє відро з точки зору їх відповідальності, але принаймні мати інструмент, який зможе допомогти їм зрозуміти це і знати це, і робити це своєчасно, очевидно, ідеальний підхід.
Робін Блор: Так, більшість сайтів, з якими я знайомий, але пройшов деякий час, коли я був там, дивився на різні сайти з багатьма базами даних, але в основному те, що я використовував, було те, що існуватимуть DBA, орієнтовані на кілька бази даних. Це були б бази даних, що якщо вони колись знизяться, це буде справді великою проблемою для бізнесу, і так далі, і так далі. А інші, вони просто збирають статистику раз у раз, щоб побачити, що у них не вистачає місця, і вони ніколи не дивляться на них зовсім. І поки ви робили демонстрацію, я дивився на це, і я добре думав, так чи інакше, ви розширюєте, просто надаючи щось подібне для баз даних, які часто були, нікого не надто хвилювали, оскільки вони мають зростання даних , вони також мають зростання додатків у рази. Ви розширюєте покриття DBA досить драматично. Тож у чому полягає питання насправді, чи з таким набором таких інструментів ви зможете в значній мірі надати послугу DBA кожній базі даних, що знаходиться у корпоративній мережі?
Bullett Manale: Звичайно, я маю на увазі, що проблема полягає в тому, що, як ви сказали, досить красномовно, це схоже на деякі бази даних, про які піклуються DBA, а потім на те, про що вони не піклуються стільки. І те, як цей конкретний продукт, як його ліцензується, залежить від конкретних випадків. Отож, я думаю, ти можеш сказати, є поріг, коли люди вирішують: «Ей, це не досить критичний екземпляр, що я хочу керувати ним за допомогою цього інструменту». Тоді, є й інші інструменти, які у нас є, що більше , Мабуть, задовольняючи ті менш важливі екземпляри SQL. Один із них був би таким, як Менеджер інвентаризації, де ми робимо легкі перевірки стану здоров’я щодо випадків, але крім того, що ми робимо, ми робимо відкриття, тому ми визначаємо нові випадки, які були виведені в Інтернеті, а потім, з цього моменту, як DBA я можу сказати: «Добре, ось новий екземпляр SQL, тепер це Express? Це безкоштовна версія чи це корпоративна версія? "Це, мабуть, питання, яке я хочу собі задати, але по-друге, наскільки важливий цей екземпляр для мене? Якщо це не так важливо, я, можливо, цей інструмент вимкне і робить це загальним, як я б назвав загальні перевірки здоров'я в тому сенсі, що вони є елементарними типами речей, які мені цікаві як DBA: Чи накопичувач накопичується? Чи відповідає сервер на проблеми? Основні речі, правда?
Тоді як з Diagnostic Manager, інструмент, який я вам тільки показував, збирається знизитися до рівня запитів, збирається перейти до рекомендацій індексів, дивлячись на план виконання та все це хороший матеріал, тоді як це в основному зосереджено про те, кому належить, що я маю та хто за це відповідальний? Які пакети послуг та гарячі виправлення у мене є? І чи працюють мої сервери з основними інгредієнтами того, що я вважаю б здоровим екземпляром SQL? Отже, щоб відповісти на ваше запитання, є трохи суміші. Коли у нас є люди, які переглядають цей інструмент, вони зазвичай переглядають більш критичний набір примірників. Однак, у нас є кілька людей, які купують кожен екземпляр, який вони мають, і керують ним, тому це просто залежить. Але я кажу вам, загалом, це поріг тих людей, які вважають, що їх оточення є досить важливим, щоб мати такий інструмент для управління цими випадками.
Робін Блор: Гаразд, ще одне питання, перш ніж я передам його Еріку. Створюється враження, що тільки спостерігаючи за галуззю, полягає в тому, що в базах даних все ще існує життя, але всі дані заливаються у всі ці озера даних тощо і так далі. Це справді галас, і ажіотаж ніколи не відображає реальність, тож мені цікаво, яку реальність ти сприймаєш там? Чи є важливими базами даних в організації, чи переживає вони традиційне зростання даних, про яке я раніше вважав 10 відсотків на рік? Або вони більше ростуть? Чи великі дані роблять ці бази повітряними кулями? Яку картину ви бачите?
Bullett Manale: Я думаю, що у багатьох випадках спостерігалося переміщення деяких даних у ті інші сегменти, де це має більше сенсу, коли з'являються інші технології.Останнім часом деякі більші дані. Але я б сказала, що ці бази даних у багатьох випадках важко узагальнити, тому що всі трохи інші. Взагалі кажучи, я бачу певну розбіжність. Я бачу, як я вже говорив, у багатьох випадках люди переходять до еластичних моделей, оскільки вони хочуть нарощувати ресурси, а не в інших сферах. Деякі люди переходять до великих даних. Але важко відчути сприйняття, скажімо, сприйняття, оскільки, як правило, люди, з якими я спілкуюся, мають традиційні бази даних і використовують це в середовищі SQL Server.
При цьому, я кажу, що стосується самого SQL, я, безумовно, все ще думаю, що його частка на ринку. І я думаю, що там багато людей, які все ще прямують до SQL з інших місць, таких як Oracle, тому що її більш доступна і, мабуть, очевидно, оскільки версії SQL стають більш досконалими - і ти бачиш це з останніми речами, які збираються з SQL, з точки зору шифрування та всіх інших можливостей, що роблять його середовищем або платформою бази даних - це, очевидно, дуже критично важлива місія. Отже, я думаю, що бачили і це. Там, де ви бачите зрушення, воно все ще відбувається. Я маю на увазі, це відбувалося 10 років тому, але все ще, я думаю, це відбувається в умовах SQL Server, де середовище зростає і зростає частка ринку.
Робін Блор: Добре, Еріку, я гадаю, у аудиторії є питання-два?
Ерік Кавана: Так, дозвольте мені перенести одну швидку до вас. Насправді це досить гарне питання. Один із присутніх запитує, чи скаже мені цей інструмент, якщо таблиці може знадобитися індекс для прискорення запиту? Якщо так, чи можете ви показати приклад?
Bullett Manale: Так, я не знаю, чи є у мене конкретно додавання індексу, але ви можете побачити тут, у нас є рекомендації щодо фрагментації. Я також просто вважаю, що ми щойно мали, і це було частиною Менеджера діагностики, який пропонує веб-версію, де він говорить мені, що у мене відсутній індекс. І ми можемо переглянути ці рекомендації, і це дозволить нам отримати потенційний прибуток, індексуючи цю інформацію. Інша річ, яку я мушу лише зазначити, це те, що коли ми виконуємо рекомендації, для багатьох з них сценарій буде створений для цього. Це не гарний приклад, але ви зможете побачити, так, ситуації, коли індекс - або дублікат індексу, або додавання індексу - покращив би ефективність, і, як я вже говорив раніше, ми робимо багато що за допомогою гіпотетичного аналізу індексу. Отже, це дійсно допомагає з точки зору розуміння навантаження, щоб мати можливість застосувати це до рекомендації.
Ерік Кавана: Це чудовий матеріал, і це дасть мені гарне враження до остаточних коментарів тут. Робін, і я, і Рік, вже багато років чули, як вони розповідають про самоналагодження баз даних. Це база даних про самонастроювання! Все, що я можу вам сказати, це: не вірте їм.
Bullett Manale: Не вірю в ажіотаж.
Ерік Кавана: Можливо, є деякі невеликі дрібниці, які робляться динамічно, але навіть це, ви можете перевірити це і переконатися, що він не робить те, чого ви не хочете. Таким чином, досить довгий час знадобилися такі інструменти, щоб зрозуміти, що відбувається на рівні бази даних, і, як сказав Робін, озера даних є захоплюючими поняттями, але, мабуть, приблизно стільки шансів, що вони захоплять, наскільки існує Чудовисько Лох-Несса незабаром. Отже, я б лише повторив: у реальному світі є багато технологій баз даних, нам потрібні люди, DBA, щоб подивитися на цей матеріал і синтезувати його. Ви можете сказати, що вам потрібно знати, що ви робите, щоб цей матеріал працював. Але вам потрібні інструменти, щоб дати вам інформацію, щоб знати, що ви робите. Отже, підсумок - це DBA будуть робити добре.
І велика подяка Буллетту Манале та нашим друзям із IDERA. І звичайно, Рік Шерман та Робін Блор. Ми архівуємо всі ці веб-трансляції, тому перейдіть на веб-сайт insideanalysis.com або на наш партнерський сайт www.techopedia.com для отримання додаткової інформації про все це.
І з цим, добре прощайтесь, люди. Ще раз дякую, добре поговоримо з вами наступного разу. Піклуватися. Бувай.