Співробітники компанії «Техопедія», 30 листопада 2016 року
Винос: Ведучий Ерік Кавана разом з докторами Робіном Блором, Дезом Бланчфілдом та IDERA Bullett Manale обговорюють запити та як їх ефективність може мати далекосяжний ефект.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Дами та панове, привіт і ще раз вітайте. У середу чотири години східного часу, а в наші дні це означає, що час для гарячих технологій! Так, справді. Ми сьогодні говоримо про класні речі. Звичайно, я твій господар, Ерік Кавана. Заголовок сьогоднішнього шоу "Ключ до ефективної аналітики: швидко повертаються запити". Ось так, люди, ми всі хочемо швидкого. Хто не хоче швидко? Слайд про твій справді, і про мене достатньо. Зачепи мене на Twitter, @eric_kavanagh. Я буду радий зв’язатися з вами там і вести бесіду в соціальних мережах. Це може бути весело, тільки не говоріть про політику.
Рік гарячий. Ми говорили про різні аналітичні питання цього року, і одна тема на сьогоднішній день насправді є лише важливою для виконання роботи. Я пам’ятаю, що, мабуть, п’ять-шість років тому я вперше почув, як хтось вживає вислів «поспілкуйся зі своїми даними», і хоча це може звучати трохи нахабно, справа в тому, що якщо ти не можеш мати ітеративного досвіду з ваші дані, якщо ви не можете швидко змінити запити, надсилати нові запити, швидко отримувати відповіді, тоді ви не ведете розмови зі своїми даними і весь аналітичний процес обрізаний. Це не добре.
Коли ви ведете бесіду зі своїми даними, то це означає, що ви здатні йти туди-сюди, і, на мою думку, саме тоді ви знайдете розуміння. Тому що дуже рідко ви вперше зіткнетеся з ідеальним запитом. Якщо ви не Моцарт аналітики - і я впевнений, що людина там - вам доведеться витратити деякий час на модифікацію, додавши певного виміру, намагаючись налагодити те, що ви шукаєте .
Тому що, знову ж таки, це не надзвичайно складні середовища, з якими ми маємо справу у світі аналітики; ми маємо справу з дуже непростими середовищами та дуже складними та багатовимірними середовищами. І тому вся ідея веб-трансляції сьогодні - це розповісти про те, як увімкнути таку ітераційну взаємодію з вашими даними.
У нас три ведучі. Звичайно, у Hot Technologies, на відміну від інструктажу, ми маємо двох аналітиків; вони спочатку беруть участь, потім приходить гість, дає свою презентацію, і ми влаштовуємо круглий стіл. І ви, наша аудиторія, можете грати велику роль у цьому. Будь ласка, не соромтеся; надсилайте свої запитання в будь-який час. Якщо можете, використовуйте панель запитань і запитань, інакше панель чату добре; Я спробую стежити за обома під час шоу. І ми це робимо, тому якщо ви щось пропустите або хочете поділитися цим із колегами, повертайтеся пізніше. Ми розміщуємо їх на Techopedia.com, а також на InsideAnalysis.com.
І з цим я збираюся залучити розумних людей. Я віддам його доктору Робіну Блору. Дозвольте мені дати йому ключі, поміняти ведучого, і ви їдете. Робін, забирай його.
Робін Блор: Гаразд. Дякую за це вступ. Близько півтора місяців тому я спілкувався з розробником, який насправді є DBA. Він насправді не DBA - він був DBA у певній компанії, і він був єдиною людиною, яка насправді могла зробити запити виконаними. Але йому це стало нудно, бо він насправді, він насправді досить розумний розробник. Тому він пішов.
І він все одно повинен робити пару днів щомісяця для них, тому що вони не змогли знайти когось, щоб зайняти його місце, і вони не мають поняття, що робить база даних або як її взагалі налаштувати. І я щось про це думав, і просто, знаєте, у них насправді не було ІТ-відділу, але цей хлопець підтримував їх. Власне, більшу частину часу він займався роботою DBA.
Для складних баз даних - Oracle, SQL Server, DB2, усіх великих, дорогих - налаштування бази даних - важка робота. Це також безпечна робота. І справді, причиною цього є те, що це мінливий ландшафт. Я якось пройду це. Ви знаєте, реляційні бази даних - зазвичай велика картина, реляційні бази даних все ще домінують у популярності. Вони, ймовірно, домінуватимуть довгий час. Так, зараз існують інші бази даних, які отримують більше ефірного часу, але, знаєте, коли ви насправді дивитесь, що там відбувається, Oracle робить більшу частину цього, Microsoft SQL Server є другим, і в хмарі відбуваються різні речі, які Однак це може спричинити виклик. Вони - великі гіганти в грі. І це бази даних, які ви можете використовувати як для OLTP, так і для фактичного навантаження даних для сховища даних. Альтернативи зазвичай використовуються в основному в аналітичних середовищах, і тоді, як правило, це визначається за даними, чому ми обираємо це, а не реляційне. Здебільшого люди цього не роблять.
Компанії, як правило, стандартизуються на одній базі даних. Нещодавно я натрапив на компанію, в якій було понад 5000 екземплярів Oracle. І я начебто, людина, з якою я розмовляв із цієї компанії, я начебто запитував їх про DBA. Вони сказали, що у них було близько 10 баз даних та близько 30 баз даних. А решта, Oracle просто використовувався як остаточна система. Дані із програм, які їх використовували, було дуже мало. Але це мене просто здивувало - 5000 екземплярів Oracle.
І, до речі, вони мали ліцензію на нерухомість Oracle. Ну, знаєте, корпоративна ліцензія, очевидно. Але вони також мали інші бази даних, оскільки інколи, знаєте, додатки постачаються з бажаною базою даних. Це було не так, як Oracle був єдиним. І варто зазначити, що ні Hadoop, ні Spark - це насправді база даних, і пройде ще багато часу, перш ніж вони придбають те, про що я думаю як правило бази даних. Звичайно, добре для посилань на дані.
З діяльністю DBA - напевно, Буллет може сказати про це набагато більше, ніж я, - але я просто пробіжу їх. Це те, що я схильний думати, ви знаєте, що робить DBA. Вони встановлюють, конфігурують, оновлюють, здійснюють управління ліцензіями. Вони так чи інакше роблять багато ETL та реплікації. Вони роблять сховища та планування потужностей. Вони займаються усуненням несправностей або є частиною команди усунення несправностей. Моніторинг та налаштування продуктивності - це майже велика частина їхньої діяльності, але все, що інше, це не мало, ви знаєте. Безпека, вони відповідають за резервне копіювання та відновлення. Вони повинні бути залучені до тестових систем програмного забезпечення, і вони можуть бути залучені до життєвого циклу даних.
Продуктивність. Коли я був одним із цих хлопців. Коли я працював і налаштовував бази даних, я так розумів це, знаєте? Є процесор, і так чи інакше в наші дні процесор нормально працює в режимі очікування, оскільки це було б одне з двох інших або другого. Ну, і одна з інших вузьких місць насправді викликала б проблему. Пам'ять, лущення та фрагментація, або насичення вводу / виводу диска, або диска, іноді накладні витрати на мережу, якщо ви працюєте в декількох вузлах мережі, і, можливо, ви могли зіткнутися з деяким блокуванням.
Але це був світ таким, яким я його бачив. Нещодавно я подивився на Oracle та кількість параметрів настройки, які є в Oracle. Це було понад 300. Ви знаєте, і якщо ви насправді задумаєтесь, то DBA, який дійсно знає, що він робить, повинен мати деяке уявлення про те, чому ви коли-небудь возиться з будь-яким із них. Значить, це складна робота, ви знаєте, і це складніше від цього.
Ви знаєте, зараз у нас є процесори, але у вас … процесори вже існували, процесори на процесорі або з FPGA на процесорі. Отже, відбувається своєрідне схрещування того, що відбувається насправді на процесорі. Процесори давно стали багатоядерними; насправді я більше не налаштовував бази даних, коли це сталося. Я поняття не маю, яка різниця це насправді, тепер, коли я думаю про це.
Ви знаєте, 3D Xpoint та IBM PCM з'являються як додатковий шар пам'яті, і у нас є SSD, але ви знаєте, вони замінюють спінінг іржі. Але SSD можуть бути різними в швидкості. Завдяки такій кількості ви можете мати паралельний доступ, і це змушує їх йти неймовірно швидко - близько до швидкості оперативної пам'яті. І у вас є всі паралельні апаратні архітектури.
І це все, ви знаєте, витрати падають, що справді приємна річ, але це все - ви знаєте, якщо ви берете наступний випуск бази даних і потім починаєте впроваджувати її на машинах, навіть деяких це, ви насправді втратили будь-яке відчуття кишки, яке ви можете мати за поведінку даних, тому що затримки просто дуже-дуже різні. І ось, ви знаєте, у вас чотири шари, а не три шари для зберігання.
Проблеми з базою даних. Ви отримуєте ентропію бази даних - поширені екземпляри дуже поширені. Бази даних, що використовуються як шафи, це те, що насправді був таким прикладом. Дуже мало баз даних налаштовується на самонастроювання, і ті, які претендують на самонастроювання, насправді не такі хороші, ви знаєте. Але інша справа, дуже мало баз даних налаштовано належним чином. Це важка робота, здатна збалансувати навантаження. Я маю на увазі, коли ви думаєте про базу даних, що може робити база даних протягом 24 годин, навантаження може бути дуже-дуже різною. База даних повинна мати особливо вірний сховище даних.
І отже, налаштування, яка не є тривіальною справою, ви знаєте, адже те, що ви робите, - це налаштування параметрів, які повинні задовольнити цілий спектр навантажень за певний момент часу. В основному це важка робота. І SQL потрібно налаштовувати спеціально для SQL JOIN. Знаєте, вони можуть бути надзвичайно трудомісткими. І якщо база даних має матеріалізовані погляди, якщо чесно, вам слід вивчити їх використання, оскільки вони зроблять все неймовірно швидшим. А для цього потрібен хтось, хто розуміє навантаження і розуміє трафік SQL і так далі і так далі.
І більшість компаній використовують дуже мало DBA - дуже дорого. Я знав досить великих компаній з, наприклад, трьома хлопцями, знаєте, величезною кількістю примірників. Дійсно, вони коштують багато, це складна робота з точки зору складності. Їм потрібні інструменти.
І я думаю, що це все, що я маю сказати. О так. Давайте передамо Dez, подивимось, що Dez має сказати.
Дез Бланчфілд: Дякую, Робін. Це масивна тема. Я збираюся дотримуватися тих речей, які, на мою думку, є щоденними проблемами, з якими ми стикаємося щодня. Оскільки давайте визнаємось, існує ціла бібліотека книг, написаних на цю тему. Хто не зайшов до технічної книгарні та не знайшов стін та стінок книг, написаних лише на загальну тему роботи баз даних та налаштування бази даних та моніторингу. І іноді це прекрасний спосіб вбити час.
Загальна тема: отримання запитів про ефективність. Існує ціла низка різних частин організації, які поглиблюють цю тему - на вашому кінцевому рівні, на моєму досвіді, ви знаєте, люди просто відчувають ефективність роботи, але все відбувається повільно. Спінінг-колеса потребують певного часу, щоб отримати запити, що повертаються. На протилежному кінці спектру у вас є люди з інфраструктури та мережевого та інженерного сховищ, яких б'ють фахівці з баз даних, оскільки все не працює так, як вони очікують. І це, на мій досвід, дуже широкий спектр речей, які можуть впливати на наше життя в цьому спектрі.
Якщо ви задумаєтесь, від фізичного вгору, ви знаєте, просто комп'ютерний простір. У вас є пам'ять, ви знаєте, оперативна пам'ять, якщо вам подобається - простір на диску, мережа та всі біти навколо цього. У цьому просторі у нас є, ви знаєте, він зберігає думку про те, що, скажімо, що, знаєте, краще використовувати необроблений диск або JBOD і просто, знаєте, підняти диск якомога швидше і дозволити базування даних впорядкувати рівень захисту даних. Інші люди є великими шанувальниками RAID, надлишкового масиву недорогих дисків, і мають різний релігійний досвід з RAID 0, 1, 3, іноді 5 і 6 різних типів зачистки або реплікації на диску, якщо жорсткий диск виходить з ладу. Навіть на рівні пам’яті та інженерному рівні все ж є люди, які мають різні погляди та досвід роботи, щодо типів пам’яті.
Чи це прямі підключені диски та самі сервери, чи підключений він через волоконний канал із мережею областей зберігання певної форми, чи це сховище, встановлене десь із сервера через iSCSI, чи це, наприклад, Ethernet. І це ще до того, як ви навіть дійсно дістанетесь до шару бази даних, де, знаєте, види речей, які ми приймаємо як належне - ви знаєте, просто підтримуючи це, як Ерік окреслив, ви знаєте, що ми називаємо розмову з вашими даними . Просто вміючи визначати закономірності та змістовні зразки, які, на нашу думку, ми можемо почати занурюватися і шукати проблеми ефективності.
І це дуже широка тема, тому я збираюся зануритися у дві сфери, де, за моїм досвідом, вкладений час та енергія та зусилля отримують хороші прибутки. Тож дозвольте мені швидко перейти до першого з них. І я лише напівжартома пішов шукати картину чогось, що мав скелет зсередини та шкіру зовні, але блок Лего був, мабуть, найменш жахливим. Але багато в чому я таким чином уявляю і подумки уявляю виклик, з яким ми стикаємося іноді з аналітичними платформами та базами даних, що їх підтримують. І це те, що ви насправді лише як споживач і кінцевий користувач або навіть розробник часто бачите шпонний шар шкіри, але це насправді скелет - це справді питання, на яке потрібно зосередитися.
Ви знаєте, що в цьому випадку, коли ми думаємо про те, що може вплинути на ефективність бази даних та аналітику в результаті цього конкретного дня, ефективність показів, основна інфраструктура та просто моніторинг цієї основної інфраструктури, і, як я окреслював лише мить назад, навколо ваш диск і пам'ять і процесор. І як підкреслив доктор Робін Блур, зараз виникають виклики у віртуалізації та речах, що відбуваються в самих чіпах, та продуктивності до основного рівня, а також об’єм пам’яті, який зараз вкладається у кожен чіп у кожному ядрі. Це дуже технічні виклики, на які слід звернути увагу повсякденній людині.
Продовжуючи моніторинг запитів. Ви знаєте, одне із завдань навколо моніторингу запитів і черг запитів, наприклад, я маю на увазі, що SQL як мова та інструменти бази даних, які є навколо інструментів аналітики, дуже потужні, і особливо SQL як мова. Але з цією потужністю і простотою в багатьох випадках також виникає, і це те, що якщо це не програма, яка робить те саме і знову і знову, написана хорошим розробником і помічена хорошим DBA, це може бути людьми, які виконують неструктуровані запити.
І проблема в цьому полягає в тому, що досить легко вивчити трохи SQL і почати робити запити, але в результаті цього вам не обов’язково мати всі навички та досвід та знання, щоб знати, чи займаєтесь ви добре чи погано робити базу даних. Тож постійне ведення тієї ж великої, широкої, неправильної може просто зруйнувати будівлю. Тримати моніторинг запитів - цікавий виклик.
Просто слідкуйте за часом відгуку на те, що робить платформа та що отримують користувачі. Знову ж таки, ви знаєте, без правильних інструментів це не те, що ви просто інтуїтивно дивитесь на річ і думаєте: "О, мережа працює повільно" або "Пам'ять користувачів не працює належним чином" або "Індекси працюють погано" "Або" здуття живота ".
І тоді, знаєте, як ви дістаєтесь до того пункту, коли ви, побачивши проблему з нею, як розірвати її та роз’єднати та вирішити весь виклик погано структурованих запитів? І, знаєте, це спеціальний запит про те, що хтось працює вручну, чи це інструмент аналітики з лицьовою панеллю приладової панелі, який працює погано, бо вони задають питання не так, чи це просто так, дійсно погано написаний фрагмент коду?
А потім, роблячи цей ітеративний порядок, Ерік сказав в початковому плані, ви знаєте, просто ітеративно перебираючи і знову і знову і точно налаштовуючи ці робочі процеси. Ви знаєте, які робочі процеси я запускаю, як вони запущені, як часто вони працюють, який код працює проти них, де вони працюють проти цього в процесорі та пам'яті, диску та мережі? Так, це просто справді, справді технічна проблема.
А потім нірвана, яку люди шукають у цьому світі, переходячи від історичної аналітики та налаштування ефективності та попереджуючи про своє оточення, що чудово побачити, тому що ви можете в майбутньому отримати план для цього, якщо знаєте, чому все пішло повільно вчора вранці о дев’ятій годині. Але це не допомагає вам зараз, і це не допомагає вашому плану рухатися вперед.
Я думаю, що планування потенціалу та розмір, а також масштабування та налаштування, так що ви знаєте, я думаю, що є тенденція, яку ми спостерігаємо зараз, коли спостерігається зміна дуже великих середовищ, де люди мають великі платформи баз даних і широко розповсюджені середовища баз даних. від історичного сповіщення та планування до прогнозного сповіщення та планування, де вони хочуть знати, що відбувається зараз, і мати можливість планувати його вперед. Або у нас не вистачає пам’яті, і ми збираємося втратити пам’ять у наступну годину, і що ми можемо з цим зробити? Яке планування потенціалу ми можемо зробити в режимі реального часу?
Перепрошую. Це доходить до того, що, ви знаєте, саме вся проблема виявлення цих перешкод перешкоджає по суті тому, що ми називаємо аналітикою рідини, і роблячи це нормою у вашій організації. Як бачите, це нетривіальний виклик для, як відомо, просто щоденних великих, немитих мас. І це все ще нетривіальний виклик для ще більш технічних кмітливості.
Ви знаєте, якщо простим смертним важко, як нам зробити це можливим? Тому що, ви знаєте, більшість із них є речами, які звичайні користувачі не можуть вирішити, і у нас можуть бути спеціальні інженери баз даних, розробники баз даних, розробники коду, програмісти, але вони все ще дійсно мають змогу відокремити середовище. Ви маєте роз'єднати, знаєте, такі питання, як люди, які повторно використовують код.
Ви знаєте, одне з найгірших речей, які я бачив у цьому просторі, навколо хітів про ефективність на платформах аналітики в дуже великих розгортаннях інфраструктури сервера баз даних, це люди, які беруть фрагмент коду, шматок SQL або вкрадену процедуру, яку вони не робили ' t пишуть, і вони не знають, хороший це чи поганий фрагмент коду, і вони просто повторно використовують його, оскільки це дає їм результат, який вони хочуть. Але виявляється, що це, можливо, було просто щось, що було написано на льоту, щоб отримати один-два результати, як звіт - хтось поспішав.
І тому люди використовують складний код, який вони не писали, і просто ляпають його в шматок розробки додатків, не знаючи, що вони насправді карають задній край. Навіть просто відстежуючи цей показник ефективності та дивлячись на те, звідки беруться запити, і, як відомо, це я щоденне завдання.
Основні поведінкові речі, такі як попередні показники даних для ефективності, де це можливо. Те, що просто переживає вас, лише навчить вас, як-от видалення індексів, якщо ви збираєтеся робити масовий імпорт, а потім повторно індексувати, щоб індекси не підтримувались, коли ви перетягуєте терабайти даних. Знаєте, без відповідних інструментів це майже неможливо побачити, оскільки ви не знаєте, що індекс забивається.
Оптимізація індексів - це на зразок 101, але що робити, ви знаєте, коли ви робите масовий імпорт або, знаєте, створюєте таблицю запитів, якщо хтось робить дійсно великий запит? Ви знаєте, це може бути величезним хітом продуктивності, і, знову ж таки, якщо ви не стежите за тим, у вас немає інструментів, щоб це бачити, це просто відбувається у фоновому режимі, і ви не знаєте, як його вирішити. .
Обмеження запитів лише кількістю потрібних вам стовпців - я маю на увазі, це звучить дуже просто, але якщо ви не бачите цього, ви не знаєте, що це відбувається, і тоді це просто відбувається на задньому плані, і це шкодить вам, на тебе.
Знаючи, коли і де використовувати тимчасові таблиці, створювати великі видалення та оновлення. Знову ж таки, все дуже прості речі, але без такої видимості, без інструментів для цього вони просто сидять на задньому плані і продовжують шкодити вам, і ви просто продовжуєте кидати більше пам'яті або процесора в середовищі бази даних, щоб отримати кращу ефективність платформи аналітики, коли насправді ви повинні мати можливість детально ознайомитись із тим, що вам шкодить, і вирішити цю конкретну річ. І тоді, знаєте, такі речі, як обмеження зовнішніх ключових питань, і як ви це знаходите, як ви навіть знаєте, що це проблема?
Це підводить мене до висновку мого ключового моменту тут, і це те, що ви знаєте, щодня ми бачимо ці проблеми всюди. Оскільки середовища баз даних стають все більшими, все більшими і більш широкими, і як доктор Робін Блор підкреслював тут, ми отримуємо все більш складні екологічні моделі з часом баз даних.
А потім ще й необхідність інтегруватися в деякі великі платформи даних, такі як Hadoop та Spark, які є разом, і все більше і більше за один раз. На мій погляд, нам потрібно знайти кращі способи та конкретні інструменти для розумної роботи цієї платформи в реальному часі та аналітики та діагностики. Тому що це коштує реального часу і реальних грошей і розчарування для кінцевих користувачів і реальних доларів, якщо ми не почнемо доходити до інструментів, щоб зануритися в ці речі.
І з цим я збираюся передати нашим друзям з IDERA, тому що я вважаю, що у них є гарна історія, щоб розповісти про те, як ми могли б вирішити цю проблему.
Bullett Manale: Звучить добре. Дуже дякую, і я буду продовжувати і розпочати справи. У мене тут також є кілька слайдів, і дозвольте мені продовжувати та щось підносити. Деякі з них ми досить швидко перескочимо.
Просто для того, щоб дати вам деяке розуміння, я директор відділу продажів тут, в IDERA, і тому, що ми робимо, це своєрідна розмова з DBA досить регулярно про болі та проблеми, які вони мають, специфічні для багатьох випадків, моніторинг ефективності та подібні речі, очевидно. І ми багато чуємо від цієї аудиторії, і тому я думаю, що я можу регулярно ділитися деякою інформацією, яку я отримую від них, і це матиме сенс. Я збираюся перескочити декілька з них, тому що я не думаю, що вони справді доречні для розмови.
Ви знаєте, у мене є власний перелік обов'язків DBA - він дуже схожий на список Робіна, і я думаю, що це досить послідовно. Я думаю, що коли ти розмовляєш з адміністратором бази даних, це завжди - ви знаєте, вони натрапляють на деякі з цих областей більше, ніж на інші, і для цього немає жодної рифми чи причини, це просто залежить від середовища.
Ви чуєте досить широке, широке коло речей, які люди хочуть зробити. І багато разів люди, які хочуть, щоб цього не зробили - вони попросять їх, а в деяких випадках ти починаєш своєрідно вивчати те, що вони насправді просять, а потім дізнаєшся, що вони ' ти дійсно шукаєш більше. Вони дійсно хочуть отримати більше інформації, ніж те, що вони спочатку думають, що їм потрібно, і коли ви починаєте свердлити в інструмент, я думаю, що саме тут ви можете почати говорити, що вони беруть розмову з даними.
І я думаю, що це справді цікава фраза, і вона має багато сенсу з точки зору можливості сказати, так, ну якщо у вас поганий запит, що насправді поганий запит? Це запит, який споживає багато читання або запису чи процесор? Це може бути той, хто багато працює, це може бути той, як ви сказали, погано написаний.
З точки зору того, як ми це визначимо, існує декілька способів, які ви побачите щодо нашого продукту - продукту «Діагностичний менеджер», який показує нам, що вони можуть зробити це. І це справді гнучко, і я думаю, що це одна з найважливіших речей - у вас повинен бути інструмент, який допоможе вам у вирішенні проблем із роботою, чи оточення у всіх трохи інше.
І буде багато, ви знаєте, потреб і, можливо, навіть незрозумілих вимог щодо моніторингу, тож вам доведеться мати щось гнучке і те, що буде працювати і бути здатним відповідати оточенню, яке ви намагаєтесь керувати. Ви знаєте, і у мене є багато таких прикладів - я не збираюся переглядати кожен з них, але вам потрібно щось, що ви зможете повертати назад і назад між однією інформацією та іншою, і я начебто поговоримо про це, коли ми трохи поглибимося в продукт і покажемо вам це, і з точки зору того, як ми це робимо.
Але інше, що я думаю, що стосується будь-якого хорошого інструменту аналітики, це, знаєте, є деякі основні речі, які ви дійсно шукаєте. Ви, очевидно, в першу чергу не хочете, щоб інструмент, який буде викликати власні проблеми з роботою в ім'я продуктивності. Коли я кажу, збирайте дані без затрат, я говорю не про витрати з точки зору, як ви знаєте, грошових витрат, а про витрати з точки зору накладних витрат та витрат з точки зору кількості ресурсів, які ми будемо використовувати в ім'я виконання. Ви обов'язково хочете, щоб щось там допомогло.
Вам потрібно щось, що зможе отримати дані, які ви шукаєте, для конкретних проблем, з якими ви стикаєтесь щодня, і можуть бути деякі речі, які вам не потрібні і які вам не потрібні " не хочу, і немає сенсу збирати ці дані, якщо ви ніколи не збираєтеся звітувати про них або не будете мати потреби в спробах керувати цими даними. Наприклад, з точки зору метаданих, пов'язаних з продуктивністю.
Ви знаєте, хороший приклад - мені не потрібно оповіщати, якщо служба Координатора розподілених транзакцій у SQL не працює, якщо я не хочу, щоб вона працювала в першу чергу. Тому не сповіщайте мене, не збирайте дані проти цього - мені ця інформація не потрібна. Отже, можливість увімкнути та вимкнути ці речі справді важливо.
Здатність також, коли ви збираєте дані, отримуючи доступ до них досить швидко - вам не потрібно, ви знаєте, запускати та масажувати дані, маніпулювати даними - бути в змозі зробити це швидко та ефективно. І тоді, коли ви отримаєте ці дані, очевидно, це дійсно важливо вміти їх розуміти.
Ось тут, з нашим - як, наприклад, продуктом Diagnostic Manager, який я сьогодні вам трохи покажу - цей продукт, ви знаєте, я хотів би сказати вам, що цей продукт збирається замінити та бути DBA у коробці. Реальність така, що вона потребує певних знань про те, що таке ваше оточення та що ви намагаєтеся досягти. Очевидно, що, мабуть, є розуміння ролі самої DBA, очевидно, важливо.
Тепер те, що ми намагаємося зробити, - це освіта за допомогою допомоги та інших методів. Але ви завжди хочете пов'язати це, очевидно, з певним рівнем досвіду або з кимось, хто має певні знання, що робити, як тільки вони отримали дані. І, можливо, мати людину, яка може задати правильні запитання продукту, і вести розмову з даними, очевидно, ключовим. І тоді, очевидно, зможете зрозуміти дані.
Після того, як я отримаю інформацію, зможу зрозуміти це потрібним людям. Мої розробники, моя операційна команда - хто б це не був, мені може знадобитися інтегруватися з іншими продуктами, маючи гачки, щоб це зробити. Це все реально важливі речі. І тоді, очевидно, не в останню чергу, якщо мені потрібно знати більше, будучи в змозі це зробити. Чи означає це ввімкнути ще трохи, на яке потрібно зібрати, чи означає це просто заглибитись у дані. Ви сподіваєтесь, що за допомогою інструменту, який буде, знаєте, допомагаючи у виконанні, ви отримуєте всі необхідні речі, щоб мати можливість відповісти на ці запитання.
Єдине, що я тут не вдягав, я вважаю, що, мабуть, варто зазначити, це те, що вам потрібен інструмент, який допоможе вам розрізнити те, що нормально, а що не нормально. І я думаю, що це велике, бо, знаєте, є тонна продуктів, які оповіщають, і речей, які там є, але якщо ви отримуєте сповіщення, і попередження є помилковим попередженням, це не приносить вам користі ; це більше марна трата часу, і це знизить вашу ефективність більше, ніж допоможе їм. Отже, ви знаєте, це я хотів би пам’ятати.
Коли я кажу про продукт, про який я пов'язую всі ці речі з пакетом продуктів IDERA, це продукт Diagnostic Manager, я думаю, що це, мабуть, основні характеристики в тому, про що ми говоримо тут, що стосується бази даних налаштування та ефективність, моніторинг та подібні речі.
Люди шукають моніторинг на рівні підприємств; вони хочуть мати доступ, мати можливість на одному екрані знати, що все працює так, як і повинно бути. Або вони хочуть мати можливість, очевидно, якщо є проблема, побачити, де проблема, а потім мати можливість розгортатися в ній. Думаю, справді велика частина того, що люди шукають, використовуючи такі типи способів, якими ви дійсно можете відточити свій виступ.
Інша річ, яка, очевидно, йде разом з цим, це те, що я не можу просто працювати в сьогоденні, і мені потрібно вміти повертатися протягом певного періоду часу, чи це означає перегляд запитів, які погано працювали, чи означає це, ви знаєте, дивлячись на те, як саме ведучий VM поводився з точки зору ресурсів. Всі ці речі, які ви повинні вміти робити, і ви не збираєтеся сидіти там, дивлячись на свою консоль 24 години на день, 7 днів на тиждень.
Якщо ви перебуваєте у відпустці, або це посеред ночі, або що б там не було, вам потрібно щось, що зможе повернутися у часі з вами, щоб мати можливість сказати, що відбувається в екземплярі в час у нас виникли проблеми. І можливість зробити це, ще раз, ефективно та швидко та мати змогу детально розібратися в цьому, безумовно, є важливою частиною з точки зору цієї дискусії. І я б сказав, що це, мабуть, одна з найбільш важливих речей з точки зору того, що люди шукають. Вони завжди шукають це вікно в минуле, тому що це насправді ім - знаєте, вам не хочеться сидіти там і чекати, що щось повториться.
Наступне, що в списку - це насправді просто прив’язання до того, про що ми говорили раніше, із самим виконанням запитів. І я покажу вам декілька різних прикладів продукту Diagnostic Manager, як ми це робимо, що, безумовно, наприкінці дня збирається запропонувати вам багато варіантів навколо самих запитів з точки зору того, що ти хочеш зібратися.
Що стосується того, чи цікавляться ви запитами, які викликають біль у ресурсах, споживання процесора або споживання вводу-виводу. Чи це запити, які потребують тривалого часу, або запити, які в цілому можуть бути не найгіршими з точки зору продуктивності, але можуть запускатися так часто, що сама частота запуску може бути проблемою. І очевидно, що здатність помітити тенденції з часом із цими запитами також є важливою частиною цього.
Існує багато різних способів, як ми можемо це зробити в цьому продукті, і я думаю, що це очевидно, що це справді важлива частина більшості DBA. І навіть якщо у вас немає власних внутрішньо розроблених додатків, все одно приємно мати можливість звернутися до своїх постачальників програмного забезпечення і сказати: «Ей, ти знаєш, що? Ви знаєте, дві години дня вдень, коли ця робота знімається ", або як би там не було, " це викликає це ваша програма, і нам потрібно було це виправити ". Тож навіть якщо у вас немає повного контроль над самим кодом, все одно приємно знати, коли виникають проблеми.
І тоді, знаєте, інша частина явно є більш ініціативною. Вміти бути першим, хто знає, вміти розуміти, коли виникає проблема. Щоб ви не тільки змогли бути першими, хто це знає, і ви можете виправити це, але у багатьох випадках, коли вам потрібно щось, що зможе автоматизувати відповідь, і в багатьох випадках. Ви можете, скажімо, знаєте, а не отримувати електронний лист із повідомленням: "Ей, вам потрібно це виправити", якщо я на зустрічі, або якщо я, знаєте, у дорозі чи що там я Я роблю, очевидно, дуже приємно сказати, що у мене є щось на місці, що зможе вирішити це в автоматизованому вигляді.
І якщо це не вирішується автоматизованим способом, принаймні, ви зможете бути першим, хто знає, щоб ви могли вжити коригувальних дій або звернутися до когось, хто зможе. Отож, це, очевидно, великі важливі склади для цих питань, з якими ви можете зіткнутися з точки зору моніторингу ваших машин та ваших примірників та самої аналітики.
Зараз я говорив про це раніше, що полягає у гнучкості речей. Я не можу наголосити на цьому достатньо, будучи в змозі сказати, знаєте, поза межами коробки, якщо є щось, що не контролюється, мати можливість функціонувати в продукті, щоб мати можливість додавати ці речі до слідкувати. І в сенсі на прикладі Diagnostic Manager, ми, очевидно, знаєте, WMI лічильники, лічильники, лічильники SQL Server, ви можете створювати власні запити.
Ви навіть можете, якщо ви хочете, витягувати дані з вашого середовища vCenter або з середовища Hyper-V в результаті опитування, яке проводиться, і ви можете це робити, регулярно, і витягніть ці дані та зможете їх переглядати. І, знову ж таки, переведіть з одного місця на інше, переглядаючи цю інформацію.
Тож це такі речі, які, з точки зору того, що я бачу, люди запитують, коли вони говорять про інструмент, який допоможе їм у налаштуванні та продуктивності - продукт, який я збираюсь показати вам лише друге - Diagnostic Manager, і він підтримує все, починаючи з 2000 року, аж до 2016 року. Це специфічно для SQL Server, тому ми контролюємо управління цими речами. Немає агентів на самих екземплярах, які контролюють екземпляр.
Це повертається до збору інформації за невеликі витрати, що, знаєте, ми намагалися, очевидно, більше збирати цю інформацію, а також не використовувати багато ресурсів, чи не так? Ми намагаємось використовувати ті речі, які вже надає нам SQL Server, і покращуємо їх, будь то динамічні погляди на управління, чи це розширені події, або будь-який випадок, що стосується самої колекції. Вміння використовувати цю інформацію та покращувати її - це один із наших мандатів.
Тепер, якщо ви швидко переглянете це справжнє, я не збираюся надто детально переглядати архітектуру, але маю резервне сховище з усіма нашими історичними даними, якими ви можете керувати, і ви зможете зберігати так довго, як ти хочеш. Ви навіть можете вибрати тип інформації, який хочете зберегти, і на який термін. Це повертається до цього, збираючи відповідні дані та залишаючи зайві дані. Якщо ви хочете зберегти запити протягом п’яти днів, які є основними, а потім тримати сповіщення протягом двох років, це залежить від вас, і це абсолютно ваша прерогатива в змозі це зробити.
Кілька різних консолей із цим виробом. У вас є веб-версія, у вас є і товста клієнтська версія. Отож, маючи гнучкість стрибати з браузера і бачити, що відбувається, або якщо у вас ноутбук, де встановлений спеціальний клієнт, будь-який із цих підходів буде працювати для вас.
Тепер я хочу зробити швидку демонстрацію. І я хотів би зазначити - я повертаюсь до цього іншого слайду тут - що у нас є, ми щойно додали, як FYI для тих, хто знайомий з продуктом, у нас є нова пропозиція, яка є Діагностичний менеджер Pro. Професійна пропозиція, яка включає в себе те, що ми називаємо Аналіз робочого навантаження.
І насправді йдеться про можливість інтерактивного перегляду дуже великих періодів часу та переходу від цього, знаєте, 30-денного перегляду до, знаєте, п'ятихвилинного перегляду приблизно за три кліки. І, будучи в змозі побачити сплеск продуктивності або проблему в вузькому вузі, яку ви могли б мати, знаєте, ви могли б бачити на дуже високому рівні і бурити до дуже низького рівня. І тим більше, що і сьогодні, це новинка у продукті.
Але те, що я хочу зробити, це лише такий собі перший початок, і я хочу трохи поговорити про те, як рухатися вперед і назад. І я привів приклад, і я збираюся поділитися на екрані тут. І, побачимо … Ось ми і підемо. Мій екран. І дайте мені знати, хлопці, що ви можете це бачити.
Ерік Кавана: Ось ти.
Bullett Manale: Там все гаразд? Добре. Отже, на що ти зараз дивишся - а це продукт Diagnostic Manager - і я просто хотів дати тобі якусь високу демонстрацію того, що тут відбувається. У цьому конкретному прикладі ми показуємо запити, пов'язані з очікуванням. І тому, коли я говорю про те, щоб можна було повертатися вперед і назад, прокручуватися глибше і поворотно, то ось цей погляд є хорошим прикладом цього. Я можу перейти з виду часової шкали, як ми бачимо тут, який зараз відображатиметься. У нашому випадку ми розглядаємо самі очікування та категорії самих очікувань. Ми можемо бачити заяви, які прив’язані до тих очікувань, ми можемо побачити додатки.
Зверніть увагу, що це переглянуто на часовій шкалі, тому я можу визначити цю інформацію лінійно виходячи з того, коли сталася проблема, але потім ще раз, якщо я хочу просто, ще раз, повернути, і я кажу: "Ви знаєте що, давайте подивимось це з іншого погляду, "давайте продовжимо та розглянемо це з точки зору:" Я хочу побачити запити чи очікування чи програми, які викликають у мене найбільше болю, і класифікувати їх ". І це ми" Подивимось на "запит чекає за тривалістю". Зараз ми бачимо самі програми, які заподіюють мені найбільше болю, або ж чекають.
І ось, ось частина, яка справді є найважливішою, - це здатність ізолювати ці речі. Я бачу, що ця програма NoSQL починається тут. Це викликає у мене велику кількість часу очікування, а також за 25 секунд часу очікування в цьому 30-хвилинному вікні, в яке ми розглядаємо. Тоді я можу ізолювати цю програму, і я бачу твердження в цьому випадку, які безпосередньо впливають на цей конкретний екземпляр.
І тому це лише один приклад того, як ви змогли б визначити вузьке місце, змогти класифікувати інформацію, маючи змогу визначити пріоритети питань, які потребують вирішення першими. Це все, що вам слід врахувати. Знаєте, ви можете вирішити проблеми протягом усього дня, але якщо ви вирішите проблеми, які знаходяться внизу списку, які потрібно виправити, то ви витрачаєте свій час. З вами пов’язана альтернативна вартість.
Наведу ще один приклад, і це трохи інший приклад. Замість того, щоб конкретно вказувати на проблему чи вказувати на область, вам також потрібен інструмент, який зможе допомогти вам у широкому розумінні, щоб можна було сказати: "Ей, чи були у нас проблеми?" Чи "Чи є речі, які я можу зробити, щоб покращити продуктивність? "і щоб щось позаду було, спостерігаючи за тим, що відбувається. І в цьому випадку це може бути пов’язано з конфігурацією; це може бути пов'язано з, знаєте, способом управління здоров’ям самого екземпляра. А також, очевидно, і продуктивність.
Якщо я перейду до цієї кнопки «Аналіз» тут, то я збираюся вам показати, що в цьому продукті ми також маємо проактивний перелік речей, які можна виконати в ранжированному форматі, який, по суті, дасть вам зрозуміти в ті речі, які, ймовірно, можуть збільшити вашу ефективність у цьому випадку або збільшити стан здоров'я цього екземпляра. І це в ранжированному форматі, в тому сенсі, що ви маєте можливість бачити, які з них мають більше шансів покращити вашу ефективність для певного типу проблеми, яка була визначена.
І тому, коли я дивлюся на ці речі і виявляю їх, я не тільки бачу, що у мене є проблема, і у багатьох випадках є сценарій, який можна автоматично створити, щоб вирішити цю проблему. Але у багатьох із цих випадків у нас також є зовнішні посилання, які стосуються типу проблеми, з якою ми стикаємось, і тоді, чому ми також даємо цю рекомендацію, тож ви отримаєте такий освітній аспект. Що, ще раз, я думаю, що це дуже важливо, коли ви говорите про, ви знаєте, вирішення проблем.
Я не хочу сліпо слідувати цим рекомендаціям, я хочу зрозуміти, чому ці рекомендації робляться. І я, можливо, я старший DBA, який займається цим протягом 30 років, і мені потрібно щось, що ви хочете, знаєте, перевірити - або розставити крапки і перетнути т у цьому випадку - або, можливо, я молодший DBA і Мені потрібно трохи допомогти в розумінні цих проблем, як вони трапляються, і чому ці рекомендації виконуються.
Як я вже говорив, я просто збираюся провести вас через кілька різних частин продукту. Цей інструмент існує, ви знаєте, він існує з 2004, 2003 рр. І в ньому дійсно багато розроблено, багато інформації, тому не було б сенсу намагатися показувати вам все тут. Але я думаю, що одне з речей, про що варто звернути увагу, - це те, що, коли ми заходимо, і ми починаємо говорити про всі речі, які ви можете відстежувати, і про все, про що можна попередити, ще раз повертаючись до цієї гнучкості речей, ось перелік усіх елементів, які ми відстежуємо.
Тепер це не обов'язково означає, що я хочу вважати, що ці речі знаходяться в стані тривоги, якщо вони виходять з удару з точки зору порогу, тому ви можете вмикати та вимикати ці речі. Це повертається до того, що: «Ей, мені потрібно робити певні речі за певними показниками. Мені потрібно лише знати, попередити про певні проблеми. "І бути в змозі переконатися, що ми не збираємось насичувати вас купою помилкових позитивів. Ви не тільки маєте можливість вмикати та вимикати ці речі, але у багатьох випадках ви помітите, що ми також надаємо таку смугу нормальності, яка стосується кожної метрики. Отже, якщо я дивлюся на цю конкретну, в даному випадку базову лінію, я помітив би, що поріг, ймовірно, вище, де вони зараз є.
З іншого боку монети, що робити, якщо у мене є екземпляр SQL, де я відстежую деякі показники та ці показники, з якої причини, встановлені вами пороги, є невірними? Іншими словами, пороги - це дамб в середній частині місця, де фактично сидить базовий рівень, а це означає, що якщо у мене буде попередження, прив'язане до цього порогу, я, ймовірно, отримуватиму попередження про щось, що є звичайною подією. І тому в таких ситуаціях ми можемо дати вам це розуміння і в усьому світі.
Для всіх показників у цьому конкретному випадку я бачу ті пороги, які, ймовірно, виявлять помилковий позитив тут з точки зору того, що нормально, а що ні. Це буде щось, що вважатиметься більшою мірою звичайною справою використання на пам'яті, і якщо я хотів би підвищити цей поріг, я міг би, але така ідея з базовими лініями.
І класна річ щодо продукту Diagnostic Manager з точки зору самих базових ліній - це можливість встановлювати кілька базових ліній. І ви можете запитати: "Чому я б це хотів робити?", І відповідь - ну, якщо у вас є вікно технічного обслуговування, яке працює, скажімо, з півночі до 4 ранку, де ви справді оподатковуєте свої ресурси, ви ти справді використовуєш ресурси якнайбільше, тоді ти хочеш ще раз перейти, і ти хочеш трохи повозитися і сказати: "Дивись, ми будемо змінювати свої пороги для цього". І ми можемо насправді динамічно коригувати наші порогові показники, зокрема, до того, в якому базовому рівні ми опинимось, залежно від часу дня або дня тижня тощо. Тоді воно буде динамічно коригувати ці пороги для нас.
Зробимо крок ще раз. Після того, як ми визначили ці пороги, як тільки ми їх пройшли, і, з точки зору налаштування сповіщень та сповіщень та ознайомлення з цими ситуаціями, які можуть трапитися, знову ж таки, гнучкість тут першорядна. Ви хочете мати можливість насторожити в конкретних ситуаціях. В інших ситуаціях ви можете надіслати електронний лист комусь іншому, ви можете запустити сценарій PowerShell, можливо, ви знаєте, список продовжується.
Я, можливо, захочу інтегруватись із чимось через SNMP пастку або навіть безпосередньо з, наприклад, SCOM. Справа в тому, що у вас є можливість зробити це, і ви можете встановити будь-які типи умов, які б гарантували, що, будь то дуже широкомасштабний стан - ви знаєте, мій процесор і пам'ять або будь-які інші ресурси - в усіх моїх випадках або, можливо, у мене є дуже специфічний тип речей, за якими я хочу відстежувати, тому що, коли я виявляю, що ми порушуємо, я хочу запустити дуже конкретний та спрямований сценарій на цю проблему. Тож саме тут ви могли б робити такі речі всередині продукту Diagnostic Manager, просто, ви знаєте, з точки зору оповіщення та сповіщення та бути здатними бути гнучкими з цього погляду.
Тепер я не буду проходити через усі насторожуючі та всі ці хороші речі. Я хотів поговорити про звіти. І, знову ж таки, можливість приймати інформацію та використовувати ці дані різними способами - і це знову повертається до розмови з вашими даними. І дуже багато людей, коли вперше бачать цей продукт, думають: «О, ну, у мене буде інструмент, який буде попереджати мене про проблеми. Це те, що мені потрібно ». І реальність полягає в тому, чи потрібен їм цей інструмент? Але інша сторона цього полягає, якщо вони дійсно є - їм також потрібен інструмент, який допоможе їм приймати рішення, і вони можуть використовувати цю інформацію, яку ми збираючи в ім'я ефективності, а також в ім'я попередження, щоб можна було допомогти вам приймати рішення по дорозі, рухаючись вперед.
Знаєте, хорошим прикладом можуть бути мої прогнози зростання в моїй базі даних. Якщо у мене є конкретна база даних, яка зростає, я можу вказати на цю базу даних або навіть на декілька баз даних, щоб можна було побачити, які показники росту. Ми не показуємо вам те, що ви знаєте, що це сьогодні; це буде прогнозувати це, виходячи з минулого зростання, який ми пережили.
Якщо у мене тут є декілька баз даних, які у мене є, уявіть це, - я міг би зайти і сказати: «Давайте візьмемо останній, знаєте, рік вартості даних, давайте співставимо це по місяцях і за вибіркою швидкість місяців, давайте продовжимо і подивимося, який ріст ми будемо спостерігати в найближчі три роки, або 36 одиниць. "У цьому випадку ми можемо дуже швидко відповісти на це питання. Тепер спробуйте зробити це самостійно, правда? Спробуйте це зробити за стільки ж часу, як я зробив це самостійно. Це займе у вас час.
Тепер, щоб ще більше наголосити на цьому, давайте візьмемо ще один звіт, який є моїм звітом про найкращі сервери. Уявіть, у мене є сто виробничих примірників, чого в цьому випадку я не роблю. Але якщо хтось приходить до мене і каже: «Мені потрібно, щоб ти мені сказав - ми збираємося поставити цю нову базу даних для цього чудового нового додатка; це змінить все, як ми це знаємо; це зробить життя таким чудовим. О, до речі, сама база даних буде насправді інтенсивною введення-виведенням, або це буде інтенсивним процесором, або дійсно великим обсягом пам'яті … ", як би там не було заповнення, я хочу зможете побачити всі мої виробничі екземпляри, де є сенс розміщувати цю базу даних? І я можу класифікувати всі мої екземпляри один проти одного за умовами типу, будь то процесор, пам'ять, диск чи будь-який інший випадок. І тому справа тут у тому, щоб ми змогли швидко та ефективно відповісти на це питання та прийняти правильне рішення, а не здогадуватися, коли ти це робиш - все це, очевидно, справді важливо, і тобі потрібно щось, що допоможе тобі.
І коли ми говоримо про аналітику, вона може варіюватися від будь-чого, як про те, про що ми говоримо при плануванні потужностей, і до, знаєте, попереджень, з якими ви працюєте щодня, які можуть мати справу з процесором, як а також, очевидно, самі запити, чи є блокування та інше тощо.
Іншим прикладом цього може бути, якби я зайшов сюди до відділу адміністрації - насправді я повертаю його назад, розділ оповіщення тут - запитую депозитарій нашої історичної інформації про речі, що відбувалися в минулому. Чи було у мене блокування, яке відбулося в моїх виробничих умовах? Я не знаю, давайте дізнаємось.
Я можу повернутися до свого виробничого тегу і можу сказати, для всіх моїх виробничих примірників, з огляду на будь-який період часу, для будь-яких показників, які я хочу визначити. Якщо я перейшов у стан сповіщення, у нашому випадку, скажімо, блокування підрахунком, а не секундами блокування, і я можу повернутися назад і, у цьому випадку, кілька місяців, якщо мені потрібно - або в цьому випадку, один місяць - і я бачу це блокування. Я бачу, коли він розпочався, я бачу, коли він закінчився, і я можу перейти до будь-якого з цих інтервалів тягнення, якщо потрібно, щоб побачити специфіку блокуючого інциденту в собі. Вам потрібно вміти щось дуже швидко, вміти знайти те, що вам потрібно і шукати, а не крутити багато циклів, щоб це зробити. І так, я думаю, що це теж важливо.
Останнє, що я хочу вам показати - і показавши вам цей продукт, продукт Diagnostic Manager - це, як я вже згадував, ми ввійшли, і ми додали ще один компонент до нашого SQL Diagnostic Manager Пропозиція І ось компонент аналізу навантаження. І це веб-версія цього, в даному випадку, що ми тут вам показуємо. Але суть у тому, що це дозволяє переглядати дійсно широкий проміжок часу або дуже специфічне вікно часу, і, знаєте, кілька кліків змогли побачити код, безпосередньо пов’язаний з проблемами, які могли статися .
Як приклад цього, якщо я дивлюся на перегляд чотирьох тижнів, тут я бачу, як тут, всі стрибки щодо баз даних та їх роботи та де ми бачили активність очікування на цих базах даних. Тепер, і ви можете побачити, якщо я бачу тут шип, користь цього інструменту саме в змозі виділити цю маленьку смужку саме там. А потім, коли я це роблю, всі речі тут змінюються. Ми змогли б побачити бази даних, ми змогли б побачити всі команди прив’язані до того, що знаходиться за цією смужкою.
Те саме, якщо я сказав: "Давайте подивимось на останні чотири години", а не на останні чотири тижні. Я все ще можу це зробити. Я все ще можу виділити той проміжок часу, а потім звідти - ось, ще раз, ось мої основні моменти - всі ці речі тут я можу пов’язати. У найпопулярніших операторах SQL я бачу ті запити, в цьому випадку, які викликали очікування, пов'язані з споживанням процесора. Тільки за допомогою буріння я можу побачити ті запити, пов'язані тут - whoops - і я також можу побачити програми і те, що не пов’язано з цим.
Ви отримуєте багато розуміння тут, і не тільки це, але ви можете бачити, коли ви опускаєтесь до рівня команд, це розповість вам речі. Він розповість вам, чи бачить він важких операторів, потім ви зможете переглянути плани виконання. Це займає небагато часу, тому що завантажувати цей досить масштабний. Але суть у тому, що у вас є багато різних способів перегляду даних, бачення того, що ви шукаєте, а потім, очевидно, зможете вжити заходів звідти, як вам потрібно, так, і цей приймає довше, ніж зазвичай, тому я залишу це.
І тому з цим сказаним я збираюся передати це назад. І, сподіваємось, це була гарна демонстрація роду речей, про які ми говорили. І як я вже говорив, сам продукт, який ми використовували для наведення цих прикладів, існує досить давно, і так багато інших речей, про які ми могли б поговорити і показати вам, але якщо це щось цікавить Ви завжди можете зайти на наш веб-сайт, завантажити його та пограти з ним.
Ерік Кавана: І мені подобається, що ти показуєш всю цю деталь. Якщо ви повернетесь до декількох екранів - навіть цей екран досить хороший. Тому що існує так багато різних способів візуалізації того, що насправді відбувається, і я думаю, що це один із найбільш недооцінених аспектів обчислень в наші дні. Це, безумовно, середовище баз даних, в чому я маю цей напівжарт. Я кажу: "Ми все ще вчимося говорити кремній". Ми все ще вчимося розуміти, як бачити, що відбувається, і на вашу думку, який було дуже добре сприйнято, вам потрібно вести цю розмову з даними, щоб краще зрозуміти, що відбувається, чому все йде повільно, тому що існує стільки можливих проблем. І, звичайно, IDERA отримала низку різних продуктів, один з яких - це старі точні продукти, які, на мою думку, можуть поздоровитись із цим.
Але, можливо, Робін, я перекажу це вам на пару запитань, а потім Дез, пару питань від вас, а потім, можливо, хтось із аудиторії, не соромтеся. Надішліть їх зараз.
Bullett Manale: Робін, ти йдеш на звук?
Робін Блор: Так. Добре, я просто знімаю звук із звуку. Треба сказати, це неймовірно - те, що насправді вразило мене найбільш драматичним щодо цього інструменту, адже це насправді - особливо зважаючи на те, що цілком очевидно, що ціла серія вимірів, яку ви просто не входили, - річ, яка насправді, Я думаю, що найбільше вразило це, це, мабуть, дійсно, дуже гарний спосіб тренувати DBA. Ви знаєте, це - тому коли ви вперше займаєтесь роботою з базою даних, і ви насправді мало знаєте про те, що відбувається насправді в базі даних, насправді дуже важко зрозуміти. Так це багато використовується, спеціально для тренувань? Я б цим скористався.
Буллет Манале: Так. Я маю на увазі, коли ви говорите, що тренуєтесь, ви маєте на увазі щось на зразок тренування, яке не відбувається, як щось, що стосується DBA, так? З точки зору …
Робін Блор: Так, так, так, так. Засіб навчання. Ви знаєте, a.
Bullett Manale: Так, я б впевнений, що це так, і тим більше, що ми додали це, компонент Analyse, який ми вам показували раніше, який має всі рекомендації, які пов'язані з ним. Але я впевнений, що ви знайдете, як допомогу, так і безліч різних областей у продукті, це дасть вам багато розуміння. Багато інформації.
І реальність, як я вже сказав, ви можете використовувати це, якщо ви не DBA. Ви, ймовірно, будете робити якісь пошуки Google і подібні речі, просто до загальних знань про те, що має більшість DBA, але ви можете це співвіднести, і це, безумовно, допоможе вам у плані: ця річ називається фрагментацією? "або" Чому цей запит працює 6000 разів? "Я маю на увазі, тому що ці речі будуть піднесені до вас, і вони заграють, і ви їх побачите. Ви побачите, що ви знаєте, що нормально, а що ні. Ви побачите речі, які шиплять, і речі, які ні.
Як правило, ми намагаємося налаштувати цю річ як з точки зору найкращих практик. Так що, коли ви вказуєте його на екземпляр, він покаже вам речі, які визначені як поза найкращими методами. Я маю на увазі, звичайно, ви знаєте, реальність така, що найкраща практика - це найкраща практика, і це не завжди реальна практика. Але, знаєте, він покаже вам люди, що випадають, навіть з початкової точки, що ви встановите його, і вкаже на екземпляр.
А потім звідти ви можете рухатися далі, як вам потрібно обов’язково виправити проблеми та визначити, чи справді це проблема чи щось, що зазвичай відбувається щодня. І тоді, тому що у вас є багато інформації на допомогу та рекомендації, так, абсолютно.
Робін Блер: Добре. І ще одне питання - але я впевнений, що відповідь на це дуже швидкий - полягає в тому, що у вас є деталізація, щоб перейти безпосередньо до індивідуального запиту та окремої точки часу і подивитися з цього виміру, .
Bullett Manale: Звичайно, так. Залежно від того, що ви хочете зробити, ви можете подивитися на однохвилинне вікно часу або на триденне вікно часу або, знаєте, тритижневе вікно часу. І, знаєте, як я вже сказав, це залежить від того, як ви хочете переглянути дані, а також того, що ви хочете збирати. У деяких випадках ми збираємо лише запити, які досягають визначеного вами порогу. В інших випадках ми можемо зібрати, знаєте, кожен запит, який викликає очікування.
Але ви також маєте можливість сказати: "Подивіться, ці пороги, які я визначив, можливо, це просто для запису, а може, це просто для читання, а може, просто для процесора". Отже, якщо припустити, що він перевищив цей поріг, то це Тоді, які часові рамки ви хочете переглянути, ви зможете побачити ті запити, які ображають, виходячи з того, що ви вважаєте правопорушним.
У вас є багато різних способів перегляду даних. Ви можете подивитися на це в зведеному вигляді, щоб побачити, знаєте, запити, які - скільки за лаштунками запитів розпочалося, і, начебто, кожен інцидент цього запиту починається, щоб переглянути шаблон, якщо ви буде, щоб побачити, чи постійно погіршується.
Але, щоб відповісти на ваше запитання, ви можете точно вказати, в який час ви хочете. У вас є ця історія під назвою «Веб-переглядач», і я її трохи використовував, але в основному в будь-який момент часу, який ви вибрали, незалежно від того, який день у вибраному вами календарі, ви можете перейти безпосередньо до цього моменту.
Зараз я дивлюсь 15 листопада о 19:05, і ми можемо переглянути запити, характерні для того часу. Якби у мене було щось, що працює погано, враховуючи це вікно часу, ми змогли б переглянути деталі сеансу, характерні для цього вікна часу, щоб побачити, які сесії працюють. Я маю на увазі, тут є цілий ряд даних, і, як я вже сказав, найважча частина насправді - це, можливо, 30 хвилин гри з консоллю і придумування, як це зробити.
Але як тільки ви визнаєте, що більшість даних тут знаходиться на цій стрічці, і вона розділена цими вкладками, і кожна вкладка має свій набір динамічно змінюються кнопок, які з’являються щоразу, коли ви натискаєте на неї, то чи дивитесь ви на реальні- час або речі, які відбулися минулого тижня, це той самий процес. По суті, я зараз дивлюся 15 листопада, але я можу так само легко подивитися на реальний час, просто натиснувши цю кнопку. І я збираюся так само взаємодіяти з даними.
Але, щоб відповісти на ваше запитання, так, існує багато різних способів перегляду історичної інформації, що стосується і самих запитів.
Робін Блор: Я бачу. Це дуже вражає. Мені подобається те, що вікна синхронізуються, навіть якщо це стає вкрай необхідним у всьому, що має справу з даними в режимі реального часу.
Буллет Манале: Так. Звичайно.
Робін Блор: Ось лише інформація, на яку я фактично не знаю відповіді. Як ваші пропозиції - SQL Server та хмара - чи можете ви вказати на хмару під Ratio?
Bullett Manale: Можна. Ви можете вказати це під хмару. Коли ви фактично додаєте екземпляри, він запитає, чи це RDS або Azure. Тепер існують певні обмеження, виходячи з того, що потрапляє до нас із хмари, тому може бути - є дещо різниця в плані того, що ми можемо контролювати, просто тому, що інструментарій, в деяких випадках, не є ми не збираємося, базуючись на тому, що викриває Microsoft.
Тепер, якщо це щось на зразок, знаєте, інфраструктури як платформи, наприклад, ви знаєте, або EC2 чи щось подібне, це зовсім не проблема. Ми отримуємо все. І як ми працюємо з Microsoft, так і з Amazon; ми працюємо над тим, щоб розкрити цю інформацію більш детально. Але абсолютно так, ми підтримуємо ці середовища.
Робін Блор: Гаразд, це цікаво. Що ж, я передам Дез, який, я впевнений, підкаже вам запитання з іншого напрямку.
Bullett Manale: Гаразд.
Дез Бланшфілд: Дякую. У мене є два дуже швидких для вас. Я думаю, ви знаєте, перше - це ваги, ви знаєте, я думаю, що одна з речей, яка мене вражає, - це те, що загальна тема вистави, як правило, є те, про що ми думаємо, коли отримуємо дуже великий, дуже великий, дуже масштабні та широкі та терабайти даних. Переглядаючи демонстрацію, мене це вразило так, що це те, що насправді стосується навіть дуже маленьких середовищ, начебто просто отримуючи хіти на продуктивність.
Яке поширення ти бачиш у поглинанні цього, і ти вважаєш, що це, знаєш, ти вважаєш, що це інструмент, який має добро? Знаєш - по-моєму, це робить, тому я думаю, що це так - але я просто хочу бачити те, що ти бачиш. Менші організації ведуть однакові розмови та шукають інструмент для цього, чи це справді щось на великому кінці міста?
Bullett Manale: Це смішно - це хороше питання. Це трохи змішування, але я б сказав, що у нас є маса маленьких клієнтів. І коли я кажу маленьким клієнтам, я маю на увазі, ви знаєте, один-п’ять примірників покупок, які мають ліцензію на управління. Тепер, у деяких випадках, у них може бути 30 екземплярів SQL, і вони дійсно дбають про п'ять справді, дуже важливо, щоб вкласти кошти в такий інструмент для цих п'яти примірників.
Але реальність полягає в тому, що навіть у менших магазинах у вас є купка SQL серверів. У більшості випадків, або у багатьох випадках, цей маленький магазин дуже і дуже залежить від цих баз даних через те, що ви знаєте, чим вони займаються. І щоб вони цього не зробили, вони не можуть відпустити це. Вони не можуть, знаєте, вони повинні мати інструмент.
Інша сторона цієї монети полягає в тому, що в деяких з цих менших магазинів вони не мають спеціальних DBA, тому хлопець, який найрозумніший хлопець у кімнаті, або більш технічний хлопець у кімнаті, нарешті, присвоюється DBA. І тому в цій ситуації вони, безумовно, шукають певної допомоги, і цей інструмент, очевидно, допоможе їм і в цьому плані.
Що стосується ваших великих середовищ, тому що я думаю, що про це згадував Дез - або Робін, я не впевнений - але, знаєте, більш широкі середовища, ви здивуєтеся, скільки у них є DBA, я маю на увазі Ви знову говорите про величезну кількість екземплярів SQL, і у вас є буквально жменька DBA, на які покладено відповідальність за них. І тому з цієї точки зору, хлопці, знаєте, шукають певної допомоги, оскільки вони не мають достатньо ресурсів, щоб реально допомогти їм, і тому інструмент допоможе компенсувати щось із цього.
І тому ми бачимо, що зовсім небагато, де, знаєте, у вас є троє хлопців, які керують 200 екземплярами. І тому ви можете уявити логістику цього, якщо у вас немає такого інструменту, спробувати розібратися, коли навіть є проблема. Це не буде проактивним шляхом, запевняю вас. Тож сподіваємось, що це відповість на ваше запитання. Так.
Дез Бланшфілд: Так, так. Мене це вразило - і я думаю, що Робін на це натякав - але, знаєте, таке обіцяння, яке ви описуєте, коли ви робили демонстрацію, я маю на увазі, що вони не виняткові для дуже великих середовищ. Ви знаєте, що ви можете придбати загальну платформу, що не використовується на постійній основі, розроблену для однієї речі, і помістити її в спільне середовище бази даних для чогось іншого, і це просто покарає все середовище.
Інше, що мене вразило - це не стільки питання, а лише спостереження, але я приведу це до питання, - але це те, що ви знаєте, коли організації вже зробили інвестиції в свою інфраструктуру та платформа та їх база даних, сервери та інфраструктура навколо цього, і вони збираються придбати продукт, який би він не був - HR, ERP, інструмент BI - вони вже зробили досить великі інвестиції.
Яку відповідь ви бачите, коли ведете розмову з людьми, і вони зрозуміли, що у них є виступ, але тепер вони відчувають, що їм потрібно зробити ще одну інвестицію? Чи є момент, коли вони, коли ви демонструєте це, усвідомлюють, що це ця річ, як непродумана, і це не стільки крок продажів, скільки скоріше епіфанія. Ви просто знаєте: "Ми негайно будемо отримувати користь від цього". На відміну від того, щоб продати товар? Мені здається, що вона продається сама, а рентабельність інвестицій просто стрибає зі сторінки.
Bullett Manale: Так, і це смішно, ви говорите, що тому, що багато разів трапиться, це те, що хтось, як DBA або навіть представники продажів, прийде, і вони скажуть: "Гей, ці хлопці хочуть дивіться на зразок аркуша рентабельності інвестицій на цьому. "І більше схожого на щось, на папері, що ми їм надішлемо. І демонстрація завжди в 10 разів краща, тим більше, що ви можете зробити це з самими DBA, тому що:
Дез Бланчфілд: Так.
Bullett Manale: Як ви вже говорили, товар продається сам. Насправді важко поставити рентабельність інвестицій на аркуш паперу і сказати: «Гаразд, скільки кліків зазвичай DBA зазвичай, ви знаєте, клацніть за годину?», Як це стосується резервного копіювання, ви знаєте, або будь-якого випадку., ти знаєш? І намагаючись покласти це на аркуші паперу, це зробити насправді важко. Але коли ти дістаєш когось і показуєш їм товар, і вони його бачать, це саме те, що ти сказав.
Люди усвідомлюють цінність цього. Тому що це не тільки допомагає їм зрозуміти та приймати кращі рішення, але це також, це допомагає, знаєте, вони не бути поганим хлопцем. Вони можуть бути першими, хто це дізнається; вони можуть виправити проблему до того, як вона навіть колись виявить, що виникла проблема.
Інша частина цього полягає в тому, що ви знаєте, як DBA, будь то, знаєте, реальне чи сприйняття - і я думаю, що це сприйняття - ви справді володієте проблемами продуктивності. Ти той хлопець, який вказує на тебе пальцем, коли продуктивність знижується, і реальність така, що це може бути саме розробником, який справді викликає проблему.
Маючи інструмент, щоб можна було сказати: «Ей, це не моя проблема, я повинен мати можливість передати це розробнику, і вони повинні це виправити», або, знаєте, в цьому напрямку. Це приємний спосіб мати щось у своєму арсеналі, щоб можна було сказати: «Тут справжня проблема.» Знаєте?
Дез Бланчфілд: Так. Останнє для вас, і те, що мене вражає, дивлячись на це, коли ми проходили це, - це те, що часто, коли ми думаємо про проблеми ефективності, ми прагнемо домогтися спеціальних навичок. Вони приїжджають із 20-річним досвідом роботи, вони дивляться на це, і вони, начебто, класичний анекдот хлопця, який заходить у інженерний цех, має маленький маленький молоток і вдаряє автомат у потрібне місце, а потім каже, "Це виправлення в 15 000 доларів", і люди йдуть: "Ми за це не платимо", ви знаєте, адже це п’ять хвилин роботи. І він каже: "Що ж, на п’ять хвилин роботи було потрібно 15 років досвіду, і це заощадило мільйони".
Мені здається, що, знаєте, є середній процес, люди переживають цю річ, кажучи: «Гаразд, принесіть спеціальні навички, вирішіть проблему, вона піде.» Але те, що вони зробили тоді, - це вони просто поставили на нього стрічку, правда? На відміну від сценарію, коли, із того, що я бачу тут, куди, коли це відбувається, так, вони, можливо, вирішили деякі проблеми, пов'язані з ефективністю, які, на їхню думку, вони відчували, але мені здається, саме тоді це було 24 / 7 видів, ви знаєте, набір очей, які спостерігають за оточенням у реальному часі.
Ви насправді ухиляєтесь від сценарію, коли DBA прокидаються о четвертій ранку, тому що працюють звіти. Це так - і, може, це риторично - але чи так трапляється, що люди швидко переходять від того, щоб шукати інвестиції в продукт, щоб отримати його для вирішення певної проблеми, але тоді він взагалі просто стає частиною ДНК?
Bullett Manale: Так, і це залежить від місця до місця, але, я маю на увазі, у мене є кілька людей, які спочатку придбали товар, наприклад, ще в 2006 році, і вони були на трьох різних роботах у різних компаніях, і вони зайшли і, переходячи до наступної компанії, вони рекламують це як щось, щоб отримати, оскільки вони мають робочий процес. І називаю це так, я ненавиджу це називати, але, знаєте, цей робочий процес включає цей продукт, і вони звикли до нього щодня, і це їм допомагає, і тому вони не хочуть дізнатися щось нове.
Але абсолютно. Я маю на увазі, що більшість часу ми змушуємо людей завантажувати цей продукт, це не тому, що у них є бюджет, а вони виходять, і вони говорять: «Ей, ну, у нас є бюджет на ефективність, нам потрібно робити підтвердження концепції, і нам потрібно вступити і розібратися, зробити оцінку і все таке. "Зазвичай, що трапляється, у них є проблема в екземплярі SQL, і вони шукають допомоги, щоб виправити цю проблему. Вони йдуть і завантажують наш інструмент, вони вирішують проблему, а потім розуміють, що це, сам інструмент зробить більше, ніж просто виправити проблему, яку вони мали на той час, що це насправді допоможе їм покращити загальну ефективність і не допускати інших проблем, рухаючись вперед. І це точно. І ви точно можете продовжувати використовувати цей інструмент для постійної настройки навколишнього середовища, тому що ви завжди зможете побачити не тільки те, що сталося зараз, але і те, що сталося минулого тижня, минулого місяця, минулого року, і порівняти це з тим, що відбудеться завтра. Ти знаєш? Така річ.
Дез Бланчфілд: Так.
Bullett Manale: Отже, точно.
Дез Бланчфілд: Ідеально. Отже, ви вже згадали, про що ви згадали - я просто збираюся завернути, перш ніж повернутись до Еріка, щоб закрити. Одне з речей, яке мене завжди цікавить, - це, знаєте, як люди отримують на це руки? Ви згадали про його завантаження. Що є 30-секундним підсумком того, як вони дістаються до нього, отримують копію, розкручують її і грають з нею, і що їм може знадобитися інфраструктура, щоб отримати примірник.
Bullett Manale: Отже, це буде, ви переходите до IDERA (idera) .com. IDERA.com - це компанія, і якщо ви перейдете на цей веб-сайт - і я фактично можу вас тут показати - я не знаю, чи все-таки ділюсь своїм екраном, але якщо ви перейдете на сторінку Продукти, тоді перейдіть до діагностичної програми Посилання менеджера, буде кнопка Завантажити трохи, і ви можете просто завантажити збірку після заповнення своїх даних. Вони попросять вас скласти 32- або 64-бітну версію, і ви їдете на гонки, як кажуть.
Дез Бланчфілд: А чи буде він працювати на ноутбуці, щоб хтось із ним грав, чи їм потрібно кудись його завантажити на сервер?
Bullett Manale: Ні, ні. Насправді те, що я вам сьогодні показав, все працює від мого ноутбука. Тепер мій ноутбук має 32 гіги та 8-ядерний процесор, але це все-таки ноутбук. Але не обов’язково мати стільки ресурсів, щоб відповісти на ваше запитання. Сама оцінка хороша протягом 14 днів, але ви більше ніж вітаємося, щоб продовжити її пробу. Якщо ви просто зателефонували нам, ми можемо повідомити про це, якщо хочете.
Дез Бланчфілд: Я думаю, що це має щось забрати, тому що я обов'язково буду це робити. Я думаю, ви знаєте, що з вигляду речей, мені здається, що не вимагає завантажувати його та грати з ним. Можливо, перейдіть до одного з ваших середовищ і просто побачите те, що ви можете бачити, тому що я підозрюю, що - як і все, що я бачив на тлі бази даних за останні 20+ років, що старіє мені - як тільки ви зрозумієте, що знаходиться під капот, дивовижно те, що ти розумієш, що можеш швидко виправити та просто отримати невеликі надбавки в продуктивності.
Чудово, дякую за демонстрацію. Це було дійсно чудово. Дякую за весь час для обговорення питань.
Bullett Manale: Вітаємо вас. Дякую за-
Dez Blanchfied: Еріку, я повернуся до тебе.
Ерік Кавана: Так, у нас справді гарне запитання з боку аудиторії. Ви щось про це говорили у своїй презентації, і я насправді це написав, бо це була така чудова цитата. Ви сказали, що не хочете використовувати інструмент для контролю ефективності, який негативно впливає на вашу ефективність.
Bullett Manale: Правильно. Це вірно. Це наче важлива частина інструмента моніторингу продуктивності, чи не викликає проблем з продуктивністю. Точно правильно.
Ерік Кавана: Саме так. Що ж, це як затьмарене - це як антивірусні програми, які можуть просто спричинити хаос у системах. Я маю на увазі, що я використовував ряд різних технологій для мовлення, де антивірусна програма запускається і скоротить ваш потік. Тож трапляються речі, яких ви не очікуєте, але питання, яке стосується конкретного коментаря, який ви зробили. І які хіти виступу ви бачите? Це два відсотки, це п’ять відсотків, це один відсоток? У вас є якісь номери, які ви можете кинути на нас?
Буллет Манале: Ну, я маю на увазі, виклик цього питання полягає в тому, що, знаєте, частина дискусії, про яку ми говорили раніше. Я можу дати вам - як правило, це приблизно один-три відсотки, щоб відповісти на ваше запитання. Але є більше пояснень, які, на мою думку, потрібні, а саме, ми пропонуємо вам безліч способів сказати інструменту, що ви хочете контролювати, правда? І так це повертається до того. Ну, я, можливо, захочу отримати зразок кожного запущеного запиту. Тому я хочу мати інструмент, який є досить гнучким, щоб можна було це ввімкнути, щоб я міг це бачити.
І так, частина цієї гнучкості включає, знаєте, її вартість. Якщо мені потрібно зібрати більше даних, тому що я хочу зразок кожного запиту, який працює за останні, знаєте, 20 хвилин, я можу це ввімкнути, і він може це зробити. І так, але, загалом кажучи, так, один-три відсотки - це те, що ми бачимо, з точки зору накладних витрат. Але це буде різнитися, і більшість цього буде залежати від ваших речей, які ви включаєте та вимикаєте, з погляду ваших порогових значень, кількості даних, які ви хочете зібрати, ваших інтервалів опитування, усіх подібних матеріалів що.
Насправді, якщо ви виходите до самого екземпляра, яким ви керуєте, одна з речей, яку ви побачите, - у нас є кілька інтервалів опитування, які ви можете вказати. І це просто тому, що ми хочемо, знаєте, мені не потрібно перевіряти кожного - Якщо я хочу зробити перевірку серцебиття в екземплярі, мені не потрібно опитувати процесор і все інше разом з ним, якщо я ' я роблю це кожні 20 секунд. Отже, у вас є кілька інтервалів опитування, які ви можете вказати.
У вас є, як я вже сказав, ваш моніторинг запитів, який ви можете вказати. І це можна зробити для кожного примірника самостійно, тож ви дійсно можете задовольнити цей конкретний екземпляр з точки зору того, що ви хочете контролювати. Для моєї статистики очікування та моніторингу очікування я можу це ввімкнути або вимкнути. І я можу сказати, щоб він захопив усе, я можу сказати, ви знаєте, що я хочу захопити і коли я хочу його захопити. Так багато цього буде - Ви повинні враховувати, що ви робите, з точки зору того, що ви говорите про інструмент для моніторингу.
Але загалом кажучи, те, що я б сказав, - це, як я вже сказав, приблизно від одного до трьох відсотків - це те, що ми бачимо. Ми давно продаємо цей інструмент - оскільки, як я вже казав, близько 2003 або 2004 років - і у нас є тисячі клієнтів, тому я можу запевнити вас, що, знаєте, у нас немає - ми спробуємо наш найкраще не створювати проблем із виконанням імені продуктивності.
Ерік Кавана: Так, це дійсно гарна інформація. Я просто подумав, що це була геніальна цитата, бо, знаєте, знову ж таки, ви не хочете перемогти мету того, що ви намагаєтеся досягти, правда?
Bullett Manale: Саме так.
Ерік Кавана: І я дуже ціную питання Робіна; це дійсно є чудовою платформою, яка допоможе DBA зрозуміти безліч різних аспектів, розмірів і шарів того, про що ми говоримо. І я вважаю, що концепція розмови з вашими даними тут дуже доречна, тому що, якщо говорити раніше, зазвичай ви не збираєтеся це зрозуміти з першої спроби. Вам потрібно витратити деякий час на перегляд даних, на перегляд історичних даних, роблячи цей синтез у своєму розумі. І це робота людини, правда? Робота професії, яка сидить там і забирає тепло від бізнесу досить регулярно, щоб виконати цю роботу і тримати поїзди вчасно, правда?
Bullett Manale: Абсолютно.
Ерік Кавана: Ну, люди, це була ще одна фантастична подія. Якщо на будь-яке запитання ви не отримали відповіді, будь ласка, повідомте мене. Надіслати електронний лист на адресу. Ми архівуємо всі ці події, тому ви завжди можете зайти на InsideAnalysis.com, щоб знайти архів, або зайти до нашого партнера, Techopedia.com. Якщо ви подивитесь праворуч на їх сторінку, ви побачите події та перелічені веб-трансляції. Якщо натиснути на Інші події, ви побачите всі перелічені нами веб-трансляції, минуле, теперішнє та майбутнє.
І з цим ми будемо прощатися з вами. За останній рік у нас є ще п’ять веб-трансляцій, люди. Ми можемо запланувати ще один. Але в іншому випадку це стане на 2017 рік. Ед кал вийшов. Повідомте нас, і якщо у вас є хтось, хто хоче показати свою технологію, надішліть електронний лист на адресу.
З цим ми попрощаємося, люди. Дякуємо ще раз за ваш час та увагу, ми поговоримо з вами наступного разу. Піклуватися. Бувай.
