Performans oyunu: gecikmeye elveda deyin

Techopedia Staff tarafından, May 9, 2016

Paket Servisi: Ev sahibi Eric Kavanagh, gecikme ve performans konusunda Mark Madsen, Dez Blanchfield ve Bullett Manale ile röportaj yapıyor.

Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.

Techopedia İçerik Ortağı

Techopedia Staff, Bloor Group'a bağlıdır ve sağdaki seçenekler kullanılarak iletişime geçilebilir. Sektör ortaklarıyla nasıl çalıştığımız hakkında bilgi için buraya tıklayın.

• Profil
• İnternet sitesi

Eric Kavanagh: Bayanlar ve baylar, merhaba ve Hot Technologies'e tekrar hoş geldiniz! Evet kesinlikle! Benim adım Eric Kavanagh, bu Hot Tech şovumuz, Techopedia'dan iyi arkadaşlarımızla bir ortaklık. Kurumsal teknoloji alanındaki en son gelişmeler için Techopedia.com'a online alışveriş yapın; elbette tüketici malzemelerini de kapsarlar. Buradaki teşebbüse programımıza odaklanıyoruz, bu yüzden bugün yapacağımız şey bu.

Senin hakkında gerçekten ve benim hakkımda bir yer var, Twitter'da beni vurmak @eric_kavanagh, Twitter'ı seviyorum, bu şeyleri kontrol etmeyi seviyorum, insanlarla iletişimde kalmak ve iyi sohbet etmek için harika bir yol ve bire bir -bir konuşma.

Peki neden bahsediyoruz? Bu yıl sıcak, bu bilgi yönetimi dünyasında bugün baktığımız bir fırsat evrenidir ve bugün hakkında konuştuğumuz sorgular olacak, sorguları hızlandıracak.

Sanırım “Performans Oyunu: Gecikmeye Elveda Deyin” başlığından bahsetmeyi unuttum. Peki kim gecikme ister? Kimse gecikme istemez, gecikme orada oturduğunuzda, düğmeyi tıklayıp bir şeylerin gerçekleşmesini beklerken olur ve kimse bunu istemez. Çocuklar hoşuna gitmiyor, havalı olduğunu düşünmüyorlar, yetişkinler de hoşlanmıyor. Hepimiz web'in hızından şımarıkız ve hızlı bir şekilde şeyler istiyoruz, şimdi bir şeyler istiyoruz ve bugün şovumuzda bunun hakkında konuşacağız.

Analist Mark Madsen bugün bizim düzenli arkadaşlarımızdan biri olan Üçüncü Doğa'dan. Yeni veri bilimcimiz Dez Blanchfield, Avustralya'nın Sydney kentinden. Ve sonra Bullett Manale, evet, aslında onun adı, aslında iki T olması gerekiyordu. Bullett Manale, çok ama çok ilginç bir şirket olan Idera'nın konuğu olarak çok şey yapıyor. Onları zaten biliyorum, bunlardan biri bir süre önce Precise adlı bir şirket satın aldılar. CEO'larının Zohar Gilad adında olduğunu biliyordum, bu nasıl bir isim? Zeki bir adamın heckiydi.

Ama millet, sorduğunuz sorularda bu web yayınında önemli bir rol oynuyorsunuz, bu yüzden lütfen utanmayın, sorularınızı istediğiniz zaman gönderin - bunu web yayını konsolunun Soru-Cevap bileşenini kullanarak yapabilirsiniz. sağ alt köşede. Benimle de sohbet edebilirsin, ben de konuşmacılarla sohbet edeceğim. Zaten İtalya'dan arayan biri var, “Ciao, ciao. Gel stai? ”Pekala, Mark'ın ilk çizgisini iteceğim, desteyi Mark'a vereceğim. Mark, şimdi WebEx'e sahipsiniz. Götürün, zemin sizindir.

Mark Madsen: Teşekkürler Eric. Ortadan başlamayacağım, en baştan başlayacağım. Dez ve Idera ile tartışmayı kurmak için sadece birkaç yorum, devletin geliştiği bir tür devlet, veritabanları ve operasyonlar. Ve bilirsiniz, Eğer buna bir bakacak olursanız, hala veritabanı ve uygulama pazarında bu tür iki dünya problemimiz var, çünkü geliştiriciler DBA'ları onları zorlayan insanlar olarak görüyorlar. Veri modelleri oluşturmalısınız, buna erişemezsiniz, o şeyi yaratamazsınız, daha hızlı hale getirmek için veritabanındaki her tablonun her sütununa bir dizin koyamazsınız. Ve elbette, neden modellere ihtiyacımız var? Sadece veri yapıları, eğer değiştirirsek, sadece serileştirilmiş bir formda yazamaz mısınız?

Sorun geliştiricilerin kodları ve uygulamaları bilmeleri, ancak genellikle bilmedikleri iki şey eşzamanlılık, eşzamanlı programlama ve veritabanları ve altındaki işletim sistemleridir. Bir çekirdek geliştirici ve işletim sistemleri ve veritabanları olduktan sonra, eşzamanlılık ve paralelliğin gerçekten zor olduğunu söyleyebilirim ve bu nedenle kodunuzdan iyi performans elde etmeyi öğrendiğiniz bir çok şey, veritabanı ile çalışma. Performans harika görünüyor, test ortamı harika görünüyor ve Soru-Cevap ortamı ve sonra gerçek sisteme çarpıyor ve sonra aniden çok iyi değil. Çok yönlü olduğundan, kodun veritabanıyla nasıl çalıştığı, çevre ile nasıl çalıştığı ve gerçekten basit küçük uygulamaların, çalıştırdığınız ölçeğe bağlı olarak önemli etkileri olabilir.

Dış uygulamalar hakkında konuşmaya başladığınızda, elbette, dışa dönük uygulamalar, web uygulamaları gerçekten zor olabilir, çünkü işler aniden düzleşene kadar harika olur ve değildir. Anlamak için çok fazla nüans gerektiren bu ilginç yaylalara çarpacaksınız.

Şeylerin tersi DBA görünümüdür. DBA görüşüne göre operasyonlar var, zamanlarının büyük kısmını yüzde 80 ila 90, ops ve belki de yüzde 10 ila 20 ön plana çıkan geliştirme işleriyle uğraşıyorlar. Bu perspektiften, ya şimdi ödeme yaparsınız ya da daha sonra ödeme yaparsınız ve tüm zamanınızı önceden harcıyorsanız, bir özelliği keşfetme eğilimi olan gelişimin aksine, daha sonra daha iyi bir şansınız olacaktır. ve şeylerin en iyi nasıl yapılacağını anlamaya çalışmak. Ve böylece sorunlarımız var ve şimdi uyumsuz yöntemlerimiz var - sürekli dağıtım, hazır olduklarında uygulamalarınızı yuvarlama, düzenli aralıklarla kod itme işlemleri yapma, dev ops uygulayan bir dükkanda çalışma. Bu tür bir şey gelişmeyi hızlandırır, ancak veritabanı etrafındaki tüm uygulamalar ve DBA'ların ne yaptığı ve sistem yöneticilerinin ne yapmak için eğitildikleri, BT operasyonları uygulamalarına ayak uydurmamıştır.

Bunu düşünürseniz, çoğu DBA sürekli bir dağıtım ortamına karşı bir değişim kontrol ortamında çalışır. Her şey istikrar ve kontrol, değişim hızı ve tersinirlik ile ilgilidir. Sürekli dağıtım, eğer değişiklikten vazgeçemezseniz, başınız belaya girer, bu yüzden her şey kolayca geri döndürülebilir ve kodla değiştirilebilir olacak şekilde inşa edilmelidir, bu ilişkisel veritabanı, geliştirme uygulamaları ve yönetim uygulamalarının çalışma şekli değildir .

Ayrıca, bir DBA olarak yapabileceğiniz daha fazla proaktif olmak zorunda olduğunuz bu problemlerle de karşılaşıyorsunuz, çünkü bir problemi duyduğunuzda yüz bin kişi web sitenizdeki şikayet formlarını dolduruyor. Bu, eski ortamınızdan dışarı çıkamayacağınız bazı yeni şeylere ihtiyaç duymanızı sağlar. Bilirsiniz, daha iyi izleme ve uyarma gibi şeyler. Aynı zamanda, veritabanları çoğalıyor, her zamankinden daha fazla şeyi desteklemek için her zamankinden daha fazla uygulamaya sahibiz, içerideler, dışarıdalar, her yerdeler. Ve analizler için daha bağımsız veri kümeleri, insanlar her yerde veritabanları başlatıyorlar, çünkü elbette, artık kolay, sanal bir makine kurabilirsiniz. Bir bulut sağlayıcınız veya dahili bir bulutunuz varsa, hemen bir şeyler açabilirsiniz ve bu, tüm tedarik yolunuzu değiştirir.

Eski satın alma yolu, bir kredi kartı kaydırarak ve beş dakika içinde birisine karşı “bir sunucu almak, bir rafa koymak, yer ayırmak, depolama almak, veritabanını kurmak ve bir şeyler yapmak için zamanım var” idi. Bunu yaparsanız, bu modern geliştirme ortamı çok farklı bir hızda çalışır ve bu nedenle veritabanları oluşturmak kolaydır ve bu daha önce gördüğümüz hiçbir şey gibi bir çoğalma sorununu yaratır. Ve bu on yıldır devam ediyor, bu kimseye bir haber değil, aynı zamanda işletim ortamlarının karmaşıklık içinde büyüdüğü anlamına geliyor.

İstemci sunucu ortamı gerçekten değişti, çünkü artık bir istemci sunucu dünyası değil. O zamanlar bir sunucunuz vardı, bir veritabanınız vardı, bir şey yanlışsa hangi sunucuya gideceğinizi biliyordunuz, en iyi uygulama bir veritabanı, bir sunucu olduğu için kaynakların nasıl yönetileceğini biliyordunuz. Sanallaştırma bunu parçalamaya başladı, bulut daha da kırdı, çünkü bir veritabanı sunucusu olduğunu düşündüğünüz şey sadece yazılım. Yani çevre gerçek değil. Gerçek olan ortamı içeren şey budur ve bu bir bıçak rafı veya parçalara ayrılmış büyük bir sunucu olabilir, gerçekten bilmiyorsunuz.

