Permainan kinerja: ucapkan selamat tinggal pada latensi

Oleh Staf Techopedia, 9 Mei 2016

Takeaway: Host Eric Kavanagh mewawancarai Mark Madsen, Dez Blanchfield dan Bullett Manale tentang latensi dan kinerja.

Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.

Mitra Konten Techopedia

Staf Techopedia berafiliasi dengan Bloor Group dan dapat dihubungi menggunakan opsi di sebelah kanan. Untuk info tentang cara kami bekerja dengan mitra industri klik di sini.

• Profil
• Situs web

Eric Kavanagh: Hadirin sekalian, halo dan selamat datang kembali ke Hot Technologies! Ya memang! Nama saya Eric Kavanagh, ini adalah acara Hot Tech kami, kemitraan dengan teman baik kami dari Techopedia. Naik online ke Techopedia.com untuk mendapatkan semua yang terbaru di bidang teknologi perusahaan yang luas; mereka, tentu saja, mencakup barang-barang konsumen juga. Kami fokus pada perusahaan di sini di program kami, jadi itulah yang akan kami lakukan hari ini.

Ada tempat tentang Anda yang benar-benar dan cukup tentang saya, hubungi saya di Twitter @eric_kavanagh, saya suka Twitter, saya suka memeriksa hal-hal itu, itu cara yang bagus untuk tetap berhubungan dengan orang-orang dan memiliki percakapan yang baik, dan percakapan pribadi -satu percakapan.

Jadi apa yang kita bicarakan? Tahun ini panas, ini adalah seluruh dunia peluang yang kita lihat hari ini di dunia manajemen informasi, dan apa yang kita bicarakan hari ini akan menjadi pertanyaan, itu akan mempercepat pertanyaan.

Saya pikir saya lupa menyebutkan judul, "Performance Play: Say Goodbye to Latency." Nah siapa yang mau latency? Tidak ada yang menginginkan latensi, latensi adalah ketika Anda duduk di sana, klik tombol dan tunggu sesuatu terjadi, dan tidak ada yang menginginkan itu. Anak-anak tidak suka, mereka pikir itu tidak keren, orang dewasa juga tidak suka. Kita semua dimanjakan oleh kecepatan web, dan kita menginginkan sesuatu dengan cepat, kita menginginkan sesuatu sekarang, dan kita akan membicarakan semua itu hari ini di acara kita.

Analis Mark Madsen bersama kita hari ini dari Third Nature, salah satu pelanggan tetap kita. Ilmuwan data baru kami, Dez Blanchfield, menelepon dari Sydney, Australia. Dan kemudian Bullett Manale, ya memang, itu namanya, sebenarnya itu seharusnya dua huruf T. Bullett Manale sebagai tamu kami dari Idera, perusahaan yang sangat, sangat menarik, melakukan banyak hal. Saya sudah tahu tentang mereka, salah satunya adalah mereka membeli perusahaan bernama Precise beberapa waktu lalu. Saya tahu CEO mereka bernama Zohar Gilad, bagaimana itu untuk sebuah nama? Dia adalah salah satu pria cerdas.

Tetapi saudara-saudara, Anda memainkan peran penting dalam siaran web ini dalam pertanyaan yang Anda ajukan, jadi tolong jangan malu-malu, kirimkan pertanyaan Anda kapan saja - Anda bisa melakukannya dengan menggunakan komponen T&J di konsol webcast, yang ada di bawah sana di sudut kanan bawah. Anda juga dapat ngobrol saya dan saya akan ngobrol ke speaker. Kami sudah memiliki seseorang yang menelepon dari Italia, jadi, “Ciao, ciao. Ayo stai? ”Baiklah, dengan itu aku akan mendorong baris pertama Mark, aku akan menyerahkan geladak kepada Mark. Mark, Anda sekarang memiliki WebEx. Bawa pergi, lantai milikmu.

Mark Madsen: Terima kasih, Eric. Saya tidak akan memulai di tengah, saya akan mulai dari awal. Jadi hanya beberapa komentar untuk mengatur diskusi dengan Dez dan Idera, semacam negara dengan pengembangan, dan database dan operasi. Dan Anda tahu, Jika Anda melihat ini, kami memiliki dua masalah dunia yang masih ada di basis data dan pasar aplikasi, karena pengembang memandang DBA sebagai orang yang merepotkan mereka. Anda harus membuat model data, Anda tidak dapat memiliki akses ke sana, Anda tidak dapat membuat hal itu, Anda tidak dapat menempatkan indeks pada setiap kolom dari setiap tabel pada basis data untuk membuatnya lebih cepat. Dan tentu saja, mengapa kita membutuhkan modelnya? Hanya struktur data, jika kami mengubahnya, tidak bisakah Anda menuliskannya dalam bentuk serial?

Masalahnya adalah bahwa pengembang tahu kode, dan aplikasi, tetapi dua hal yang sering tidak mereka ketahui, adalah konkurensi, pemrograman bersamaan, dan basis data serta sistem operasi di bawahnya. Setelah menjadi pengembang kernel dan sistem operasi dan database, saya dapat mengatakan bahwa konkurensi dan paralelisme sangat sulit, dan banyak hal yang Anda pelajari untuk mendapatkan kinerja yang baik dari kode Anda, benar-benar mulai berantakan ketika Anda bekerja dengan database. Dan kinerja terlihat hebat, lingkungan pengujian tampak hebat, dan lingkungan T&J, dan kemudian menyentuh sistem yang sebenarnya, dan kemudian tiba-tiba tidak terlalu bagus. Karena multifaset, bagaimana kode bekerja dengan database, cara kerjanya dengan lingkungan, dan praktik kecil yang sangat sederhana dapat memiliki efek drastis tergantung pada skala yang Anda jalankan.

Dan ketika Anda mulai berbicara tentang aplikasi eksternal, tentu saja, aplikasi yang menghadap ke luar, aplikasi web, bisa sangat sulit karena banyak hal yang hebat sampai tiba-tiba mereka datar, dan sebenarnya tidak. Anda akan menemukan dataran tinggi yang menarik ini yang membutuhkan banyak nuansa untuk mengerti.

Kebalikan dari hal-hal adalah pandangan DBA. Pandangan DBA adalah bahwa ada operasi, mereka menghabiskan sebagian besar waktu mereka, 80 hingga 90 persen, di operasi, dan mungkin 10 hingga 20 persen berurusan dengan hal-hal pengembangan yang terjadi di muka. Dari perspektif ini, Anda membayar sekarang atau membayar nanti, dan jika Anda menghabiskan seluruh waktu Anda di muka, maka Anda akan memiliki peluang yang jauh lebih baik di kemudian hari, sebagai lawan dari pengembangan yang cenderung mengeksplorasi fitur. ruang, dan mencoba mencari cara terbaik untuk melakukan sesuatu. Dan jadi kami memiliki masalah, dan sekarang kami memiliki metodologi yang tidak kompatibel - penerapan berkelanjutan, menggulung aplikasi Anda kapan pun mereka siap, melakukan dorongan kode secara berkala, bekerja di toko yang mempraktekkan pengembang. Hal semacam ini mempercepat pengembangan, tetapi semua praktik di sekitar basis data dan apa yang dilakukan DBA dan apa yang telah dilatih oleh manajer sistem, praktik operasi TI belum sejalan.

Jika Anda memikirkannya, sebagian besar DBA beroperasi di bawah lingkungan kontrol perubahan versus lingkungan penggunaan berkelanjutan. Ini semua tentang stabilitas dan kontrol, versus kecepatan perubahan dan keterbalikan. Penerapan berkelanjutan, jika Anda tidak dapat mundur dari perubahan, Anda berada dalam masalah, jadi semuanya harus dibangun agar mudah dibalikkan dan dapat ditukar kode, yang sama sekali bukan cara database relasional, praktik pengembangan, dan praktik manajemen bekerja .

Anda juga menghadapi masalah-masalah ini karena harus lebih proaktif jika Anda bisa, sebagai DBA, karena pada saat Anda mendengar masalah, seratus ribu orang sedang mengisi formulir pengaduan di situs web Anda. Itu membuat Anda membutuhkan beberapa hal baru yang tidak Anda dapatkan dari lingkungan lama Anda. Anda tahu, hal-hal seperti pemantauan dan peringatan yang lebih baik. Pada saat yang sama, basis data telah berlipat ganda, kami mendapat lebih banyak aplikasi daripada sebelumnya untuk mendukung lebih banyak hal dari sebelumnya, mereka ada di dalam, mereka di luar, mereka ada di semua tempat. Dan set data yang lebih independen untuk analisis, orang-orang memulai basis data di seluruh karena, tentu saja, mudah sekarang, Anda dapat mengatur mesin virtual. Jika Anda memiliki penyedia cloud atau cloud internal, Anda dapat segera memunculkan berbagai hal, dan ini mengubah seluruh jalur pengadaan Anda.

Jalur pengadaan yang lama adalah, “Saya punya waktu untuk mendapatkan server, mendorongnya di rak, mengalokasikan ruang, mendapatkan penyimpanan, memasang basis data dan melakukan sesuatu, ” versus seseorang menggesekkan kartu kredit dan berjalan dalam lima menit. Jika Anda melakukan itu, lingkungan pengembangan modern beroperasi pada kecepatan yang sangat berbeda, sehingga mudah untuk membuat basis data, dan itu hanya menciptakan masalah proliferasi ini, seperti yang belum pernah kita lihat sebelumnya. Dan ini telah berlangsung selama sepuluh tahun sekarang, ini bukan berita untuk siapa pun, tetapi itu juga berarti bahwa lingkungan operasi telah tumbuh dalam kompleksitas.

Seluruh lingkungan server klien telah benar-benar berubah, karena itu bukan dunia server klien lagi. Saat itu Anda memiliki server, Anda memiliki database, jika ada sesuatu yang salah Anda tahu ke server mana Anda harus pergi, Anda tahu bagaimana mengelola sumber daya di dalamnya karena praktik terbaik adalah satu database, satu server. Virtualisasi mulai memecah belah itu, cloud memecahnya bahkan lebih, karena apa yang Anda pikirkan adalah server basis data, hanyalah perangkat lunak. Jadi lingkungannya tidak nyata. Itu yang mengandung lingkungan yang merupakan kenyataan, dan itu mungkin rak pedang atau server besar yang diukir menjadi berkeping-keping, Anda tidak benar-benar tahu.

