Ekleyen Techopedia Staff, May 26, 2016
Paket Servisi: Host Eric Kavanagh, Hot Technologies'in son bölümünde Robin Bloor, Dez Blanchfield ve Bullett Manale ile veritabanı yönetimi ve örnek keşiflerini tartışıyor.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.
Eric Kavanagh: Tamam bayanlar ve baylar. Tekrar hoş geldiniz. Benim adım Eric Kavanagh. Sıcak. Burada işler ısınıyor. Neler olduğunu bilmiyorum. Ah, doğru, Hot Technologies zamanı. Evet, gerçekten benim adım Eric Kavanagh. Beni Twitter'da @eric_kavanagh sitesinde bulabilirsiniz. Bu, pazarda neyin sıcak olduğu hakkında konuşmak için tasarlanan şov. Bugün başlık, “Krallık Anahtarları: SQL Server'ı Dinamik Keşifle Yönetme.” İyi şeyler. Gerçekten seninki var. Tamam, bu resim birkaç yıl önceydi. Yalan söylemeyeceğim, şimdi biraz daha yaşlı görünüyorum, ama sorun değil.
Yani, teknolojilerin ve SQL Server'ın gerçekten, gerçekten, gerçekten, gerçekten nasıl sıcak olduğunu konuşuyoruz. Bugün bir sürü içeriğimiz var, bu yüzden hemen teslim edeceğim. Bekle, işte başlıyoruz. İşte konuşmacılar. Ve Robin Bloor önce gidiyor.
Robin Bloor: Evet, gerçekten. Sunum, veritabanı yönetimine derinlemesine gidecek, bu yüzden insanları yönetimine sokabileceğimi düşündüm, ya da bilirsiniz, veritabanı labirentinde insanları ruhuna sokmak için. Eskiden DBA'ydım, sanırım yaklaşık 20 yıl önce bir veritabanı danışmanı olduğumu söyleyebilirdiniz ve veritabanları hakkında beni şaşırtan şey çok fazla değişmedi. Hız, veri hacimleri ve bunun gibi şeyler açısından birçok şey değişti, ancak bunların çoğu gerçekte olanlara çok benziyor.
Bir veritabanı, bence, belirli iş yükleri için optimize edilebilen ve veri yönetimi yetenekleri sağlayabilen organize bir genişletilebilir veri koleksiyonudur. Öncelikle ortaya çıktı çünkü dosyalardaki verileri yönetmek istiyorsanız çok zor bir işti. Yapmanız gereken hemen hemen her şeyi yapacak bir yazılım parçasını bir araya getirme fikri, 1970'lerde IBM ana bilgisayarlarına rasgele eriştiğimiz anda neredeyse anında başladı.
İlişkisel veritabanı 70'lerde icat edildi ve 80'lerde prototip olarak ortaya çıktı ve 90'lı yılların başından itibaren piyasada çekişini sürdürdü. Ve ilişkisel veritabanları hala popülerlik bakımından hâkimdir. Basını okursanız, SQL veritabanları hakkında çok fazla şey duyacaksınız ve son zamanlarda grafik veritabanları hakkında çok fazla gürültü var. İsterseniz bunlar ilginç, ama aslında hala en son satış rakamlarında, ilişkisel veritabanları pazarın% 95'ine sahip. Bugün derinlemesine ele alacağımız Microsoft SQL Server, Oracle için en popüler ikinci.
İlişkisel veritabanları ile ilgili olduklarından motorları açısından alışılmadık hale getiren şey, hem OLTP hem de sorgu iş yükleri üzerinde çalışabilmeleridir. Bunu yapacaksanız onları farklı şekilde ayarlamanız gerekir, ancak aslında her iki iş yükünü de yapabilirler. Bunlardan biri kısa rasgele işlemler, diğeri ise çok sayıda veriyi kapsayan uzun sorgulardır. Alternatif, NoSQL veritabanı ve grafik veritabanı temel olarak analitik amaçlıdır ve son zamanlarda oldukça yükselmiştir. İlk önce NoSQL geldi ve grafik son zamanlarda biraz çekiş yapmaya başladı. NoSQL işlem faaliyetleri için kullanılabilir, ancak grafikler işlem etkinlikleri için neredeyse hiç kullanılmaz. Bunun nedeni, yazılım envanterine bakarsanız, çoğu şirketin en az üç tane olduğunu, aslında rakamın 3.5, farklı veritabanları markaları olduğunu söyleyen en az on yaşında olduğunu düşündüğüm bir istatistikle karşılaştım.
Ancak gerçek şu ki, çoğu şirket belirli bir veritabanında standartlaşıyor. Ve çoğu şirket SQL Server ve Oracle'da standart veritabanları için en popüler ikisi olarak standartlaştırılmıştır. Ve alternatifleri sadece istisnai durumlarda kullanıyorlar, örneğin farklı bir veritabanına ihtiyaç duyan bir yazılım paketi alıyorlar ya da ortaya çıkan bazı büyük veri analizi hedeflerinin peşinden gidiyorlar.
İsterseniz, Hadoop'un müdahalesine de sahibiz. Hadoop şu ya da bu şekilde bir dosya sisteminden daha fazlası haline geldi, ancak henüz bir veritabanı değil. Ancak üstte oturan SQL var. Ancak, kanıtlar, dünyanın kalplerini ve zihinlerini kazanan ilişkisel veritabanlarının gerçekten yerini almamasına veya yerini almaya yakın bir yere sahip olduğudur. Bunun nedeni, ilişkisel veri tabanlarının yirmi yıl, aslında yirmi yıldan uzun sürdüğü kadar iyi olmalarıdır. Ve sadece çok kısa bir sürede gerçekten performans gösteren bir sorgu motoru veya SQL motoru oluşturmazsınız. Sadece olmadı.
Ve böylece bu slaydın sonucu, veritabanlarının stratejik olduğu ve geliştikleri, daha iyi hale geldikleri. Oracle ve Microsoft SQL Server için de durum böyle. Muhtemelen, birçoğunuz veritabanlarının ilk ortaya çıktığı günleri hatırlıyorsunuz ama ben yaptım, o zaman ben bir çocuktum. Orijinal fikir, tek bir veritabanı olacağı ve bu kesinlikle hiçbir zaman kök salmayan kavramsal bir fikirdi. IBM'in AS / 400 ile birlikte veritabanı tabanlı bir dosya sistemine sahip olma girişimi vardı, ama bu da iktidara gelmedi. Veritabanlarının doğal olarak parçalanmış olduğu gerçeği kaldı. Aslında doğal olarak birden çok örneğiniz var. Ölçeklenebilirlik sorunları var. Veritabanı sadece belirli bir boyuta ölçeklendirilmiştir, itiraf ki bu boyut yıllar içinde artmıştır, ancak sınırları vardır.
Ve iş yükü sorunları vardı, başlıca iş yükü sorunu OLTP iş yükleri ve büyük sorgu iş yüklerinin birbirleriyle uyumlu olmamasıdır. Ve bunu yapacak bir motor inşa etmek imkansızdı. Karşılaştığımız şey, bu biraz ilginç, son zamanlarda binden fazla farklı Oracle örneği olan bir siteyle karşılaştım. Kaç tane DBA'ya sahip olduklarını tam olarak hatırlayamıyorum, ancak onlarla gerçekten bu veritabanlarından kaçının bir DBA tarafından izlendiğiyle ilgili konuştuysanız, on gibi bir şeydi. Temel olarak veritabanını bir dolap olarak kullanıyorlardı ve veriyi veriye atıyorlardı, çünkü en azından bir şemanız vardı ve bir dosya sisteminin olacağından daha düzenliydi, ancak kimse varsayılan bir yapılandırma vermek ve ayarlamaktan başka bir şey yapmıyordu. gevşek.
Bunun iyi bir fikir olup olmadığından emin değilim. Dürüst olmak gerekirse, bana garip geliyor, çünkü bence, veritabanları ile çalıştığımda, veritabanlarına devam gerekiyordu ve bir şekilde başka neler olduğunu tam olarak bilmeniz gerekiyordu. Ve çok sayıda sistem bağımlılığı, belirli hizmet düzeylerinin kesinlikle karşılanması gerektiği veya sorun yaşadığınız anlamına gelir.
Son zamanlarda konuşma vardı, kendinden ayarlı olduğunu iddia eden çeşitli veritabanlarına rastladım. Sorgu trafiği için ayarlanmış sütun depoları, büyük ölçüde kendi kendini ayarlarlar, çünkü dizinler açısından almanız gereken iki seçenek vardır. Ancak bu alanın yanı sıra veritabanlarının ayarlanması gerekir. Ve ayarlanmaları gerekiyor, belirli ilişkisel veritabanları, çünkü esasen çok sayıda işlem birleşmeyi içeriyor. Birleşimler pahalı faaliyetlerdir. Doğru dizinleri doğru yere koymazsanız, birleştirmeler gerekmediklerinde aşırı zaman alır.
Şu anda kendi kendini ayarlayan veritabanları, yalnızca iş yüklerinin iyi bilindiği bu alanlarda mevcuttur. Deneyimlerime göre, çoğu şirket çok az sayıda DBA kullanıyor ve bunun nedeni pahalı olmaları. Bu nedenle, DBA'nın yaptıklarını değiştirebiliyorsanız daha iyidir. Anladığım kadarıyla bu bir DBA'nın faaliyetleri. Veritabanlarının kurulumunu, yapılandırılmasını ve yükseltilmesini yaparlar. Bu arada yükseltme mutlaka önemsiz bir etkinlik değildir. Bir veritabanını yükseltmenizin nedeni, yani, her zaman birlikte çalıştığım kural, çalışıyorsa ona dokunmayın ve bir veritabanını belirli bir yeni sürüme yükseltirseniz, bunu test modunda yaparsınız önce ve sonra her şeyi yükseltirsiniz. Hala her zaman aynı sürümle uğraşıyorsunuz. Ama aslında karşılaştığım birçok site, bu böyle değil. Diyelim ki oldukça fazla bir entropi var. Lisans yönetimi, sahip olduğunuz lisansa bağlı olarak bir sorundur. ETL ve veri çoğaltma.
Veritabanındaki hilelerden biri, bölünmesi gereken bir sorgu iş yükünüz varsa, iki örnek oluşturabilir ve çoğaltabilirsiniz ve bu genellikle insanların çoğaltmayı gerekirse bir sıcak yedekleme olarak kullandıkları yerlerde yapılır. Daha sonra depolama ve kapasite planlaması, elbette DBA'nın faaliyetinin bir parçası, çünkü elbette veriler büyüyor ve bunu izlemeniz gerekiyor. Ve sonra çeşitli donanım yükseltmeleri veya donanım büyütmeleri planlamanız gerekir. Çoğu DBA için acı verici bir faaliyet olan sorun giderme vardır. Bir şeylerin yanlış gittiği ve yedeklemenin tam olarak mükemmel bir şekilde çalışmadığı ve ardından kollarını toplayıp aşağı inip günlük dosyalarından bir şeyler kurtarmaya çalışmaları gerekir. Bu düşündüğümden çok daha sık oluyor, bunu hatırlıyorum ama en az on yıldır oyun dışında kaldım, ama bunun olmasını beklediğinizden daha sık hatırlıyorum. Performans izleme ve ayarlama, bir DBA işinin atan kalbidir. Ancak erişim yönetimi, yedekleme ve kurtarma, canlı bir sistemin makul ölçüde paralel olacağı yazılım test sistemleri oluşturma konusunda da güvenlik vardır. Ve tüm veri yaşam döngüsü şeyler. Benim görüşüme göre, DBA'nın yapmaları istenebilecek herhangi bir şey dışında iş listesi. Operasyonel dinamik. Sonuç olarak veri bütünlüğü ve hizmet seviyesi yönetimi DBA'nın başlıca sorumluluğundadır. Ve normalde kritiktirler. Ve tüm söylemek istediğim bu. Dez'e teslim edeceğim.
Dez Blanchfield: Çok teşekkür ederim. Bizi bugün tüm konunun neden olduğu ve her zamankinden daha kritik olduğu konusunda biraz eğlenceli, anekdotsal bir yolculuğa çıkaracağım. Çok uzun zaman önce, A + Addition adlı bir şeyi çalıştıran bir Fujitsu anabilgisayar platformundan lisans kaydı ve araç kaydı için kullanılan bir devlet yönetimi platformunu ve bu konuyla ilgili bir dizi şeyi taşıdığımız bir projeye katıldım. bir Solaris işletim sistemi veya başka bir deyişle Unix, Oracle'ı çalıştırıyor ve çok iyi bir iş çıkarıyor. Ve görüş şu ki, bu şey yaşlanıyor ve başka bir şeye taşınmanın zamanı gelmişti. Biz ana bilgisayarda Unix çalışan çok eğlenceli vardı ve çok istikrarlı ve çok güvenli ve garip SDL platformu ve sadece kesinlikle yıldırım hızlı oldu. Ancak bilgelik, ana bilgisayardan inip taşınmanın zamanı gelmişti.
Altındaki veritabanları için tüm sistemlerin ve iş mantığının ve SQL ortamının haritalandırılması ve bunun için yeni bir ev nasıl mimar edip mühendislik yapacağımıza bakmanın bu önemli zorluğu. Ve bunu şu anda birkaç yaşında olan şeylerden birine götürdük, ancak Sun raf sistemi Starfire sunucularının üst ucundan biri. Ve bunlar muhtemelen gezegendeki satın alabileceğiniz en büyük kalaydan bazıları ve büyük bir kutuda ve simetrik çok işlemcili bir sunucuda yaşıyorlar. Dünyamızda orta sınıf bir sistemdi. Unix'i çalıştırdı ve Oracle'ı doğal olarak çalıştırdı ve görüş, “Ne yanlış gidebilir?” İdi.
Örneğin, o zamanlar ve uzun zaman önce konuşmuyoruz, ana bilgisayar platformunda neler olduğunu keşfetmek ve karşılaşmak için çok manuel bir süreçten geçmek zorunda kaldık. Özellikle gerçek veritabanı ortamı ve SQL mantığı. Dolayısıyla görüş oldukça basit bir Oracle-Oracle hamlesi, veritabanından veritabanına hamle olacaktı; tüm iş mantığı karşımıza çıkacaktı, iş mantığının çoğu gömülü sorgular ve tetikleyicilerle yazılmıştı ve ne kadar zor olabilirdi? Ancak aylarca sürmesi gereken bir şey, bir yıl sürmedi. Ana çerçeve ortamındaki Unix'in her parçasını fiziksel ve manuel olarak incelemek için, tüm veritabanlarının nerede olduğunu ve kaç örneğin çalıştığını ve bu örneklerde ne çalıştığını ve önemsiz olmayan bir egzersiz olduğunu keşfettik ve bitirdik her şeyi yakaladığımızdan emin olmak için üç kez. Çünkü ihtiyaç duyduğumuz kadar derin kazdığımızı her düşündüğümüzde, yüzeyin altında daha fazlası vardı.
Karşılaştığımız diğer zorluk, hangi örneklerin ve hangi durumda çalıştığıydı. Bu bir geliştirme ortamı mı? Test ortamı mı? Entegrasyon sürecinin bir parçası mı? Sistem entegrasyonu mu? Kullanıcı kabul testi UAT mı? Üretim mi? Bir DR ortamı mı? Çünkü ana kareler ile ilgili en güzel şey, şu anda hepimizin aldığı bu küçük sanal ortamları inşa edebilir ve bir şeyler hareket ettirebilirsiniz. Ve bu kişi üretim seviyesinde geliştirme ve test yapıyor mu, yoksa üretim üretimi yapıyor mu? Bu konuda gerçek kullanıcılar var mı? Bu şeyin sürücü ehliyeti ve araba kaydı ve insanların yaşamları için gerçekten önemli olan şeyleri gerçek zamanlı olarak yaptıklarını hatırlamak.
Ve bu şey için yedek çalıştırmak çok zaman aldı, bu yüzden şeyi çevrimdışına almak ve ne olduğunu görmek için gerçekten bir bakım penceremiz yoktu. Yeniden yönlendirme diye bir şey yoktu. Ayrıca sadece hangi örneklerin çalıştığını ve nerede ve kimin için çalıştığını bulmakla kalmayıp aynı zamanda hangi örneklerin hangi sürümlerinin çalıştığını bulmak zorunda kaldık. İşte bu noktada komploumu neredeyse kaybettim. Üretim ortamının çeşitli test seviyelerinden geçen iki veya üç versiyonuna sahip olduğumuzu fark etmeye başladığımda, bunun için çok az araç ve sistematik yaklaşım vardı. Kelimenin tam anlamıyla kodu ve çalışan örneği incelemek zorunda kaldık ve bazı durumlarda bir süreliğine çevrimdışı bir şey alma riskini aldık. Bütün bu şeyin alt kısmına geldik, haritaya koyduk ve dediğim gibi çok manuel bir süreçti. Ve sonunda tüm ETL vardiyasını yaptık, bir yerden bir yere döküp başka bir yere taşıdık ve işe yaradı. Ve biz gibiydik, tamam işlevsel, bundan çok memnunuz.
Ama sonra çok ciddi katı tuğla duvarlarla karşılaştık. Özellikle performans sorunları bulduk. Ve günün mantıklı düşüncesi, daha büyük, daha iyi, daha hızlı, daha sert bir donanıma gitti, veritabanı düzeyinde uygulamada kötü performans göstermesinin bir nedeni yok, bu yüzden başka bir yere bakmaya başlayalım. Böylece ağı tamamen iki kez yeniden tasarladık. Her yönlendirici, her anahtar, her kablo, bazı durumlarda Ethernet'ten fibere gittik, yazılımı yükselttik, yamanız, görünümü elde edersiniz. Aslında, performans sorunları olduğunu düşünerek ağı iki kez yeniden kurduk. Ve öyle görünüyordu ve öyle hissediyordu. Farklı güvenlik sistemlerinden, farklı güvenlik duvarlarından geçtik. İşletim sistemini yamaladık. İşleri bir hesaplama bıçağından diğerine taşıdık. Bunun alt yapısına bakarak önemli bir zaman geçirdik.
Ve sonra sunucuların bağlantısını kestiğimizde ve üzerinde ağın iyi çalıştığı başka uygulamalar çalıştırdığımızı fark ettik. Böylece işletim sistemini birbirinden ayırmaya başladık. Aynı sorun. Ama ilginç, ağ seviyesi ve işletim sistemi seviyesi, araçlar oradaydı, aslında bu parçaların her birinin çalıştığını test etmek ve test etmek ve kanıtlamak bizim için nispeten basitti. Ancak o zaman bile, SPARC donanım platformundaki orta sınıftaki Solaris'te, araçlar veritabanı ortamını teşhis etmeye başlamamız için orada değildi. Bilirsiniz, tüm örnekleri bir araya getirip getirmeyeceğimizi haritalandırarak. Bu nedenle, aslında kendi araçlarımızı oluşturup bazılarını yazıp oturmak zorunda kaldık ve ister yerel komut dosyası dillerinde veritabanı araçlarının içinde olsun, ister bir dizi kabuk komut dosyası veya bazı durumlarda bir grup C programı olsun.
Sonunda SQL katmanının altındaki mantığın, gerçek veritabanı motorlarının kendilerinin olduğu, bazı şeylerin, Oracle'ın ana bilgisayar sürümünde çalışan bir şey için belirli bir yol oluşturulduğunda, SPARC üzerindeki Solaris'e taşındığı bazı ilginç konularla ilgili araştırmalar yaptık. Oracle sürümü aynı performansı hemen aktarmadı. Yani bu bizim için ilk etapta oldukça acı verici bir yolculuktu, sadece onu yapıyor ve hepsini buluyorduk, ama şimdi yeni üretim sisteminde teşhis etmek zorunda kaldık ve yine bu şey yaklaşık bir yıl boyunca bir aylık göçü patlattı. Ve basitçe, etrafta araçlara sahip olmadığımız gerçeğine geldi. Meta verileri eşlemeye çalışmak gibi şeyler yapmak için etrafta dolaşmak.
Bir noktada neredeyse bir Ouija tahtasına ihtiyacımız olduğuna karar verdik, çünkü bu sadece rastgele işaret edip kurcalamak için daha kolay olacaktı. Eski sistemlere kimin eriştiğini ve neden bu erişime sahip olduklarını bulmak gibi basit şeyler. Ve yenisine erişmeye ve onaylamaya kimin ihtiyaç duyduğunu, birisinin oturumu kapatıp onaylamasını ve eşlemesini kim sağladı. Veritabanının boyutu kadar basit bir şey bile iki platformda tutarlı değildi. Bunu yapmak ve Sistem A'ya karşı Sistem A'da ham megabayt veya terabaytta veritabanının ne kadar büyük olduğu ve performans ve performans ortamı hakkında daha fazla ayrıntıya dalma arasında bir karşılaştırma yapmak zorunda kaldık. Yine, yeni araçlar inşa etmek zorunda kaldı. Bizim için herhangi bir hazır değildi.
Ve tüm bu mesajı buradan çıkarırsınız, çalıştığımız şeyi elde etmenin sonuna geldiğimizde ve kararlı hale getirdiğimizde, her bir parçası çok manuel bir süreçti, bir şeyi otomatikleştirebilmemizin tek yolu, yeni araç veya yeni komut dosyası. Ve bugün mevcut araçlarımız olsaydı, hayat çok daha kolay ve çok daha iyi olurdu. Ve bu projede milyonlar biriktirirdik. Ancak bugün hakkında konuşmak üzere olduğumuz şeyin araçların şu anda mevcut olması ve hayatı çok daha kolay hale getirdikleri gerçeği olduğunu düşünüyorum. Tuzakların çoğu hala var. Orada olan ve hangi örneklerin ne çalıştırdığı veritabanlarının keşfi. Hangi durumdalar. Kaç kişi kaçıyor? Neden koşuyorlar. İyi çalışıyorlar mı. Yedekleniyorlar mı?
Bunların hepsi, şimdi doğru araçlarla birçok yönden alabileceğimiz şeyler. Ama dediğim gibi bu özel fıkrada bir dönem vardı, bunun birçoğumuzun çok fazla saç kaybettiği bir şeydi, muhtemelen hayatımızdan on beş yıl çıkardık ve araçların şu anda olmadığı gerçeğini yakalıyorduk . Ve bugün konuğumuz Bullett'den çok daha fazlasını duymayı dört gözle bekliyorum. Böylece, Bullett, size geçeceğim ve bu sorunu nasıl çözdüğünüzü duymayı dört gözle bekliyorum.
Bullett Manale: Tamam. Harika görünüyor. Eric, buradaki slaytları ele alalım ve ürüne girmeden önce Idera, şirket hakkında biraz konuşalım. Tıpkı bir FYI gibi, elimizde mevcut olan farklı ürünlerden oluşan bir portföy.
Eric Kavanagh: Sesiniz biraz sıcak, bu yüzden bir kulaklık kullanıyorsanız bunu biraz yukarı çekin.
Bullett Manale: Sorun değil. Bu daha iyi mi?
Eric Kavanagh: Bu çok daha iyi. Götürün.
Bullett Manale: Tamam. Bugün, tartıştığımız bu konuların birçoğuna açıkça hizalanan Envanter Yöneticisi'ne odaklanacağız. Size sadece bu ürünün nerede olduğunu nasıl anladığınıza dair biraz bilgi vermek istiyorum. Ürün grubumuzla günlük olarak bakmaya başladık, Tanı Yöneticisi adlı bir performans izleme aracımız var. Bir Uyum Yöneticisi aracımız var. Bu nedenle, SQL Server çevresinde birçok farklı araç var ve kaçınılmaz olarak her zaman soruyu lisanslama amaçları için soruyoruz, "Şu anda kuruluşunuzda yönettiğiniz örnek sayısı nedir?" İlginç olan şu ki, bu konuda hiçbir zaman kesin bir cevap alamadık. Kiminle konuştuğun önemli değildi. Her zaman "Bu sayının etrafında olduğunu sanıyoruz." Bu tür şeyler her zaman ortaya çıktı ve sonra yönettiğimiz durumlar açısından lisanslamak istediklerinin tam olarak ne olduğunu anlama sürecinden geçmeliyiz.
Açıkçası çok hızlı bir şekilde DBA'ların çoğunda bununla ilişkili bir acı olduğunu gördük. Açıkçası bir DBA olarak sorumlu oldukları şeylerden biri bunu bilmektir, çünkü yapmaları gereken şeylerden biri Microsoft ve SQL Server ile olan lisans anlaşmaları hakkında endişelenmektir. Açıkçası, sorumlu oldukları başka birçok farklı alana sahipler, ancak bu, genel sorumluluklarınızın ne olduğu bir DBA olarak büyük bir bilet öğesi olan alanlardan biridir. Sonuç olarak, DBA'nın bu sayıyı gerçekten anlayabilmesini kolaylaştıran bir araca ihtiyacımız var. Çünkü bunu çağırmak istiyorsanız SQL yayılımınız var ve bunun birkaç farklı nedeni var. Yazılımı kimin yüklediği ve bu tür şeyler hakkında o kadar fazla kontrol yoktur.
Ve olabilecek en kötü şey, birinin ellerini SQL Server'ın bir kopyasına alması, kurması, şirketteki diğer kuruluşlara veya departmanlara herhangi bir bilgi olmadan onunla çalışmaya başlaması ve sonra bildiğiniz bir sonraki şey, belki de verilerin yedeklenmemesi ve olabilecek bu tür şeyler. Şimdi başka bir sorununuz olduğunda, kritik verileri gerçekten kaybedeceğiniz durumlarınız olduğu için, örneğin ilk etapta var olduğunu bile bilmiyorsunuz.
Yapmamız gereken şeylerden biri, keşif parçasını bulalım diyelim. Ve bunun üzerine, topladığımız bilgileri, işin ne yaptığına bağlı olarak mantıklı bir şekilde organize edebilir ve yönetebiliriz. Ve daha sonra açık bir şekilde bu bilgiler hakkında kararlar alabilecek ve bu tür şeyler yapabilecektir. Bu, aracın nereden başladığı ve nereden geldiği. DBA'larla düzenli olarak konuştuğumuzda, gerçekten sahip olduğumuz şeyin, kaç tane örneğe sahip olduklarını bilmeme sorunu olduğunu söyleyebilirim.
Ve komik çünkü terim, ölçemediğiniz şeyi yönetemezsiniz, her zaman sahip olduğumuz performans araçlarını bulduk, SQL Diagnostic Manager gibi, ama bunu bilmiyorsanız gerçekten hiçbir şeyi yönetemezsiniz. "Onun" bile ilk etapta. Bu da bu aracın büyük bir parçası, sadece orada olduğunu bilme yeteneğine sahip.
Şimdi bu notta, SQL Server ile daha büyük kuruluşlardan veya kurumsal mağazalardan bazılarıyla konuştuğumuzda, konuştuğumuz birçok adamla bulduğumuz ilginç şey, yıl boyunca aslında bir zaman ayarladıklarıydı. aslında bu sayının neye benzediğini belirlemeye çalışmak için fiziksel olarak bir yerden başka bir yere yürüdüler. Bir DBA olarak, bazı durumlarda fiziksel olarak bir makineden diğerine yürümek için oldukça iyi bir para ödediğinizi hayal edebilirsiniz, bu şaşırtıcı bir şekilde adlandırmayacağım bazı oldukça büyük şirketlerden duyduğumuz şeydi. Ancak, lisans sayılarının doğru olup olmadığını öğrenmek için yılın iki haftasının bu tür alıştırmalar yaparak harcanabileceği ilginç bir nokta.
Bu, bu araç ve nasıl yardımcı olduğu ile ilgilidir, ancak ele aldığımız yol, SQL Server'ın bir dizi özelliğine dayanan keşif yapabilmekti. Ve ilk soru şu, neye işaret ediyorsun ya da önce neye bakmaya çalışıyorsun? Bunu yapmamız, IP aralığına göre yapalım diyelim ya da etki alanının üyesi olan bilgisayarlar açısından etki alanının kendisinin üyeliğiyle yapabiliriz. Bu kısmı bu şekilde ele aldık, sadece bunun keşif açısından odaklanmak istediğimiz alan olduğunu söyleyebilmek için.
Ve sonra bunun diğer kısmı bu özelliklere, bağlantı noktalarına ve diğer şeylere, WMI kayıt defteri anahtarlarına ve bu tür şeylere dayanıyor, SQL'in o örnekte veya belirli bir ortamda muhtemelen çalıştığını ve kurulduğunu belirleyebiliriz. Spor ayakkabı yönteminden veya spor ayakkabı ifade yönteminden çok daha iyi bir yöntem olduğu açıktır. Şimdi harika olan şey, örnek hakkında topladığımız tüm bilgilerin bir depoda tutulması ve çevre değiştikçe değişebilmesidir. Bu sadece “Hey, bir örnek var, işte bulduğumuz bir liste” değil, aynı zamanda DBA ya da örnekleri yöneten, envanterin bir kısmını yapmak isteyip istemediklerini belirleyebilen kişi ve ne zaman bu örneği devre dışı bırakabilmek envanterin bir parçası değildir. Ve böylece SQL Server örneğinin tüm sürecinin araç içinde gerçekten kolayca anlaşılabilmesi için kullanım ömürleri vardır.
Örnekleri keşfettikten sonra bundan sonra ne yapacağız? Başka bir şey örnek hakkında birçok bilgi, ben manuel olarak almak ve bir elektronik tablo veya bu tür şeyler koymak gitmek istemiyorum. Ve bu, DBA'larla envanter süreci ve lisanslama hakkında konuşurken ilginç bir şey, kaç tane DBA ile konuştuğum, onlara “Stoklarınızı nasıl koruyorsunuz?” Diye sorduğunuzda şaşıracaksınız. gerçekten ironik olan DBA'larla konuşuyoruz, bunu tutuyorlar ve her şeyin statik bir elektronik tablosunda izliyorlar. Dediğim gibi, bunu bir dakika düşündüğünüzde çok ironik. Ancak bu pek çok durumda idi ve bunu nasıl yönettikleri hala birçok organizasyon için geçerli. Bunu nasıl tutuyorlar. Kayan bir Excel elektronik tablosunun ana kopyasıdır ve düzenli olarak güncellenmesi gerekir.
Bunlar zorlayıcı şeylerdi ve bu nedenle bu örneği kaydedip envanterin bir parçası haline getirerek bunu yapabilir ve bilgileri alabilirsiniz. Envanterin, sürümün, sürümün, onunla yapabileceğiniz diğer şeylerin bir parçası olup olmayacağını otomatikleştirebilirsiniz, belki de bu listeyi veya Excel e-tablonuzu manuel olarak ekleyebilirsiniz. Bunu SQL Inventory Manager adlı araca aktarabilirsiniz. Zaten kendinizden emin olduğunuzu düşündüğünüz bir başlangıç noktalarınız varsa, bu örnekleri içeri aktarabilir ve ardından ürün içinde yönetilen envanterinizin bir kısmını yapabilirsiniz. Bir kez örneğe sahip olduktan ve orada olduğunu öğrendikten sonra, o zaman olur, tamam, o örneğin orada olduğunu bilerek, dışarı çıkıp bu bilgileri toplayarak kaldırabileceğimiz çok fazla bilgiye sahibiz.
Ve sadece lisanslama amaçlarından daha fazlası için birçok bilgiye ihtiyaç duyulacaktır. Birçoğu, sadece bir şeylerin nerede olduğunu bilmek, elde edildikten sonra bu bilgileri arayabilmek için kullanılabilir. Ama en önemli şey sunucu, donanımın kendisidir. Ne tür bir makine olduğunu anlamak, model veya üretici, bellek, bellek miktarı, fiziksel veya sanal bir makine olup olmadığını ve özellikle fiziksel soket veya çekirdek ve CPU sayısını ve bu tür şeyleri anlayabilmek.
Çekirdek sayısı açısından, özellikle SQL Server ile, lisanslamalarını nasıl yaptıklarını bilmek, şimdi SQL'in yeni sürümlerinde çekirdek başına hesaplamalar, bunun gerçekten önemli bir parçası haline geliyor ve sahip olduğunuz hiçbir şey değil dışarı çıkmak ve aslında kazmak için. Örnek belirlendikten sonra, bu bilgileri sağlayabilir ve çıkarabilir ve onu görüntülemenize ve anlamanıza izin veririz ve açıkça bundan yararlanabiliriz.
Bir sonraki katman, standart veya kurumsal ya da bu konu için ekspres olsun ya da SQL Server'ın ücretsiz sürümü olsun, SQL Server örneğinden çok farklı olduğu açıktır. Bu örneğin hangi uygulamalara bağlı olduğunu da anlayabilir ve bu otomatik olarak yapılabilir. Yapılandırma ayarlarını ve bu tür şeyleri ve SQL Server örneğiyle ilgili diğer bilgileri anlayabilme.
Daha sonra gerçek veritabanına inersiniz ve yapılandırma ayarlarını, bu verilere bağlı alan miktarını, bulunduğu yeri görürsünüz, tüm bu şeyler otomatik olarak doldurulur ve böylece büyük bir zaman tasarrufu sağlar. Ve bir kez daha, dinamik olarak dışarı çıktığı ve günlük olarak yeni örnekleri belirlediği için, envanteriniz açısından sahip olduğunuz canlı bir şey. Bu ürünün amacı bu şekilde yapmak, dinamik olarak değişen bir şey yapmaktır.
Şimdi tüm bu bilgiler bize ulaştığında ve tüm bu verileri içeri aktarabildiğimizde, bazı durumlarda bu örneklerle ilişkili kendi meta verilerinizi oluşturmaya başlamak gerçekten mantıklıdır ve bu meta veriler bu tür bir şekilde oluşturulabilir iş yapma şeklinize uyum sağlar.
Dolayısıyla, örnekleriniz coğrafi konuma veya uygulama sahiplerine veya DBA sahiplerine veya başka bir şeye göre gruplandırıldıysa, bu örnekleri nasıl gruplamak istediğiniz, bu örnekleri nasıl mantıklı bir şekilde anlamlandırmak istediğinize göre, araç içinde size bu yeteneği verecek iki alandan oluşur.
Birincisi, bir örnek etiketi veya bir etiket oluşturma yeteneğidir. Bu, esasen sunucuya, örneğe veya veritabanına bir ilişki oluşturuyor, böylece günlük olarak ortaya çıkabilecek görünümleri ve soruları yanıtlayabilmeniz, sahip olduğunuz şeyleri ele almanıza gerçekten yardımcı oluyor, ne yönettiğinizi ve bu bilgilerle nasıl ilerlemek istediğinizi
Sahip olduğumuz bir diğer şey, envanter alanları veya özel envanter alanları olarak adlandırılan bir şeydir ve bunlar, içine girebileceğiniz bilgi türlerine daha spesifiktir, örneğin, bir açılır liste eklemeye karar verebileceğim veritabanı katmanı tüm DBA'lar ve ben, bu tür bir duruma veya herhangi bir şeye bağlı olarak bu veritabanından kimin sorumlu olduğunu koyabiliriz, hangisinden sorumlu olursa olsun, hangi veritabanı olursa olsun, bunu seçebilmeliyim, böylece sorumlu olanlar olduklarını biliyorum ve kolayca envantere girerek.
Dolayısıyla, bu bilgi parçaları, özellikle de geniş bir ortamınız varsa, çok değerli hale gelir, çünkü bu bilgiyi anlamanıza ve neye sahip olduğunuzu ve bunu nasıl yaptığınızı bilmenize yardımcı olur.
Şimdi devam edip bir sonraki slayda geçeyim. Şimdi size gösterdiğim şey, topladığımız tüm bu bilgilerin, meta veri topladığımız ve uyguladığımız tüm bu bilgi ve verilerin size gelince çok daha kolay ve hızlı kararlar verebilmenizi sağlıyor. Microsoft ile kurumsal toplu lisanslama veya yazılım sigortasında lisanslarınızı Microsoft ile artırın.
Bu, bunu yapmaktan çok daha kolay hale getirir, gitmesi ve bir çok manuel veri toplaması yapmak zorunda kalır, bu bilgiyi gerçekten çok daha iyi hale getirir ve bu da onu genel olarak bir süreçten çok daha iyi hale getirir. DBA'ların lisanslama konusunda bu kararları almasını kolaylaştırmak için bu, ürünün görevlerinden biri.
Şimdi, DBA'larla konuştuğumuz, gerçekten hızlı bir şekilde keşfettiğimiz ve öğrendiğimiz bir diğer şey, - ve daha önce tartışılana geri dönmektir - SQL Server ortamınızda 300 örneğiniz olabilir, ancak gerçekten sadece bir alt küme olabilir geleneksel performans izleme türü araçlardan gerçekten tam olarak izlenen ve yönetilenlerin.
Yani giderseniz ve aslında DBA ile oturursanız ve şöyle diyorsunuz, “Bakın, 300'ü takip eden ve bunu izlemek için tasarlanmış bu araçla izlenen bu 20 örneğe veya 10 örneğe sahip olduğunuzu biliyoruz. SOA'lar ve uyarılar ve her türlü iyi şeyleri almak, ”diye de bulduğumuz şey şuydu:“ Öyleyse sahip olduğunuz diğer 280 örneğe ne dersiniz? Bunları önemsiyor musunuz? ”Ve onlar da önemsiyorlar, ama onlar sadece 10 veya 20'ye karşı bu örneklerle yapılabilecek derinlik düzeyinde olanları izlemek için bir yatırım yapmak istemiyorlar, gerçekten kritik ürün örnekleri.
Dolayısıyla, bu araçla denklemin diğer kısmı, temel düzeyde, örneğin sağlık durumu ile ilgili olduğunuzdan emin olmanız açısından da yardımcı olmasıdır. Şimdi size bir kilitlenme olup olmadığını veya kilitlenme kurbanının kim olduğunu söylemeyecek. Oturumların bu düzeyine ve sorguların ayrıntılarına ulaşmak değil. Ama aynı zamanda hala size bildirecek, hey sunucu kapalı veya hey birim dolduruyor ya da veritabanının yedeklerini yapmanız gerekiyor, bu bir DBA olmanın önemli bir parçası.
Bu tür şeyler kesinlikle hala önemlidir ve bu araçla, gittikleri takdirde, kendilerine çok fazla, çok değerli olan gerçekten kritik örnekleriniz için bir yakalama yapmanın bir yolunu yaptım. Hemen bilmeniz gerekir. Bu tür şeyleri daha yüksek düzeyde izleyebilir ve yapabilirler; bununla birlikte, çevreye eklenen yeni örnekleri alabilir ve bunların hesaba katıldığından ve ayrıca bu temel sağlık kontrol seviyelerinin oluştuğundan emin olun.
Bu, Inventory SQL Import Manager'ın ne hakkında olduğu gibi. Şimdi size bir gösteri göstereceğim. Bunu yapmadan önce, hızlı bir şekilde size buradaki mimari slayt olduğunu ve sadece bunu göstermek için, yönettiğimiz SQL örneklerini, SQL 2000'den yenisine kadar her şeyi keşfedebiliriz. SQL sürümleri.
Böylece bunu, örneklerin kendilerine ajan dağıtmak zorunda kalmadan yapabiliriz. Bunu bir toplama hizmeti aracılığıyla yapıyoruz ve dışarı çıkıp bu bilgileri toplayıp bir depoya koyacağız ve bir Tomcat web hizmeti ön uç konsolundan daha sonra bu verilerle etkileşime geçip bunları görüntüleyebileceğiz. Yani oldukça basit bir mimari.
Devam edip, geçiş yapıyorum ve aslında bizi ürünün içine götürüyorum, böylece bir his elde edebilirsiniz, nasıl çalıştığını anlayabilirsiniz. Bunu yapmanın en iyi yolu, sizi öncelikle arayüzün kendisine tanıtmaktır, burada baktığımız bir gösterge paneli.
Şu anda yönetim altında olduğum örneklerin sayısını pek göremiyorum. Ama arka cebimde de tam bir veri merkezi yok. Burada gördüğümüz yaklaşık altı örneğim var. Şimdi, ben, yapacağım şey, keşif sürecinden geçmek ve nasıl çalışacağını göstermek.
Şimdi yapacağınız ilk şey yönetim bölümünde örneklerinizi nasıl keşfetmek istediğinizi belirtebilirsiniz. Bu bilgiyi buraya ve bir kez daha bir dizi IP adresi aracılığıyla yapılabilecek şekilde koyabilirsiniz. Bir etki alanını veya alt etki alanını işaret edebilir ve yalnızca bu etki alanının üyesi olan makinelerde SQL'in ne zaman denetleneceğini çalıştırabileceğiniz çeşitli özellikleri seçebileceğiniz denetimleri gerçekleştirebilirsiniz.
Sonra bunu yaptıktan ve bu verileri toplamak ve toplamak için günlük olarak çalıştırılmasını otomatik hale getirebilirsiniz. Gerekirse bunu geçici olarak da yapabilirsiniz. Ama bir kez başladıktan sonra, o keşif süreci görmeye başlayacağınız şey, buradaki örnek görünümüne gittiğinizde. Bir Keşif sekmeniz var ve Keşif sekmesi bize yakın zamanda keşfedilen örnekleri gösterecek. Bizim durumumuzda burada bir numara var. Devam edeceğim ve yapacağım şey örnek olarak kullanacağımız olanı eklemektir. Bu durumda bu bir Chicago örneği, değil mi? Devam edip bu örneği envanterime ekleyeceğim.
Tamam ve burada birkaç şeyden geçeceğim. Ben sadece devam edeceğim ve göreceksiniz ki kimlik bilgilerini ayarlayabiliriz. Kimlik bilgilerim orada iyi olmalı. Devam edeceğim ve eğer istersem bunun sahipliğini atayabileceğimi fark edeceksiniz. Bir yer de belirtebilirim. Şimdi konumun kendisi de eklenebilir ve bir dahaki sefere bunu açıkça hatırlayacaktır.
Bir kez daha, etiketleri meta veriler ve bu SQL örneklerini, özellikle bu örnekleri, koymak istediğimiz kovalara nasıl koymak istediğimizle de ilişkilendirebilirim. Bu nedenle, bazı güncel etiketler, popüler etiketlerimiz var., daha önce eklemiş olabileceğim bir grup farklı etikete bakabiliriz. Bunlardan bazılarını rastgele seçeceğim ve bunu uygulayabiliriz.
Şimdi devam edip envantere eklediğimde. Şimdi eklendiğine göre, artık bu yönetilen görünüm altında göründüğünü görüyoruz ve böylece burada listelenmiş olduğunu görebilirsiniz. Yani biliyorsunuz ki bu ilk adım ve size az önce gösterdiğim şey, günlük olarak ilerlerken bu örnekleri daha çok eklemenin yoluydu. Bazı durumlarda, SQL sunucusunun kurumsal bir sürümü ise bunu otomatik olarak envanteme eklemek istediğimi biliyorsunuz? Manuel olarak gitmem ve bunu seçmem gerekmiyor.
Jocelyn: Seni çok çabuk keseceğim. Demoyu görmüyoruz.
Bullett Manale: Yapmadın mı?
Jocelyn: Hayır.
Bullett Manale: Bu iyi değil, bir bakalım.
Eric Kavanagh: Sol üst köşeye giderseniz, başlat'ı tıklayın, tıklayın.
Bullett Manale: Ah, tamam.
Eric Kavanagh: Şimdi ekranı paylaş.
Bullett Manale: Üzgünüm. Evet.
Eric Kavanagh: Sorun değil. İyi yakalan, yapımcı Jocelyn.
Bullett Manale: Pekala, bu daha iyi mi? Şimdi görüyor musun?
Robin Bloor: Evet, gerçekten.
Bullett Manale: Pekala, hadi sizi hızlıca gerçek olduğumuz yere götürelim. Daha önce keşfettiğimiz örnekleri bulduk. Chicago örneğini yeni ekledim ve şimdi gördüğünüz şey şimdi burada listeleniyor. Zaten çok fazla ek bilgi çektiğine dikkat edin. Örneğin kendisini tıklarsam, o örnek hakkında önceden topladığımız her türlü bilgiyi görmeye başlarsınız. Şimdi burada bulunan tüm veritabanlarının bir listesi. Veritabanlarının büyüklüğe ve etkinliğe göre dağılımını, hangilerinin büyüklük ve etkinliğe en çok sahip olduğunu görebiliyoruz.
Bir kez daha, aynı zamanda, örnek üzerinde çalışırken gördüğümüz iş yüküne bağlı olarak, o örnekte çalışırken hangi uygulamaları gördüğümüzü söyleyebiliriz. Yani bunu otomatik olarak yapabilmek çok hoş. İçeri girip uygulamayı insidansa bağlamak zorunda değilim. Gördüklerimize dayanarak bunu doldurabiliriz. Şimdi manuel olarak bir uygulama eklemek istiyorsanız, bunu kesinlikle yapabilirsiniz. Ancak, örneğin veritabanıyla ilişkisini veya uygulama ile özür dilerim.
Ayrıca ekranın sağ tarafında anlık bir özetimiz olduğunu ve altında bir sunucu özetimiz olduğunu fark edeceksiniz. Yani burada örnek anahtar bilgilerden bahsediyoruz, sürümü biliyor ve sadece SQL Server 2012'yi değil, hangi düzeltmelerin bağlı olduğunu ve hangi servis paketlerinin bağlı olduğunu bize bildiren gerçek sürüm numarasını ona bağlıysa, bilmek çok önemli olabilir. Açıkçası bellek gereksinimi önemlidir. Kümelenmiş olsun, bütün bu bilgilerin hepsi gibi, her şeyi koymak zorunda değilim - zaten toplanıp toplanıyor ve bunun keşfedilen bir örnek olduğunu belirledikten sonra, bu envanterimizin bir parçası olacak.
Burada göreceğiniz diğer bir şey - ve size gösterecek - bu örnek görünümü altında. Daha önce bahsettiğim bu niteliklere, eklenebilecek özel özelliklere sahibiz. Böylece açık tür metin kutusu alanları ekleyebiliriz, bilirsiniz, milyar çeşit seçenek açısından evet / hayır yapabiliriz. Açılır listeler bile yapabiliriz. Bunu veritabanı örneğinde veya sunucu düzeyinde yapabilirsiniz.
Daha sonra biraz daha aşağı kaydırırsak, ilgili tüm bilgileri sunucunun kendisine görebiliriz. Yani tüm bu tür şeylerin açıkçası gerçekten yararlı olduğunu biliyorsunuz çünkü hepsi toplanmış ve toplanmış ve bu kararı envanterimizin bir parçası haline getirmeye karar verdiğimizde bizim için orada. Burada CPU'lar, mantıksal ve fiziksel olanların sayısı, ne kadar bellek açısından bazı farklılıklar gösterebiliriz. Yani çok fazla iş yapmanıza gerek kalmadan gerçekten çok iyi ve zengin bir bilgiye ulaşıyorsunuz.
Şimdi bunun diğer kısmı, dediğim gibi, bu verileri sunucu düzeyinde toplıyoruz. Veritabanına bile gidersek, bu şeylerin çoğunun bizim için de bozulduğunu görebiliriz. Bu yüzden uyumluluk depomuma gidersem, bu durumda şunu söyleyebilirim, bunun bir uğraştığını biliyorsunuz, bu, uyumluluk veya düzenleme gereksiniminin ilişkili olduğu bir uyumluluk veritabanıdır ve diyelim ki, SOX uyumluluğu veya PCI uyumluluğu. Böylece hangi veritabanlarının kendileriyle ilişkili uyumluluğa sahip olduğumu seçebilirim veya bu düzenleme gereksinimi açısından sürdürdüğümden emin olabilirim.
Dolayısıyla, bu tür şeylerin DBA'lara çok yardımcı olduğu kanıtlanmıştır, çünkü bu ilişkili meta verilerin tümünü merkezi olarak kolayca çevrelerinde tutabilecekleri bir yer var ve dediğim gibi, işlerine olduğu gibi uyum sağlayabilirler ' iş yapma biçimleri olarak yapıyorlar. Bu yüzden şimdiye kadar gördüğümüz şeylere bakarsak, örneğe baktığımda örneğe oldukça iyi bir genel bakış elde edersiniz.
Ayrıca arama yapabilirim, böylece envanterimdeki bu uyum deposunu arayalım. O zaman burada göreceğiniz şey, bu şeyleri arayabileceğim ve onları tanımlayabileceğim. Bunu söylüyorum - Ne olduğundan emin değilim, git düğmem orada çalışmıyor. Tamam. Bakalım, tekrar deneyelim. Oraya gidiyoruz. Böylece, uyum içinde olduğumuz herhangi bir şeyi gördüğümüz yerde bir döküm görebiliriz ve bunu inceleyebilir ve bu açıdan da görebilirim. Yani bu verileri incelemek için hızlı ve kolay bir yolunuz var.
Şimdi daha önce de belirttiğimiz gibi, örnek sunucuya ve veritabanına meta veri oluşturmanın birçok farklı yolu var. Bunun diğer kısmı, gruplandırdığınız ve ilişkilendirdiğiniz şekilde bundan yararlanabilmektir. Kaşif manzarasına gidiyoruz, tam da bunu yapabiliriz. Konumlara göre bir veritabanı sayımı yapmak istediğimi söyleyebiliriz. Bu yüzden desteklediğim ortamların her bir yerlerindeki veritabanlarının sayısı. Ya da belki de orada örnek sayısı açısından sahip olduğum örneklerin sahibine dayanır. Böylece bunu görebileceğiz. O zaman cevaplamaya çalıştığınız soru ne olursa olsun, bu resimleri sizin için boyamak için gerçekten iyi ve kolay bir yol elde edersiniz.
Daha sonra bu bilgilere ne tür bir şekilde istediğinizi oluşturduysanız, onu kullanabilmek ve meslektaşlarımıza gönderebilmek veya ihtiyaç duyduğumuz her şeyi yapabilmek için PDF'ye veya farklı formatlara aktarabiliriz. Yani bu tür şeyleri yapabileceğinizi biliyorsunuz. Geri dönelim - kaybettim mi? Oraya gidiyoruz. Pekala, umarım bu şimdiye kadar bahsettiğim şeyler açısından anlamlıdır. Şimdi topladığımız veriler, bunların hepsi bir dizi nedenden ötürü açık bir şekilde hayati öneme sahip - lisanslama ve ne olursa olsun.
Bahsettiğimiz son şey, buradaki yönetim bölümüne geçmemiz. Burası aynı zamanda e-postanızı ve uyarılarınızı yapılandırabileceğiniz ve gerçekten bilmek istediğiniz şeyler için bu şeyleri de ayarlayabileceğinizden emin olabileceğiniz yerdir. Böylece e-posta uyarıları ayarlayabiliriz, belirli şeyleri açma ve belirli şeyleri kapatma yeteneğini ayarlayabilir ve daha sonra bu e-postaları kimin alacağını belirleyebilir ve bu uyarılara abone olup istediğimizi ilişkilendirebiliriz kim bu tür şeyleri bilmek ister ki.
Ancak daha önce de söylediğim gibi, bu gerçekten güzel bir yoldur, en azından tüm kurumsal SQL örnekleriniz için bilmenin genel huzuruna sahip olmak - sahip olduğunuz şeydir ve ayrıca, t, bu örneği yönetmek için ağır bir performans izleme aracına yatırım yapmaya karar vermediler. Bu sizi kapsayacaktır, çünkü dışarı çıkmanın çok uygun bir yoludur ve birçok örnek için bu envanterleri yapabilir ve emin olmak için bir tür genel izleme düzeyi yapabilirsiniz. İçiniz rahat olsun ve neler olduğunu bilin.
Umarım bu onu tanımladığımız ve size gösterdiğimiz şekilde anlamlıdır. Sanırım bu bakış açısıyla devam edip geri verebiliyorum ve biraz daha konuşabiliriz.
Eric Kavanagh: Kulağa hoş geliyor. Peki Robin? Dez? Sorusu olan?
Robin Bloor: Sorularım var. Aslında çok ilginç, yani sadece DBA'lar arasında değil, ağ adamları arasında, depolama makineleri arasında, sanal makine yönetimi adamları arasında, neredeyse her yerde bulunduğum yorum yapmak istedim. tüm elektronik tablolar üzerinde çalışıyor.
Eric Kavanagh: Doğru.
Dez Blanchfield: Bunun bir çeşit olduğunu biliyorsunuz, sayılar hareket etmeye başlayana kadar bunun iyi olduğunu biliyorsunuz. Sayılar hareket etmeye başladığında, başlarının belaya gireceğini biliyorsun. Şimdi soru biraz ilgileniyorum ve cevaplamanızın zor olacağını biliyorum, ama ne, eğer elektronik tabloların çalışması için böyle bir şeyleri olmayan bir yere girerseniz, varsayalım DBA'lar çok akıllı çocuklar ve benzerleri, böyle bir şeyi uygulamaktan ne tür bir YG elde edeceğinizi düşünüyorsunuz? Bununla ilgili herhangi bir rakamınız veya bununla ilgili herhangi bir talimatınız var mı?
Bullett Manale: YG'nin ne olduğunu söylemek zor çünkü çevre biraz farklı olacak. Açıkçası, işletme ne kadar büyükse, çevre de o kadar büyüktür, tabii ki, şimdi manuel yöntemleri kullanıyorlarsa, ROI muhtemelen daha fazla olacaktır.
Binlerce ve binlerce çalışanı olan büyük organizasyonlar ve muhtemelen binlerce örneği de söylediğimde, bunu onlara gösterdiğim insanlara sahip olduğum bir dizi ile konuştuğumu biliyorum ve bunun alacağını söylüyorlar iki hafta geri döndüm. Bunu bana bir kereden fazla söylemiştim. Bu nedenle, bir satın alma işlemindeki gerçek dolar miktarı açısından söylemek zor, ancak ortamlarınız olduğunda dikkate değerdir.
Dediğim gibi, oldukça tutarlı, benim konuştuğum insanlar, konuştuğum insanların çoğu bu sayfayı bir e-tabloda tutuyor. Bu sadece çok, çok öznel bir şey çünkü her ortam, lisanslamalarını nasıl yaptıkları ve Microsoft ile lisanslamalarını nasıl yaptıkları açısından biraz farklı. Ancak her yıl veya üç yılda bir gerçek artışlar yapmak zorunda kalırlarsa, sanırım Microsoft için en fazla üç yıl, en azından üç yılda bir doğrulamanızı istiyorlar.
O zaman onun hatırı sayılır olduğunu biliyorsunuz ve biliyorsunuz ki bu çok daha kolay bir şey. Her zaman değişen dinamik bir şey olduğu için, ayetlere baktığınız açısından da biraz daha geçerlilik verir, e-tabloyu altı ay veya bir yıl içinde gerçekten güncellemedik. Dolayısıyla, e-tabloyu ne sıklıkta güncellediğiniz, YG'ye verilen cevabı anlamak için başka bir sorudur.
Dez Blanchfield: Evet, yani SQL lisansı, bunun lisanslanması sadece lanet bir kabus, ama özellikle bir kabus çünkü lisans Microsoft ve Oracle ile orada veritabanı işleri yapan herkes arasında aynı değil. E-tablolarda aslında gerçekte olan olma eğiliminde olan şeyleri saklıyorsanız, gerçekten fark etmeden önce lisanslama zamanının geldiğini biliyorsunuz ve aslında ne demek istediğimi biliyorsanız, kolayca ulaşmak için verilere sahip değilsiniz. bu bilgi.
Her neyse, işaret ettiğiniz gibi, dinamik ve kişisel olarak hiçbir fikrim yok çünkü aslında Microsoft ile asla müzakere etmek zorunda kalmadım, bu yüzden hiçbir fikrim yok, ancak muhtemelen insanların genellikle test verilerini aşağı çektiği, test ettiği veritabanları var ve lisanslama yapıyorsanız bunların yanınızda bir diken olduğunu tahmin ediyorum. Sen olduğunu-?
Bullett Manale: Evet, evet. Durum böyle çünkü birçok şey unutuluyor ve sonra anlamaya çalışıyoruz, tamam, tamam, tamam, bu örneklerin her biri için çekirdek sayısını bulmamız gereken temel lisanslarımız var ve ben bilmiyorum, akıllıca satın aldığınızın standartları açısından, oldukça iyi bir donanım satın alabilirsiniz, o zaman bu donanımı kullanmanız gerektiği şekilde kullanmıyorsanız, fazla ödeme yapıyorsunuz çünkü bu çekirdekler kullanılmadığında çekirdek fiyatlandırma için ödeme yapmak sorun haline gelir.
Bu nedenle, SQL'in her sürümü, lisanslamanın uygulandığı farklı bir yola sahiptir, bu da onu biraz kafa karıştırıcı hale getirir. Yani bununla ilgili bazı zorluklarınız var ve bu yüzden bu bilginin çok yararlı olmasının büyük bir parçası, çünkü size hangi sürümün olduğunu söyleyebiliriz, SQL'in eski sürümleri varsa, sahip olduğunuz çekirdek sayısını açık bir şekilde söyleyebiliriz bu da soket başına fiyatlandırmaydı, yine de bunu açıkça gösterebiliriz. Bu yüzden, bu şeyleri gerçekleştirmek için zaman geldiğinde geçmeniz gereken bir rutini daha basit hale getirir.
Dez Blanchfield: Benim için aklıma gelen bir şey var, üzgünüm git-
Robin Bloor: Sorun değil, sen Dez'e gir, muhtemelen alakasız bir soru soracaktım.
Dez Blanchfield: Şu anda bulunduğunuz konuyla ilgili çok hızlı bir şey - bulut ortamlarının çok daha fazla benimsendiğini görüyoruz ve bunu kendi veri merkezimizde, kendi ortamımızda çalıştırıyorsak, etrafta sürünüyorlar ve buluyorlar, bir şeyler keşfetmek nispeten basit.
Bu ortamlarda üç veri setinin, iki bulutun ve görünürlüğün olabileceği senaryo ile nasıl başa çıkabiliriz? Güvenlik duvarı ve genellikle bir borunun veya VPN'nin sonunda bir veri kümesi vardır. Bu tür bir bulut ve bu platformun çalıştığı tesisler arasındaki belirli ortamları tarayabilmemiz için bağlantı noktalarını açmaya başlamak için ön uçtan keşfetmek için mi yoksa ihtiyacımız var mı?
Bullett Manale: Evet, limanlar açısından biraz düşünülecekti. Yani, ne yazık ki tüm bu ortamları kıracağını söyleyebilseydim, ancak bununla yapabileceğiniz bazı farklı seçenekler var. Açıkçası, Amazon EC2 gibi bir şey yapıyorsanız, bağlantı noktalarınızın açık olduğunu varsayarak ve sonra IP adreslerinizi veya bununla ilişkili etki alanınızı belirleyebildiğinizi varsayarak, bağlantınız aracılığıyla o ortama gerçekten ihtiyacınız olacak ve başlayabilir toplama ve keşfetmeye başlayın.
Yani bu tür ortamlarda bu gerçekten sorun değil; RDS gibi daha spesifik ortam türleri ve veritabanını bu tür bilgileri görmek ve keşfetmek için biraz daha zorlayıcı olacağınız yerdir.
Dez Blanchfield: Yani bundan sonra, orada veritabanları ve veritabanları var. Yani, örneğin, sadece bir büyük platform ve tek yaptığı ön planda paylaştığım ön planda paylaştığım anekdot gibi çok, çok büyük bir veritabanı motoruna sahip olmanın eski güzel günleri veritabanı sağlamaktır. Bu günlerde, veritabanları her şeye gömülüdür, aslında, telefonun içinde uygulamaların arkasında çalışan iki veya üç tane var.
Lotus Notes'tan ortamların geldiği senaryolarla, arkalarındaki uygulamalarla, çeşitli internetteki veritabanıyla SharePoint vb.İle ilgili ne tür zorluklarla karşılaşıyorsunuz? Temelde her şey arka uç veritabanı tarafından desteklenmektedir. Orada ne tür şeyler görüyorsunuz ve insanların sadece bu tür dünyaları haritalamaya çalışırken ne tür zorluklarla karşılaştığını ve aracınızın onlar için ne yaptığını görüyorsunuz?
Bullett Manale: Demek istediğim, söylediğiniz şey - her şeyin şimdi bir veritabanına ihtiyacı var, bu yüzden birçok kez muhtemelen DBA'nın kendisiyle çevreye tanıtılan birçok veritabanı var çevrede bir SQL sunucusu kurmanın çok zor olmadığı için, genel olarak konuşursak bile farkında değiliz.
Bu araç aynı zamanda hızlı veritabanları gibi şeyleri de tanımlar, böylece SQL Server'ın ücretsiz sürümleri. DBA'larla konuştuğunuzda yeterince komik, bir kez daha, orada bulunan ücretsiz veritabanlarını önemsemeleri açısından tutarlı bir cevap alamıyorsunuz. Bahsettiğiniz bu uygulamaların birçoğu veritabanının ücretsiz sürümünü kullanacaktır. Ancak kuruluşların kendileri, kiminle konuştuğunuza bağlı olarak bu veritabanından kimin sorumlu olduğu konusunda farklı bir tutum sergileyecektir.
Konuştuğum bazı DBA'lar, son kez Seattle'da olan SQL Server PASS'ta olduğumu düşünebilirim, “Hızlı veritabanlarınızı önemsiyor musunuz?” Sorusunu soruyorsunuz ve yaklaşık elli elli idi. Bazıları, onlar hakkında bir DBA olarak bilmek istediler, çünkü hala kritik bilgiler içerebilecekleri ifade edilen veritabanlarında bile sorumluluklarının bir parçası olduklarını hissettiler; hala yedeklenme sürecinden geçmeleri ve her şeyin onlar üzerinde bir sağlık perspektifinden çalıştığından emin olmaları gerekir. Ancak sadece var olduklarını bilmek, daha önemli olmasa bile aynı derecede önemlidir.
İnsanların diğer yarısı ise, “Hey, biz bu veritabanlarından biz sorumlu değiliz ve onlara koydukları herhangi bir şey onları kuran kişiye dikkat etmektir.” Ama şunu söyleyebilirim ki dedi ki, bugünlerde her şey ona bağlı bir uygulama var, bu da sadece bu bilgileri envantere almanın karmaşıklığına ve karışıklığına daha fazla katkıda bulunuyor.
Dez Blanchfield: Evet, bazılarını gördüm, hükümet siteleri muhtemelen benim favorim ama çoğu zaman kurumsal ortamlarda görmekten daha fazla. Söylediğiniz gibi, insanlar SharePoint gibi bir şey yüklediklerinde bile benim unuttuğumu unutuyorlar. öz-değişim gibi, böylece sadece yerleşik ücretsiz bir sürümle geldiklerini biliyorsunuz çünkü istedikleri, biliyorsunuz, hızlı bir şekilde yükleyin ve lisans alıp gitme konusunda endişelenmeyin.
Sonra büyüyor ve birileri performanstan şikayet etmeye başlıyor ve şöyle diyorlar: “Bu sadece eski sunucunuz, depolama alanınız, ağınız, her neyse, ” ve sonra DBA çağrılıyor ve “Şey, her şeyi veritabanının bu ücretsiz sürümüne tıkıştırdı, bu da bu kadar büyük bir performans sergilemeniz için gerekli değil. ”
Özellikle Project Manager ve Office gibi senaryolarınız olduğunda, büyük bir kuruluşta veya şirkette binlerce proje olmasa bile yüzlerce proje çalışıyor ve SharePoint'i Microsoft Project Server ile kullanıyor ve tüm PMO öğelerini bu veritabanına döküyorlar. Ama ön tarafta onlar gibi, bu sadece bir web arayüzü. Ama gerçekten veritabanları ve veritabanları var.
Bullett Manale: Evet.
Dez Blanchfield: Öyleyse onlar ne, buradaki insanların ilk adımlarından biri, sanırım izleyicilerden getirmek isteyebileceğimiz birkaç soru var. İlk sorulardan biri insanların nereden başladığıdır? Gitmeleri için ilk doğal adım nedir, “Tamam, Adsız Alkolikler versiyonunu yapmamız gerekiyor mu?”
Ne yapacağımızı bildiğimizden daha fazla veritabanımız var. "Tamam, bu şeyi alıp koşmaya başlamamız lazım mı?" Diye gitmek için doğal bir adım nasıl görünüyor? Sadece soğuk hindi mi yoksa daha sonra gerçekten küçük başlamalılar ve çevrelerini haritalama konusunda biraz deneyim sahibi olmalılar ?
Bullett Manale: Bence bu çevreyi haritalamak zorunda olduklarını söyledi. Microsoft şimdi bunu yapmak için ücretsiz bir araç sunuyor, Microsoft Değerlendirme Planlama Aracı, bu ücretsiz bir araç ama durağan. Keşfi yapıyorsunuz ve hepsi bu. Orada olan şeylerin bir listesini alırsınız. Bunu aldık ve bak bir adım daha atalım, keşfi yapalım, dışarıda ne olduğunu bulalım ve depoya koyalım ve dinamik hale getirelim ve ekleyelim, ondan kaldıralım.
Ama genel olarak en büyük ilk adım, keşfi yapmak, bulmak için düşünüyorum. Bu, deneme sürümünde ürünümüzü indirmek anlamına gelirse, bunu indirebilir ve 14 gün boyunca deneyebilir ve ortamınıza işaret edebilir ve koleksiyonu yapabilirsiniz.
Şimdi, bu bilgilerin doğru olduğundan biraz emin olduğunuz bir sürü bilgi içeren bir e-tablonuz varsa, tüm bu bilgilerle e-tabloyu CSV'ye aktarmayı beğenebilir ve bu bilgilerinizin bir kısmını yapabilirsiniz. çoktan sahip. Ancak bilmediğiniz şeyleri bulmak açısından, bunu yapmanın tek yolu el ile dışarı çıkmak, yapmak veya böyle bir şeyi arayan bir araca sahip olmaktır. Bir noktada yapmak zorunda olduğunuz karar şudur: “Bu keşfi otomatikleştirmeye mi yoksa en azından orada olanların iyi bir temelini oluşturmaya mı çalışıyorum ve sonra bazı istisnalar hakkında endişelenmeye mi çalışıyorum?” büyük olasılıkla bir araca ihtiyacınız vardır.
Dez Blanchfield: Çok çabuk. İnsanlar buna başlamak için nereye gidiyor? Web sitenize mi vurdular? Bu konuya nasıl çabucak ulaşırlar ve başlarlar?
Bullett Manale: IDERA.com Idera'ya giderseniz, göreceksiniz, ve gerçekten hızlı bir şekilde bunu gerçekten hızlı bir şekilde gösterebilirim. Idera web sitesinde ürünlere, envanter yöneticisine gideceksiniz. Burada bir indirme bağlantısı olduğunu göreceksiniz. Sadece hangi yapıyı 64 veya 32 bit üzerine kurmak istediğinizi siz belirlersiniz ve bu sizi devam ettirir ve keşfinizi oradan başlatabilirsiniz.
Robin Bloor: Harika ve harika, harika sunum, çok teşekkür ederim.
Bullett Manale: Teşekkür ederim.
Eric Kavanagh: İzleyicilerden birkaç sorumuz var ve bunları size e-postayla göndereceğiz, çünkü bugün kendimizi durdurmak zorundayız, ancak Bullett, yine demoda harika bir iş, yapımcımızın iyi bir iş olmadığını t gösteriliyor.
Bullett Manale: Üzgünüm.
Eric Kavanagh: Hayır, bu iyi şeyler, işin özüne görünürlük veriyorsunuz değil mi? Çünkü iş verileri çalıştırıyor ve çekirdeğe görünürlük sağlıyor. Artık el dalgalı şeyler yok; şimdi aslında bir şeye işaret edebilir ve çözebilirsiniz. Senin için çok iyi.
Bullett Manale: Teşekkür ederim.
Robin Bloor: Ama bu arada çok canlı olduğunu görmek harikaydı, aferin.
Eric Kavanagh: Evet, bu web yayınını daha sonra izlemek için arşivleyeceğiz ve umarım yaklaşık bir ya da iki saat içinde ilk arşiv artar, bazen bundan biraz daha uzun olur, ancak millet biliyorum. Bununla gitmene izin vereceğiz millet. Brifing Odası'na katıldığınız için tekrar teşekkür ederiz, biz aslında Sıcak Teknolojileriz. Bir dahaki sefere seni yakalayacağız. Kendine iyi bak bay bay.