Veritabanı yönetimi ve performans yönetimi ile ilgili her şey ve bir veritabanıyla veya bir avuç sunucuyla ve birkaç veritabanıyla sıkı kontrol etrafında oluşturulmuş veritabanları, her şeyi kontrol edemezsiniz. Orada bir makinede oturuyorsunuz, ancak bant genişliği sanal yöneticiler tarafından kolayca bölümlenemiyor ve bu nedenle her şey bellek ve CPU ile iyi olabilir, ancak ele alınamayan bazı kaynaklarda tıkanırsınız ve ne zaman düzeltmeye çalışırsanız, eski model zor işlerde olurdu, daha büyük bir sunucu alıp böyle bir şey yapardı, şimdi gerçekten basit olabilir, sadece sanal ders ekleyin, sadece VM'ye bellek ekleyin ve çözüldü. Ancak VM'niz aşırı kalabalık bir sunucudaysa ve taşınması gerekiyorsa ne olur? Veya bir AWS sisteminin büyüklüğündeyseniz ve maksimum boyuta ulaşıldıysa, şimdi nereye gidiyorsunuz?

Böylece, ortamın veritabanının bir parçası olduğu tüm bu sorunlara sahipsiniz, bir ortamı bir veritabanıyla paketliyorsunuz, tüm özel kaynaklar, uygulamadaki her şey yapılandırmanın bir parçası, yapılandırma oraya itiliyor. Bu veritabanı ortamından, yönetmek ve kontrol etmek çok daha zor.

Veri tabanı merkezlerinin ne yaptığını görürseniz, ellerinde oturuyorlar, değil mi? Veritabanlarına ve sunuculara evcil hayvan gibi davranma fikrinden uzaklaştık. Sunucuların isimleri var, onlara bireysel olarak benzersiz şeyler gibi davranıyorsunuz, onlara sığır gibi davranıyorsunuz, sürüyü yönetiyorsunuz. Sürüleri yönetmeyle ilgili sorun, onları kontrol etmezseniz, sonunda damgalanabilir ve bir damgalama iyi bir şey değildir. Daha iyi izleme araçlarına ihtiyacımız var, bu şeylerle başa çıkmak için daha iyi yollara ihtiyacımız var ve neyin etkilendiğini bilmek. Eski modelde daha kolaydı, çünkü op'larınız ve tüm kontrol sistemleriniz size söyledi, ancak sunucu adınız bir UPC kodu olduğunda, şeyleri anlamak biraz zor.

Yanlış uyarıları göze alamazsınız, “Bu makinede bir sorun var ve bu makine 30 veritabanına ev sahipliği yapıyor” diyen şeyleri göze alamazsınız. İzleme konsolları yandığında harikadır, ancak kırmızı ışık tekrar yeşile dönerse ve nedenini bilmiyorsanız ve buna neyin yol açtığına ve neyin yol açtığına bakmak için geri dönecek bir geçmişiniz yok. bağlam, başın belada. Bizim için izleyecek sistemlere ihtiyacımız var, daha iyi bir izlemeye ihtiyacımız var, bu veri geçmişini koruyan elzem aralıklı problemlerle başa çıkmak.

Bize önemli metrikleri getiren daha iyi şeyler ve basit metrik eşikleri, ancak doğrudan normal olana, anormal olana ve bu sorunların ne sıklıkta ortaya çıktığı konusunda bizi yönlendirmez. Gerçekten bahsettiğimiz şey, izleme ortamı ve performansla uğraşmanın bir kombinasyonudur ve satıcılar ellerinde oturuyorlar. Bize daha iyi araçlar vermediler. Her şeyle ne yapacağımızı bildiğimizden daha fazla CPU ve belleğe sahip sistemlerimiz var ve yine de manuel müdahale modellerine güveniyoruz, makineyi çalışmaya, bizi yönlendirmeye, bizi sorun noktasına getirmeye koymadık, "Burada bir sorun var, bunu düzeltmek için bunu yapabilirsiniz" veya "Bir performans sorunu var, aslında bu özel SQL deyimiyle, yapabileceğiniz üç şey var. SQL deyimini düzeltmek için kullanın. ”Sezgisel yöntemler uygulamak, sorunları tespit etmek ve yanlış uyarıları önlemek için sisteminizin kullanım şekillerine bakabilen makine öğrenme modelleri uygulamak. Makinenin en iyi yaptığı şeyi yapmak, DBA'yı arttırmak veya performans sorunları ile uğraşmak zorunda olan kişiyi arttırmak için makineyi kullanma.

Eski tarzın aksine yeni yol budur. Bu veritabanı ile ilgili bir sorun var, işler yavaş, ve bu yüzden yeni tekniklerimiz, yeni yöntemlerimiz var ve bunları uygulamalıyız ve pazar burada ilerliyor. Büyük satıcılarla değil, üçüncü taraf şirketlerle büyümeye başladığını görüyorsunuz ve bu, veritabanı satıcılarının sistemleri yönetmeye yardımcı olmak için tek bir şey sağlamadığı 20 yıl önce olan bir şeyi yansıtıyor. Yani pazarın yönü budur ve bununla tekrar Eric'e geri dönmek istiyorum.

Eric Kavanagh: Pekala, bunu Dez'e teslim edeceğim. Ve Dez, götürün, zemin sizindir.

Dez Blanchfield: Teşekkürler Mark. Bunun teknik bileşenini kapsayan harika bir iş yaptınız. Dünyanın geri kalanında neler olduğunu vurgulamak için biraz farklı bir açıdan geleceğim, iş dünyası ve onların etrafındaki veritabanlarına etkisi. Sadece ilk slaytıma atlayayım.

İşlerin teknik yönünden ve şeylerin geliştirici tarafından az önce bahsettiğiniz şeyin arkasında, işletmelerin özellikle veri ve veritabanlarıyla ilgili zorluklarla yüzleşmek zorunda kaldıklarını görüyorum ve açıkçası bu önemli kayma yaşadık bu büyük veri kavramı, ancak veritabanları etkin bir şekilde, kuruluşların iş bilgilerini sakladıkları yerin kalbi ve ruhudur ve ön kapıdan arka ofise kadar uzanır. Kuruluşun her bölümüne bir çeşit veri tabanı dokunuyor ve bir veri tabanı tarafından destekleniyor ve çok nadiren proje tartışmalarına ya da veri tabanı veya veritabanı sisteminin konusunun olduğu bir kuruluşta bir çeşit yenilikçi stratejik konuşmaya giriyorum. gelmiyor ve her zaman duyduğumuz şeylerin türü, performans ve güvenlik ve geliştirme bu zorluğa nasıl yaklaşıyor ve veritabanları nereye uyuyor ve ortam ve uygulama hakkındaki farkındalığımız hakkında her zaman sorular var ortamlar konuşur, cihazlar ve mobilite ne olacak?

Bu hala çok, çok sıcak bir konudur ve modern teknolojinin ilerleyişine göre, büyük şemada uzun, uzun süredir bir konudur. Bu noktaya kadar, günlük yaşamlarımızda, günlük yaşamlarımızda yaptığımız hemen hemen her şeyin şu anda bir çeşit veritabanı tarafından desteklenmekte olduğuna inanıyorum. Çevremizdeki her şeyi düşündüğümüzde, satın aldığımız bir hizmet için her gün postada gelen bir fatura olsun, kaçınılmaz olarak bir veritabanıyla konuşan bir sistem tarafından basılıyor ve oradayız. Telefonlarımızda kişiler, arama kayıtları ve diğer şeylerle ilgili veritabanları vardır.

Nereye gidersek gidelim, konuşmanın ve kullandığımız sistemlerin arkasında bir çeşit veritabanı var ve çoğu zaman bizim için oldukça şeffaflar, ama gerçek şu ki oradalar. Bu yüzden kısa sürede bunun neden bir sorun haline geldiğini çabucak ele alacağımı düşündüm. Başlangıçta, veritabanı kavramı bu sevimli beyefendi Edgar Codd'dan geldi. IBM'de çalışırken, şimdi ilişkisel veritabanı olarak adlandırdığımız bir konsept oluşturarak dünyayı veri yönetimine kadar değiştirdi.

Başlangıçta veritabanı bir veritabanıydı ve hayat iyiydi, hem sütunlarda hem de referanslarda ve benzeri yerlerde oldukça basitti ve yazılım ve geliştirme yazılımı oldukça basitti ve performans gerçekten büyük bir sorun değildi - yeni ve heyecan verici bir teknolojiydi. Veritabanlarına bir tür terminal aracılığıyla eriştik ve sadece bir ana karedeki 3270 terminalinin sonunda çok fazla tahribat yaratabilirsiniz ve her zaman diğer terminal türleri, diğer sistemler ortaya çıktı. Çoğu durumda, eski stil terminalleri şu anda hangi web ortamlarına çok benziyordu ve terminaldeki ekranda bir form doldurup Enter'a basarsınız ve gidecekti, bir paket olarak, istek olarak ateş edin ve arka uç sistemi bununla başa çıkacaktır. Bir web tarayıcısında bir bağlantı yazdığınızda ve bu form genellikle sisteme gerçek zamanlı olarak gitmediğinde, bu günlerde bir web tarayıcısında olan şey budur, ancak bu günlerde AJAX ile bu tamamen durum.

Ama sonra bir şey oldu, gelecek geldi ve daha yakın zamanda internet ve neredeyse dün, bir saniye web 2.0'da ve hemen köşede Nesnelerin İnterneti var. Ve gelecekteki gerçekleşme sürecinde, veritabanı dünyası patladı ve veritabanlarıyla etkileşimler varsayılan olarak hepimizin yaptığı bir şey haline geldi, satın almak gibi bir yere gitmek için bir yere gitmenizin bir örneği değildi bir uçak için bir bilet ve gezegenin diğer tarafına seyahat etmek isteyen biri, tüm terminale tüm bilgilerinizi yazıp bir veritabanına girip bir bilet basmak zorunda kaldı.