Segala sesuatu di sekitar administrasi basis data dan manajemen kinerja, dan basis data apa yang telah dibangun dengan kontrol ketat dengan satu server, atau beberapa server dan beberapa database, Anda tidak dapat mengendalikan semuanya. Anda duduk di sana pada mesin, tetapi bandwidth tidak dapat dipartisi dengan mudah oleh manajer virtual, dan semuanya bisa baik-baik saja dengan memori dan CPU, tetapi Anda mengalami hambatan pada beberapa sumber daya yang tidak dapat ditangani, dan kemudian ketika Anda mencoba memperbaikinya, model lama akan bekerja keras, mendapatkan server yang lebih besar dan melakukan sesuatu seperti itu, sekarang bisa sangat sederhana, cukup tambahkan saja virtual, cukup tambahkan memori ke VM dan itu diselesaikan. Tetapi apa yang terjadi jika VM Anda berada di server yang terlalu padat dan perlu bermigrasi? Atau apa yang terjadi jika Anda berada pada ukuran sistem AWS, dan ukuran maks telah tercapai, sekarang ke mana Anda pergi?

Jadi Anda memiliki semua masalah ini di mana lingkungan adalah bagian dari basis data sekarang, Anda mengemas lingkungan dengan basis data, semua sumber daya khusus, semua yang ada dalam aplikasi itu adalah bagian dari konfigurasi, konfigurasi akan terdorong ke sana. Ini dari lingkungan basis data, jauh lebih sulit untuk dikelola dan dikendalikan.

Jika Anda melihat apa yang telah dilakukan pusat data, mereka telah duduk di tangan mereka, bukan? Kami telah beralih dari gagasan untuk memperlakukan basis data dan server seperti hewan peliharaan. Server memiliki nama, Anda memperlakukan mereka seperti mereka adalah hal-hal unik secara individual, Anda memperlakukan mereka seperti ternak, itu mengelola kawanan. Dan masalah dengan mengelola ternak adalah bahwa jika Anda tidak mengendalikan mereka, mereka pada akhirnya dapat menyerbu, dan penyerbuan bukanlah hal yang baik. Kami membutuhkan alat pemantauan yang lebih baik, kami membutuhkan cara yang lebih baik untuk menangani hal ini, dan tahu apa yang telah terpengaruh. Dalam model lama, itu lebih mudah karena ops Anda dan semua sistem kontrol Anda memberi tahu Anda, tetapi ketika nama server Anda adalah kode UPC, agak sulit untuk mencari tahu.

Anda tidak dapat membeli lansiran palsu, Anda tidak mampu membeli hal-hal yang mengatakan, "Ada masalah dengan mesin ini, dan mesin itu menampung 30 database." Anda tidak mampu memiliki hal-hal yang tidak memberi Anda sejarah. Memantau konsol sangat bagus ketika menyala, tetapi jika lampu merah berubah menjadi hijau lagi dan Anda tidak tahu mengapa, dan Anda tidak memiliki sejarah untuk kembali ke apa yang mengarah ke sana, dan apa yang terjadi. konteksnya adalah, Anda dalam kesulitan. Kita membutuhkan sistem yang akan memantau kita, kita perlu pemantauan yang lebih baik, berurusan dengan masalah intermiten kursif yang mempertahankan sejarah data itu.

Hal-hal yang lebih baik dan ambang metrik sederhana yang memberi kami metrik kunci, tetapi jangan mengarahkan kami langsung ke apa yang normal, apa yang tidak normal, dan seberapa sering masalah ini terjadi. Apa yang sebenarnya kita bicarakan adalah kombinasi dari lingkungan pemantauan, dan berurusan dengan kinerja, dan vendor telah duduk di tangan mereka. Mereka belum memberi kami alat yang lebih baik. Kami memiliki sistem dengan lebih banyak CPU dan memori daripada yang kami tahu apa yang harus dilakukan dengan itu semua, namun kami masih mengandalkan model intervensi manual, kami belum menempatkan mesin untuk bekerja, untuk membimbing kami, untuk membawa kami ke titik masalah, kita belum sampai pada gaya baru ini yaitu, "Ada masalah di sini, Anda dapat melakukan ini untuk memperbaikinya, " atau, "Ada masalah kinerja, sebenarnya dengan pernyataan SQL khusus ini, berikut adalah tiga hal yang Anda bisa lakukan gunakan untuk memperbaiki pernyataan SQL itu. ”Menerapkan heuristik, menerapkan model pembelajaran mesin yang dapat melihat pola penggunaan sistem Anda untuk menemukan masalah dan menghindari peringatan palsu. Menggunakan mesin untuk melakukan apa yang paling baik dilakukan mesin, untuk menambah DBA, atau untuk menambah orang yang harus berurusan dengan masalah kinerja.

Itu cara baru, berbeda dengan gaya lama. Ada masalah dengan database ini, semuanya lambat, jadi kami memiliki teknik baru, cara baru untuk melakukannya, dan kami harus menerapkannya, dan di situlah pasar menuju. Anda melihatnya mulai muncul, bukan dengan vendor besar, tetapi dengan perusahaan pihak ketiga, dan ini mencerminkan sesuatu yang terjadi 20 tahun lalu ketika vendor database tidak memberikan satu hal pun untuk membantu mengelola sistem. Jadi seperti itulah arah pasar, dan dengan itu, saya ingin mengembalikannya kepada Eric.

Eric Kavanagh: Baiklah, saya akan menyerahkannya kepada Dez. Dan Dez, bawa pergi, lantai milikmu.

Dez Blanchfield: Terima kasih, Mark. Anda telah melakukan pekerjaan luar biasa dalam meliput komponen teknisnya. Saya akan membahasnya dari sudut yang sedikit berbeda untuk menyoroti apa yang terjadi di seluruh dunia, sejauh dampaknya terhadap bisnis dan basis data di sekitar mereka. Biarkan saya melompat ke slide pertama saya.

Di balik apa yang baru saja Anda bahas dari sisi teknis hal dan sisi pengembang hal, saya melihat bisnis harus menghadapi tantangan data dan database pada khususnya, dan jelas kami telah mengalami perubahan signifikan menuju konsep data besar ini, tetapi basis data secara efektif masih menjadi jantung dan jiwa tempat organisasi menyimpan informasi bisnis mereka, dan itu dari pintu depan hingga kantor belakang. Setiap bagian dari organisasi tersentuh oleh suatu basis data, dan didukung oleh suatu basis data, dan sangat jarang saya melakukan diskusi proyek, atau suatu bentuk percakapan strategis yang inovatif dalam suatu organisasi di mana topik dari basis data atau sistem basis data tidak muncul, dan selalu ada pertanyaan seputar jenis hal yang baru saja kita dengar, dalam kinerja dan keamanan dan bagaimana pengembangan datang mendekati tantangan ini, dan di mana basis data cocok, dan kesadaran kita akan lingkungan dan aplikasi berbicara dengan lingkungan, bagaimana dengan perangkat dan mobilitas?

Itu masih merupakan topik yang sangat, sangat panas, dan sudah lama, dalam skema besar sejauh teknologi modern berjalan. Untuk itu, saya percaya itu adalah fakta bahwa hampir semua yang kita lakukan dalam kehidupan kita sehari-hari, yaitu kehidupan kita sehari-hari, yang sekarang didukung oleh beberapa bentuk basis data. Ketika kita memikirkan semua hal di sekitar kita, apakah itu tagihan yang datang melalui pos setiap hari untuk beberapa layanan yang kita beli, itu pasti dicetak oleh sistem yang berbicara dengan database, dan kita di sana. Ponsel kami memiliki basis data dengan kontak dan log panggilan, dan hal-hal lainnya.

Ke mana pun kita pergi, ada beberapa bentuk basis data di belakang pembicaraan dan sistem yang kita gunakan, dan lebih sering daripada tidak, mereka cukup transparan bagi kita, tetapi kenyataannya adalah bahwa mereka ada di sana. Jadi saya pikir saya akan segera membahas mengapa ini menjadi sedikit masalah dalam waktu yang sangat singkat. Pada awalnya, konsep basis data berasal dari pria yang baik hati ini, Edgar Codd. Saat bekerja di IBM, ia mengubah dunia sejauh manajemen data berjalan dengan menciptakan konsep yang kami sebut sekarang sebagai basis data relasional.

Pada awalnya, basis data adalah basis data dan kehidupan baik, cukup mudah baik dalam kolom, dan referensi, dan sebagainya, dan tabel, dan pengembangan perangkat lunak cukup mudah, dan kinerja tidak terlalu besar masalah - itu adalah teknologi baru yang menarik. Kami mengakses database melalui beberapa bentuk terminal, dan Anda hanya dapat benar-benar membuat begitu banyak malapetaka di akhir terminal 3270 pada mainframe, dan selalu jenis terminal lainnya, sistem-sistem lain datang. Dan dalam kebanyakan kasus, terminal gaya lama sangat mirip dengan lingkungan web sekarang, dan itu adalah bahwa Anda akan mengisi formulir di layar pada terminal itu sendiri dan tekan Enter dan off it go, itu akan menembak sebagai satu paket, sebagai permintaan, dan sistem back-end akan menghadapinya. Pada dasarnya itulah yang terjadi pada peramban web saat ini, ketika Anda mengetik tautan pada peramban web dan formulir itu biasanya tidak secara real time kembali ke sistem, meskipun dengan AJAX hari ini, itu tidak sepenuhnya kasus.

Tapi kemudian sesuatu terjadi, masa depan tiba, dan baru-baru ini internet, dan hampir kemarin, di web 2.0 detik, dan di ujung jalan kita sudah mendapatkan Internet of Things. Dan dalam proses yang terjadi di masa depan, dunia basis data baru saja meledak, dan interaksi dengan basis data hanya menjadi hal yang kita semua lakukan secara default, itu bukan kasus bahwa Anda akan pergi ke suatu tempat untuk melakukan sesuatu, seperti membeli tiket untuk pesawat terbang, dan ingin melakukan perjalanan ke sisi lain dari planet ini, seseorang harus mengetikkan terminal semua rincian Anda dan pergi ke database dan mencetak tiket.

Hampir semua yang kita lakukan sekarang, apakah itu memanggil taksi di Google dengan aplikasi, apakah itu melompat di internet banking, semua yang kita lakukan sehari-hari, dengan semacam sistem, didukung oleh database. Dan ketika internet muncul, itu sedikit lebih mudah untuk dibawa kepada kita, kehidupan kita sehari-hari melalui browser web, dan kemudian web 2.0 muncul dan hal-hal menjadi mobile, dan skala hal-hal baru saja meledak. Faktanya, baris favorit saya dalam topik ini adalah bahwa, “Internet menghubungkan semuanya, web 2.0 menjadikannya mobile dan sosial, dan segalanya menjadi sangat, sangat besar dan sekarang kami memiliki internet dan hal-hal dan, dan IOT… Astaga !!” Kami bahkan belum mulai membayangkan dampak Internet of Things ketika datang ke dunia pada sistem basis data.

