Bawa pulang: Host Eric Kavanagh membahas ramalan dengan Dr. Robin Bloor, Rick Sherman dan IDERAs Bullett Manale.
Anda harus mendaftar untuk acara ini untuk melihat video. Daftar untuk melihat videonya.
Eric Kavanagh: Hadirin sekalian, halo sekali lagi dan selamat datang kembali ke seri webcast Hot Technologies! Nama saya Eric Kavanagh, saya akan menjadi tuan rumah seminar web hari ini, yang disebut “Menghemat Waktu, Uang, dan Masalah dengan Prakiraan yang Optimal.” Tentu saja saya melewatkan bagian pertama dari judul di sana, “Rencana Penempatan Terbaik.” Kami selalu berbicara tentang itu di acara ini. Jadi, Hot Technologies tentu saja adalah forum kami untuk memahami apa yang beberapa produk keren ada di dunia saat ini, dunia teknologi perusahaan, apa yang dilakukan orang-orang dengan mereka, bagaimana mereka bekerja, semua hal menyenangkan semacam itu.
Dan topik hari ini, seperti yang saya sarankan, berkaitan dengan peramalan. Anda benar-benar berusaha memahami apa yang akan terjadi di organisasi Anda. Bagaimana Anda akan membuat pengguna Anda bahagia, apa pun yang mereka lakukan? Jika mereka melakukan analisis, jika mereka melakukan pekerjaan nyata, mereka menghadapi pelanggan nyata dengan sistem transaksional, apa pun masalahnya, Anda ingin memahami bagaimana sistem Anda berjalan dan apa yang sedang terjadi, dan itulah yang dibicarakan dengan baik hari ini. Agak lucu karena peramalan bukan sesuatu yang saya suka lakukan, karena saya percaya takhayul, seperti saya pikir jika saya terlalu banyak meramalkan, hal-hal buruk akan terjadi, tetapi itu hanya saya. Jangan ikuti petunjuk saya.
Jadi, inilah presenter kami hari ini, milik Anda benar-benar di sudut kiri atas, Rick Sherman sedang menelepon dari Boston, teman kami Bullett Manale dari IDERA dan Dr. Robin Bloor kami sendiri. Dan dengan itu, saya akan menyerahkannya kepada Robin dan hanya mengingatkan orang-orang: Ajukan pertanyaan, jangan malu-malu, kami suka pertanyaan yang bagus, berikan kepada presenter kami dan yang lainnya hari ini. Dan dengan itu, Robin, bawa pergi.
Robin Bloor: OK, well, karena saya di posisi terdepan seperti yang mereka katakan, saya pikir saya menceritakan kisah SQL hari ini, karena itu latar belakang untuk apa diskusi yang akan berlangsung dan pasti akan tidak berbenturan dengan karena Rick tidak fokus pada ini , dan tidak akan berselisih dengan apa yang dikatakan Rick. Jadi, dalam cerita SQL, ada beberapa hal menarik tentang SQL karena sifatnya yang begitu dominan. Lihat, itu salah ketik, SQL adalah bahasa deklaratif. Idenya adalah bahwa Anda dapat membuat bahasa di mana Anda akan meminta apa yang Anda inginkan. Dan basis data akan mencari cara mendapatkannya. Dan itu bekerja dengan cukup baik, sebenarnya, tetapi ada sejumlah hal yang agak layak dikatakan tentang hal itu, konsekuensi dari mendasarkan seluruh industri TI pada bahasa deklaratif. Pengguna tidak tahu atau peduli tentang organisasi fisik data, dan itulah hal yang baik tentang bahasa deklaratif - itu memisahkan Anda dari semua itu, dan bahkan mengkhawatirkannya - hanya meminta apa pun yang Anda inginkan, dan database akan pergi dan mendapatkannya.
Tetapi pengguna tidak tahu apakah cara mereka menyusun permintaan SQL akan mempengaruhi kinerja permintaan dan itu sedikit kelemahan. Saya pernah melihat pertanyaan yang panjangnya ratusan dan ratusan baris, yang hanya satu permintaan SQL, Anda tahu, dimulai dengan "pilih" dan hanya berjalan terus-menerus dengan sub-permintaan dan seterusnya dan seterusnya. Dan ternyata bahwa jika Anda ingin kumpulan data tertentu dari database, Anda dapat memintanya dengan berbagai cara dengan SQL, dan mendapatkan jawaban yang sama jika Anda memiliki pengetahuan tentang data. Jadi, satu permintaan SQL tidak selalu merupakan cara terbaik untuk meminta data, dan basis data akan merespons dengan sangat berbeda sesuai dengan SQL yang Anda masukkan ke dalamnya.
Jadi, SQL benar-benar memengaruhi kinerja, sehingga orang yang menggunakan SQL, kebenarannya, juga pemrogram SQL yang menggunakan SQL dan mereka bahkan lebih kecil kemungkinannya untuk memikirkan dampak yang akan mereka miliki, karena sebagian besar fokus mereka sebenarnya pada manipulasi data dan bukan pada mendapatkan, menempatkan data. Dan hal yang sama juga berlaku pada alat BI, saya telah melihat SQL yang, jika Anda suka, keluar dari alat BI dari berbagai database dan harus dikatakan, bahwa banyak dari itu, baik, saya tidak akan menulis query SQL seperti itu. Seseorang telah membuat, jika Anda suka, motor kecil yang apa pun parameternya, ia akan membuang beberapa SQL, dan sekali lagi, bahwa SQL tidak harus menjadi SQL yang efisien.
Lalu saya pikir saya menyebutkan ketidakcocokan impedansi, data yang digunakan programmer berbeda dari data seperti itu. Jadi, DMS kami menyimpan data dalam tabel, mengatur kode berorientasi objek sebagian besar adalah coders, pemrograman bentuk berorientasi objek saat ini dan mereka memesan data dalam struktur objek, sehingga tidak memetakan satu sama lain. Jadi, ada kebutuhan untuk menerjemahkan dari apa yang dipikirkan programmer data ke apa database berpikir apa data itu. Yang sepertinya kita telah melakukan sesuatu yang salah untuk itu menjadi masalahnya. SQL memiliki DDL untuk definisi data, ia memiliki DML - bahasa manipulasi data - pilih, proyeksikan dan bergabung, untuk mendapatkan data itu. Sekarang, ada sangat sedikit matematika dan hal-hal berbasis waktu yang sangat sedikit, jadi itu bahasa yang tidak sempurna, meskipun harus dikatakan diperpanjang dan terus diperluas.
Dan kemudian, Anda mendapatkan masalah pembatas SQL, yang selalu lebih lurus daripada diagram, dalam hal itu tetapi banyak orang yang mengajukan pertanyaan untuk alasan analitis, setelah mereka mendapatkan jawaban untuk persyaratan data pertanyaan, ingin mengajukan pertanyaan lain. Jadi, itu menjadi hal dialog, yah, SQL tidak dibangun untuk dialog, itu dibangun untuk menanyakan apa yang Anda inginkan sekaligus. Dan jenisnya perlu diketahui, karena ada beberapa produk di luar sana yang benar-benar meninggalkan SQL untuk memungkinkan percakapan antara pengguna dan data.
Dalam hal kinerja database - dan jenis ini menyebar ke segala sesuatu - ya, ada CPU, ada memori, ada disk, ada overhead jaringan dan ada masalah penguncian lebih dari satu orang yang ingin memiliki penggunaan data secara eksklusif pada suatu waktu tertentu titik waktu. Tapi ada juga panggilan SQL yang buruk, ada banyak sekali yang dapat dilakukan jika Anda benar-benar mengoptimalkan SQL, dalam hal kinerja. Jadi, faktor kinerja basis data: desain buruk, desain program buruk, konkurensi beban kerja hilang, penyeimbangan beban, struktur kueri, perencanaan kapasitas. Itu adalah pertumbuhan data. Dan dalam beberapa kata, SQL itu mudah, tetapi tidak mengoptimalkan sendiri.
Karena itu, saya pikir kita bisa meneruskan ke Rick.
Eric Kavanagh: Baiklah, Rick, izinkan saya memberi Anda kunci ke mobil WebEx. Bawa pergi.
Rick Sherman: Baiklah, bagus. Terima kasih Robin, ketika kami memulai di awal presentasi, grafik saya masih cukup membosankan, tapi ikuti saja. Jadi, saya setuju dengan semua yang dibicarakan Robin di sisi SQL. Tapi yang ingin saya konsentrasikan sekarang adalah permintaan akan data, yang dengan sangat cepat melewati, pasokan seperti pada alat yang digunakan di ruang itu atau kebutuhan akan alat di ruang itu.
Pertama, ada beberapa di setiap artikel yang Anda baca terkait dengan data besar, banyak data, data tidak terstruktur yang berasal dari cloud, data besar di mana saja yang dapat Anda bayangkan. Tetapi pertumbuhan pasar database terus menerus dengan SQL, database relasional mungkin pada 2015, masih 95 persen dari pasar database. Tiga vendor relasional teratas memiliki sekitar 88 persen pangsa pasar di ruang tersebut. Jadi, masih berbicara, ketika Robin berbicara, tentang SQL. Dan sebenarnya, bahkan jika sedang mencari di platform Hadoop, Hive dan Spark SQL - yang digunakan anak saya, yang seorang ilmuwan data, gunakan sepanjang waktu sekarang - tentu saja merupakan cara dominan bagi orang untuk mendapatkan data.
Sekarang, di sisi basis data, ada dua kategori besar penggunaan basis data. Salah satunya adalah untuk sistem manajemen basis data operasional, jadi perencanaan hubungan perusahaan, pengelolaan hubungan pelanggan, Salesforce ERP, Oracles, EPICs, N4s, dll., Dari dunia. Dan, ada sejumlah besar dan jumlah data yang meluas di gudang data dan sistem berbasis intelijen bisnis lainnya. Menyebabkan semuanya, terlepas dari di mana dan bagaimana ia ditangkap, disimpan atau ditransaksikan, pada akhirnya dianalisis dan ada permintaan besar dan peningkatan dalam penggunaan basis data, terutama basis data relasional di pasar.
Sekarang, kami sudah mendapatkan permintaan, kami memiliki data dalam jumlah besar. Dan saya tidak benar-benar berbicara hanya tentang data besar, saya berbicara tentang penggunaan data di semua jenis perusahaan. Tetapi menyertai hal itu dari sisi penawaran, untuk orang-orang yang dapat mengelola sumber daya tersebut, pertama-tama kami memiliki, kami memiliki semacam kekurangan DBA. Kami memiliki menurut Biro Statistik Tenaga Kerja, dari 2014-2024 pekerjaan DBA hanya akan tumbuh sebesar 11 persen - sekarang orang-orang yang memiliki jabatan pekerjaan DBA, tetapi berbicara tentang hal itu dalam hitungan detik - versus 40-plus persen ruang pertumbuhan data tahunan. Dan kami memiliki banyak DBA; rata-rata bahwa studi yang sama berbicara tentang usia rata-rata cukup tinggi dibandingkan dengan profesi TI lainnya. Dan kemudian kita memiliki banyak orang meninggalkan lapangan, tidak harus pensiun, tetapi beralih ke aspek lain, masuk ke manajemen, atau apa pun.
Sekarang, bagian dari alasan mereka pergi, adalah karena pekerjaan DBA terus semakin sulit. Pertama, kami memiliki DBA yang mengelola banyak basis data sendiri, basis data fisik, yang terletak di semua tempat, serta berbagai jenis basis data. Sekarang mungkin bersifat relasional, atau mungkin juga basis data lain, jenis basis data juga. Tetapi bahkan jika itu berhubungan, mereka dapat memiliki satu, dua, tiga, empat vendor berbeda yang sebenarnya mereka coba kelola. DBA biasanya terlibat setelah desain basis data atau aplikasi. Robin berbicara tentang bagaimana database atau aplikasi dirancang, bagaimana SQL dirancang. Nah, ketika sedang berbicara tentang pemodelan data, pemodelan ER, pemodelan ER diperpanjang, pemodelan dimensi, pemodelan dimensi maju, apa pun, biasanya pemrogram aplikasi dan pengembang aplikasi merancang dengan tujuan akhir mereka dalam pikiran - mereka tidak merancang untuk efisiensi struktur database itu sendiri . Jadi kami memiliki banyak desain yang buruk.
Sekarang, saya tidak berbicara tentang vendor aplikasi perusahaan komersial; mereka biasanya memiliki model ER atau model ER diperpanjang. Apa yang saya bicarakan adalah ada lebih banyak proses bisnis dan aplikasi yang sedang dibangun oleh pengembang aplikasi di setiap perusahaan - mereka adalah yang tidak perlu dirancang untuk efisiensi atau efektivitas penyebaran. Dan DBA sendiri terlalu banyak bekerja dan kadang-kadang mereka memiliki tanggung jawab 24/7, mereka terus mendapatkan lebih banyak database. Saya pikir itu sedikit membantu orang tidak mengerti apa yang mereka lakukan, atau bagaimana mereka melakukannya. Kelompok kecil mereka sendiri dan orang-orang hanya terus berpikir, "Yah semua alat ini sangat mudah digunakan, kita bisa terus menggunakan lebih banyak dan lebih banyak basis data pada beban kerja mereka," yang bukan itu masalahnya.
Yang membawa kita ke DBA paruh waktu dan tidak disengaja. Kami memiliki tim IT yang kecil dan mereka tidak dapat membeli DBA khusus. Nah, itu berlaku untuk usaha kecil hingga menengah, di mana perluasan basis data dan aplikasi basis data telah meledak dalam dekade terakhir dan terus berkembang. Tapi itu juga kasus perusahaan besar, biasanya telah melakukan pergudangan data, analisis intelijen bisnis untuk waktu yang sangat lama. Dahulu kala kami biasa mendapatkan DBA khusus untuk proyek-proyek itu; kami tidak pernah mendapatkan DBA khusus lagi. Bertanggung jawab untuk mendesain database, yang baik-baik saja, jika itu seseorang yang memiliki pengalamanTetapi secara umum, DBA adalah pengembang aplikasi, mereka sering mengambil peran itu sebagai bagian paruh waktu dari pekerjaan mereka, mereka tidak memiliki pelatihan formal di dalamnya dan sekali lagi, mereka merancang untuk tujuan akhir mereka, mereka tidak merancang untuk efisiensi.
Dan ada banyak perbedaan antara desain dan pengembangan, versus penyebaran dan manajemen. Jadi, kita memiliki "uang receh, pound bodoh," dengan celengan kecil di sana, melewatkan mendapatkan keterampilan dan sumber daya yang dibutuhkan dalam proyek. Berpikir bahwa semua orang berasal dari "Revenge of the Nerds," foto kecil saya di sana. Sekarang, sejauh yang dibutuhkan orang, jadi kami memiliki perluasan penggunaan basis data dan data dalam SQL. Kami memiliki jumlah DBA yang terbatas - orang-orang yang terampil dan ahli dalam pengaturan dan perancangan serta manajemen dan penempatan ini. Dan kami memiliki lebih banyak paruh waktu atau tidak sengaja DBA, orang-orang yang belum memiliki pelatihan formal.
Jadi, apa saja hal-hal lain yang juga masuk ke dalam masalah fakta bahwa basis data ini tidak disetel juga, atau dikelola juga? Pertama, banyak orang beranggapan bahwa sistem database itu sendiri memiliki alat yang cukup untuk mengelola diri mereka sendiri. Sekarang, alat semakin mudah dan lebih mudah untuk dilakukan - desain dan pengembangan - tetapi itu berbeda dari melakukan desain yang baik, dan pengelolaan yang baik, perencanaan kapasitas, pemantauan, dll untuk penyebaran. Jadi, pertama-tama, orang berasumsi bahwa mereka memiliki semua alat yang mereka butuhkan. Kedua, jika Anda seorang DBA paruh waktu atau tidak disengaja, Anda tidak tahu apa yang tidak Anda ketahui.
Saya kira saya lupa beberapa ungkapan di sana, sehingga sering kali mereka tidak mengerti apa yang mereka perlu lihat dalam desain atau ketika mereka mengelola atau mengoperasikan database. Jika itu bukan profesi Anda, maka Anda tidak akan mengerti apa yang perlu Anda lakukan. Yang ketiga, adalah bahwa SQL adalah alat bantu, jadi Robin berbicara tentang SQL, dan seberapa buruk SQL kadang-kadang dibangun, atau sering dibangun. Dan juga salah satu kencing hewan peliharaan saya di pergudangan data BI, migrasi data, ruang rekayasa data adalah bahwa daripada menggunakan alat, orang-orang memiliki kecenderungan untuk menulis kode SQL, prosedur yang tersimpan, bahkan jika mereka menggunakan alat integrasi data yang mahal atau mahal Alat BI, mereka sering benar-benar menggunakannya hanya untuk menjalankan prosedur yang tersimpan. Sehingga pentingnya memahami desain basis data, konstruksi SQL, semakin penting.
Dan akhirnya ada pendekatan silo ini, di mana kita memiliki orang-orang individu melihat pada basis data individu. Mereka tidak melihat bagaimana aplikasi bekerja dan berinteraksi satu sama lain. Dan mereka juga benar-benar sering melihat database versus aplikasi yang mereka gunakan. Jadi, beban kerja yang Anda dapatkan di database sangat penting dalam desain, kritis dalam menyetelnya, penting dalam mencoba mencari cara untuk merencanakan kapasitas, dll. Jadi, melihat hutan dari pohon, orang-orang di gulma , melihat masing-masing tabel dan database dan tidak melihat interaksi keseluruhan dari aplikasi ini dalam beban kerja.
Akhirnya, orang perlu melihat bidang-bidang utama yang perlu mereka perhatikan. Ketika mereka berencana untuk mengelola database, mereka harus terlebih dahulu berpikir tentang, mengembangkan beberapa metrik kinerja aplikasi-sentris, sehingga mereka perlu melihat tidak hanya bagaimana tabel ini disusun, bagaimana modelnya, tetapi bagaimana penggunaannya? Jadi, jika Anda memiliki aplikasi perusahaan yang ada dalam manajemen rantai pasokan, jika Anda menerima pesanan dari web, jika Anda melakukan BI - apa pun yang Anda lakukan - Anda perlu melihat siapa yang menggunakannya, bagaimana mereka menggunakannya, berapa volume data , ketika itu akan terjadi. Apa yang benar-benar Anda coba cari adalah waktu tunggu, karena bagaimanapun juga, semua aplikasi dinilai berdasarkan berapa lama untuk menyelesaikan sesuatu, apakah itu orang atau hanya pertukaran data antara aplikasi atau prosesor. Dan apa hambatannya? Jadi sering kali ketika Anda mencoba untuk men-debug masalah, tentu saja, Anda benar-benar mencoba untuk melihat apa saja hambatan yang sebenarnya - belum tentu cara memperbaiki semuanya, tetapi bagaimana Anda menyingkirkan dan meningkatkan kinerja pada waktu tunggu dan throughput - apa pun Anda perlu melihatnya.
Dan Anda benar-benar perlu memisahkan pengambilan data, transaksi, aspek transformasi dalam database beserta analitiknya. Masing-masing memiliki pola desain yang berbeda, masing-masing memiliki pola penggunaan yang berbeda dan masing-masing harus disetel secara berbeda. Jadi, Anda perlu berpikir tentang bagaimana data ini digunakan, kapan digunakan, untuk apa digunakan, dan mencari tahu apa metrik kinerja dan apa hal-hal kunci yang ingin Anda analisis terkait dengan penggunaan itu. Sekarang, ketika Anda melihat pemantauan kinerja, Anda ingin melihat operasi basis data itu sendiri; Anda ingin melihat struktur data, sehingga indeks, partisi, dan aspek fisik lainnya dari basis data, bahkan struktur basis data - apakah model ER atau model dimensionalnya, namun terstruktur - semua hal itu berdampak pada kinerja , terutama dalam kontra yang berbeda dari analisis penangkapan data dan transformasi yang terjadi.
Dan seperti yang disebutkan Robin di sisi SQL, melihat SQL sedang dijalankan oleh berbagai aplikasi di seluruh basis data ini, dan menyetelnya sangat penting. Dan melihat keseluruhan beban kerja aplikasi, dan lingkungan infrastruktur tempat database dan aplikasi ini berjalan. Jadi, bahwa jaringan, server, cloud - apa pun yang sedang mereka jalankan - juga melihat dampak yang dimiliki aplikasi ini dan database ini di dalam con itu, semua ini memiliki interaksi yang saling mempengaruhi untuk dapat menyempurnakan database.
Dan akhirnya, ketika Anda melihat alat, Anda ingin dapat melihat tiga jenis analitik yang terkait dengan itu. Anda ingin melihat analisis deskriptif: apa yang terjadi dan di mana, terkait dengan database dan kinerja aplikasi. Anda ingin memiliki kemampuan untuk melakukan analisis diagnostik untuk mengetahui tidak hanya apa yang terjadi tetapi mengapa itu terjadi, di mana kemacetannya, di mana masalahnya, apa yang berjalan dengan baik, apa yang tidak berjalan dengan baik? Tetapi dapat menganalisis dan menelusuri ke area masalah untuk mengatasinya, baik untuk desain atau apa pun yang perlu Anda lakukan.
Dan akhirnya, jenis analisis yang paling agresif atau proaktif adalah benar-benar melakukan beberapa analisis prediktif, pemodelan analitik prediktif, apa pun. Kita tahu bahwa basis data dan aplikasi berfungsi dalam con ini, jika kita meningkatkan kapasitas, jika kita mendapatkan lebih banyak pengguna, jika kita melakukan lebih banyak throughput, apa pun yang dilakukan, dapat memproyeksikan apa, bagaimana dan di mana itu akan berdampak pada database, aplikasi, memungkinkan kita untuk merencanakan dan mencari tahu secara proaktif, di mana hambatannya, di mana waktu tunggu mungkin menderita dan apa yang perlu kita lakukan untuk memperbaiki keadaan. Jadi kami ingin memiliki alat yang mampu mengimplementasikan metrik kinerja, memantau kinerja, seperti dalam melakukan ketiga jenis analisis ini. Dan itulah gambaran saya.
Eric Kavanagh: Baiklah, biar saya serahkan - itu adalah dua presentasi hebat, omong-omong - biarkan saya serahkan ini pada Bullett Manale untuk mengambilnya dari sana. Dan teman-teman, jangan lupa untuk mengajukan pertanyaan bagus; kami sudah memiliki konten yang bagus. Bawa pergi, Bullett.
Bullett Manale: Kedengarannya bagus. Terima kasih, Eric. Jadi, banyak yang dikatakan Rick dan Robin, jelas saya setuju dengan 100 persen. Saya akan mengatakan bahwa saya menarik slide ini ke atas, karena saya pikir itu pas, saya tidak tahu bagi Anda yang adalah penggemar "A-Team" di tahun 80-an, John Hannibal Smith memiliki pepatah mengatakan selalu mengatakan, "Saya suka ketika sebuah rencana datang bersama-sama, "dan saya pikir ketika Anda berbicara tentang SQL Server, yang merupakan fokus, yang merupakan produk yang akan dibicarakan hari ini, SQL Diagnostic Manager, itu pasti salah satu hal yang Anda harus memiliki; Anda harus dapat memanfaatkan data yang Anda miliki, dan dapat membuat keputusan dari data itu, dan dalam beberapa kasus, Anda tidak mencari keputusan; Anda sedang mencari sesuatu untuk memberi tahu Anda ketika sesuatu akan kehabisan sumber daya, ketika Anda akan kehabisan sumber daya, ketika Anda akan mengalami hambatan, hal-hal semacam itu.
Ini bukan hanya tentang memonitor metrik tertentu. Jadi, dengan Manajer Diagnostik, salah satu hal yang dilakukannya dengan sangat baik adalah membantu Anda dalam hal perkiraan, dan memahami secara spesifik beban kerja dan akan membicarakan banyak hal hari ini. Alat ini diarahkan untuk manajer data, DBA atau DBA akting, jadi banyak hal yang disebutkan Rick, akting DBA sangat benar. Dalam banyak kasus, jika Anda bukan DBA, akan ada banyak tanda tanya yang akan Anda miliki ketika tiba saatnya untuk mengelola lingkungan SQL, hal-hal yang tidak Anda ketahui. Maka Anda mencari sesuatu untuk membantu Anda, membawa Anda melalui proses itu, dan juga mendidik Anda dalam proses itu juga. Jadi, penting bahwa alat yang Anda gunakan untuk keputusan semacam itu akan memberi Anda wawasan tentang alasan mengapa keputusan itu dibuat, itu tidak hanya memberi tahu Anda, "Hei, lakukan ini."
Karena saya adalah akting DBA, akhirnya saya mungkin menjadi DBA penuh dengan keahlian dan pengetahuan yang sebenarnya untuk mendukung gelar itu. Jadi, yang mengatakan, ketika berbicara tentang menjadi administrator basis data - Saya selalu menunjukkan slide ini terlebih dahulu, karena DBA memiliki beberapa peran yang berbeda dan tergantung pada organisasi yang Anda miliki, Anda akan miliki, mereka akan berbeda dari satu tempat ke tempat lain - tetapi biasanya, Anda akan selalu bertanggung jawab atas penyimpanan Anda, perencanaan penyimpanan dan pemahaman Anda tentang antisipasi, saya harus mengatakan, berapa banyak ruang yang akan Anda butuhkan, apakah itu untuk cadangan Anda, atau apakah itu untuk database sendiri. Anda harus memahami dan menilai itu.
Selain itu, Anda harus dapat memahami dan mengoptimalkan berbagai hal berdasarkan kebutuhan, dan saat Anda melakukan pemantauan lingkungan, jelas penting bagi Anda untuk melakukan perubahan sesuai kebutuhan berdasarkan pada hal-hal yang berubah dalam lingkungan. diri. Jadi, hal-hal seperti jumlah pengguna, hal-hal seperti popularitas aplikasi, musiman database, semua harus dipertimbangkan ketika Anda melakukan peramalan. Dan kemudian, jelas melihat hal-hal lain dalam hal dapat memberikan laporan dan informasi yang diperlukan karena berkaitan dengan pengambilan keputusan tersebut. Dalam banyak kasus itu berarti melakukan analisis komparatif; itu berarti bisa melihat secara spesifik pada metrik tertentu dan memahami apa nilai metrik itu dari waktu ke waktu, sehingga Anda dapat mengantisipasi ke mana akan bergerak maju.
Jadi apa yang dilakukan banyak alat oleh Manajer Diagnostik memiliki kemampuan itu dan orang-orang menggunakannya setiap hari untuk dapat melakukan hal-hal seperti perkiraan, dan saya telah menempatkan definisi di sini tentang perencanaan kapasitas. Dan itu definisi yang cukup luas dan sebenarnya cukup samar, yang hanya merupakan proses penentuan kapasitas produksi yang dibutuhkan oleh suatu organisasi untuk memenuhi tuntutan perubahan untuk produk-produknya, dan pada akhirnya, itulah yang sebenarnya terjadi: tentang kemampuan untuk mengambil informasi yang Anda miliki dengan beberapa cara dan mengambil informasi itu dan membuat keputusan untuk membantu Anda bergerak maju saat Anda maju melalui siklus kehidupan basis data Anda. Jadi, jenis-jenis hal yang menjadi alasan mengapa orang perlu melakukan ini jelas pertama dan terutama, dalam banyak kasus, untuk menghemat uang. Bisnis, jelas, itulah tujuan utama mereka untuk menghasilkan uang dan menghemat uang. Tetapi dalam proses bersamaan dengan itu, itu juga berarti dapat memastikan bahwa Anda tidak bekerja, tidak ada waktu henti. Dan dapat memastikan bahwa Anda mengurangi kemungkinan downtime terjadi, jadi jaga agar tidak terjadi mulai dari awal, dengan kata lain, tidak menunggu hal itu terjadi dan kemudian bereaksi terhadapnya.
Selain mampu meningkatkan produktivitas pengguna secara keseluruhan, menjadikannya lebih efisien sehingga Anda dapat menyelesaikan lebih banyak bisnis jelas merupakan kuncinya di sini, jadi ini adalah jenis hal yang DBA atau seseorang terlibat dalam peramalan atau kapasitas perencanaan harus dapat mengarungi informasi untuk dapat membuat keputusan. Dan kemudian, secara keseluruhan, ini jelas akan membantu Anda menghilangkan pemborosan, tidak hanya pemborosan dalam hal uang, tetapi juga dalam hal waktu dan dalam hal hanya sumber daya yang secara umum dapat digunakan untuk hal-hal lain, mungkin. Jadi, bisa menghilangkan limbah itu sehingga Anda tidak memiliki biaya peluang yang terkait dengan limbah itu sendiri.
Jadi, dengan itu, apa saja jenis pertanyaan yang kita dapatkan, khusus untuk orang itu DBA? Kapan saya akan kehabisan ruang? Itu yang besar, tidak hanya berapa banyak ruang yang saya konsumsi sekarang, tetapi kapan saya akan kehabisan, berdasarkan tren dan sejarah masa lalu? Hal yang sama dengan contoh aktual SQL, database, server mana yang dapat saya konsolidasi? Saya akan meletakkan beberapa di VMs, apa yang masuk akal dalam hal database mana saya akan mengkonsolidasikan dan contoh SQL mana yang harus mereka tinggal? Semua jenis pertanyaan itu harus bisa dijawab. Karena dalam kebanyakan kasus, jika Anda seorang DBA atau bertindak DBA, Anda akan mengkonsolidasikannya dalam karir Anda. Dalam banyak kasus, Anda akan melakukan itu secara berkelanjutan. Jadi, Anda harus bisa membuat keputusan itu dengan cepat, bukan bermain tebak-tebakan.
Kami berbicara tentang kemacetan dan di mana mereka akan terjadi selanjutnya, bisa mengantisipasi itu, sekali lagi, bukannya menunggu mereka terjadi. Jadi, jelas semua hal ini sedang dibicarakan, masuk akal dalam arti bahwa Anda mengandalkan data historis, dalam banyak kasus, untuk dapat menghasilkan rekomendasi ini, atau dalam beberapa kasus dapat merumuskan keputusan sendiri, untuk dapat datang dengan jawaban ini. Tapi itu mengingatkan saya pada, ketika Anda mendengar iklan radio untuk seseorang yang menjual sekuritas atau sesuatu seperti itu, selalu "kinerja masa lalu tidak menunjukkan hasil di masa depan" dan hal-hal semacam itu. Dan hal yang sama berlaku di sini. Anda akan mengalami situasi di mana perkiraan ini dan analisis ini mungkin tidak 100 persen benar. Tetapi jika Anda berurusan dengan hal-hal yang telah terjadi di masa lalu dan yang diketahui, dan mampu mengambil dan melakukan "bagaimana jika" dengan banyak jenis pertanyaan ini, Anda akan mengalami, sangat berharga dan akan membuat Anda lebih jauh daripada memainkan permainan menebak.
Jadi, pertanyaan-pertanyaan semacam ini jelas akan muncul, jadi bagaimana kita menangani banyak pertanyaan ini dengan Manajer Diagnostik, pertama-tama kita memiliki kemampuan perkiraan, mampu melakukan ini di database, di meja, maupun di drive atau volume. Agar tidak hanya bisa mengatakan, "Hei, penuh ruang," tetapi enam bulan dari sekarang, dua tahun dari sekarang, lima tahun dari sekarang, jika saya menganggarkan untuk itu, berapa banyak ruang drive yang akan saya butuhkan untuk anggaran untuk? Itu adalah pertanyaan yang harus saya tanyakan, dan saya harus dapat menggunakan beberapa metode untuk melakukan itu daripada menebak dan meletakkan jari saya di udara dan menunggu untuk melihat ke arah mana angin berhembus, yang sangat banyak sayangnya, cara banyak keputusan ini dibuat.
Selain itu, bisa - sepertinya slide saya terputus di sana sedikit - tetapi mampu memberikan bantuan dalam bentuk rekomendasi. Jadi, satu hal untuk dapat menunjukkan kepada Anda sebuah dasbor yang penuh dengan metrik dan dapat mengatakan, "OK, inilah semua metrik dan di mana mereka berada," tetapi kemudian dapat membuat beberapa atau memiliki beberapa pemahaman tentang apa yang harus lakukan, berdasarkan itu adalah lompatan lain. Dan dalam beberapa kasus, orang cukup terdidik dalam peran DBA untuk dapat membuat keputusan itu. Jadi kami memiliki beberapa mekanisme dalam alat yang akan membantu dengan itu, yang akan menunjukkan kepada Anda hanya dalam sedetik. Tetapi mampu menunjukkan tidak hanya apa rekomendasi itu, tetapi juga memberikan beberapa wawasan tentang mengapa rekomendasi itu dibuat dan kemudian juga di atas itu, dalam beberapa kasus, mampu benar-benar membuat naskah yang mengotomatiskan perbaikan masalah itu juga ideal.
Pindah ke yang berikutnya di sini, yang melihat dengan baik, umumnya hanya memahami ke tingkat metrik apa yang normal. Saya tidak bisa memberi tahu Anda apa yang tidak normal jika saya tidak tahu apa yang normal. Jadi, memiliki beberapa cara untuk mengukur itu adalah kuncinya dan Anda harus dapat mempertimbangkan berbagai jenis area, misalnya - atau saya harus mengatakan kerangka waktu - pengelompokan server yang berbeda, dapat melakukan ini secara dinamis, dari Perspektif peringatan, dengan kata lain, pada tengah malam, selama jendela pemeliharaan, saya berharap CPU saya berjalan pada 80 persen berdasarkan pada semua pemeliharaan yang terjadi. Jadi, saya mungkin ingin meningkatkan ambang batas saya lebih tinggi, selama jangka waktu versus versus mungkin di tengah hari, ketika saya tidak memiliki banyak kegiatan.
Itu adalah beberapa hal yang jelas akan lingkungan, tetapi hal-hal yang dapat Anda terapkan pada apa yang dikelola, untuk dapat membantu Anda mengelola lingkungan itu lebih efisien, dan membuatnya lebih mudah untuk melakukannya. Area lain, tentu saja, hanya mampu memberikan laporan dan informasi secara keseluruhan untuk dapat menjawab pertanyaan-pertanyaan "bagaimana jika" tersebut. Jika saya baru saja membuat perubahan pada lingkungan saya, saya ingin memahami apa dampaknya, sehingga saya dapat menerapkan perubahan yang sama ke instance lain atau database lain di lingkungan saya. Saya ingin dapat memiliki beberapa informasi atau amunisi untuk dapat membuat perubahan itu dengan ketenangan pikiran dan mengetahui bahwa itu akan menjadi perubahan yang baik. Jadi, bisa melakukan pelaporan komparatif, mampu membuat peringkat contoh SQL saya, mampu membuat peringkat basis data saya terhadap satu sama lain, untuk mengatakan, "Yang merupakan konsumen CPU saya yang tertinggi?" Atau yang mana yang paling lama menggunakan hal menunggu dan hal-hal seperti itu? Jadi banyak informasi yang akan tersedia dengan alat ini juga.
Dan kemudian, yang tak kalah pentingnya, hanyalah kemampuan keseluruhan yang Anda butuhkan alat yang akan dapat menangani situasi apa pun yang Anda hadapi, dan apa yang saya maksudkan adalah, jika Anda memiliki lingkungan yang besar dengan banyak contoh, Anda mungkin akan mengalami situasi di mana Anda perlu menarik metrik yang biasanya bukan metrik yang ingin DBA bahkan memantau dalam beberapa kasus, tergantung pada situasi tertentu. Jadi, memiliki alat yang Anda dapat, itu dapat diperluas, untuk dapat menambahkan metrik tambahan dan untuk dapat menggunakan metrik tersebut dalam bentuk dan mode yang sama yang akan Anda gunakan jika Anda menggunakan out-of-the-box metrik, misalnya. Jadi, bisa menjalankan laporan, mampu memberi peringatan, garis dasar - semua hal yang dibicarakan - juga merupakan bagian kunci untuk dapat melakukan peramalan ini dan membuatnya sehingga Anda mendapatkan jawaban yang Anda cari untuk dapat membuat keputusan itu, bergerak maju.
Sekarang dengan cara Diagnostic Manager melakukan ini, kami memiliki layanan terpusat, sekelompok layanan yang berjalan, mengumpulkan data terhadap instance 2000 hingga 2016. Dan kemudian apa yang kita lakukan adalah kita mengambil data itu dan kita memasukkannya ke dalam repositori pusat dan kemudian apa yang baik dilakukan dengan data itu, jelas, adalah kita melakukan banyak hal untuk dapat memberikan wawasan lebih lanjut. Sekarang, selain itu - dan salah satu hal yang tidak ada di sini - adalah kami juga memiliki layanan yang berjalan di tengah malam, yang merupakan layanan analisis prediktif kami, dan yang melakukan beberapa angka berderak dan membantu memahami dan membantu Anda sebagai DBA atau bertindak DBA, untuk dapat membuat jenis rekomendasi tersebut, untuk dapat juga memberikan beberapa wawasan dalam hal baseline.
Jadi, apa yang ingin saya lakukan, dan ini hanyalah contoh singkat dari arsitektur, hal yang paling penting di sini adalah tidak ada agen atau layanan yang benar-benar berada pada contoh yang Anda kelola. Tapi apa yang ingin saya lakukan adalah benar-benar membawa Anda ke aplikasi di sini dan memberi Anda demo cepat. Dan biarkan aku keluar juga, dan mewujudkannya. Jadi, beri tahu saya, saya pikir Eric, dapatkah Anda melihat itu baik-baik saja?
Eric Kavanagh: Saya mengerti sekarang, ya.
Bullett Manale: OK, jadi saya akan membawa Anda melalui beberapa bagian berbeda yang saya bicarakan. Dan pada dasarnya mari kita mulai dengan hal-hal yang lebih sesuai dengan hal-hal yang perlu Anda lakukan, atau di sini ada sesuatu yang merupakan titik waktu di masa depan dan akan memberi Anda wawasan tentang hal itu. Dan ini bisa benar-benar mengantisipasi - atau saya harus mengatakan secara dinamis mengantisipasi - hal-hal yang terjadi. Sekarang, dalam hal laporan, salah satu hal yang kami miliki dalam alat ini adalah tiga laporan perkiraan berbeda. Dan dalam kasus, misalnya, perkiraan basis data, apa yang mungkin akan saya lakukan dalam situasi dapat mengantisipasi ukuran basis data selama periode waktu tertentu, dan saya hanya akan memberi Anda beberapa contohnya. Jadi, saya akan mengambil database audit saya, yang cukup intensif I / O - punya banyak data pergi ke sana. Kami punya, mari kita lihat, lakukan yang ini di sini, dan mari kita ambil saja database layanan kesehatan di sini.
Tapi intinya adalah, saya tidak hanya melihat apa yang ada di ruang ini, saya dapat mengatakan, "Dengar, mari kita ambil data tahun-tahun terakhir" - dan saya akan sedikit ke sini sedikit, saya benar-benar tidak punya tahun senilai data, saya memiliki data sekitar dua bulan - tetapi, karena saya memilih tingkat sampel bulan di sini, saya akan dapat mengantisipasi atau memperkirakan dalam kasus ini 36 unit berikutnya karena tingkat sampel kami ditetapkan ke bulan - itu adalah satu unit, satu bulan - dan kemudian saya bisa, untuk kemudian menjalankan laporan untuk menunjukkan kepada saya di mana kita akan mengantisipasi pertumbuhan masa depan kita, untuk tiga database ini. Dan kita dapat melihat bahwa kita memiliki tingkat perbedaan yang berbeda, atau perbedaan, antara tiga basis data yang berbeda, khususnya dengan jumlah data yang mereka konsumsi secara historis.
Kita bisa melihat titik data di sini mewakili data historis, dan kemudian garis akan memberikan kita perkiraan, bersama dengan angka untuk mendukungnya. Jadi kita bisa melakukan itu di level tabel, kita bisa melakukannya bahkan di level drive, di mana saya bisa mengantisipasi seberapa besar drive saya akan dapatkan, termasuk titik pemasangan. Kami dapat memperkirakan jenis informasi yang sama ini, tetapi sekali lagi, tergantung pada tingkat sampel, akan memungkinkan saya untuk menentukan berapa banyak unit dan di mana mengambil apa yang ingin kami perkirakan. Perhatikan juga kami memiliki berbagai jenis tipe perkiraan. Jadi Anda mendapatkan banyak pilihan dan fleksibilitas ketika tiba saatnya melakukan peramalan. Nah, itu satu hal yang harus dilakukan, dalam benar-benar memberi Anda tanggal tertentu dan dapat mengatakan "Hei pada tanggal ini, di sinilah kami akan mengantisipasi pertumbuhan data Anda." Selain itu, meskipun demikian, kami dapat memberikan Anda dengan wawasan lain yang terkait dengan beberapa analisis yang kami lakukan selama jam libur dan layanan saat dijalankan. Beberapa hal yang dilakukannya, adalah berusaha mengantisipasi hal-hal yang kemungkinan akan terjadi, berdasarkan sejarah ketika hal-hal terjadi di masa lalu.
Jadi kita dapat melihat di sini, sebenarnya, ramalan memberi kita wawasan tentang kemungkinan kita mengalami masalah sepanjang malam berdasarkan hal-hal yang sekali lagi terjadi di masa lalu. Jadi, jelas ini bagus, terutama jika saya bukan DBA, saya bisa melihat hal-hal ini, tetapi apa yang lebih baik jika saya bukan DBA, adalah tab analisis ini. Jadi, sebelum ini ada di sini di alat kami akan pergi dan menunjukkan produk kepada orang-orang dan mereka akan "Itu bagus, saya melihat semua angka-angka ini, saya melihat semuanya, tapi saya tidak tahu harus berbuat apa" (tertawa) "seperti hasil dari itu. ”Dan apa yang kita miliki di sini, adalah cara yang lebih baik bagi Anda untuk dapat memahami, jika saya akan mengambil tindakan untuk membantu kinerja, jika saya akan mengambil tindakan bahkan membantu kesehatan saya lingkungan, mampu memiliki peringkat cara memberikan rekomendasi tersebut, serta tips yang berguna dalam informasi untuk mempelajari lebih lanjut tentang rekomendasi tersebut dan benar-benar bahkan memiliki tautan eksternal ke beberapa data itu, yang akan menunjukkan kepada saya dan membawa saya ke alasan mengapa rekomendasi ini dibuat.
Dan dalam banyak kasus, mampu menyediakan skrip yang akan mengotomatisasi, seperti yang saya katakan, perbaikan masalah ini. Sekarang, bagian dari apa yang dilakukan di sini dengan analisis ini - dan saya akan tunjukkan ketika saya masuk untuk mengkonfigurasi properti dari contoh ini, dan saya pergi ke bagian konfigurasi analisis - kami memiliki banyak kategori berbeda yang tercantum di sini, dan sebagian dari itu, kami memiliki optimasi indeks dan optimasi permintaan. Jadi, mengevaluasi tidak hanya metrik sendiri, dan hal-hal seperti itu, tetapi juga hal-hal seperti beban kerja dan indeks. Dalam kasus di sini, sebenarnya melakukan beberapa analisis indeks hipotetis tambahan. Jadi, ini adalah salah satu situasi di mana saya tidak ingin, dalam banyak kasus, saya tidak ingin menambahkan indeks jika saya tidak perlu. Tetapi pada titik tertentu ada semacam titik kritis, di mana saya berkata, “Tabelnya mencapai ukuran atau jenis kueri yang berjalan dalam beban kerja masuk akal sekarang untuk menambahkan indeks. Tapi itu tidak masuk akal mungkin enam minggu sebelumnya. "Jadi ini memungkinkan Anda untuk secara dinamis mendapatkan wawasan tentang hal-hal yang mungkin, seperti saya katakan, meningkatkan kinerja berdasarkan apa yang terjadi di lingkungan, apa yang terjadi dalam beban kerja, dan melakukan hal-hal semacam itu.
Jadi Anda mendapatkan banyak informasi yang baik di sini, serta kemampuan untuk mengoptimalkan hal-hal ini secara otomatis. Jadi, itulah bidang lain di mana kami dapat membantu, dalam hal yang kami sebut analisis prediktif. Sekarang, di samping itu, saya harus mengatakan, kami juga memiliki bidang-bidang lain yang saya pikir hanya cocok untuk membantu Anda membuat keputusan. Dan ketika kita berbicara tentang membuat keputusan, sekali lagi, bisa melihat data historis, memberikan beberapa wawasan untuk membawa kita ke tempat yang kita butuhkan untuk meningkatkan kinerja itu.
Sekarang, salah satu hal yang dapat kita lakukan adalah kita memiliki visualizer dasar yang memungkinkan kita untuk memilih metrik mana saja yang kita inginkan - dan biarkan saya menemukan yang layak di sini - saya akan menggunakan SQL CPU, tetapi intinya adalah Anda dapat pergi kembali selama beberapa minggu untuk melukis gambar-gambar ini untuk Anda lihat ketika outlier Anda, untuk melihat secara umum di mana nilai itu jatuh dalam periode waktu yang telah kami kumpulkan data. Dan kemudian, selain itu kamu juga akan memperhatikan bahwa ketika kita pergi ke instance yang sebenarnya, kita memiliki kemampuan untuk mengkonfigurasi baseline kita. Dan garis dasar adalah bagian yang sangat penting untuk dapat mengotomatisasi hal-hal serta dapat diberitahu tentang hal-hal. Dan tantangannya, seperti yang akan dikatakan sebagian besar DBA, adalah bahwa lingkungan Anda tidak selalu berjalan sama, sepanjang malam, versus malam dan yang lainnya seperti yang kami sebutkan sebelumnya dalam contoh dengan periode pemeliharaan waktu, ketika kami memiliki tingkat CPU yang tinggi atau apa pun yang mungkin terjadi.
Jadi, dalam kasus di sini, dengan garis dasar aktual ini, kita dapat memiliki beberapa garis dasar, jadi saya mungkin memiliki garis dasar misalnya, itu selama jam pemeliharaan saya. Tapi saya bisa dengan mudah membuat garis dasar untuk jam produksi saya. Dan inti dari melakukan itu adalah ketika kita masuk ke contoh SQL dan kita benar-benar memiliki beberapa baseline, maka kita akan dapat mengantisipasi dan dapat melakukan beberapa jenis otomatisasi, beberapa jenis perbaikan atau hanya mengingatkan secara umum, berbeda khusus untuk jendela waktu tersebut. Jadi, salah satu hal yang akan Anda lihat di sini, adalah garis dasar yang kami hasilkan menggunakan data historis untuk memberikan analisis itu, tetapi yang lebih penting, saya dapat mengubah ambang batas ini secara statis, tetapi saya juga dapat mengotomatisasi ini secara dinamis juga. Jadi, seperti jendela pemeliharaan, atau saya harus mengatakan jendela baseline pemeliharaan muncul, ambang batas ini akan secara otomatis beralih spesifik ke beban yang saya temui selama jangka waktu itu, dibandingkan mungkin di tengah hari ketika beban saya tidak sebesar banyak, ketika beban kerja tidak berdampak.
Jadi, ada hal lain yang perlu diingat, dalam hal baseline. Jelas ini akan sangat membantu bagi Anda, dalam hal juga memahami apa yang normal dan dapat juga memahami, terlibat ketika Anda juga akan kehabisan sumber daya. Sekarang, hal lain yang kita miliki dalam alat ini, yaitu akan membantu Anda membuat keputusan, di samping baseline dan mampu mengatur peringatan di sekitar baseline dan ambang yang Anda buat secara dinamis, seperti yang saya katakan sebelumnya, hanya bisa menjalankan segudang laporan yang membantu saya menjawab pertanyaan tentang apa yang terjadi.
Jadi, sebagai contoh, jika saya memiliki 150 instance yang saya kelola - dalam kasus saya, saya tidak melakukannya, jadi kami harus memainkan permainan pura-pura di sini - tetapi jika saya memiliki semua instance produksi dan saya perlu memahami di mana area yang saya gunakan perlu perhatian pada, dengan kata lain, jika saya hanya akan memiliki waktu terbatas untuk melakukan beberapa jenis administrasi untuk meningkatkan kinerja, saya ingin fokus pada bidang-bidang utama. Maka, dengan mengatakan itu, saya dapat mengatakan, "Berdasarkan lingkungan itu, rangking instans saya satu sama lain, dan beri saya peringkat itu dengan pipa pertentangan." Jadi apakah penggunaan disk, penggunaan memori, apakah menunggu, apakah waktu responsnya, saya dapat menghubungkan - atau saya harus mengatakan peringkat - contoh-contoh itu terhadap satu sama lain. Jelas contoh itu ada di bagian atas setiap daftar, jika itu contoh yang sama, itu mungkin sesuatu yang benar-benar ingin saya fokuskan, karena jelas sekali lagi di bagian atas daftar.
Jadi, Anda memiliki banyak laporan dalam alat yang membantu Anda dalam hal menentukan peringkat lingkungan pada tingkat instance; Anda dapat melakukan ini juga di tingkat basis data, di mana saya dapat menentukan peringkat basis data saya satu sama lain. Khusus untuk ambang batas dan area yang dapat saya atur, saya bahkan dapat mengatur wildcard di sini jika saya mau, untuk hanya fokus pada database tertentu, tetapi intinya adalah bahwa saya dapat membandingkan database saya dengan cara yang sama. Juga, sejauh jenis analisis komparatif lainnya dan yang besar dalam alat ini, adalah analisis dasar yang kami miliki. Jadi jika Anda gulir ke bawah ke tampilan layanan di sini, Anda akan melihat bahwa ada laporan statistik dasar. Sekarang laporan ini jelas akan membantu kita untuk memahami tidak hanya apa nilai metrik itu, tetapi untuk contoh spesifik saya bisa keluar, dan untuk setiap metrik ini, dapat benar-benar melihat baseline untuk metrik ini.
Jadi, apa pun itu, sebagai persen atau apa pun yang saya bisa keluar dan katakan, "Mari kita lihat garis dasar untuk ini pecah dalam 30 hari terakhir," dalam hal ini akan menunjukkan kepada saya nilai aktual versus baseline dan Saya akan dapat membuat beberapa keputusan menggunakan informasi itu, jelas, jadi ini adalah salah satu situasi itu, di mana itu akan tergantung pada pertanyaan apa itu, yang Anda tanyakan pada saat itu. Tapi ini jelas akan membantu Anda untuk banyak pertanyaan itu. Saya berharap saya bisa mengatakan kami memiliki satu laporan yang melakukan semuanya, dan jenisnya seperti laporan yang mudah, di mana Anda menekan dan menekan dan itu hanya menjawab setiap pertanyaan "bagaimana jika" yang bisa Anda jawab. Tetapi kenyataannya adalah, Anda akan memiliki banyak atribut dan banyak opsi untuk dapat dipilih dalam pull-down ini untuk dapat merumuskan "bagaimana jika" -jenis pertanyaan yang Anda cari.
Jadi banyak dari laporan ini diarahkan untuk dapat menjawab pertanyaan-pertanyaan semacam itu. Jadi, sangat penting juga bahwa laporan-laporan ini dan sebagai tambahan, semua hal yang sudah kami tunjukkan dalam alat ini, seperti yang saya sebutkan sebelumnya, memiliki fleksibilitas untuk memasukkan metrik baru, untuk dikelola, bahkan dapat membuat penghitung, atau pertanyaan SQL yang dimasukkan ke dalam interval pemungutan suara Anda, untuk dapat membantu saya menjawab pertanyaan-pertanyaan ini, bahwa mungkin di luar kotak kami tidak mengantisipasi untuk memantau, Anda dapat menambahkan hal-hal itu. Dan Anda kemudian dapat melakukan semua hal yang sama seperti yang saya tunjukkan kepada Anda: baseline, menjalankan laporan, dan membuat laporan dari metrik itu, dan dapat menjawab dan melakukan banyak hal berbeda yang saya tunjukkan kepada Anda di sini.
Sekarang, di samping itu - dan salah satu hal yang jelas-jelas kita temui belakangan ini adalah - pertama, semua orang membalik atau beralih ke VM. Dan sekarang kita punya banyak orang yang menuju ke awan. Dan ada banyak pertanyaan yang muncul di sekitar hal-hal semacam itu. Apakah masuk akal bagi saya untuk pindah ke cloud? Apakah saya akan menghemat uang dengan pindah ke cloud? Jika saya meletakkan benda-benda ini pada VM, pada mesin sumber daya bersama, berapa banyak uang yang bisa saya hemat? Jenis-jenis pertanyaan itu, jelas juga akan muncul. Jadi, banyak hal yang perlu diingat, dengan Manajer Diagnostik, kita dapat menambah dan menarik dari lingkungan tervirtualisasi baik dari VMware dan Hyper-V. Kami juga dapat menambahkan instance yang ada di cloud, jadi lingkungan Anda seperti Azure DB, misalnya, atau bahkan RDS, kami dapat menarik metrik dari lingkungan itu juga.
Jadi ada banyak fleksibilitas dan banyak kemampuan untuk menjawab pertanyaan-pertanyaan itu karena berkaitan dengan jenis-jenis lingkungan lain yang kita lihat orang menuju. Dan masih ada banyak pertanyaan seputar hal ini, dan ketika kita melihat orang-orang mengkonsolidasikan lingkungan itu mereka akan perlu untuk dapat menjawab pertanyaan-pertanyaan itu juga. Jadi, itulah gambaran yang cukup bagus, Id say, dari Diagnostic Manager, karena berkaitan dengan topik ini. Saya tahu bahwa subjek intelijen bisnis muncul dan kami juga memiliki alat untuk intelijen bisnis yang tidak kami bicarakan hari ini, tetapi juga akan memberi Anda wawasan dalam hal menjawab pertanyaan-pertanyaan semacam ini karena berkaitan dengan kubus Anda dan semua jenis hal yang berbeda, juga. Tapi semoga ini menjadi gambaran yang bagus, setidaknya dalam hal bagaimana produk ini dapat membantu merumuskan rencana yang baik.
Eric Kavanagh: Baiklah, barang bagus. Ya, aku akan membuangnya ke Rick, jika dia masih di luar sana. Rick, ada pertanyaan darimu?
Rick Sherman: Ya, jadi pertama, ini bagus, saya suka. Saya terutama suka memperluas ke VM dan cloud. Saya melihat banyak pengembang aplikasi berpikir bahwa jika itu ada di cloud maka mereka tidak perlu menyetelnya. Begitu-
Bullett Manale: Benar, kita masih harus membayarnya, kan? Anda masih harus membayar untuk apa pun yang diletakkan orang di atas awan, jadi jika itu berjalan buruk, atau jika menyebabkan banyak siklus CPU, semakin banyak uang yang harus Anda bayar, jadi tidak, Anda masih perlu mengukur hal ini, tentu saja.
Rick Sherman: Ya, saya pernah melihat banyak desain yang buruk di cloud. Saya memang ingin bertanya, apakah produk ini juga akan digunakan - saya tahu Anda menyebutkan produk BI dan Anda memiliki banyak produk lain yang berinteraksi satu sama lain - tetapi apakah Anda akan mulai melihat kinerja SQL, pertanyaan individu dalam alat ini? Atau apakah itu alat lain yang akan digunakan untuk itu?
Bullett Manale: Tidak, ini akan benar-benar. Itulah salah satu hal yang saya tidak membahas dan maksud saya, adalah bagian permintaan itu. Kami memiliki banyak cara berbeda untuk mengidentifikasi kinerja kueri, apakah itu terkait dengan, khususnya menunggu seperti yang kita lihat pada tampilan ini di sini, atau apakah itu terkait dengan konsumsi sumber daya kueri secara keseluruhan, ada sejumlah cara kita dapat menganalisis kueri kinerja. Baik itu durasinya, CPU, I / O, dan sekali lagi, kita juga bisa melihat beban kerjanya sendiri untuk memberikan beberapa wawasan. Kami dapat memberikan rekomendasi di bagian analisis dan kami juga memiliki versi berbasis web yang menyediakan informasi di sekitar kueri itu sendiri. Jadi saya bisa mendapatkan rekomendasi tentang indeks yang hilang dan kemampuan untuk melihat rencana eksekusi dan semua hal semacam itu; itu juga kemampuan juga. Jadi, tentu saja, kita dapat mendiagnosis kueri tujuh cara hingga Minggu (tertawa) dan dapat memberikan wawasan itu dalam hal jumlah eksekusi, baik itu konsumsi sumber daya, menunggu, durasi, semua hal yang baik.
Rick Sherman: OK bagus. Lalu apa beban pada instans sendiri dengan semua pemantauan ini?
Bullett Manale: Ini pertanyaan yang bagus. Tantangan dengan menjawab pertanyaan itu adalah, apakah itu tergantung, sama seperti hal lainnya. Banyak hal yang ditawarkan alat kami, alat ini memberikan fleksibilitas dan bagian dari fleksibilitas itu adalah Anda bisa memberi tahu apa yang harus dikumpulkan dan apa yang tidak boleh dikumpulkan. Jadi misalnya, dengan kueri sendiri, saya tidak perlu mengumpulkan informasi tunggu, atau saya bisa. Saya dapat mengumpulkan informasi terkait pertanyaan yang melampaui durasi waktu eksekusi. Sebagai contohnya, jika saya masuk ke configure query monitor dan saya berkata, "Mari kita ubah nilainya menjadi nol," kenyataannya adalah pada dasarnya membuat alat mengumpulkan setiap permintaan yang berjalan dan itu sebenarnya bukan Semangat mengapa itu ada, tetapi secara umum jika saya ingin memberikan sampel data lengkap untuk semua pertanyaan, saya bisa melakukannya.
Jadi, ini sangat relatif terhadap pengaturan Anda, secara umum, di luar kotak. Di mana saja dari sekitar 1-3 persen overhead, tetapi ada kondisi lain yang akan berlaku. Ini juga tergantung pada seberapa banyak permintaan port berjalan di lingkungan Anda, bukan? Itu juga tergantung pada metode pengumpulan pertanyaan-pertanyaan itu dan apa versi SQL itu. Jadi, misalnya, SQL Server 2005, tidak akan dapat menarik dari peristiwa yang diperpanjang, sedangkan kami akan menarik dari jejak untuk melakukan itu. Jadi, akan sedikit berbeda dalam hal cara kita mengumpulkan data itu, tetapi yang mengatakan, seperti yang saya katakan, kita sudah sekitar karena saya kira sejak sekitar 2004 dengan produk ini. Sudah ada sejak lama, kami sudah mendapatkan ribuan pelanggan, jadi hal terakhir yang ingin kami lakukan adalah memiliki alat pemantauan kinerja yang menyebabkan masalah kinerja (tertawa). Jadi kami berusaha menghindari hal itu, sebanyak mungkin, tetapi secara umum, sekitar 1-3 persen adalah aturan praktis yang baik.
Rick Sherman: OK, dan itu cukup rendah, jadi itu hebat.
Eric Kavanagh: Baik. Robin, ada pertanyaan darimu?
Robin Bloor: Maaf, saya bisu. Anda telah mendapatkan beberapa kemampuan basis data, dan saya tertarik pada penyebabnya Anda dapat melihat banyak basis data dan karenanya Anda dapat mengetahui basis sumber daya yang lebih besar dapat dibagi antara berbagai mesin virtual dan seterusnya dan seterusnya. Saya tertarik pada bagaimana orang menggunakannya. Saya tertarik dengan apa yang pelanggan lakukan. Karena itu terlihat bagi saya, yah, tentu saja, ketika saya mengotak-atik basis data, sesuatu yang tidak pernah saya miliki. Dan saya hanya akan mempertimbangkan satu contoh dengan cara yang berarti pada titik waktu tertentu. Jadi, bagaimana orang menggunakan ini?
Bullett Manale: Secara umum, Anda berbicara tentang secara umum hanya alat itu sendiri? Bagaimana mereka menggunakannya? Maksud saya, secara umum, tentang kemampuan untuk memiliki titik sentral keberadaan lingkungan. Memiliki ketenangan pikiran dan mengetahui bahwa jika mereka menatap layar dan mereka melihat hijau, mereka tahu semuanya baik. Ketika masalah terjadi dan jelas sebagian besar kasus dari perspektif DBA, sering kali masalah terjadi ketika mereka berada di depan konsol, sehingga dapat diberitahu segera setelah masalah terjadi. Tetapi di samping itu, dapat memahami kapan masalah itu terjadi, mampu mendapatkan inti dari informasi yang memberikan mereka beberapa con dalam hal mengapa hal itu terjadi. Dan itulah, menurut saya, bagian terbesar: menjadi proaktif tentang hal itu, bukan menjadi reaktif.
Sebagian besar DBA yang saya ajak bicara - dan saya tidak tahu, ini adalah persentase yang baik dari mereka - sayangnya masih dalam jenis lingkungan reaktif; mereka menunggu konsumen mendekati mereka untuk memberi tahu mereka ada masalah. Jadi, kita melihat banyak orang berusaha melepaskan diri dari itu dan saya pikir itu adalah sebagian besar alasan mengapa orang menyukai alat ini adalah karena alat ini membantu mereka menjadi proaktif tetapi juga memberi mereka wawasan tentang apa yang sedang terjadi. , apa masalahnya, tetapi dalam banyak kasus, apa yang kami temukan setidaknya - dan mungkin hanya DBA yang memberi tahu kami - tetapi DBA, persepsi selalu menjadi masalah mereka, bahkan jika itu adalah pengembang aplikasi yang menulis aplikasi tersebut. yang tidak menuliskannya dengan benar, mereka yang akan disalahkan, karena mereka mengambil aplikasi itu ke dalam sistem atau server mereka dan kemudian ketika kinerjanya buruk, semua orang menunjuk ke DBA berkata, "Hai ini salahmu."
Jadi alat ini, sering kali, akan digunakan untuk membantu membuat DBA mengatakan, “Hei, di sinilah masalahnya dan bukan saya.” (Tertawa) Kita perlu perbaiki ini, apakah itu mengubah kueri atau apa pun itu. Dalam beberapa kasus itu akan jatuh dalam ember mereka dalam hal tanggung jawab mereka, tetapi setidaknya memiliki alat untuk dapat membantu mereka memahami itu dan mengetahui itu, dan melakukannya tepat waktu jelas merupakan pendekatan yang ideal.
Robin Bloor: Ya, sebagian besar situs yang saya kenal, tetapi sudah lama sejak saya sudah di luar sana, melihat berbagai situs multi-database, tetapi kebanyakan apa yang saya temukan adalah bahwa akan ada DBA yang berfokus pada beberapa basis data. Dan itu akan menjadi basis data, bahwa jika mereka turun, itu akan menjadi masalah besar bagi bisnis, dan seterusnya dan seterusnya. Dan yang lainnya, mereka hanya akan mengumpulkan statistik setiap sekarang dan kemudian untuk melihat mereka tidak kehabisan ruang dan mereka tidak akan pernah melihat mereka sama sekali. Dan ketika Anda sedang melakukan demo saya melihat ini dan saya berpikir dengan baik, dalam satu atau lain cara, Anda memperluas, hanya dengan menyediakan sesuatu seperti ini untuk database yang sering, tidak ada yang terlalu peduli, karena mereka memiliki pertumbuhan data , mereka juga mengalami pertumbuhan aplikasi. Anda memperluas cakupan DBA dengan cara yang cukup dramatis. Jadi itulah pertanyaan sebenarnya, apakah dengan seperangkat alat seperti ini, Anda akhirnya bisa memberikan layanan DBA ke setiap basis data yang ada di jaringan perusahaan?
Bullett Manale: Tentu, maksud saya, tantangannya adalah, seperti yang Anda katakan dengan fasih, seperti ada beberapa basis data yang diperhatikan oleh DBA dan kemudian ada yang tidak terlalu mereka pedulikan. Dan cara produk khusus ini, cara dilisensikan adalah berdasarkan per-contoh. Jadi, ada, saya kira Anda akan mengatakan, ambang ketika orang memutuskan "Hei, ini bukan contoh yang cukup kritis yang ingin saya kelola dengan alat ini." Yang mengatakan, ada alat lain yang kami miliki yang lebih Saya kira, melayani contoh SQL yang kurang penting. Salah satunya akan seperti Inventory Manager, di mana kami melakukan pemeriksaan kesehatan ringan terhadap instance, tetapi selain itu yang kami lakukan adalah kami melakukan penemuan, jadi kami mengidentifikasi contoh baru yang telah dibawa online dan kemudian, sejak saat itu, sebagai DBA saya dapat mengatakan, “Oke, ini contoh baru dari SQL, sekarang apakah itu Ekspres? Apakah ini versi gratis atau versi perusahaan? ”Mungkin itu pertanyaan yang ingin saya tanyakan pada diri saya, tetapi kedua, seberapa pentingkah hal itu bagi saya? Jika itu tidak begitu penting, saya mungkin memiliki alat ini keluar dan melakukannya, generik, apa yang saya sebut pemeriksaan kesehatan generik dalam arti bahwa mereka adalah jenis unsur hal yang saya pedulikan sebagai DBA: Apakah drive terisi? Apakah server merespons masalah? Hal-hal utama, bukan?
Sedangkan dengan Manajer Diagnostik, alat yang baru saja saya tunjukkan, akan turun ke tingkat permintaan, akan turun ke rekomendasi indeks, melihat rencana pelaksanaan dan semua hal yang baik, sedangkan ini terutama difokuskan pada siapa yang memiliki apa, apa yang saya miliki dan siapa yang bertanggung jawab untuk itu? Paket layanan dan perbaikan apa yang saya miliki? Dan apakah server saya berjalan dengan bahan utama dari apa yang saya anggap sebagai contoh SQL yang sehat? Jadi untuk menjawab pertanyaan Anda, ada sedikit campuran. Ketika kami melihat orang-orang melihat alat ini, mereka biasanya melihat serangkaian contoh yang lebih kritis. Yang mengatakan, kami memiliki beberapa orang yang membeli setiap contoh yang mereka miliki dan mengelolanya, jadi itu tergantung. Tapi saya katakan, secara keseluruhan, pasti ada ambang batas orang-orang yang menganggap lingkungan mereka cukup penting untuk memiliki alat seperti ini untuk mengelola contoh-contoh itu.
Robin Bloor: Oke, pertanyaan lain sebelum saya berikan pada Eric. Kesan yang didapat, hanya dari menonton industri adalah bahwa database masih memiliki kehidupan, tetapi semua data mengalir ke semua danau data ini dan seterusnya dan seterusnya. Benar-benar hype, dan hype tidak pernah mencerminkan kenyataan, jadi saya tertarik pada realitas seperti apa yang Anda rasakan di luar sana? Apakah basis data penting dalam suatu organisasi, apakah mereka mengalami pertumbuhan data tradisional, yang saya anggap 10 persen setahun? Atau mereka tumbuh lebih dari itu? Apakah data besar membuat balon database ini? Apa gambar yang kamu lihat?
Bullett Manale: Saya pikir banyak kasus melihat beberapa data dipindahkan ke segmen lain di mana lebih masuk akal, ketika ada teknologi lain yang tersedia. Sampai saat ini, beberapa hal data lebih besar. Tetapi database ini, saya katakan, sulit untuk digeneralisasi dalam banyak kasus karena semua orang sedikit berbeda. Namun secara umum, saya memang melihat beberapa perbedaan. Saya melihat, seperti yang saya katakan, orang-orang pindah ke model elastis dalam banyak kasus, karena mereka ingin menumbuhkan sumber daya dan tidak begitu banyak di daerah lain. Beberapa orang pindah ke data besar. Tetapi sulit untuk merasakan, Anda mengatakan, persepsi, karena secara umum orang-orang yang saya ajak bicara semua memiliki database tradisional dan menggunakan ini pada lingkungan SQL Server.
Yang mengatakan, saya katakan dalam hal SQL itu sendiri, saya pasti masih berpikir mendapatkan pangsa pasar. Dan saya berpikir bahwa ada banyak orang yang masih menuju SQL dari tempat lain seperti Oracle, karena lebih terjangkau dan tampaknya jelas, karena versi SQL menjadi lebih maju - dan Anda melihat ini dengan hal-hal yang lebih baru yang terjadi dengan SQL, dalam hal enkripsi dan semua kemampuan lain yang menjadikannya sebuah lingkungan atau platform database - yang jelas sangat misi kritis yang mampu, saya kira. Jadi, saya pikir melihat itu juga. Di mana Anda melihat perubahan, itu masih terjadi. Maksud saya, itu terjadi 10 tahun yang lalu, masih, saya pikir, terjadi dalam hal SQL Server, di mana lingkungan tumbuh dan pangsa pasar tumbuh.
Robin Bloor: Oke, Eric, saya kira audiens punya satu atau dua pertanyaan?
Eric Kavanagh: Ya, izinkan saya melemparkan satu cepat ke Anda. Sebenarnya itu pertanyaan yang cukup bagus. Salah satu peserta bertanya, apakah alat ini akan memberi tahu saya jika tabel mungkin perlu indeks untuk mempercepat kueri? Jika demikian, dapatkah Anda menunjukkan contoh?
Bullett Manale: Ya, jadi saya tidak tahu apakah saya punya satu untuk secara khusus menambahkan indeks, tetapi Anda bisa lihat di sini, kami memiliki rekomendasi fragmentasi di sini. Saya juga hanya percaya kita baru saja dan ini adalah bagian dari Manajer Diagnostik yang menawarkan versi berbasis web, di mana ini memberitahu saya bahwa saya memiliki indeks yang hilang. Dan kita dapat melihat rekomendasi itu dan akan memberi tahu kita potensi keuntungannya dengan mengindeks informasi tersebut. Hal lain yang harus saya sebutkan adalah ketika kita melakukan rekomendasi, untuk banyak dari ini, skrip akan dibangun untuk itu. Itu bukan contoh yang baik, tetapi Anda akan dapat melihat, ya, situasi di mana indeks - baik indeks duplikat, atau penambahan indeks - akan meningkatkan kinerja, dan seperti yang saya katakan sebelumnya, kami melakukan banyak hal. itu melalui analisis indeks hipotetis. Jadi, sangat membantu dalam hal memahami beban kerja, untuk dapat menerapkannya pada rekomendasi.
Eric Kavanagh: Itu hal-hal hebat, dan ini akan memberi saya segue bagus untuk komentar terakhir di sini. Robin dan I dan Rick juga, telah mendengar selama bertahun-tahun sekarang, ada yang berbicara tentang database self-tuning. Ini adalah basis data yang dapat disesuaikan sendiri! Yang bisa saya katakan adalah: Jangan percayai mereka.
Bullett Manale: Jangan percaya hype.
Eric Kavanagh: Mungkin ada beberapa hal kecil yang dilakukan secara dinamis, tetapi bahkan itu, Anda mungkin ingin memeriksanya dan memastikan tidak melakukan sesuatu yang Anda tidak ingin lakukan. Jadi, untuk beberapa waktu, akan membutuhkan alat-alat seperti ini untuk memahami apa yang terjadi di tingkat basis data dan seperti kata Robin, danau data adalah konsep yang menarik, tetapi mungkin ada kemungkinan mereka mengambil alih sebanyak mungkin karena ada Monster Loch Ness dalam waktu dekat. Jadi, saya hanya akan mengatakan lagi, dunia nyata memiliki banyak teknologi basis data, kami membutuhkan orang, DBA, untuk melihat hal-hal ini dan mensintesisnya. Anda bisa tahu, Anda perlu tahu apa yang Anda lakukan untuk membuat barang ini bekerja. Tetapi Anda membutuhkan alat untuk memberi Anda informasi untuk mengetahui apa yang Anda lakukan. Jadi, intinya adalah DBA akan baik-baik saja.
Dan terima kasih banyak untuk Bullett Manale dan teman-teman kami di IDERA. Dan tentu saja, Rick Sherman dan Robin Bloor. Kami mengarsipkan semua webcast ini, jadi lompat online insideanalysis.com atau ke situs mitra kami www.techopedia.com untuk informasi lebih lanjut tentang semua itu.
Dan dengan itu, selamat berpamitan, kawan. Terima kasih sekali lagi, bicaralah dengan Anda lain kali. Hati hati. Sampai jumpa.