Şu anda yaptığımız hemen hemen her şey, ister Google'da bir uygulama ile taksi çağırıyor olsun, ister internet bankacılığına atlıyor olsun, günlük bazda yaptığımız her şey, bir çeşit sistemle, bir veritabanı ile güçlendiriliyor. Ve internet geldiğinde, bu bize getirmek biraz daha kolaydı, günlük hayatımızı bir web tarayıcısıyla yaşadık ve sonra web 2.0 geldi ve işler mobil hale geldi ve şeylerin ölçeği patladı. Aslında, bu konudaki en sevdiğim çizgi, “İnternet her şeyi birbirine bağladı, web 2.0 onu mobil ve sosyal hale getirdi ve işler çok, çok büyüdü ve şimdi internet ve şeylere sahibiz ve IoT… Yikes !!” Dünyaya gelince veritabanı sistemlerinde Nesnelerin İnterneti'nin etkisini hayal etmeye bile başlayamadık.

Modern terimlerle, bir terminal olarak düşündüğümüz şey, bu şeyler etkili hale geldi, cep telefonları, kişisel tüketici veya kurumsal sınıf geniş ekran tabletler, dizüstü bilgisayarlar ve geleneksel masaüstü bir şekilde. Bu görüntüde, elimizde dolaşan ve yapıştırılmış gibi görünen küçük araçlardan, bunlarla çalışan veritabanı sistemleri ve uygulamalarla konuşmak için kullandığımız hemen hemen her arabirim biçimini görebilirsiniz. biraz daha büyük sürümlere ve iPad'lere ve diğer tabletlere ve Microsoft Surfaces'e, her zaman profesyonel ortamlarda vb. İnsanlar sabit bir masaüstü değil, bir dizüstü bilgisayar edinme eğilimindedir, ancak benim görüşüme göre modern bir terminaldir ve veritabanlarının sadece gelişim değil, yönetim performansı bölümünde her türlü zorluğu yaşamalarının bir parçasıdır.

Dolayısıyla, işletmelerin günlük olarak karşılaştıkları en büyük zorluklardan biri olduğunu varsayıyorum. Herkes veritabanlarının tek sorunumuz olduğunu düşünüyordu, değil. Peki tüm bu karışıklık ne hakkında? Veri tabanları ile ilgili her şeyle, ticari anlamda ve Mark'ın teknik bileşenleri çok ama çok iyi kapsadığı, ancak ticari anlamda bir organizasyon olarak veritabanlarını düşünüyoruz. Temel tasarım ve geliştirme ön ucundan başlayarak her şeyle ilgileniyoruz. Bir işletme başladığında, uygulama geliştirme, bir yetenek geliştirme ve hatta mevcut bir uygulamayı bir şekilde uygulamayı düşünürler. Bazı tasarım ve geliştirme biçimleri yer almalı ve bu veritabanı sistemlerinin nasıl uygulanacağı, desteklenip yönetileceği ve performansların izlenmesi vb. Üzerine büyük bir düşünce getirilmelidir.

Veritabanı ortamının ve uygulamalarının entegrasyonu ve API türleri, şu anda sağlanan erişim türleri gittikçe daha zorlu ve karmaşık hale geliyor. Günlük yönetim, destek ve yedeklemeler, yine, bunlar çözüldüğünü düşündüğümüz şeyler, ancak daha sonra ölçek birden büyüdü ve işler daha hızlı ilerledi ve hacim çok daha büyüktü; ortamların büyüklüğü, veritabanı sistemleri işlemlerin hareket hızını desteklemek zorunda kaldı.

Çok, çok yüksek frekanslı bir ticaret ortamında bir veritabanı düşünün, insanların bunu takip edebilmesinin hiçbir yolu yoktur, sadece yüksek frekanslı ticaret, satın alma ve satış yapmak için başka bir makine kümesiyle savaşan ve bu işlemler gerçekleşiyor. Modern bir senaryoyu düşünün, örneğin sadece yüzlerce veya binlerce, hatta yüz binlerce, potansiyel olarak milyonlarca insanın bu filmi piyasaya çıktığı andan itibaren izlemek isteyen bir Netflix filminin erken sürümü gibi düşünün. Tüm bu bilgiler bir veritabanı platformunda yakalanır, izlenir ve kaydedilir ve analiz edilir.

Ve şimdi içinde yaşadığımız her zaman açık olan dünya var, 7/24, sadece Güneş'i takip etmekle kalmıyor, aynı zamanda gece yarısında her zaman bir şeyler yapmak isteyen biri var ve iş saatleri dünyanın her yerinde Güneş'i takip ediyor. Bu nedenle, çalışma süresi ve kullanılabilirlik varsayılan olarak şimdi bir iklimdir, bir kesintiye sahip olmak gerçekten kabul edilebilir bir şey değildir. Ve artıklık, bir performans sorunu varsa veya yükseltme veya düzeltme eki veya güvenlik yapmak için bir bakım penceresine ihtiyacımız varsa, gerçekten, bir veritabanı ortamından diğerine kesip sorunsuz ve otomatik olarak yapabiliriz.

Güvenlik ve standartlar ve uyumluluk, geç dünyada, özellikle GFC'de oldukça büyük şeyler oldu ve bu nedenle uyumluluk, güvenlik ve eşleşen standartlar etrafında bir dizi yeni zorluğumuz var ve ihtiyacımız var gerçek zamanlı olarak ve ideal olarak gösterge tablosu şeklinde rapor verebilme. Bir şeyler bulmaya çalışan bir veri merkezine maymunlardan oluşan bir ekip göndermek istemiyoruz, bunu derhal gerçek zamanlı olarak bize bildirmek için sisteme ihtiyacımız var.

Ve neredeyse hiç kimsenin bahsetmediği iki eğlenceli, genellikle onları halının altına itiyoruz ve çirkin kafalarını yükseltmemelerini umuyoruz, ancak felaket kurtarma ve iş sürekliliği - bunlar da yapılması gereken şeyler çoğunlukla, ihtiyaç olduğunda otomatik olarak gerçekleşir.

Veritabanı ortamlarında yanlış gidebilecek şeyler hakkında konuşarak günler geçirebiliriz ve insanların genellikle yanıt verdiklerini, ancak şimdi bunu bizim için yapmak için sistemlere ve araçlara ihtiyacımız var. Bir örnek veri ihlali ve bu nedenle, veritabanları hakkında düşündüğümüzde ve bu soruyu çeşitli şekillerde oldukça açık bir şekilde sorduğumda: gözlerimizi topun dışına aldığımızda veritabanlarına ne olur ve kritik bir şey yanlış gider? Özellikle performans ve güvenliği izleyen bir sistem yoksa ve veritabanlarını çalıştırmanın diğer önemli yönleri varsa.

Olabilecek şey, bu son iki ila üç yıl içinde meydana gelen son ihlallerin bir ekran görüntüsü. Her zaman bir veritabanı sisteminden geliyorlar ve her zaman güvenlik veya kontrol veya erişimde bir sorun oluştu ve sol üst köşede 152 milyon Adobe hesabına bakıyoruz. müşterilerinden biri ihlal edildi. Ve olayı izlemek ve yakalamak ve güvenliği kontrol etmek için uygun araçların mevcut olması durumunda, bunlardan bazılarından kaçınmış olabiliriz, çalınan yüz kayıtların ilk birkaçı bizi uyarmış olabilir ve sonraki yüz elli milyonu durdurdu.

Sonra bu yolculuğun anahtar noktasına ulaşıyoruz, bizi ele geçirdik, yani: neden daha iyi sistemlere ihtiyacımız var? Neden bu şeye daha fazla ceset alamıyoruz, bence dönüm noktasını iyi ve gerçekten geçtik ve kesinlikle geç kanıt olduğuna, daha fazla DBA, yönetici ve daha fazla insan attığına inanıyorum. bu şey sorunu çözmez. Daha iyi bir araç setine ve daha iyi bir sistem setine ihtiyacımız var.

İşte bunu desteklediğime inandığım ilk beş nedenim ve bu özel işletmeler ve yönetilen ortamlar, veritabanı ortamlarıyla karşılaştıkları zorluklar karşısında gördüğüm şeylere göre önem sırasına göre sıralanıyorlar, ve onları yönetmek.

Güvenlik ve uyumluluk - bir numara. Kimin erişebileceğini, nereden erişebileceğini, erişime sahip olduklarında, ne sıklıkta erişime sahip olduklarını, nereden eriştiklerini kontrol edebilirsiniz. Potansiyel olarak gerçekten dokundukları cihazlar ve baktıkları şeyler ve etrafındaki uyumluluk. İnsanların 30 gün sonra işlerin iyi olup olmadığını anlatmak için raporlar yayınlaması artık uygun değil, gerçek zamanlı olarak gerçekleşmesi gerekiyor.

Performans ve izleme - beyinsiz gibi görünüyor, ama her zaman değil. Açık kaynaklı araçlar veya bazı üçüncü taraf ticari araçlar kullanıyor olsak da, gerekli olan performans izleme türleri ve hangi ayrıntıyla ve zaman içinde yanıt verme kabiliyeti ile her zaman tekneyi kaçırmadık .

Olay tespiti ve yanıtı - anında gerçek zamanlı bir şey olmalı ve her zaman bunu bizim için yapacak bir sisteme ihtiyacımız var veya en azından bizi hızlı bir şekilde uyarmalıyız, böylece ortaya çıkan birkaç sorun ele alınacak ve kontrolün dışına çıkmayın.

Yönetim ve idare - yine, bu sorunların çözüldüğünü düşünüyoruz, çözülmediler. Veritabanı ekiplerinin, özellikle de bir sistemin bizim için bir şeyle ilgilenmesi gereken DBA'ların karşılaştığı sorunların hedefi, bu sorunu henüz çözmedik, hala gerçek bir şey.

Ve tasarım ve geliştirmeyle ön uçtan itibaren, bu araçları oluşturmaya başladığımızda, veritabanı ortamlarını oluşturuyoruz, geliştirme ve test ve entegrasyon platformlarına uygun araçları atabiliyoruz. Bu hala bizim için kolay bir şey değil ve tüm bu yolculuk, bizi aynı mesaja yönlendiriyor, bence, ihtiyaç duyduğumuz sonuçları sunmamıza yardımcı olacak daha iyi sistemlere ve daha iyi araçlara ihtiyacımız var. veritabanı ortamımızın, dolayısıyla müşterilerimizden değer sağlayan işletmeler. Sadece daha fazla beden ve daha fazla DBA atmaya devam edemeyiz, ölçek çok büyük, hız çok hızlı ve ses seviyesi çok yüksek. Bununla Eric sana geri dönebilirim.