Jadi dalam istilah modern, apa yang dulu kita anggap sebagai terminal telah secara efektif menjadi hal-hal ini, itu adalah ponsel, berbagai jenis tablet, baik tablet layar lebar ukuran besar untuk konsumen atau perusahaan, laptop dan desktop tradisional dalam beberapa bentuk. Dalam satu gambar itu Anda dapat melihat hampir setiap bentuk antarmuka yang sekarang kami gunakan untuk berbicara dengan sistem database dan aplikasi yang didukung oleh itu, dari gadget kecil di tangan kami yang berjalan di sekitar dan kami tampaknya terpaku pada, semua jalan ke versi yang sedikit lebih besar, dan iPad, dan tablet lain dan Microsoft Surfaces, ke laptop sehari-hari, yang selalu menjadi kasus di lingkungan profesional dan sebagainya. Orang-orang cenderung mendapatkan laptop dan bukan desktop yang tetap, tetapi mereka adalah terminal modern dalam pandangan saya dan bagian dari alasan bahwa database mengalami semua jenis tantangan di bagian kinerja manajemen dalam kehidupan kita, dan bukan hanya pengembangan.

Jadi saya berasumsi itu adalah salah satu tantangan terbesar yang masih dihadapi bisnis setiap hari. Semua orang mengira bahwa basis data adalah satu-satunya masalah kita, bukan itu. Jadi apa yang diributkan? Ya, ketika kita beralih dari satu ujung ke ujung yang lain dengan semua hal yang terkait dengan basis data, dari sisi komersial, dan Markus membahas komponen teknis dengan sangat baik, tetapi dalam pengertian komersial, sebagai sebuah organisasi, kita berpikir tentang basis data. Kami berurusan dengan banyak hal mulai dari desain dasar dan pengembangan front end. Ketika sebuah bisnis dimulai, mereka akan berpikir tentang mengembangkan aplikasi, mengembangkan kemampuan, atau bahkan mengimplementasikan aplikasi yang sudah ada dalam beberapa bentuk. Beberapa bentuk desain dan pengembangan harus terjadi dan banyak pemikiran harus dibawa ke bagaimana sistem database ini akan diimplementasikan, dan didukung dan dikelola, dan kinerja dilacak dan sebagainya.

Integrasi lingkungan basis data dan aplikasi, dan jenis-jenis API, jenis-jenis akses yang disediakan sekarang semakin menantang, semakin kompleks. Administrasi sehari-hari, dukungan dan cadangan, sekali lagi, ini adalah hal-hal yang kami pikir telah diselesaikan, tetapi kemudian tiba-tiba skalanya menjadi jauh lebih besar, dan hal-hal bergerak lebih cepat, dan volumenya jauh lebih besar; ukuran lingkungan, sistem database harus mendukung kecepatan di mana transaksi bergerak.

Pikirkan tentang basis data dalam lingkungan perdagangan frekuensi sangat tinggi, tidak mungkin manusia dapat melacaknya, itu hanya sekelompok mesin yang melawan kelompok mesin lain untuk melakukan perdagangan frekuensi tinggi, jual beli, dan volume pada dimana transaksi tersebut terjadi. Pikirkan skenario modern, seperti rilis awal film Netflix di mana Anda tidak hanya berbicara tentang ratusan atau ribuan, atau bahkan ratusan ribu, berpotensi jutaan orang yang ingin melihat film itu sejak detik dirilis. Semua informasi itu ditangkap, dilacak, dicatat, dan dianalisis dalam platform basis data.

Dan kemudian ada dunia yang selalu ada di mana kita hidup sekarang, 24/7, tidak hanya mengikuti Matahari tetapi selalu ada seseorang di tengah malam yang ingin melakukan sesuatu, dan jam kerja mengikuti Matahari di seluruh dunia. Jadi uptime dan ketersediaan secara default, iklim sekarang, memiliki pemadaman sebenarnya bukan hal yang dapat diterima. Dan redundansi, jika ada masalah kinerja atau jika kita memerlukan jendela pemeliharaan untuk melakukan pemutakhiran atau tambalan, atau keamanan, sungguh, kita harus dapat memotong dari satu lingkungan basis data ke yang lain dan melakukannya dengan mulus dan otomatis.

Keamanan dan standar dan kepatuhan, kami telah mengalami beberapa hal besar yang cukup besar di dunia akhir-akhir ini, khususnya GFC, dan karenanya kami memiliki seluruh jajaran tantangan baru untuk dipenuhi seputar kepatuhan, dan keamanan, dan standar yang sesuai, dan kami membutuhkan untuk dapat melaporkan mereka secara real time, dan idealnya dalam bentuk dasbor. Kami tidak ingin mengirim tim monyet ke pusat data untuk mencari sesuatu, kami membutuhkan sistem untuk memberitahu kami segera, secara real time.

Dan dua hal yang sangat menyenangkan yang hampir tidak ada yang pernah dibicarakan, kita biasanya mendorong mereka di bawah karpet dan berharap bahwa mereka tidak pernah mengangkat kepala jelek mereka, tetapi pemulihan bencana dan kelangsungan bisnis - ini adalah hal-hal yang seharusnya, untuk sebagian besar, terjadi secara otomatis, jika diperlukan.

Kita dapat menghabiskan waktu berhari-hari untuk membicarakan jenis-jenis hal yang dapat salah di lingkungan basis data, dan bahwa manusia pada umumnya telah merespons, tetapi sekarang kita membutuhkan sistem dan alat untuk melakukannya bagi kita. Salah satu contohnya adalah pelanggaran data dan, ketika kita berpikir tentang basis data, dan saya mengajukan pertanyaan ini secara terbuka dalam berbagai bentuk: apa yang terjadi pada basis data ketika kita mengalihkan perhatian, dan sesuatu yang kritis menjadi salah? Terutama jika tidak ada sistem yang memantau kinerja dan keamanan dan aspek utama lainnya dari menjalankan basis data.

Nah, yang bisa terjadi adalah ini, ini adalah tangkapan layar dari beberapa pelanggaran terbaru dalam dua hingga tiga tahun terakhir. Selalu, ini semua berasal dari sistem database, dan selalu, ada beberapa masalah dalam keamanan atau kontrol, atau akses yang terjadi, dan di sudut kiri atas kita melihat 152 juta akun Adobe, di mana setiap detail dari para pelanggan itu dilanggar. Dan seandainya alat yang tepat mungkin ada di tempat untuk melacak dan menangkap insiden itu, dan mengendalikan keamanan, kita mungkin telah menghindari beberapa dari mereka, beberapa ratus catatan pertama yang dicuri mungkin telah memperingatkan kita, dan kita akan memiliki menghentikan seratus lima puluh juta berikutnya.

Kemudian kita sampai pada titik kunci dari seluruh perjalanan ini, membawa kita melalui, yaitu: mengapa kita membutuhkan sistem yang lebih baik? Mengapa kita tidak bisa begitu saja melempar lebih banyak benda pada hal ini, bahwa kita telah dengan baik dan benar-benar melewati titik kritis dalam pandangan saya, dan tentu saja saya percaya ada kasus yang menjadi bukti akhir-akhir ini, yang melemparkan lebih banyak DBA, administrator, dan lebih banyak orang di Hal ini tidak memperbaiki masalah. Kita membutuhkan seperangkat alat yang lebih baik dan seperangkat sistem yang lebih baik.

Berikut adalah lima alasan utama saya yang saya yakini mendukung hal ini, dan mereka diurutkan berdasarkan tingkat kepentingannya, berdasarkan apa yang saya lihat di seluruh perusahaan swasta dan negara bagian yang mengatur lingkungan, tantangan yang mereka hadapi dengan lingkungan basis data, dan mengelolanya.

Keamanan dan kepatuhan - nomor satu. Anda tahu, mengendalikan siapa yang memiliki akses, di mana mereka memiliki akses, kapan mereka memiliki akses, seberapa sering mereka memiliki akses, dari mana mereka mengaksesnya. Berpotensi perangkat yang telah mereka sentuh dan jenis hal yang telah mereka lihat, dan kepatuhan terhadap hal itu. Jika manusia menjalankan laporan 30 hari kemudian untuk memberi tahu kami apakah semuanya baik-baik saja tidak lagi sesuai, itu harus terjadi secara real time.

Performa dan pemantauan - sepertinya tidak punya otak, tapi selalu tidak. Apakah kita menggunakan alat sumber terbuka atau alat komersial pihak ketiga, selalu kita tidak ketinggalan, dalam banyak hal, dengan jenis pemantauan kinerja yang diperlukan dan detail yang mana, dan kemampuan untuk merespons dalam waktu .

Deteksi dan respons insiden - itu harus menjadi hal real-time instan, dan selalu kita membutuhkan sistem untuk melakukannya untuk kita, atau setidaknya mengingatkan kita dengan cepat sehingga kita dapat menghadapinya, sehingga beberapa masalah yang muncul ditangani dengan cepat, dan jangan mengalir di luar kendali.

Manajemen dan administrasi - sekali lagi, kami pikir masalah ini terpecahkan, mereka tidak. Sasaran masalah yang dihadapi oleh tim basis data, khususnya DBA di mana suatu sistem harus mengurus hal-hal untuk kita, kita belum memecahkan masalah itu, itu masih merupakan hal yang nyata.

Dan langsung dari ujung depan dengan desain dan pengembangan, ketika kita mulai membangun alat-alat ini, kita membangun lingkungan basis data, dapat melemparkan alat yang sesuai pada pengembangan dan pengujian, dan integrasi, platform. Ini masih bukan hal yang mudah untuk kita lakukan, dan seluruh perjalanan ini, itu semacam mendorong kita ke pesan yang sama, bahwa dalam pikiranku kita membutuhkan sistem yang lebih baik dan alat yang lebih baik untuk membantu kita memberikan hasil yang kita butuhkan dari lingkungan basis data kami, sehingga bisnis yang mendorong nilai dari pelanggan kami. Kita tidak bisa terus melempar lebih banyak benda dan lebih banyak DBA, skalanya terlalu besar, kecepatannya terlalu cepat dan volumenya terlalu tinggi. Dengan itu, Eric saya mungkin akan membalas Anda.

Eric Kavanagh: Saya suka, kami punya banyak tanah yang tertutup di sana orang-orang, banyak calon prospek, dan kami pergi ke depan dan menyerahkan kunci mereka ke Bullett hanya dalam satu detik.

Bullett Manale: Baiklah.

Eric Kavanagh: Oh, ayo ambil dan Bullett, sekarang saya serahkan kepada Anda, dan lantai itu milik Anda.

Bullett Manale: Baiklah, terima kasih. Saya pikir banyak poin bagus telah dibuat. Saya ingin berbicara sebentar tentang Idera, siapa kita, dan kemudian kita akan melompat. Saya akan berbicara tentang alat yang saya pikir banyak hal yang sedang kita bicarakan, kita bisa semacam set dan semacam membahas beberapa bidang di mana ini menyelaraskan, dengan alat ini, produk Manajer Diagnostik.

Sekarang, apa yang ingin saya lakukan pertama, adalah hanya memberi Anda sedikit latar belakang tentang siapa Idera; kami sudah ada sejak sekitar 2003, dan kami memulai dengan hanya alat SQL Server, dan itulah yang akan kami fokuskan hari ini, yaitu, akan menjadi produk Manajer Diagnostik. Tetapi Anda dapat melihat semua hal yang kami miliki di sini, dan kami baru-baru ini, seperti yang disebutkan sebelumnya, kami mengakuisisi Precise dan melalui akuisisi, kami juga memiliki Embarcadero, sehingga kami memiliki portofolio produk yang cukup bagus.

Dalam hal pemantauan kinerja, dalam hal SQL Server, produk yang ingin saya bicarakan, yang menyelaraskan topik-topik yang sedang kita diskusikan, adalah Manajer Diagnostik. Sekarang, ini adalah produk yang sudah ada sejak cukup dekat dengan awal hari Idera, dan saya cukup beruntung untuk menjadi bagian dari itu sejak sekitar tahun 2005. Dan saya telah melihat banyak perubahan dalam hal SQL Server, perubahan dari fisik ke virtual, semua hal semacam itu terjadi, dan juga kebutuhan DBA saat lingkungan tumbuh, dan hal-hal semacam itu.

Apa yang saya mulai dengan, adalah pengguna khas produk kami adalah DBA, dan jadi ketika kita berbicara dengan orang-orang untuk pertama kalinya, calon pelanggan, sebagian besar adalah DBA yang sedang kita bicarakan. Kami tidak berbicara dengan manajer TI, atau direktur, mungkin pada titik tertentu mencapai tingkat itu, tetapi permulaannya adalah bahwa DBA memiliki masalah, DBA mencoba untuk memperbaiki masalah, dan sering kali kita Saya akan pergi dan mengunduh serta mencoba produk tersebut sebagai bagian dari itu. Anda bisa mendapatkan pengelola data atau DBA atau DBA yang bertindak, orang yang cukup beruntung untuk menjadi yang paling teknis di ruangan itu, dalam beberapa kasus. Sekarang, ketika Anda sampai ke lingkungan perusahaan yang lebih besar, tentu saja, maka Anda akan mendapatkan DBA lengkap yang biasanya mereka akan menggunakan alat. Dan saya melanjutkan dan baru saja menambahkan uraian kecil di sini dari Wikipedia. Ini semacam tanggung jawab DBA seperti yang dikatakan Wikipedia, itulah yang mereka lakukan.

Jika Anda membaca daftar di sini, banyak hal-hal ini, saya tidak akan membacanya, tetapi Anda mendapatkan banyak hal-hal khas yang akan Anda pikirkan, dan kemudian pada salah satu dari mereka, Anda punya pemantauan dan mengoptimalkan kinerja database, dan itu yang cukup besar. Dan yang menarik, adalah ketika Anda berbicara dengan DBA, mereka selalu orang-orang yang disalahkan terlebih dahulu, ketika datang ke masalah, dan itu mungkin tidak benar-benar kesalahan mereka, tetapi ketika ada masalah kinerja, biasanya dengan aplikasi yang terkait dengan database DBA, merekalah yang disalahkan, jadi mereka selalu mencari alasan mengapa itu bukan kesalahan mereka. Dalam banyak kasus itulah yang dapat mereka gunakan alat ini, Manajer Diagnostik, untuk membantu mereka melakukannya.

Tetapi pada akhirnya, juga, jika database tidak berkinerja, maka banyak dari hal-hal lain ini tidak terlalu penting, aplikasi Anda tidak berfungsi, maka tidak terlalu penting untuk banyak dari ini sesuatu. Pertama dan terutama, kami ingin dapat memastikan bahwa pengalaman pengguna seperti yang kami ketahui, tidak berkurang, itu adalah sesuatu yang selalu berusaha untuk dina. Dan saya pikir, jika Anda melihat alasan mengapa orang biasanya membeli dan menggunakan produk SQL Diagnostic Manager, salah satu alasan pertama, mungkin bukan yang paling utama, bukan yang terakhir atau paling tidak, tapi agak sama secara keseluruhan, dan tergantung pada siapa Anda berbicara, alasan-alasan ini, hampir satu atau dua dari mereka selalu, ada semacam kebutuhan di sekitar.

Tapi yang pertama hanya bisa memiliki pandangan terpusat dari contoh sebagai SQL yang mereka kelola. Dan lucunya adalah bahwa dalam banyak kasus, jika Anda bertanya DBA, "Berapa banyak contoh yang Anda kelola?" Jumlahnya berubah begitu sering, sehingga mereka tidak benar-benar yakin dalam beberapa kasus. Jadi, Anda membutuhkan sesuatu yang lebih dari sekadar mampu membuang semuanya di layar. Anda ingin memegang informasi itu, Anda ingin membuatnya masuk akal, dan itulah salah satu hal yang pasti dapat membantu Manajer Diagnostik, adalah untuk dapat memberi Anda pandangan seperti itu ke lingkungan.

Dan itu bukan hanya pandangan ke lingkungan, tetapi pandangan bahwa DBA, administrator basis data, nyaman dengan dan itu adalah konsol yang DBA sentris, jika Anda mau. Itu dibuat untuk administrator basis data. Ada banyak alat pemantauan di luar sana, ada banyak alat kinerja di luar sana, tapi seperti yang saya katakan, pada akhirnya, DBA menginginkan alat yang dirancang untuk DBA, karena ada banyak hal khusus untuk apa yang mereka lakukan di hari ke hari mereka.

Dan dengan itu, Anda memiliki SCOM, Anda memiliki HPF, Anda memiliki semua teknologi lainnya, tetapi mereka menginginkan sesuatu yang khusus untuk apa yang mereka lakukan. Saya pikir kami dapat membantu di bidang itu dengan produk ini, Anda akan melihat ketika kami membahasnya dalam sedetik. Hal lain yang kita lihat dengan DBA yang jelas merupakan salah satu hal yang kita singgung sebelumnya, adalah bahwa mereka harus dapat melihat apa yang terjadi, jelas, dan mereka harus dapat melihat seluruh perusahaan. dan memiliki ketenangan pikiran dalam mengetahui apa yang terjadi. Tetapi pada saat yang sama, mereka tidak duduk di sana menatap konsol.

Ingat semua poin-poin yang Anda lihat dalam daftar itu, yang baru saja saya tarik? Mereka harus melakukan hal-hal lain juga, jadi ini bukan hanya tentang menunggu api untuk padam. Dalam banyak kasus akan ada pertemuan, atau banyak jendela pemeliharaan yang terkait dengan administrator database berjalan di tengah malam ketika mereka sedang tidur, sehingga mereka harus memiliki kemampuan untuk kembali dan melihat apa yang terjadi . Dalam banyak kasus, jika Anda tidak menangkap sesuatu ketika itu terjadi, setelah masalahnya hilang, atau setidaknya dengan SQL Server, itu menjadi semacam masalah di mana Anda berurusan dengan situasi di mana Anda tidak punya sisa-sisa masalah itu lagi. Dan masalah-masalah itu hilang, dan begitu juga sisa-sisa, yang berarti bahwa Anda memiliki lebih sedikit masalah, Anda memiliki lebih sedikit informasi untuk dikerjakan.

Dengan mengatakan itu, itu pasti salah satu hal yang dapat membantu dengan Manajer Diagnostik, adalah memberi Anda pandangan ke masa lalu untuk menanyakan informasi dari masa lalu, "Apakah saya memiliki peringatan dengan pemblokiran, apakah saya memiliki masalah dengan kebuntuan, apakah kita memiliki hal-hal yang terjadi dalam hal sumber daya kita? ”Saya dapat kembali dan menanyakan informasi itu. Saya dapat menelusuri titik-titik tertentu dalam waktu. Saya dapat melakukan semua hal itu langsung dari dalam alat.

Semua hal itu, terlepas dari apakah itu aplikasi internal atau eksternal atau tidak, DBA ingin tahu, karena mereka ingin dapat melihat apa yang menyebabkan masalah. Tidak masalah apakah seseorang di dalam organisasi, atau seseorang di luar organisasi yang menulis kode; mereka masih ingin mengisolasinya, sehingga mereka tahu bahwa masalahnya sedang terjadi, dan mereka tahu dari mana asalnya.

Jadi kinerja dan akuntabilitas adalah bagian penting dari apa yang dilakukan produk kami. Kami dapat memberikan semua detail itu, dan yang menyenangkan, adalah Anda memiliki kemampuan untuk menelusuri. Jika ada hambatan, Anda bisa menghubungkannya dengan aplikasi, ke pengguna, ke database, ke kueri. Dan sekali lagi, ini semacam pistol merokok. Anda mendapatkan korelasi langsung antara saat kueri ini berjalan, apa yang dilakukannya? Dan ini bukan hanya tentang permintaan itu sendiri, dalam hal mengeksekusi di dalam dan dari dirinya sendiri, tetapi juga apakah permintaan dari waktu ke waktu semakin buruk? Dan hal-hal itu dapat dijawab juga, dengan produk, yang pastinya adalah sesuatu yang jika Anda mencoba untuk menjadi proaktif, senang bisa mengatakan, "Hei, ini pertanyaan yang berjalan buruk, tetapi anak laki-laki melihatnya saat berjalan lebih jauh, kita dapat melihat itu berjalan semakin buruk, saya dapat melakukan sesuatu tentang itu. "

Jika kita pergi ke area berikutnya di sini; dan ini mungkin - saya akan mengatakan ini adalah salah satu yang besar. Salah satu pertanyaan yang saya ajukan, ketika saya menunjukkan produk kami adalah, saya akan selalu bertanya kepada administrator database, "Bagaimana Anda mendengar tentang masalah yang terkait dengan database SQL Server Anda?" Dan itu sangat lucu, karena sebagian besar waktu - sekarang diberikan, sebagian besar waktu mereka melihat produk kami, karena dalam banyak kasus mereka berusaha menyelesaikan kebutuhan tertentu. Tapi itu menarik untuk mendengar hal-hal awal - setidaknya dengan SQL Server, adalah bahwa itu semacam - Anda tahu, pada hari-hari awal SQL Server Anda memiliki SQL Server dan kemudian Anda memiliki Oracle. Dan semua orang memiliki Oracle, dan SQL Server adalah semacam, karena kurangnya ekspresi yang lebih baik, anak tiri berambut merah dari database, ketika pertama kali dimulai.

Dan ketika Microsoft menambahkan lebih banyak fitur ke dalamnya, itu menjadi sedikit lebih dari alat perusahaan. Dan jelas, itu sudah jauh sejak itu. Tapi intinya adalah, suatu kali Anda bisa berdebat bahwa basis data tidak dianggap kritis saat itu. Dan itu berubah seiring waktu. Sekarang karena itu, dalam banyak kasus orang berusaha untuk mengatasinya, dan berkata, “Kamu tahu? Saya punya semua database SQL Server ini, saya mencoba untuk mengatasinya. "Dan daripada mendengar tentang masalah dari help desk, atau mendengar tentang masalah dari orang-orang tertentu yang - seperti para pengguna itu sendiri, mereka Saya sedang mencari cara untuk mengatasinya, mereka mencari cara untuk dapat mengetahui situasi tersebut sebelum terjadi.