Eric Kavanagh: Bayıldım, orada çok fazla yerimiz var, çok fazla potansiyel müşteri ve devam edip sadece bir saniyede Bullett'e geçtik.

Bullett Manale: Tamam.

Eric Kavanagh: Oh, hadi götürelim ve Bullett, şimdi sana teslim ediyorum ve zemin senin.

Bullett Manale: Tamam, teşekkür ederim. Bence birçok iyi noktaya değinildi. Idera hakkında kim olduğumuz hakkında hızlıca konuşmak istedim ve sonra atlayacağız. Bence bahsettiğimiz bu şeylerin çoğundan bahsettiğimiz araç hakkında konuşacağım bu araçla Diagnostic Manager ürününün hizalandığı alanların bazılarını oluşturup türlerini tartışabilirsiniz.

Şimdi, ilk olarak yapmak istediğim şey, size Idera'nın kim olduğu hakkında biraz bilgi vermek; 2003'ten beri buradayız ve bu yüzden sadece SQL Server araçlarıyla başladık ve bugün odaklanacağımız şey Teşhis Yöneticisi ürünü olacak. Ancak burada sahip olduğumuz şeylerin tüm kovalarını görebilirsiniz ve son zamanlarda daha önce de belirtildiği gibi, Precise'ı satın aldık ve satın alma yoluyla Embarcadero'muz da var ve bu yüzden oldukça iyi bir ürün portföyümüz var.

Performans izleme açısından, SQL Server açısından bahsetmek istediğim, tartıştığımız bu konuları hizalayan ürün Tanı Yöneticisi'dir. Şimdi, bu, Idera'nın günlerinin başlangıcından beri oldukça yakın olan bir üründür ve 2005'ten beri bunun bir parçası olacak kadar şanslıydım. Ve açısından birçok değişiklik gördüm. SQL Server, fizikselden sanal olana geçişler, olan bu tür şeyler ve ayrıca ortamlar büyüdükçe DBA'ların ihtiyaçları ve bu tür şeyler.

Başladığım şey, ürünümüzün tipik kullanıcısı DBA idi ve bu yüzden ilk kez, potansiyel müşterilerle konuşurken, çoğunlukla konuştuğumuz DBA'lar. BT yöneticileri veya yöneticileri ile konuşmuyoruz, bir noktada bu seviyeye gelebilir, ancak ilk başlangıç ​​DBA'nın bir sorunu olduğu, DBA'nın sorunu çözmeye çalıştığı ve çoğu zaman Ürünün bir parçası olarak gidip ürünü indirip denemeniz gerekir.Veri yöneticisi veya DBA veya oyunculuk DBA, bazı durumlarda odadaki en teknik olacak kadar şanslı olan adamı alırsınız. Şimdi, daha büyük kurumsal ortamlara ulaştığınızda, açıkçası, tam gelişmiş DBA'ları alacaksınız, bunlar genellikle aracı kullananlardır. Ve devam ettim ve Wikipedia'dan biraz bulanıklık ekledim. Wikipedia'nın dediği gibi DBA'nın sorumluluklarını aşıyor, işte böyle yapıyorlar.

Buradaki listeden geçerseniz, bu şeylerin çoğunu okuyacağım, ama düşüneceğiniz tipik şeylerden birçoğunu alıyorsunuz ve sonra bunlardan birinde, izlemeniz var ve veritabanının performansını optimize ediyoruz ve bu oldukça büyük. Ve ilginç olan şey, DBA ile konuştuğunuzda, her zaman ilk önce suçlananlardır, sorun söz konusu olduğunda ve gerçekten onların hatası olmayabilir, ancak bir performans sorunu olduğunda, genellikle bir DBA veri tabanına bağlıdır, suçu alan kişilerdir, bu yüzden her zaman onların suçu olmamalarının nedenlerini ararlar. Çoğu durumda, bu aracı, Tanı Yöneticisi'ni kullanmaları için kullanabilecekleri şey budur.

Ancak günün sonunda, eğer veritabanı performans göstermiyorsa, diğer şeylerin çoğu gerçekten önemli değil, uygulamalarınız işe yaramıyor, o zaman bunların çoğu için gerçekten önemli değil bir şeyler. Her şeyden önce, kullanıcı deneyimini bildiğimiz şekilde deneyimlediğimizden emin olmak istiyoruz, bu DBA'ların her zaman doğru çabaladığı bir şey. Ve bence, insanlar genellikle SQL Diagnostic Manager ürününü satın alıp kullanma nedenlerine bakarsanız, ilk nedenlerden biri, muhtemelen en önemlisi değil, en az değil, en azından, ve kiminle konuştuğunuza bağlı olarak, bu nedenlerden, neredeyse bir veya iki tanesi her zaman vardır, etrafta bir çeşit ihtiyaç vardır.

Ancak birincisi, örneklerin yönettikleri SQL olarak bu merkezi görüntüye sahip olabiliyor. Komik olan şey, bir çok durumda, bir DBA'ya “Kaç örnek yönetiyorsunuz?” Diye sorarsanız, sayı o kadar sık ​​değişir ki, bazı durumlarda gerçekten emin değildirler. Yani her şeyi ekrana fırlatmaktan başka bir şeye ihtiyacınız var. Bu bilgileri kavramak istiyorsunuz, anlam ifade etmek istiyorsunuz ve bu nedenle Tanı Yöneticisi'nin kesinlikle yardımcı olabileceği şeylerden biri, size çevreye bu tür bir bakış açısı sağlayabilmektir.

Ve bu sadece çevreye bir bakış değil, aynı zamanda veritabanı yöneticisi DBA'nın rahat olduğu ve eğer istersen DBA merkezli bir konsol. Bir veritabanı yöneticisi için yapılır. Dışarıda çok sayıda izleme aracı var, orada çok sayıda performans aracı var, ama dediğim gibi, günün sonunda DBA, DBA için tasarlanmış bir araç istiyor, çünkü yaptıkları işe özgü birçok şey var gün geçtikçe.

Bununla birlikte, SCOM'unuz var, HPF'niz var, diğer tüm teknolojilere sahipsiniz, ancak yaptıkları işe özgü bir şey istiyorlar. Bu ürünle bu alanda yardımcı olabileceğimizi düşünüyorum, bir saniyede ne zaman girdiğimizi göreceksiniz. Kesinlikle daha önce de değindiğimiz şeylerden biri olan DBA ile gördüğümüz diğer bir şey, açık bir şekilde neler olduğunu görebilmeleri ve tüm işletmeye bakabilmeleri gerektiğidir. ve neler olduğunu bilmek için biraz huzurlu olun. Ama aynı zamanda orada oturmuyorlar, konsollara bakıyorlar.

Listede gördüğünüz, az önce çektiğim tüm kurşun noktalarını hatırlıyor musunuz? Diğer şeyleri de yapmak zorundalar, bu yüzden sadece yangınların söndürülmesini beklemekle ilgili değil. Çoğu durumda toplantılar olacak veya veritabanı yöneticisi ile ilgili bakım pencerelerinin birçoğu uyudukları gecenin ortasında çalışıyor, bu yüzden geri dönüp neler olduğunu görmeleri gerekiyor . Çoğu durumda, bir şey olurken yakalamazsanız, sorun ortadan kalktığında veya en azından SQL Server ile ilgili olarak, bu, yapmadığınız durumla uğraştığınız bir sorun haline gelir. artık bu sorunun kalıntıları var. Ve bu sorunlar ortadan kalkar ve kalıntılar da gider, yani sorun gidermek için daha az şeyiniz vardır, çalışmak için daha az bilginiz vardır.

Bununla birlikte, bu kesinlikle Diagnostic Manager'ın yardımcı olabileceği şeylerden biri, geçmişten gelen bilgileri sorgulamak için geçmişe bu görüşü vermektir, “Engelleme konusunda bir uyarı aldım mı, kilitlenme ile ilgili sorunum oldu mu, kaynaklarımız açısından olan şeyler oldu mu? ”Geri dönüp bu bilgiyi sorgulayabilirim. Zaman içinde belirli noktalara inebilirim. Tüm bunları doğrudan araç içinden yapabilirim.

Tüm bunlar, dahili veya harici bir uygulama olmasına rağmen, DBA bilmek ister, çünkü soruna neyin neden olduğunu görmek isterler. Örgütün içinde biri mi yoksa kodu dışında örgütün dışında biri olması önemli değil; hala onu izole edebilmek istiyorlar, böylece sorunun olduğunu biliyorlar ve nereden geldiğini biliyorlar.

Dolayısıyla performans ve hesap verebilirlik, ürünümüzün önemli bir parçasıdır. Tüm bu ayrıntıları sağlayabiliriz ve hoş olan şey, detaya inme yeteneğine sahip olmanızdır. Bir darboğaz varsa, bunu uygulama, kullanıcı, veritabanı ve sorgu ile ilişkilendirebilirsiniz. Ve bir kez daha, bir tür sigara silahı. Bu sorgu çalıştığında, ne yapıyor arasında doğrudan bir ilişki olsun. Ve sadece sorgunun kendisi ile ilgili değil, kendi içinde ve kendi başına yürütülüyor, aynı zamanda zaman içinde sorgu daha da kötüleşiyor mu? Ve bu şeyler de ürünle cevaplanabilir, ki bu kesinlikle proaktif olmaya çalışıyorsanız, "Hey, işte kötü giden bir sorgu, ama çocuk bak daha da ilerledikçe, daha da kötüleştiğini görebiliyoruz, bu konuda bir şeyler yapabilirim. "

Burada bir sonraki bölgeye gidersek; ve bu muhtemelen - bunun büyüklerden biri olduğunu söyleyebilirim. Sorduğum sorulardan biri, ürünümüzü gösterdiğimde, veritabanı yöneticisine her zaman "SQL Server veritabanlarınızla ilgili bir problemi nasıl duyuyorsunuz?" Ve bu çok komik, çünkü çoğu zaman - şimdi veriliyor, çoğu zaman ürünümüze bakıyorlar, çünkü çoğu durumda belirli bir ihtiyacı çözmeye çalışıyorlar. Ama ilk tür şeyleri duymak ilginç - en azından SQL Server ile, bu tür bir şeydi - bilirsiniz, SQL Server'ın ilk günlerinde SQL Server'ınız vardı ve sonra Oracle'ınız vardı. Herkesin Oracle'ı vardı ve SQL Server, daha iyi bir ifade eksikliği nedeniyle, ilk başladığında veritabanlarının kızıl saçlı üvey çocuğuna benziyordu.