Dan dengan Manajer Diagnostik, itulah salah satu hal, yang kami coba lakukan juga, adalah yang paling tidak dapat membuat DBA adalah yang pertama tahu tentang situasi itu, atau masalah itu, sehingga mereka dapat melakukan sesuatu tentang hal itu, baik ketika itu terjadi, atau untuk mengambil bahkan selangkah lebih maju, untuk menganalisis sistem ini yang sedang dipantau. Dan untuk dapat memberi Anda saran proaktif yang akan meningkatkan kinerja contoh itu, dan untuk dapat melakukannya secara teratur. Misalnya, kita perlu menambahkan indeks, berdasarkan pada beban kerja; hal-hal semacam itu, alat yang mampu melakukannya juga. Jadi kita akan melihat banyak hal di alat.

Hal lain dan hal terakhir yang ada dalam daftar ini, yang lebih merupakan gambaran umum, tetapi itu sesuatu yang patut dicatat. Dan terutama, ketika Anda masuk ke jenis situasi tingkat perusahaan yang lebih besar, di mana Anda memiliki banyak contoh, akan selalu ada beberapa hal yang tidak jelas yang ingin saya pantau, jika saya adalah administrator basis data, untuk contoh. Jadi apa yang kami coba lakukan adalah mengantisipasi apa yang ingin dipantau oleh DBA pada umumnya.

Dengan itu dikatakan, Anda juga bisa dalam hal - selalu akan ada sesuatu yang baru. Jadi, kami menyediakan cara bagi Anda untuk menambahkan metrik apa pun yang Anda butuhkan untuk memantau dan mengelola setelah titik pemasangan dapat ditambahkan. Jadi setiap penghitung PerfMon, penghitung WMI, objek counter SQL Server; semua itu dapat dimasukkan ke dalam alat. Anda memiliki kemampuan untuk menambahkan kueri tambahan yang dapat dimasukkan ke dalam interval pemungutan suara Anda.

Dan, hal terakhir yang juga patut dicatat adalah kita dapat menambahkan, dan benar-benar berkomunikasi dengan vCenter dan Hyper-V untuk dapat menarik metrik dari lingkungan tersebut. Karena salah satu hal yang telah kami identifikasi dengan DBA, adalah bahwa mereka biasanya bukan bagian dari operasi secara khusus. Dan mereka biasanya tidak memiliki, Anda tahu, lingkungan vCenter, tersedia untuk mereka, atau hal-hal semacam itu tersedia untuk mereka.

Jadi masalahnya adalah jika mereka berhadapan dengan instance SQL Server, dan mereka telah mengalokasikan sumber daya, tetapi instance itu divirtualisasikan, itu mungkin terlihat seperti mereka memiliki semua sumber daya di dunia, ketika mereka hanya memantau apa pada sistem operasi tamu. Kenyataannya adalah, pada host, mungkin ada 30, atau 40, atau 50 atau 100 VM lain yang mereka coba akses, dan memiliki pendapat tentang sumber daya yang sama. Dan satu-satunya cara untuk benar-benar melihat itu adalah berkomunikasi dengan lingkungan lain itu, dan ke antarmuka itu, dalam hal ini, yang kita lakukan.

Anda memiliki kemampuan untuk menambahkan jenis penghitung lainnya ke dalam alat. Sekarang ini bukan hanya tentang dapat memantau penghitung itu, tetapi tentang mampu membuat penghitung baru itu, yang Anda perkenalkan pada produk, menjadikannya bagian dari alat, seolah-olah itu adalah metrik out-of-the-box . Suatu hal di luar kotak yang ingin Anda pantau; jadi itu berarti bisa memasukkan mereka ke dalam dashboard mereka. Itu berarti bisa menambahkannya ke laporan khusus Anda sendiri, bisa secara jelas menetapkan ambang batas dan mengingatkan mereka, tetapi juga membuat garis dasar mereka dan dapat menetapkan ambang batas dengan beberapa pengetahuan, di mana untuk mengaturnya berdasarkan hal-hal seperti Anda baseline dan apa yang normal. Jadi, Anda memiliki banyak hal yang juga ada dalam produk.

Apa yang saya berikan kepada Anda adalah apa yang saya sebut "hasil inti untuk Manajer Diagnostik, " dan saya dapat melanjutkan dan memberi Anda sedikit rasa dengan masuk ke produk. Yang akan saya lakukan adalah bagikan layar saya, oke, dan hanya akan melakukan ini. Jadi apa yang akan Anda lihat, ini adalah konsol untuk Manajer Diagnostik. Dan seperti yang saya sebutkan sebelumnya, pergi ke pengiriman inti pertama, dapat melihat hal-hal dari jenis tampilan tingkat perusahaan. Ada banyak contoh berbeda dari itu dalam alat. Kami memiliki semacam tampilan thumbnail, kami memiliki lebih banyak tampilan seperti grid. Kami juga memiliki, dalam hal fleksibilitas, kami memiliki konsol berbasis web juga. Konsol berbasis web memiliki pandangan lain yang tersedia untuk Anda, seperti peta kunci dan hal-hal seperti itu. Tetapi intinya adalah, Anda memiliki kemampuan untuk melihat dan melihat berbagai hal. pada tingkat tinggi, tetapi ketika masalah terjadi, Anda akan menggali sedikit lebih jauh ke dalam alat, dan benar-benar melihat masalah spesifik kelihatannya, dan punya beberapa cara untuk memahami dan tahu apa yang terjadi. Dan jelas itu sangat penting.

Sekarang, dalam hal bisa benar-benar melihat apa yang terjadi di masa lalu; jika saya melihat masalah yang terjadi kemarin, atau seminggu yang lalu, maka dalam situasi itu, Anda tahu, Anda akan perlu untuk dapat pergi ke contoh SQL tertentu. Dan kabar baiknya adalah, jika Anda tahu jam berapa masalah itu terjadi dalam produk, Anda bisa langsung menuju ke browser riwayat. Dan saya dapat menunjukkan waktu tertentu dalam sehari; bisa dari beberapa minggu yang lalu, bisa dari kemarin. Tapi hari apa pun yang saya pilih di kalender, saya akan disajikan dengan interval jajak pendapat yang berbeda. Dalam hal ini sekarang, saya secara efektif melihat apa yang akan saya lihat jika saya telah melihat konsol pada 20 April pukul 1:37 siang

Jadi saya dapat kembali ke masa lalu, dan setelah saya melakukannya, semua tab berbeda yang kita lihat di sini akan mencerminkan titik waktu tertentu, termasuk kueri yang mungkin berjalan buruk, termasuk mungkin jika Saya memiliki sesi dengan pemblokiran. Semua hal semacam itu akan muncul di alat, dan itu akan memungkinkan saya untuk dengan jelas memanfaatkan informasi historis untuk dapat, Anda tahu, memperbaiki masalah. Sekarang dalam catatan itu, ketika kita berbicara tentang sejarah, hal lain yang patut dicatat di sini adalah tidak hanya menggunakan sejarah untuk memperbaiki masalah. Sejarah itu jelas sangat berharga, karena alasan lain. Dan, salah satu yang besar adalah untuk dapat membuat keputusan secara efisien, dan untuk dapat membuat keputusan dengan cepat, dengan informasi yang benar. Jadi semua sejarah itu, semua informasi yang kami kumpulkan, dapat kami laporkan.

Jika seseorang datang kepada saya dan berkata, "Saya mendapat aplikasi baru yang sangat bagus ini. Ini akan mengubah dunia seperti yang kita kenal. Oh, omong-omong itu akan membutuhkan database, dan oh omong-omong itu akan benar-benar mematok I / O pada mesin tempat database itu berada. " Jika saya mengetahui hal itu, maka saya dapat memanfaatkan informasi itu untuk dapat memberikan peringkat dari semua server produksi saya, berdasarkan mungkin pada tujuh hari pengumpulan terakhir. Dan saya akan dapat dengan cepat sampai pada kesimpulan yang contoh paling masuk akal untuk menggunakan database itu. Jadi itu adalah jenis informasi historis yang juga jelas sangat berharga.

Dalam hal pertanyaan sendiri; dalam hal melihat pertanyaan, kami memiliki banyak cara berbeda untuk melakukannya di alat. Dan yang saya suka lihat adalah Query Waits View, karena Query Waits View sangat membantu dalam hal kemampuan untuk menilai. Jika saya memiliki bottleneck yang terjadi, pada dasarnya saya dapat mengidentifikasi semua area berbeda yang memengaruhi kueri khusus itu; bukan hanya permintaan itu sendiri dan apa dampak dari permintaan itu, tetapi juga, Anda tahu, dari mana aplikasi itu berasal, dari sesi mana, dari mana pengguna memanggilnya dan semua hal itu, saya dapat melihat bahwa, jelas, informasi secara real time, tetapi saya juga memiliki kemampuan untuk melihat data dari masa lalu. Dan itulah salah satu hal di sini, dan saya memulai sebuah skrip, tetapi saya harus menunggu sampai muncul pop up.

Sementara kita menunggu itu, saya ingin - dan saya tahu kita kekurangan waktu, jadi saya ingin sedikit berbicara juga tentang pemberitahuan pemberitahuan menjadi proaktif. Dan ketika Anda berbicara tentang hal-hal semacam itu, seperti saya katakan, menjadi bagian proaktif, ada banyak alat yang mengingatkan. Bagian yang sulit adalah tidak mengirim email. Bagian yang sulit adalah tidak menulis ke log peristiwa atau menghasilkan perangkap SNMP. Bagian yang sulit adalah mengetahui kapan mengirim peringatan itu pada waktu yang tepat. Dan dengan itu datang banyak harus melakukan beberapa perhitungan, harus memahami, "Ada apa dengan instance tertentu dan apa yang normal seperti yang berkaitan dengan instance itu?"

Dan untuk semua metrik yang masuk akal untuk melakukannya, kami membuat baseline metrik tersebut. Kami benar-benar menunjukkan kepada Anda garis dasar, kami akan menunjukkan kepada Anda batas yang saat ini ditetapkan. Dan hal baik lainnya tentang itu, adalah katakanlah, saya menetapkan ambang batas saya dalam kasus ini enam dan sepuluh hanya untuk contoh ini. Enam minggu dari sekarang, jika saya kembali ke contoh ini, garis dasar ini dapat sepenuhnya berubah, karena salah satu hal yang kami lakukan ketika kami menghitung garis dasar, secara default, adalah perhitungan tujuh hari yang bergulir. Jadi selalu memberi saya versi terbaru dari baseline. Dan apa yang terjadi jika garis dasar itu bergeser ke ambang saya? Dalam hal ini, saya bisa melihat dan mengingatkan rekomendasi yang pada dasarnya mengatakan, "Hei, Anda memiliki ambang batas yang mungkin ditetapkan secara tidak benar, khusus di tempat kami melihat ambang tersebut, dan jelas di mana garis dasarnya berada, Anda mungkin akan dapatkan peringatan untuk sesuatu yang merupakan kejadian normal. "

Jadi daripada mengobati gejala dari sesuatu yang normal, saya dapat mengidentifikasi jenis situasi di mana ambang sebenarnya diatur secara tidak benar. Dan apa yang memungkinkan saya untuk melakukan dengan jelas, adalah mengatur ambang batas sesuai dengan di mana saya akan mendapatkan peringatan. Itu sesuatu yang saya tahu lebih dari seruan untuk bertindak versus penyelidikan untuk melihat apakah itu benar-benar masalah. Dan saya pikir bagian dari alat ini sangat membantu dalam hal baseline itu sendiri, dan mampu menghitung.

Sekarang, dengan produk ini Anda memiliki kemampuan untuk benar-benar memiliki banyak baseline; Anda dapat mengaturnya untuk periode waktu yang berbeda, dan Anda dapat secara dinamis menyesuaikan ambang batas berdasarkan garis dasar Anda, yang juga merupakan bagian yang sangat penting dari jenis adaptasi terhadap perubahan yang terjadi setiap hari untuk instance SQL Server Anda . Sekarang, dalam kasus ini di sini, kami semacam menutupi banyak pengaturan ambang, dan menunjukkan garis dasar. Tetapi sejauh menyangkut peringatan yang sebenarnya, pemberitahuan itu sendiri, hal paling keren tentang Manajer Diagnostik, apakah itu memberi Anda beberapa profil yang mengingatkan. Jadi, jika Anda memiliki, misalnya, profil panggilan dari 2:00 hingga 5:00 pagi, maka saya dapat memiliki profil khusus untuk rentang waktu itu saja, dan saya dapat mengatur semua kondisi, dan pengaturan yang sesuai di sini atas tanggapan saya.

Sekarang, hal tentang tanggapannya adalah bahwa, dalam beberapa kasus, ya saya dapat mengirim email, atau saya dapat menembak dan menghasilkan perangkap SNMP, atau menulis ke log peristiwa. Ada banyak hal lain yang bisa kita lakukan, tetapi ketika saya berbicara dengan DBA, apa yang sebenarnya mereka sukai adalah kenyataan bahwa dalam banyak kasus banyak pekerjaan yang dilakukan adalah hal yang berulang. Itu adalah hal yang mereka tahu persis ketika masalah terjadi, apa yang harus dilakukan untuk memperbaikinya. Mereka hanya harus pergi dan campur tangan. Dan ketika Anda menumbuhkan lingkungan Anda, karena Anda memiliki lebih banyak contoh, itu menjadi jauh lebih sulit untuk dilakukan. Jadi salah satu hal yang dapat Anda lakukan di dalam alat yang menurut saya patut dicatat, adalah Anda memang memiliki kemampuan untuk mengatur suatu kondisi, tetapi berdasarkan kondisi itu untuk dapat mengatur respons untuk menjalankan skrip, untuk menjalankan pekerjaan, untuk menjalankan executable. Dan, intinya adalah jika Anda memutuskan untuk menjalankan skrip saya dapat menggunakan parameter, di dalam skrip yang akan dijalankan, diisi dengan informasi aktual.

Jadi, jika ada masalah dengan database tertentu, skrip akan dirancang untuk berjalan tepat terhadap database di mana masalah terjadi. Jadi, Anda dapat secara dinamis mengatasi masalah dengan cara otomatis, dan kemudian saya masih dapat menerima email untuk kembali dan memberi tahu saya bahwa, "Hei ada masalah, tetapi omong-omong, masalah itu sudah diperbaiki." Script dijalankan, dan sebagai DBA Anda tahu tentang hal itu, tetapi Anda tidak benar-benar harus masuk dan campur tangan. Sekarang, pada catatan yang sama tentang menjadi proaktif, jelas kami juga memiliki fitur lain di sini yang merupakan fitur "Analisis". Dan, apa yang akan dilakukan adalah melakukan pemeriksaan rutin, terhadap contoh SQL. Dan, dalam beberapa kasus ia akan melakukan penyelaman yang lebih dalam dalam hal apa yang dicari. Hal-hal seperti analisis indeks hipotetis akan dilakukan. Apakah saya menambahkan indeks? Apakah saya menghapus indeks? Dan, semua hal itu jelas akan membantu kinerja saya, tetapi sekali lagi, ini semua tentang menjadi proaktif. Ini tentang kemampuan membuat keputusan sebelum barang rusak, dan membuatnya berjalan lebih baik. Dan, dalam banyak kasus, itulah yang sebenarnya kami coba lakukan di sini.

Kembali ke Query Waits yang kita bicarakan sebelumnya; seperti yang Anda lihat, ada lonjakan besar di sini. Saya menjalankan skrip sebelumnya yang hanya menyebabkan beberapa aktivitas menunggu, dan seperti yang saya sebutkan sebelumnya, kami memiliki cara yang sangat unik untuk menelusuri informasi ini. Jika saya ingin melihat aplikasi apa itu; Saya dapat melihatnya berasal dari aplikasi NoSQL. Kita akan dapat melihat basis data yang terkait, sesi, pengguna, dan kemudian jika saya ingin, saya dapat peringkat ini, dalam hal menunggu saya, juga. Jadi, bisa saya katakan, dari semua menunggu yang terjadi di jendela waktu itu, mana yang paling banyak terjadi? Dan jika saya melihat bahwa ketika itu paling banyak terjadi, hal yang sangat menyenangkan adalah saya dapat menelusuri jenis menunggu itu dan saya dapat melihat semua perintah. Jika Anda melihat di sini, mereka membuat menunggu itu terjadi. Dan saya juga bisa melihat terutama, aplikasi apa itu, yang membuat menunggu itu terjadi.

Jadi menonjol seperti jempol yang sakit. Saya dapat segera pergi dan berkata, "Ini adalah aplikasi yang menyebabkan kemacetan saya. Sekarang apa permintaan yang dijalankan? Pengguna mana yang menjalankannya? Basis data mana yang dihadapinya?" Dan seterusnya. Jadi mudah-mudahan itu masuk akal, dan ini juga membantu dalam hal memastikan bahwa Anda tidak memiliki latensi dalam lingkungan Anda, karena ini berkaitan dengan basis data Anda. Semoga ini membantu. Saya akan terus maju pada titik ini dan meneruskannya kembali, dan saya kira kita bisa melanjutkan dari sana.

Eric Kavanagh: Tentu. Jadi, saya kira saya hanya akan melemparkannya ke ahli kami hari ini. Mark, mungkin pertama-tama Anda ingin berkomentar dan mengajukan beberapa pertanyaan. Lalu Dez, kamu bisa berpadu.

Mark Madsen: Ya, terima kasih, saya sangat menikmati menonton ini. Ini adalah pemantauan yang jauh lebih cerdas daripada yang biasa saya lihat. Saya ingin tahu dengan pengelolaan data di balik ini; mengelola metrik yang dapat Anda lacak, dan Anda tahu, mencari hal-hal seperti menggeser garis dasar pada khususnya, yang menjadi salah satu titik sakit hewan peliharaan saya, dengan dasbor. Bagaimana Anda menangani data itu, dan bagian kedua dari itu, adalah dengan, Anda tahu, metrik dasar, seperti jenis pergeseran - apakah Anda memiliki kemampuan untuk secara otomatis menggeser ambang juga, sehingga saya tidak perlu kembali dan mengatur ulang ambang batas dengan tangan, ketika garis dasar bergeser?

Bullett Manale: Anda tahu, dan hal baiknya adalah Anda dapat memutuskan itu. Anda bisa melakukannya. Saya dapat menetapkan ambang batas dan menjadikannya pengaturan statis, atau saya dapat mencentang kotak untuk mengatakan, "Jadikan ini ambang batas dinamis, itu akan berubah ketika garis dasar saya berubah." Dan saya memiliki kemampuan dan alat untuk mengatur jendela default waktu untuk baseline saya, tetapi jika saya perlu, saya mungkin memiliki jendela baseline terpisah, misalnya, dari jendela pemeliharaan saya dari jam 02:00 katakanlah sampai jam 5:00, karena saya akan mengenakan pajak CPU, drive saya, dan yang lainnya karena saat itulah kami melakukan semua perawatan kami, maka secara otomatis, jika saya memilihnya, itu akan secara otomatis menyesuaikan ambang batas saya untuk berada di luar di mana apa pun yang normal untuk metrik yang Saya memilih untuk melakukan itu dengan. Ini akan memungkinkan saya untuk melakukan itu. Pada dasarnya Anda memiliki kemampuan di dalam alat untuk mengatur jendela waktu, yaitu jendela dasar Anda, dan setiap jendela dapat diperlakukan sebagai entitas terpisah, dalam hal penyesuaian garis dasar dinamis yang dapat dilakukan. Dan Anda dapat menambahkan sebanyak mungkin jendela baseline Anda sebagai yo kamu perlu, jika itu masuk akal. Anda bisa memiliki jendela akhir pekan, hari kerja selama jam kerja, jendela pemeliharaan yang terjadi di tengah malam dan seterusnya dan seterusnya.

Mark Madsen: Terima kasih.

Bullett Manale: Saya kira kembali ke bagian pertama dari pertanyaan, kita memang punya, dan mengumpulkan semua informasi ini. Saya tidak benar-benar berbicara tentang arsitektur, tetapi kami memiliki repositori back-end, bahwa Anda memiliki kontrol penuh atas penyimpanan data itu, tetapi kami juga memiliki layanan yang berjalan di tengah malam yang berjalan dan tidak semua perhitungan dasar kami dan dibutuhkan data itu, mengumpulkan, dan membuatnya masuk akal. Dan tentu saja, seiring dengan itu, Anda juga memiliki banyak laporan yang dapat kami gunakan untuk melaporkan terhadap baseline Anda, untuk metrik tertentu. Dan, Anda bahkan memiliki kemampuan untuk membandingkan baseline Anda dari server yang sama, untuk metrik yang sama untuk periode waktu yang berbeda. Anda dapat melihat apakah ada perbedaan yang terjadi, atau apa delta itu. Ada banyak jenis opsi juga.

Eric Kavanagh: Dez.

Dez Blanchfield: Satu pertanyaan singkat yang saya miliki untuk Anda - ada spektrum luas tentang apa yang dapat dilakukan alat ini. Apakah Anda melihat penggunaannya pada tahap awal pengembangan sekarang, atau apakah itu masih merupakan alat lingkungan produksi? Dengan kata lain, apakah pengembang mendapatkan akses dan menggunakannya melalui pengembangan awal mereka, dan kemudian menguji fase integrasi? Atau masih dominan digunakan di lingkungan produksi?