Ve sonra Microsoft ona daha fazla özellik ekledikçe, biraz daha kurumsal bir araç haline geldi. Ve açıkçası, o zamandan beri çok yol kat etti. Ama mesele şu ki, bir kez veritabanlarının gün içinde kritik olarak değerlendirilmediğini iddia edebilirsiniz. Ve bu zamanla değişti. Bundan dolayı, birçok durumda insanlar ellerini etrafında tutmaya çalışıyor ve “Biliyor musunuz? Tüm bu SQL Server veritabanlarına sahibim, bunun üstesinden gelmeye çalışıyorum. "Ve yardım masasındaki sorunları duymak veya kullanıcıların kendileri gibi belirli kişilerden gelen sorunları duymak yerine bunun etrafından dolaşmanın bazı yollarını arıyorlar ve bu durumlardan daha önce farkına varılmanın yollarını arıyorlar.

Ve böylece Diagnostic Manager ile, bu da yapmaya çalıştığımız şeylerden biri, en azından DBA'nın bu durumlar veya bu problemler hakkında ilk bilen kişi olmasını sağlayabilmektir, böylece izledikleri bu sistemleri analiz etmek için, ne zaman olurlarsa olsunlar, ya da bir adım daha ileri gitmek. Ve bu örneğin performansını artıracak proaktif önerilerde bulunabilmek ve bunu düzenli olarak yapabilmek. Örneğin, iş yüküne dayalı bir dizin eklememiz gerekir; bu tür şeyler, yapabilen araçlar da. Yani araçta bunların çoğunu göreceğiz.

Diğer şey ve bu listedeki son şey, bu biraz daha genel bir açıklama, ama kesinlikle kayda değer bir şey. Ve özellikle, çok sayıda örneğinizin olduğu daha büyük kurumsal düzeydeki durumlara girdiğinizde, veritabanı yöneticisiysem izlemek isteyeceğim her zaman belirsiz bir şey olacaktır. misal. Ve yapmaya çalıştığımız şey, tipik DBA'nın izlemek istediği şey açısından tahmin etmektir.

Bununla birlikte, her zaman yeni bir şey olacak. Bu nedenle, yükleme noktası eklendikten sonra izlemeniz ve yönetmeniz gereken metrikleri eklemeniz için bir yol sağladık. Yani herhangi bir PerfMon sayacı, WMI sayacı, SQL Server sayaç nesnesi; bunların hepsi araca dahil edilebilir. Yoklama aralıklarınıza eklenebilecek ek sorgular ekleme olanağınız vardır.

Ayrıca, dikkat çekmeye değer son şey, metrikleri bu ortamlardan alabilmek için hem vCenter hem de Hyper-V ekleyebilir ve aslında iletişim kurabiliriz. Çünkü DBA ile belirlediğimiz şeylerden biri, tipik olarak özel olarak operasyonların bir parçası olmamalarıdır. Ve genellikle, bilirsiniz, vCenter ortamına, kendilerine veya bu tür şeylere erişebilecekleri şeyler olması gerekmez.

Ve sorun şu ki, eğer bir SQL Server örneği ile uğraşıyorlarsa ve kaynak tahsis edilmişlerse, ancak bu örnek sanallaştırılmışsa, sadece ne olduğunu izlediklerinde dünyadaki tüm kaynaklara sahip gibi görünebilirler. Konuk işletim sisteminde. Gerçek şu ki, ana bilgisayarda, erişmeye çalıştıkları 30 veya 40 veya 50 veya 100 başka VM olabilir ve aynı kaynakların çekişmesine sahip olabilirler. Ve bunu gerçekten görmenin tek yolu diğer ortamlarla ve bu arayüzlerle yaptığımız bu arayüzlerle iletişim kurmaktır.

Bu tür sayaçları araca ekleme olanağına sahipsiniz. Şimdi sadece bu sayaçları izlemekle kalmıyor, aynı zamanda bu yeni sayaçları da ürünle tanıştırabiliyor, onları hazır bir metrikmiş gibi aletin bir parçası haline getirebiliyoruz. . İzlemek istediğiniz hazır bir şey; bu, onları gösterge tablolarına dahil edebilmek anlamına gelir. Bunları kendi özel raporlarınıza ekleyebilmeniz, açık bir şekilde eşikler ayarlayabilmeleri ve bunlar hakkında uyarıda bulunabilmeniz, aynı zamanda bunları temel alabilmeniz ve ve normal olan. Yani, üründe de olan bir çok şey var.

Size ne tür bir şey sağladığım, "Tanı Yöneticisi için temel çıktılar" olarak adlandırdığım şeydir ve devam edebilir ve ürüne girerek size biraz tadına bakabilirim. Ekranımı paylaş, tamam, ve sadece onu sürükleyeceksin. Göreceksin, bu Teşhis Yöneticisi'nin konsolu ve daha önce de belirttiğim gibi, ilk çekirdeğe gidip, kurumsal düzeyde bir bakış açısına göre işler.Araç içinde bunun birçok farklı örneği var.Bir tür küçük resim görünümümüz var; daha çok ızgara benzeri bir bakış açısına sahibiz.Ayrıca, esneklik açısından, Web tabanlı konsol da önemli haritalar ve bunun gibi şeyler gibi kullanabileceğiniz başka görünümlere sahiptir.Ama nokta, şeylere bakma ve bunları görme yeteneğine sahip olmanızdır. Ancak sorunlar ortaya çıktıkça, araca biraz daha inersiniz ve aslında belirli probları görürsünüz. ve neler olduğunu anlamak ve bilmek için bir yol var. Ve tabii ki bu çok önemli.

Şimdi, geçmişte neler olduğunu gerçekten görebilmek için; dün veya bir hafta önce olan bir soruna bakıyorsam, bu durumda, bilirsiniz, belirli bir SQL örneğine gitmeniz gerekecek. Ve iyi haber şu ki, bu sorunun ürün içinde ne zaman meydana geldiğini biliyorsanız, doğrudan geçmiş tarayıcısına gidebilirsiniz. Ve günün belirli bir zamanına işaret edebilirim; birkaç hafta önce olabilir, dünden olabilir. Ama takvimde hangi gün seçersem seçeyim, farklı seçim aralıkları ile karşılaşacağım. Bu durumda şimdi, 20 Nisan'da 13: 37'de konsolu görseydim ne göreceğimi etkili bir şekilde görüyorum.

Bu yüzden zaman içinde geri dönebiliyorum ve sonra bunu yaptıktan sonra, burada gördüğümüz tüm farklı sekmeler, o zaman da dahil olmak üzere, kötü çalışmış olabilecek sorgular da dahil olmak üzere belirli bir noktayı yansıtacaktır. Engelleme seansları yaptım. Tüm bu tür şeyler araçta görünecektir ve bu, problemi çözebilmeniz için tarihsel bilgilerin açık bir şekilde kullanılmasına izin verecektir. Şimdi bu notta, tarih hakkında konuşurken, burada dikkat çeken bir diğer şey, sadece problemleri çözmek için geçmişi kullanmak değil. Bu tarih açıkça başka nedenlerle çok değerlidir. Ve en önemlilerinden biri, doğru bilgilerle verimli bir şekilde karar alabilmek ve hızlı bir şekilde karar alabilmektir. Böylece tüm bu tarih, topladığımız tüm bilgiler hakkında rapor verebiliriz.

Birisi bana gelir ve "Bu gerçekten harika yeni bir uygulama var. Dünyayı bildiğimiz gibi değiştirecek. Oh, bu arada bir veritabanı gerektiriyor, ve bu arada gerçekten peg olacak Bu veritabanının bulunduğu makinedeki G / Ç. " Bunun içine girmeyi biliyorsam, belki de son yedi güne dayanan tüm üretim sunucularımın bir sıralamasını sağlayabilmek için bu bilgilerden yararlanabilirim. Ve hangi örneklerin bu veritabanını çalıştırmanın en mantıklı olduğu sonucuna çok çabuk ulaşabilirim. Yani bu da çok değerli olan tarihsel bilgi türüdür.

Sorguların kendileri açısından; sorgulara bakmak açısından, bunu araçta yapmanın birçok farklı yolu var. Bakmak istediğim, Sorgu Bekleme Görünümüdür, çünkü Sorgu Bekleme Görünümü değerlendirme yapabilmek açısından çok yararlıdır. Gerçekte meydana gelen bir darboğazım varsa, temelde bu belirli sorguyu etkileyen tüm farklı alanları tanımlayabilmek için; sadece sorgunun kendisi ve bu sorgunun etkisi nedir, aynı zamanda hangi uygulamadan geldiğini, hangi oturumdan geldiğini, hangi kullanıcının onu çağırdığını ve tüm bu şeyleri açık bir şekilde görebilirim. aynı zamanda geçmişten gelen verilere bakma yeteneğim de var. Ve buradaki şeylerden biri ve ben bir senaryo başlattım, ama bir tür pop-up'ın açılmasını beklemeliyim.

Bunu beklerken, istiyorum - ve zamanımızın kısa olduğunu biliyorum, bu yüzden bildirimin proaktif olduğu konusunda da biraz konuşmak istedim. Ve dediğim gibi, proaktif kısım olarak, bu tür şeylerden bahsederken, uyarı veren birçok araç var. Zor kısım e-posta göndermiyor. Sabit bölüm olay günlüğüne yazmıyor veya bir SNMP tuzağı oluşturmuyor. Zor kısım, bu uyarıyı uygun zamanlarda ne zaman göndereceğini bilmektir. Ve bununla birlikte, bazı hesaplamalar yapmak zorunda kalmak, "O örnek hakkında ne var ve o örnekle ilgili normal olan nedir?"

Ve böylece, bunu yapmak anlamlı olan tüm metrikler için, bu metrikleri temel alıyoruz. Aslında size taban çizgisini gösteriyoruz, size şu anda ayarlanmış olan eşiği göstereceğiz. Ve sonra bununla ilgili diğer güzel şey, diyelim ki, bu örnek için eşiklerimi bu durumda altı ve on olarak ayarladım. Bundan altı hafta sonra, bu örneğe geri dönersem, bu taban çizgisi tamamen değişebilir, çünkü taban çizgisini hesaplarken yaptığımız şeylerden biri, varsayılan olarak, yedi günlük bir hesaplamadır. Yani bana her zaman taban çizgisinin güncel bir versiyonunu veriyor. Ve bu taban çizgisi eşiklerime doğru yükselirse ne olur? Bu durumda, temel olarak, "Hey, muhtemelen yanlış ayarlanmış bir eşik var, eşiğin nerede olduğunu gördüğümüze ve açıkça taban çizgisinin nerede olduğunu belirten önerileri görebilir ve uyarabilirim. normal bir olay için bir uyarı almak. "

Bu nedenle, normal bir şeyin belirtisini tedavi etmek yerine, gerçek eşiğin yanlış ayarlandığı bu tür bir durumu tanımlayabiliyorum. Ve bu açıkça yapmamı sağlayan şey, eşikleri bir uyarı alacağım yere göre ayarlamak. Gerçekten bir sorun olup olmadığını görmek için bir soruşturmaya karşı bir eylem çağrısı olarak bildiğim bir şey. Ve aracın bir kısmının taban çizgisinin kendisi ve hesaplayabilme açısından gerçekten yararlı olduğunu düşünüyorum.

Şimdi, bu ürünle aslında birden fazla taban çizgisine sahip olma yeteneğine sahipsiniz; bunları farklı süreler için ayarlayabilirsiniz ve taban çizgilerinize göre eşikleri dinamik olarak ayarlayabilirsiniz; bu, SQL Server örneklerinize günlük olarak gerçekleşen değişikliklere uyum sağlamanın çok önemli bir parçasıdır. . Şimdi, bu durumda burada, eşiklerin birçok ayarını ele alıyoruz ve size taban çizgilerini gösteriyoruz. Ancak, gerçek uyarılar söz konusu olduğunda, bildirimin kendileri, Tanı Yöneticisi ile ilgili harika şey, size birden fazla uyarı profili sağlamasıdır. Örneğin, 2: 00-17: 00 arasında bir çağrı üzerine profiliniz varsa, o zaman aralığına özgü bir profilim olabilir ve tüm koşulları ve uygun ayarları burada ayarlayabilirim cevabım için.

Şimdi, yanıtla ilgili olan şey, bazı durumlarda, evet bir e-posta gönderebilirim veya bir SNMP tuzağı çekip oluşturabilir veya olay günlüğüne yazabilirim. Yapabileceğimiz başka pek çok şey var, ancak DBA'larla konuştuğumda, gerçekten, gerçekten sevdikleri şey, çoğu durumda yapılan işlerin çoğunun tekrarlayan şeyler olmasıdır. Sorunun tam olarak ne zaman meydana geldiğini, düzeltmek için ne yapmaları gerektiğini bildikleri şey. Sadece gidip müdahale etmek zorundalar. Ve böylece ortamınızı büyüttüğünüzde, daha fazla örneğiniz olduğu için, bunu yapmak çok daha zor hale gelir. Bu nedenle, dikkat çekmeye değer olduğunu düşündüğüm araçta yapabileceğiniz şeylerden biri, bir koşulu ayarlayabilme yeteneğiniz var, ancak bu koşula dayanarak bir komut dosyasını çalıştırmak, çalıştırılabilir. Ve mesele şu ki, bir komut dosyasını çalıştırmaya karar verirseniz parametreleri kullanabilirim, bu komut dosyasının içinde çalışma zamanında olacak, gerçek bilgilerle doldurulur.

Bu nedenle, belirli bir veritabanıyla ilgili sorunlar varsa, komut dosyası, sorunun oluştuğu veritabanıyla çalışacak şekilde tasarlanır. Böylece, sorunları otomatik olarak dinamik bir şekilde çözebilirsiniz ve sonra geri dönüp bana "Hey bir sorun vardı, ancak bu arada düzeltildi" diyen bir e-posta alabilirim. Senaryo çalıştırıldı ve DBA olarak bunu biliyorsun, ama aslında içeri girip müdahale etmek zorunda değilsin. Şimdi, proaktif olmakla ilgili aynı notta, tabii ki burada "Analiz" özelliği olan başka bir özelliğimiz daha var. Ve bunun yapacağı şey, SQL örneğine karşı düzenli bir kontrol yapmasıdır. Ve bazı durumlarda, aradığı şey açısından daha derin bir dalış yapacak. Varsayımsal indeks analizi gibi şeyler yapılacaktır. Bir dizin ekleyebilir miyim? Bir dizini kaldırabilir miyim? Ve tüm bu tür şeyler açıkça performansımla ilgili olacak, ama bir kez daha, hepsi proaktif olmakla ilgili. İşler bitmeden kararlar alabilmek ve daha iyi çalışmasını sağlamakla ilgilidir. Ve birçok durumda, gerçekten burada yapmaya çalıştığımız şey bu.

Sorguya Dönme Daha önce konuştuğumuzdan bekler; gördüğünüz gibi, burada büyük bir artış var. Daha önce biraz bekletme aktivitesine neden olan bir senaryo çalıştırdım ve daha önce de bahsettiğim gibi, bu bilgiyi inceleyebilmeniz için gerçekten benzersiz bir yolumuz var. Hangi uygulama olduğunu görmek istersem; NoSQL uygulamasından geldiğini görebiliyorum. Bağlı olduğu veritabanını, oturumu, kullanıcıyı görebilecektik ve eğer istersem bunu beklemelerim açısından da sıralayabilirim. Yani, o zaman penceresinde gerçekleşen tüm beklemelerden en çok hangilerinin gerçekleştiğini söyleyebilirim? Ve eğer en çok olay olduğunda, gerçekten güzel olan şey, o bekleme türünü inceleyebileceğim ve tüm komutları görebildiğimdir. Eğer buraya bakarsanız, bu beklemeyi gerçekleştiriyorlardı. Öncelikle, hangi uygulamanın olduğunu, bu beklemeyi meydana getirdiğini de görebiliyorum.

Böylece ağrılı bir başparmak gibi dışarı çıkıyor. Hemen gidip “Bu benim darboğuma neden olan uygulama. Şimdi çalıştırılan sorgu neydi? Hangi kullanıcı tarafından çalıştırıldı? Hangi veritabanına karşı çalıştırıldı?” Vb. Diyebilirim. Umarım bu mantıklıdır ve Ayrıca, veritabanlarınızla ilgili olduğu için ortamınızda gecikme olmadığından emin olmanıza yardımcı olur. Umarım bu yardımcı olur.Bu noktada devam edip geri vereceğim ve sanırım oradan devam edebiliriz.

Eric Kavanagh: Elbette. Yani, sanırım günün uzmanlarımıza atacağım. Mark, belki önce bir kaç soru sorup yorum yapmak istersin. Sonra Dez, içeri girebilirsin.

Mark Madsen: Evet, teşekkürler, bazılarını izlemekten gerçekten zevk aldım. Görmeye alışık olduğumdan çok daha akıllı bir izleme. Bunun arkasındaki verilerin yönetilmesini merak ediyorum; izleyebileceğiniz metriklerin yönetilmesi ve bildiğiniz gibi, özellikle taban çizgilerini kaydırmak gibi, evcil hayvan ağrılarımdan biri olan panolar ile ilgili şeyleri arayın. Bu verilerle nasıl başa çıkıyorsunuz ve bunun ikinci kısmı, bildiğiniz gibi, temel kayma gibi temel metriklerle - eşikleri de otomatik olarak kaydırma yeteneğiniz var mı? bir taban çizgisi değiştiğinde geri dönün ve eşikleri elle sıfırlayın?

Bullett Manale: Yapıyorsunuz ve bununla ilgili güzel olan şey buna karar verebilmeniz. İkisini de yapabilirsiniz. Bir eşik ayarlayabilir ve bunu statik bir ayar yapabilirim veya kutuyu işaretleyerek, "Bunu temel çizgilerim değiştikçe değişecek dinamik bir eşik yap" diyebilirim. Ve varsayılan bir pencere ayarlama yeteneğine ve aracına sahibim Ama eğer gerekirse, örneğin bakım penceremden saat 2: 00'den saat 05: 00'e kadar ayrı bir temel pencerem olabilir; çünkü vergilendireceğim CPU, sürücülerim ve diğer her şey çünkü tüm bakımımızı yaptığımız zaman, otomatik olarak, eğer bunu seçmiş olsaydım, eşiklerimi otomatik olarak bu metrikler için normal olanın dışında olacak şekilde ayarlayacaktır. Bunu yapmamı sağlayacaktı. Temelde, zaman pencerelerini ayarlama olan temel pencereleriniz olan araç içinde bir yeteneğiniz var ve her pencere, ayrı bir varlık olarak ele alınabiliyor. dinamik taban çizgisi ayarı yapılabilir ve taban çizginizin yo kadar penceresi ekleyebilirsiniz gerek, eğer bu mantıklı. Bir hafta sonu penceresi, çalışma saatlerinde bir hafta içi, gecenin ortasında gerçekleşen bir bakım penceresi vb. Olabilir.

Mark Madsen: Teşekkürler.

Bullett Manale: Sanırım sorunun ilk kısmına geri dönüyoruz, tüm bu bilgileri aldık ve topladık. Mimariden gerçekten bahsetmedim, ama bu verilerin saklanması üzerinde tam kontrole sahip olduğunuz bir arka uç depomuz var, ama aynı zamanda gecenin ortasında çalışan ve giden bir hizmetimiz var. tüm temel hesaplamaları yapar ve bu verileri alır, toplar ve anlamlandırır. Açıkçası, bununla birlikte, belirli metrikler için taban çizgilerinize karşı raporlamak için kullanabileceğimiz çok sayıda raporunuz var. Ayrıca, aynı sunucudaki temel çizgilerinizi, aynı metrik için farklı sürelerle karşılaştırabilirsiniz. Meydana gelen farklılıklar olup olmadığını veya deltanın ne olduğunu görebilirsiniz. Bu tür birçok seçenek de var.

Eric Kavanagh: Dez.

Dez Blanchfield: Sizin için kısa bir sorum var - bu aracın neler yapabileceğine dair geniş bir spektrum var. Şimdi gelişimin ilk aşamasında kullanımında bir artış görüyor musunuz, yoksa hala bir üretim ortamı aracı mıdır? Başka bir deyişle, geliştiriciler erişime geçiyor ve erken geliştirmeleriyle kullanıyor ve daha sonra entegrasyon aşamasını test ediyor mu? Yoksa hâlâ ağırlıklı olarak üretim ortamlarında mı kullanılıyor?