Bullett Manale: Saya akan mengatakan itu, untuk sebagian besar waktu kita melihatnya di lingkungan produksi. Itu tergantung pada situasi, tetapi untuk sebagian besar saya akan mengatakan terutama produksi dan kami lakukan - dan itu juga, Anda tahu, adil untuk menyebutkan bahwa kami memiliki harga yang berbeda untuk dev dan lingkungan pengujian, jadi itu sedikit lebih menarik. Kami memang melihat orang-orang menggunakannya untuk lingkungan tersebut, tetapi saya akan mengatakan, jika saya harus memberikan jawaban kepada Anda dengan satu atau lain cara, saya akan mengatakan itu terutama masih lingkungan produksi di mana kami melihat orang melakukan investasi untuk produk ini. .

Dez Blanchfield: Tentu, ya dan itu menarik untuk mendengar bahwa Anda punya poin harga yang berbeda, karena jelas ada beban kerja yang berbeda, dan semakin berat pekerjaan di mana semua pekerjaan nyata sedang dilakukan. Tetapi saya melihat banyak organisasi, terutama di pemerintahan, dan tentu saja di pertahanan, di mana pembangunan sekarang mendapatkan tingkat investasi yang sama dalam alat dan sistem dengan lingkungan produksi, karena mereka melakukan lebih banyak pengujian di muka. Dalam pertahanan misalnya ada tim yang menjalankan pengujian milyaran, ratusan miliar pengujian pada aplikasi dan sistem dan alat, dan memantau mereka bahkan sebelum mereka pergi ke pengujian integrasi, karena mereka ingin memastikan ada kode yang dibangun dan database itu duduk di bawahnya. Mencapai iterasi seratus juta atau sesuatu, sementara Anda berada di lapangan menembaki seseorang, itu tidak "bang."

Bullett Manale: Tentu.

Dez Blanchfield: Dalam dunia basis data sekolah lama dalam pengalaman saya, berpikir bahwa lingkungan basis data adalah sesuatu yang baru saja meninggalkan data dan beberapa dari Anda tahu, sangat jarang terlihat, dan sangat jarang dibicarakan, jadi ketika kita mendapatkan titik sekarang di mana alat dan aplikasi sedang dikembangkan, terutama dengan platform analitik, mereka sekarang ada di handset kami, dan perangkat kami. Apakah Anda melihat klien membawa perbincangan tentang kinerja basis data dan manajemen basis data dalam diskusi yang lebih sehari-hari sebagai lawan dari teknisi murni? Dan saya tahu Anda sebutkan sebelumnya bahwa sebagian besar Anda berbicara dengan DBA, tetapi apakah sekarang ada kecenderungan di mana ia ada dalam kosa kata umum, apakah Anda melihat orang-orang di mana mereka mendiskusikan topik-topik ini, bukan hanya para geek?

Bullett Manale: Ya itu sulit untuk dikatakan. Maksud saya, seperti yang saya katakan sebagian besar, orang-orang yang berurusan dengan kami dalam hal proses penjualan tetap dengan para praktisi, yang merupakan DBA. Jadi, dalam hal pertanyaan Anda, apakah Anda hanya mengatakan, "Secara umum, orang-orang di dalam organisasi TI, apakah mereka menjadi lebih sadar akan basis data?" Saya kira adalah pertanyaannya dan saya akan mengatakan mungkin jawabannya adalah "ya." Saya mungkin tidak melihatnya terlalu banyak, berdasarkan di mana saya berada, setiap hari, tetapi saya pikir jika saya memahami pertanyaan Anda, itu akan menjadi jawaban saya, saya kira.

Dez Blanchfield: Ya, tidak apa-apa. Ini mungkin pertanyaan yang banyak, maaf, karena jelas minat utama Anda, di dunia Anda, adalah sisi teknis dari banyak hal. Saya ingin tahu bahwa dalam kegiatan sehari-hari saya, saya melihat organisasi mulai membawa ini ke dalam percakapan sangat awal. Jadi, ketika mereka berbicara tentang inisiatif baru, proyek baru, program kerja baru, salah satu hal yang datang segera adalah, "Bagaimana kita memonitornya, bagaimana kita melacaknya, bagaimana menangani masalah ketika mereka muncul, sebagai lawan peluncuran, akan ditayangkan? "

Bullett Manale: Saya akan mengatakan itu -

Dez Blanchfield: Maaf, silakan.

Bullett Manale: Saya akan mengatakan bahwa saya melihat tren, saya kira saya harus mengatakan - Anda tahu, banyak kali di masa lalu Anda akan mendapatkan, "Kami punya masalah, dan sekarang kami membutuhkan alat. " Dan saya pikir kita melihat sedikit lebih banyak penerimaan di sekitar memiliki alat di tempat sebelum masalah terjadi, jika itu masuk akal. Jadi saya akan mengatakan itu menjadi lebih normal, Anda tahu, "Hei, kami membutuhkan alat pemantauan, kami membutuhkan sesuatu." Dan orang-orang pasti melihat nilai dari produk ini, karena seperti yang Anda katakan sebelumnya, hanya menambahkan DBA dan menambahkan contoh baru, Anda perlu sesuatu yang mengelola itu. Anda perlu sesuatu yang membantu dalam pengelolaannya, dan itulah mengapa kami melihat banyak penerimaan di sekitar produk ini juga, atau kami miliki.

Dez Blanchfield: Pertanyaan cepat. Di mana ini harus tinggal? Apakah itu harus duduk tepat di belakang membakar LAN, di dalam pusat data, sedekat mungkin dengan lingkungan basis data, atau apakah nyaman ditempatkan di suatu tempat, berpotensi keluar di awan, awan pihak ketiga dengan semacam baik terowongan VPN atau akses jarak jauh ke berbagai lingkungan? Di mana hal itu perlu dilakukan, sejauh menyangkut lingkungan dan pemantauan?

Bullett Manale: Dalam hal arsitektur, ada repositori back-end, dan itu adalah database SQL Server. Kami memiliki konsol yang dapat berupa klien yang gemuk, atau klien yang kurus; kami memberi Anda pilihan keduanya. Dan kami juga memiliki klien tipis yang benar-benar diarahkan khusus untuk perangkat seluler. Tetapi dalam hal di mana ini sebenarnya bisa duduk; itu bisa duduk di lingkungan, sebenarnya bagian yang lebih sulit dari itu, dari banyak informasi yang perlu kami kumpulkan, memang memerlukan hak administratif, dalam beberapa kasus, atau dalam banyak kasus. Sekarang kami tidak membuat Anda melakukan itu; jika Anda mau, Anda dapat mengumpulkan data dan hanya untuk hal-hal yang tidak dapat kami kumpulkan, karena kami tidak memiliki hak admin, kami hanya akan membiarkan Anda tidak melihat informasi itu, jika itu pilihan yang Anda buat.

Tergantung pada rasanya, seperti jika Anda berbicara tentang AWS, beberapa lingkungan, ia bekerja lebih baik daripada yang lain, tetapi sejauh lingkungan itu sendiri, biasanya baik menggunakan otentikasi SA untuk mengumpulkan data terhadap kejadian adalah semua yang diperlukan. Atau jika itu adalah domain yang tidak dipercaya, biasanya itulah saat Anda ingin melakukannya, tetapi beberapa domain; selama ada kepercayaan di antara mereka, kita bisa mengumpulkan terhadap mereka. Tidak masalah apakah itu di LAN atau di WAN, koleksi yang sebenarnya itu sendiri cukup diabaikan dalam hal jumlah data yang kami kumpulkan. Jika kita memiliki koneksi ukuran WAN yang cukup, itu tidak masalah. Saya telah melihat lingkungan di mana mereka memiliki cabang di mana mereka memiliki SQL Server di seluruh Amerika Serikat. Dan ini adalah satu server di masing-masing lokasi yang berbeda, dan mereka memantaunya secara terpusat. Bagian yang sulit hanyalah memastikan bahwa Anda memiliki jumlah konektivitas yang layak untuk melakukan itu. Mudah-mudahan, itu menjawab pertanyaan Anda, semuanya ada di seluruh peta.

Dez Blanchfield: Benar, tentu saja. Terima kasih. Jadi, dua pertanyaan cepat yang datang melalui peserta pagi ini; satu adalah: apa dampaknya - sering kita melihat alat pemantau sistem menghasilkan beban sendiri dengan hanya memantau hal-hal, jadi pertanyaannya adalah, maaf itu bergulir dari layar saya sekarang, tetapi untuk hanya memparafrasekannya; dengan memantau apakah kita menghasilkan beban sendiri? Apakah ada dampak terukur dari alat ini, hanya mengamati lingkungan, atau apakah itu dampak yang dapat diabaikan?

Bullett Manale: Akan selalu ada sedikit dampak karena harus meminta contoh SQL Server untuk menarik kembali data. Pertanyaan seperti yang Anda katakan adalah, "Apakah bisa diabaikan atau penting?" Di luar kotak Anda menunjuk ke sebuah instance, itu diabaikan. Kami sudah melakukan ini untuk, seperti saya katakan, cukup lama sekarang. Kami memiliki lebih dari 20.000 pelanggan, dan saya dapat meyakinkan Anda bahwa jika hal itu menyebabkan dampak kinerja yang signifikan, kami tidak akan berada dalam bisnis. Dengan itu, kami juga memungkinkan pengguna untuk memutuskan apa yang ingin mereka monitor. Jadi saya pikir itu hal yang penting untuk disebutkan, adalah bahwa setiap lingkungan sedikit berbeda.

Contohnya adalah, dengan komponen pemantau kueri, salah satu hal yang kami dapat lakukan, adalah kami dapat menetapkan ambang batas dari apa yang Anda anggap sebagai batas normalitas Anda. Jadi bisa didasarkan pada waktu pelaksanaan permintaan. Itu bisa didasarkan pada CPU, I / O, tetapi sebagai contoh, katakan saja saya telah mengatur waktu eksekusi saya menjadi nol milidetik. Secara efektif apa yang saya katakan alat untuk lakukan adalah mengumpulkan semua pertanyaan yang berjalan sejak interval menarik terakhir, dan menjadikannya bagian dari koleksi sejarah saya, juga.

Sekarang ketika kita melakukan itu, kita akan mengumpulkan berapa pun jumlah kueri yang kita jalankan di kotak sejak jajak pendapat terakhir. Nah, itu elektif, dan pengguna memiliki kemampuan untuk melakukan itu. Apakah kita mengatakan, "Itu yang harus Anda lakukan"? Tidak. Tetapi kami juga memberi Anda opsi untuk melakukan itu jika Anda ingin sampel data yang memungkinkan Anda untuk mengumpulkan informasi itu. Jadi secara umum, Anda memiliki sarana di dalam alat untuk mengaturnya dan menyetelnya sesuai keinginan Anda, tetapi Anda memiliki kemampuan untuk benar-benar membukanya jika Anda mau, dan mengumpulkan banyak informasi tambahan yang mungkin belum tentu Anda butuhkan secara teratur kumpulkan, jika itu masuk akal.