Bullett Manale: Bunu söyleyebilirim, çoğu zaman bunu üretim ortamlarında görüyoruz. Durumlara bağlıdır, ancak çoğunlukla öncelikle üretim söyleyebilirim ve biz söylerim - ve ayrıca, geliştirici ve test ortamları için farklı fiyatlandırmaya sahip olduğumuzu belirtmek doğru, bu yüzden biraz daha çekici. İnsanları bu ortamlar için kullandığını görüyoruz ama söyleyebilirim ki, size şu ya da bu şekilde bir cevap vermek zorunda kalsaydım, öncelikle insanların bu ürün için yatırım yaptığını gördüğümüz üretim ortamları olduğunu söyleyebilirim. .

Dez Blanchfield: Tabii, evet ve farklı fiyatlandırma noktalarına sahip olduğunuzu duymak ilginçti, çünkü açıkçası farklı iş yükleri var ve işlerin gerçek işin yapıldığı yerde daha ağır olacağı açık. Ancak, özellikle hükümette ve kesinlikle savunmada, kalkınmanın artık üretim ortamları ile aynı araç ve sistemlere yatırım yapacağı birçok organizasyon görüyorum, çünkü çok daha ön test yapıyorlar. Örneğin savunmada milyarlarca test, uygulama ve sistem ve araçlarda yüz milyarlarca test yapan ve entegrasyon testine girmeden önce bunları izleyen ekipler var, çünkü bir kodun ve veritabanının oluşturulduğundan emin olmak istiyorlar. altında oturuyor. Yüz bir milyon yinelemeye ya da bir şeye ulaşır, birisine ateş ederken dışarıda "patlama" olmaz.

Bullett Manale: Tabii.

Dez Blanchfield: Deneyimlerime göre eski okul veritabanı dünyasında, veri tabanı ortamının sadece veri ve bazılarınızın bildiği bir şey olduğunu düşünmek, çok nadir görülür ve çok nadiren konuşulur, bu yüzden şimdi araçların ve uygulamalar, özellikle analitik platformlarla geliştiriliyor, artık el cihazlarımızda ve cihazlarımızda. Müşterilerin, sadece tekniklerin aksine, veritabanı performansı ve veritabanı yönetimi konusundaki konuşmalarını daha günlük bir tartışmada getirdiğini görüyor musunuz? Ve daha önce bahsettiğinizi daha önce DBA'larla konuştuğunuzu biliyorum, ama şimdi genel kelime haznesinde olduğu bir eğilim var mı, insanları sadece ineklerin aksine bu konuları tartıştıkları yerde görüyor musunuz?

Bullett Manale: Söylemesi zor. Demek istediğim, çoğunlukla söylediğim gibi, satış süreci açısından zaten uğraştığımız insanlar, DBA'lar olan uygulayıcılarla. Sorunuz açısından, sadece "Genel olarak, BT organizasyonu içindeki insanlar, veritabanı konusunda daha bilinçli hale geliyorlar mı?" Diyorsunuz. Sanırım soru bu ve muhtemelen cevabın “evet” olduğunu söyleyebilirim. Muhtemelen nerede olduğumuza göre günlük olarak çok fazla görmüyorum, ama sanırım sorunuzu anlarsam cevabım bu olurdu, sanırım.

Dez Blanchfield: Evet, sorun değil. Muhtemelen yüklü bir soru, özür dilerim, çünkü belli ki sizin dünyanızdaki baskın çıkarlarınız şeylerin teknik tarafıdır. Günlük aktivitelerimde, organizasyonların bunu çok erken konuşmaya başladığını merak ediyorum. Yani, yeni girişimler, yeni projeler, yeni iş programları hakkında konuşurken, hemen gelen şeylerden biri, "Nasıl izliyoruz, nasıl izliyoruz, ortaya çıkan sorunlarla nasıl başa çıkılıyor, lansmanın aksine canlı yayına mı başladınız?

Bullett Manale: Bunu söyleyebilirim -

Dez Blanchfield: Üzgünüm, devam et.

Bullett Manale: Sanırım söylemem gereken bir eğilim gördüğümü söyleyecektim - bilirsiniz, geçmişte pek çok kez elde edersiniz, "Bir sorunumuz vardı ve şimdi bir araca ihtiyacımız var. " Ve bence bu sorun oluşmadan önce aletin yerinde olması konusunda biraz daha fazla kabul görüyoruz. Yani bunun kesinlikle daha normal hale geldiğini söyleyebilirim, bilirsiniz, “Hey, bir izleme aracına ihtiyacımız var, bir şeye ihtiyacımız var.” Ve insanlar kesinlikle bu ürünün değerini görüyor, çünkü daha önce söylediğin gibi, sadece DBA'lar ekleyerek ve Yeni örnekler ekleyerek, bunu yöneten bir şeye ihtiyacınız var, bunun yönetimine yardımcı olacak bir şeye ihtiyacınız var, ve bu yüzden bu ürünün etrafında da çok fazla kabul görüyoruz ya da var.

Dez Blanchfield: Hızlı soru. Bunun nerede yaşaması gerekiyor? Veri merkezindeki LAN'da arka yanıkta, veritabanı ortamlarına olabildiğince yakın oturmak zorunda mı yoksa bir yere, potansiyel olarak bulutta, bir çeşit üçüncü taraf bulutuyla bir yere yerleştirilmiş rahat mı? VPN tüneli veya çeşitli ortamlara uzaktan erişim? Ortamlar ve izleme söz konusu olduğunda bunun nerede oturması gerekir?

Bullett Manale: Mimari açıdan bir arka uç deposu var ve bu bir SQL Server veritabanı. Konsolumuz ya şişman bir müşteri ya da ince bir müşteri olabilir; ikinize de seçenek sunuyoruz. Ayrıca, özellikle mobil cihazlara yönelik ince bir istemcimiz de var. Ancak bunun gerçekte nerede oturabileceği açısından; bir ortamda oturabilir, gerçekten onunla ilgili daha karmaşık olan kısım, toplamamız gereken birçok bilgiden idari haklar, bazı durumlarda veya birçok durumda. Şimdi size bunu yapmıyoruz; isterseniz, veri toplayabilirsiniz ve sadece toplayamadığımız şeyler için, yönetici haklarımız olmadığı için, yaptığınız seçim buysa, bu bilgileri görmenize izin vermeyeceğiz.

Lezzete bağlı olarak, AWS hakkında konuşuyorsanız, bazı ortamlar gibi, diğerlerinden daha iyi çalışır, ancak gerçek ortamın kendisi kadar, tipik olarak verileri örneklere karşı toplamak için SA kimlik doğrulamasını kullanmak yeterlidir. Veya güvenilir olmayan bir alan adı ise, genellikle bunu yapmak istediğiniz zaman olur, ancak birden fazla alan adı; aralarında bir güven olduğu sürece bunlara karşı toplayabiliriz. Bir LAN'da mı yoksa WAN'da mı olduğu önemli değil, gerçek koleksiyonun kendisi topladığımız veri miktarı açısından oldukça ihmal edilebilir. Yeterli boyutta WAN bağlantımız varsa, sorun değil. Amerika Birleşik Devletleri'nin her yerinde SQL Server'ları olan şubeleri olan ortamlar gördüm. Ve bu farklı konumların her birinde bir sunucu ve merkezi olarak izliyorlar. Zor kısmı sadece bunu yapmak için iyi bir bağlantı var emin olmaktır. Umarım, bu sorunuzu cevaplar, her şey harita üzerinde.

Dez Blanchfield: Kesinlikle öyle. Teşekkür ederim. Yani, bu sabah katılımcılardan gelen iki hızlı soru; birincisi: etkisi nedir - çoğu zaman sistem izleme araçlarının sadece şeyleri izleyerek kendilerini yük ürettiğini görüyoruz, bu yüzden soru şuydu, şimdi ekranımdan ayrıldı, ama sadece yorumlamak için; izleyerek kendimize yük üretiyor muyuz? Aracın ölçülebilir bir etkisi var mı, sadece çevreyi izliyor mu yoksa ihmal edilebilir bir etkisi var mı?

Bullett Manale: Verileri geri almak için SQL Server örneğini sorgulaması gerektiğinden, her zaman biraz etki olacaktır. Söylediğin soru "İhmal edilebilir mi yoksa önemli mi?" Bir örneğe işaret ettiğiniz kutudan, ihmal edilebilir. Bunu bir süredir söylediğim gibi yapıyoruz. 20.000'den fazla müşterimiz var ve eğer önemli bir performans etkisine neden olursa, işimizde olmayacağımızı garanti edebilirim. Bununla birlikte, kullanıcının ne izlemek istediklerine karar vermesine de izin veriyoruz. Bence bu önemli bir nokta, her ortamın biraz farklı olması.

Bir örnek, sorgu izleme bileşeniyle yapabileceğimiz şeylerden biri, normalliğin sınırı olduğunu düşündüğünüz şeyin eşiğini ayarlayabilmemizdir. Bu nedenle, sorgunun yürütülmesi zamanına bağlı olabilir. CPU, G / Ç'ye dayanabilir, ancak örnek olarak, yürütme süremi sıfır milisaniyeye ayarladığımı varsayalım. Etkili bir şekilde aracı yapmamı söylediğim şey, son çekme aralığından bu yana yürütülen tüm sorguları toplamak ve tarihsel koleksiyonumun bir parçası haline getirmek.

Şimdi bunu yaptığımızda, son yoklamadan bu yana kutuda yürüttüğümüz her türlü sorguyu toplayacağız. Şimdi bu seçmeli ve kullanıcı bunu yapabilir. Hayır, ama bunu yapmanýzý istiyor muyuz? Ama bu bilgiyi toplamanýza izin veren bir örnek veri istemeniz durumunda size bunu yapma seçeneđini de veriyoruz. Genel olarak, … neyi rahat hissettiğinize göre ayarlamak ve tam olarak nasıl istediğinizi ayarlamak için bir araçtır.Ama isterseniz gerçekten açabilme ve düzenli olarak gerekli olmayabilecek birçok ek bilgi toplama yeteneğiniz vardır. mantıklıysa, toplamak.