Dez Blanchfield: Ya, tentu saja. Saya tahu kami berjalan agak lama, tetapi ada dua pertanyaan yang sangat bagus yang ingin saya sampaikan kepada Anda sebelum saya selesai. Mereka berdua datang langsung kepada saya, tetapi saya pikir yang terbaik adalah jika Anda menjawabnya. Pertanyaan umumnya adalah, "Apa cakupan jangkauan alat sejauh pengetahuan tentang sistem yang ada?" Jadi bisakah kita tancapkan ini, dan minta secara otomatis mendeteksi platform yang ada di sana, dan tahu apa yang normal untuk platform itu, dan segera mengambil seperti Mark bicarakan sebelumnya? Beberapa pengetahuan dasar dari platform dengan memasukkan, Anda tahu, saya tidak tahu, itu bisa menjadi Microsoft Dynamics. Apa ruang lingkup pengetahuan platform dengan apa yang normal dan di beberapa alat off-the-shelf saat ini yang digunakan di sekitar bisnis?

Bullett Manale: Saya akan mengatakan bahwa, secara umum, ketika kami mulai mengumpulkan data pada contoh SQL, kami bekerja dengan praktik terbaik untuk memulai, dalam hal ambang batas kami dan di mana mereka diatur. Yang mengatakan, kami juga mengakui bahwa siapa pun yang Anda ajak bicara, dalam hal praktik terbaik, setiap lingkungan berbeda. Apa yang akan kami lakukan pada awalnya kami hanya mengumpulkan data, dan apa yang kami sarankan dilakukan orang, Anda dapat mencoba produk selama 14 hari lebih lama jika perlu. Tetapi setelah sekitar dua hari, Anda akan mulai melihat data dasar terisi. Setelah memiliki informasi sampel yang cukup untuk dikerjakan, maka ia akan mulai memberi Anda konteks dalam hal baseline, di mana jangkauannya, dan semua hal semacam itu. Kemudian dari sana, jika Anda mau, Anda dapat secara otomatis mengatur ambang Anda dari informasi yang telah dikumpulkan. Dibutuhkan sedikit pengumpulan awal dan pemungutan suara untuk dapat mulai menentukan apa yang normal, sehingga Anda dapat mulai menggeser ambang Anda.

Tetapi hal yang saya anggap perlu dicatat juga adalah bahwa, ketika Anda mengubah ambang tersebut, hal itu dapat dilakukan berdasarkan kelompok-per-kelompok dari instance Anda. Ini dapat spesifik untuk satu instance atau Anda dapat melakukannya terhadap semua instances Anda, serta kemampuan untuk membuat hal-hal seperti templat, sehingga Anda dapat mengatakan, "Ini adalah instance produksi, tetapi ini adalah templat yang saya inginkan untuk menetapkan itu. " Jadi ketika instance produksi baru online, kami secara otomatis menerapkan ambang itu untuk itu, karena memiliki jenis perangkat keras yang sama, dan biasanya memiliki beban kerja yang sama, jadi kami juga bisa melakukannya dengan cara itu. Semoga itu membantu dalam hal pertanyaan.

Dez Blanchfield: Benar, tentu saja. Sebenarnya, Anda benar-benar menjawab pertanyaan lain yang baru saja datang kepada saya, dan itu adalah, "Apakah ada unduhan uji coba?" Ada, saya bisa menjawabnya, saya tahu. Saya yakin Anda akan mengonfirmasi bahwa ada unduhan gratis, dan saya pikir Anda mengatakan itu 14 hari dari situs web. Anda dapat mengunduhnya dan bermain dengannya. Saya kira dengan cepat dengan itu, "Lingkungan seperti apa yang saya butuhkan untuk dapat menjalankan uji coba? Dapatkah saya menjalankannya di laptop saya dan bermain dengannya atau apakah saya benar-benar membutuhkan server?"

Bullett Manale: Hal utama yang diperlukan adalah repositori, database SQL Server yang 2005 atau lebih baru. Selain itu, ada beberapa persyaratan sumber daya minimal, persyaratan .NET, dan hanya itu. Jadi, itu hanya masalah menginstal produk dan membuat basis data.

Dez Blanchfield: Sempurna. Satu pertanyaan terakhir yang akan saya sampaikan kepada Anda, karena kami kehabisan waktu sekarang, tetapi dengan cepat, sekitar dua atau tiga orang bertanya kepada saya, "Apakah saya perlu menjadi DBA untuk benar-benar dapat bangun dan berjalan dengan ini, dan bermain dengannya? ”

Bullett Manale: Tidak. Saya akan mengatakan bahwa, jika Anda seorang DBA, Anda akan memiliki berbagai kegunaan alat ini. Maksudku, mungkin akan ada nilai yang sedikit lebih jika Anda seorang DBA berpengalaman. Anda akan melihat lebih dalam untuk alat yang dapat Anda manfaatkan. Tetapi juga sebagai DBA baru, atau bahkan orang yang, itu bukan DBA, kami memiliki banyak rekomendasi, dan saya di halaman itu sekarang. Rekomendasi ini akan muncul secara teratur, dan hal yang benar-benar menyenangkan dari rekomendasi tersebut, adalah memberi Anda alasan mengapa rekomendasi tersebut dibuat. Namun selain itu, mereka juga akan memiliki tautan ke konten eksternal yang menjelaskan lebih detail tentang alasan mengapa rekomendasi tersebut dibuat juga. Sehingga akan terhubung ke situs web eksternal Microsoft, blog, dan semua hal seperti itu, itu eksternal.

Tetapi untuk menjawab pertanyaan Anda, itu semacam, Anda tahu, jika Anda seorang DBA senior, akan ada banyak hal di sini, Anda mungkin akan mengambil keuntungan dari, bahwa Anda mungkin tidak akan menjadi DBA pemula. Tetapi pada saat yang sama, itu juga merupakan alat pembelajaran, karena ketika Anda membaca rekomendasi ini, Anda akan mulai mengambil beberapa hal ini sendiri melalui penggunaan rekomendasi.

Dez Blanchfield: Fantastis. Terima kasih. Saya sangat menikmati bagian demo. Presentasinya luar biasa. Demo itu fantastis. Dengan cepat dari memori, ada seluruh pusat sumber daya di situs web Anda yang saya sarankan orang-orang juga melihatnya. Saya ingat melewati itu tadi malam untuk mendapatkan beberapa detail. Anda memiliki banyak hal, hanya dari blog, data, dan percakapan hingga, dari memori, Anda juga memiliki sebagian besar produk dokumentasi online, ya?

Bullett Manale: Ya, itu benar, dan bentuk yang saya pikir Anda rujuk adalah situs community.idera.com. Dan satu hal yang akan saya sebutkan juga, sebelumnya Anda bertanya tentang, "Apakah ini akan mengenali lingkungan?" Dalam hal instance baru atau menambahkan instance, ada alat lain yang kami miliki yang dapat menemukan instance. Dan itu semua tentang inventaris dan mengelola inventaris Anda. Saya hanya akan mengarahkan Anda ke arah itu, dalam hal benar-benar menemukan contoh. Namun sejauh sebenarnya kinerja dan pemantauan, semua hal yang kami bicarakan, di situlah Manajer Diagnostik akan berperan.

Dez Blanchfield: Fantastis. Lihat, cakupan yang bagus. Sangat menikmati presentasi Anda. Saya suka demo langsung dan itu saja dari saya pagi ini, karena saya tahu kita mungkin sudah 10 menit dari waktu ke waktu. Eric, aku akan membalasmu.

Eric Kavanagh: Baiklah. Saya hanya menyukai demo. Saya senang Anda melakukan demo. Saya senang kita harus melihat dengan saksama saat kita menjalani Q&A.

Bullett Manale: Hebat.

Eric Kavanagh: Karena ini memberi orang gambaran tentang apa yang Anda lihat, dan itu benar-benar membuat saya takjub berpikir bahwa kita masih belajar tentang cara berbicara dengan komputer ini, ketika Anda langsung melakukannya. Maksudku, tingkat diagnostik ini cukup canggih, dan semakin baik setiap hari. Kami mendapat lebih banyak wawasan tentang apa yang sebenarnya terjadi. Tetapi Anda benar-benar membutuhkan seseorang yang menghadap hal-hal ini, membacanya, menempatkan kemampuan kognitif di balik apa yang Anda lakukan, bukan?

Bullett Manale: Ya, maksud saya dalam banyak kasus - saya berharap saya bisa memberi tahu Anda ini adalah DBA di dalam kotak, tetapi ada terlalu banyak hal yang terjadi. Maksud saya, kami memang memberikan panduan, dan kami memang membantu, tetapi pada akhirnya itu mengharuskan orang membuat keputusan tentang data yang kami sajikan. Saya tidak berpikir itu akan berubah dalam waktu dekat.

Eric Kavanagh: Ya, itu kabar baik bagi orang-orang di luar sana, kawan.

Bullett Manale: Benar.

Eric Kavanagh: Anda ingin seseorang menonton ini, tim yang menonton ini, dan Anda akan belajar, seperti yang Anda dengar dari Bullett di sini, dengan melihat rekomendasi ini Anda akan mengambil apa yang terjadi. Dan saya menebak dari sejarah itu, dan saya pikir Anda telah menyentuh ini, Bullett, tetapi sangat cepat, bahwa sejarah memungkinkan Anda untuk mengenali pola-pola yang signifikan dan karenanya dapat mengidentifikasi mereka ketika itu terjadi di masa depan, bukan?

Bullett Manale: Itu benar. Salah satu hal yang dapat kita lakukan adalah melacak kinerja kueri dari waktu ke waktu. Kita juga dapat dengan jelas melihat hal-hal lain, seperti garis dasar dan melihatnya bergeser, dan jelas mendapat peringatan dan hal-hal seperti itu ketika itu terjadi, jadi Anda pasti memiliki kemampuan itu.

Eric Kavanagh: Kedengarannya bagus, kawan. Kami tidak akan lama di sini, tetapi saya ingin mendapatkan pertanyaan-pertanyaan itu. Terima kasih banyak atas waktu dan perhatiannya. Kami mengarsipkan semua webcast ini. Lompat online ke Techopedia.com atau ke InsideAnalysis.com, Anda akan melihat tautan dari kedua tempat.

Dan dengan itu, kami mengucapkan selamat tinggal. Terima kasih sekali lagi, teman-teman, kami akan menyusul Anda minggu depan, tiga lagi webcast minggu depan, Selasa, Rabu, Kamis. Jadi kami akan berbicara dengan Anda minggu depan, kawan. Hati hati. Sampai jumpa.

Mitra Konten Techopedia

Staf Techopedia berafiliasi dengan Bloor Group dan dapat dihubungi menggunakan opsi di sebelah kanan. Untuk info tentang cara kami bekerja dengan mitra industri klik di sini.

• Profil
• Situs web