Dez Blanchfield: Evet, kesinlikle. Biraz uzun sürdüğümüzü biliyorum, ama bitirmeden önce size atmak istediğim iki harika soru var. İkisi de doğrudan bana geliyor, ama bence cevap verirseniz en iyisi bu. Soru genel olarak, "Mevcut sistemlerin bilgisine kadar, aracın erişiminin kapsamı nedir?" O halde, bunu takabilir ve oradaki platformu otomatik olarak algılayabilir ve bu platform için neyin normal olduğunu hemen öğrenebilir miyiz? Mark'ın daha önce bahsettiği gibi almak? Biliyorsunuz, bilmiyorum, Microsoft Dynamics olabilir, platformların temel bilgilerinin bazıları, normal olan ve iş çevresinde kullanılan mevcut hazır araçların bazılarında?

Bullett Manale: Genel olarak konuşursak, SQL örneğinde veri toplamaya başladığımızda, eşiklerimiz ve nerede ayarlandıkları açısından başlamak için en iyi uygulamalarla çalışırız. Bununla birlikte, en iyi uygulamalar açısından kiminle konuşursanız olun, her ortamın farklı olduğunu da kabul ediyoruz. Başlangıçta ne yapacağız sadece verileri topluyoruz ve insanların yapmasını önerdiğimiz ürün, gerekirse 14 gün daha deneyebilirsiniz. Ancak yaklaşık iki gün sonra temel verilerin doldurulduğunu görmeye başlayacaksınız. Çalışmak için yeterli örnek bilgiye sahip olduktan sonra, size taban çizgisi, aralığın nerede olduğu ve bu tür şeyler bağlamında bağlam sağlamaya başlayacaktır. Daha sonra, isterseniz, eşiklerinizi toplanan bilgilerden otomatik olarak ayarlayabilirsiniz. Neyin normal olduğunu belirlemeye başlayabilmek için biraz ilk toplama ve yoklama gerekir, böylece eşiklerinizi değiştirmeye başlayabilirsiniz.

Ama benim de dikkat çekmeye değer olduğunu düşündüğüm şey, bu eşikleri değiştirdiğinizde, örneklerinizin grup bazında yapılabileceği. Bir örneğe özgü olabilir veya bunu tüm örneklerinize ve şablonlar gibi şeyler oluşturma yeteneğine karşı yapabilirsiniz, böylece "Bu bir üretim örneğidir, ancak bu istediğim şablon atamak. " Ve böylece yeni bir üretim örneği çevrimiçi olduğunda, bu eşikleri otomatik olarak uygularız, çünkü aynı donanıma sahiptir ve genellikle aynı iş yüklerine sahiptir, bu yüzden bunu da yapabiliriz. Umarım bu soru açısından yardımcı olur.

Dez Blanchfield: Kesinlikle öyle. Aslında, bana yeni gelen başka bir soruyu cevapladınız ve "Deneme sürümü indirildi mi?" Var, cevap verebilirim, biliyorum. Eminim ücretsiz bir indirme olduğunu onaylayacaksınız ve sanırım web sitesinden 14 gün geçtiğini söylediniz. İndirebilir ve onunla oynayabilirsiniz. Bununla hızlı bir şekilde sanırım, "Deneme sürümünü çalıştırmak için ne tür bir ortama ihtiyacım var? Dizüstü bilgisayarımda çalıştırabilir ve onunla oynayabilir miyim yoksa gerçekten bir sunucuya ihtiyacım var mı?"

Bullett Manale: İhtiyaç duyduğu en önemli şey, bir havuz, 2005 veya üstü bir SQL Server veritabanı. Bunun dışında, bazı minimum kaynak gereksinimleri, bir .NET gereksinimi vardır ve hepsi bu kadar. Yani, sadece ürünü kurmak ve bir veritabanı oluşturmak meselesi.

Dez Blanchfield: Mükemmel. Sana atacağım son bir soru, çünkü şimdi zamanımız doldu, ama çabucak, yaklaşık iki ya da üç kişi bana sordu, "Gerçekten kalkabilmek için bir DBA olmam gerekiyor mu Bu ve onunla bir oyun var mı? ”

Bullett Manale: Hayır. Bir DBA iseniz, aracın farklı kullanımlarına sahip olacağınızı söyleyebilirim. Demek istediğim, deneyimli bir DBA iseniz muhtemelen biraz daha fazla değer olacaktır. Yararlanabileceğiniz araç için çok daha fazla derinlik göreceksiniz. Ama aynı zamanda yeni bir DBA, hatta bir DBA olmayan bir kişi olarak, çok fazla tavsiyemiz var ve şu anda o sayfadayım. Bu öneriler düzenli olarak ortaya çıkacak ve öneriler hakkında gerçekten güzel olan şey, size önerilerin yapılma nedenlerini sağlamalarıdır. Ancak buna ek olarak, bu önerilerin de yapılma nedenleri hakkında daha ayrıntılı olarak açıklayan harici içeriğe bağlantıları olacak. Bu, harici Microsoft web sitelerine, bloglarına ve bunun gibi her türlü şeye bağlanır, bu harici.

Ama sorunuza cevap vermek için, bu, bilirsiniz, eğer kıdemli bir DBA iseniz, burada bir şeyler olacak, muhtemelen yararlanacaksınız, muhtemelen acemi bir DBA olarak olmayacaksınız. Ama aynı zamanda, aynı zamanda bir tür öğrenme aracıdır, çünkü bu önerileri inceledikçe, önerileri kullanarak bu şeylerden bazılarını kendi başınıza almaya başlayacaksınız.

Dez Blanchfield: Harika. Teşekkür ederim. Demo bölümünden gerçekten keyif aldım. Sunum harikaydı. Demo harikaydı. Hafızadan hızlı bir şekilde, web sitenizde insanların da göz atmasını tavsiye ettiğim bir kaynak merkezi var. Bazı gece detaylar almak için geçen geceyi hatırlıyorum. Sadece bloglarınızdan, verilerinizden ve sohbetlerinizden, bellekten, ürün belgelerinizin çoğuna çevrimiçi olarak sahip olduğunuz pek çok şey var, evet?

Bullett Manale: Evet, bu doğru ve referans verdiğinizin community.idera.com web sitesi olduğunu düşünüyorum. Ve sonra da bahsedeceğim bir şey daha önce "Çevreyi tanıyacak mı?" Yeni örnekler veya örnek ekleme açısından, örneklerin keşfini yapan başka bir araç var. Ve hepsi envanter ve envanterinizi yönetmekle ilgilidir. Örnekleri gerçekten keşfetme açısından sizi bu yönde göstereceğim. Ancak aslında performans ve izleme ile ilgili konuştuğumuz bu tür şeyler, Tanı Yöneticisi'nin devreye gireceği yer.

Dez Blanchfield: Harika. Bak, büyük kapsam. Sunumunuzdan gerçekten keyif aldım. Canlı demoyu sevdim ve bu sabah benden hepsi bu, bildiğim gibi muhtemelen 10 dakika içinde gittik. Eric, sana geri döneceğim.

Eric Kavanagh: Tamam. Demoyu çok sevdim. Demoyu yaptığınıza sevindim. Soru-Cevap bölümünden geçerken buna sert bir göz atmamız gerektiğine sevindim.

Bullett Manale: Harika.

Eric Kavanagh: Çünkü bu, insanlara neye baktığınız hakkında bir fikir veriyor ve bu bilgisayarlarla nasıl konuşacağınızı hala öğrendiğimizi düşünmek gerçekten de beni şaşırtıyor. Yani, bu teşhis seviyesi oldukça sofistike ve her geçen gün daha da iyiye gidiyor. Gerçekte olup bitenler hakkında çok daha fazla fikir ediniyoruz. Ama gerçekten bu şeylere bakan, okuyan, bilişsel yeteneği yaptığınız şeyin arkasına koyan bir kişiye ihtiyacınız var, değil mi?

Bullett Manale: Evet, yani birçok durumda - keşke bunun kutuda bir DBA olduğunu söyleyebilseydim, ama devam eden çok fazla şey var. Yani, rehberlik sağlıyoruz ve yardım ediyoruz, ancak günün sonunda insanların sunduğumuz veriler hakkında karar vermelerini gerektiriyor. Bunun yakında değişeceğini sanmıyorum.

Eric Kavanagh: Buradaki gerçek insanlar için iyi haber millet.

Bullett Manale: Doğru.

Eric Kavanagh: Bunu izleyen birisinin, bunu izleyen bir ekibin olmasını isteyeceksiniz ve Bullett'ten duyduğunuz gibi, bu önerilere bakarak neler olduğunu öğreneceksiniz. Ve o tarihten tahmin ediyorum ve bence buna dokundunuz, Bullett, ama çok hızlı bir şekilde, bu tarih önemli kalıpları tanımanıza ve bu nedenle onları gelecekte meydana geldiklerinde tanımlayabilmenize izin veriyor, değil mi?

Bullett Manale: Doğru. Yapabileceğimiz şeylerden biri, bir sorgunun zaman içindeki performansını izlemek. Ayrıca, taban çizgileri gibi diğer şeylere de bakabilir ve bunların değiştiğini görebiliriz ve bu olduğunda uyarı ve benzeri şeyler alabiliriz, bu yüzden kesinlikle bu yeteneğe sahipsiniz.

Eric Kavanagh: Kulağa hoş geliyor millet. Burada uzun sürmezdik, ama bu sorulara ulaşmak istedim. İlginiz ve zamanınız için çok teşekkür ederim. Tüm bu web yayınlarını arşivliyoruz. Techopedia.com'a veya InsideAnalysis.com'a çevrimiçi olarak atlayın, her iki yerden de bağlantılar göreceksiniz.

Ve bununla size veda ediyoruz. Tekrar teşekkürler millet, önümüzdeki hafta, Salı, Çarşamba, Perşembe gelecek üç web yayını daha yakalayacağız. Gelecek hafta sizinle konuşacağız millet. Kendine iyi bak. Güle güle.

Techopedia İçerik Ortağı

Techopedia Staff, Bloor Group'a bağlıdır ve sağdaki seçenekler kullanılarak iletişime geçilebilir. Sektör ortaklarıyla nasıl çalıştığımız hakkında bilgi için buraya tıklayın.

• Profil
• İnternet sitesi