Ottaa mukaan: Isäntä Eric Kavanagh keskustelee ennustamisesta tohtori Robin Bloorin, Rick Shermanin ja IDERA Bullett Manale -tapahtuman kanssa.
Sinun on ilmoittautunut tapahtumaan nähdäksesi videon. Rekisteröidy nähdäksesi videon.
Eric Kavanagh: Hyvät naiset ja herrat, hei jälleen kerran ja tervetuloa takaisin Hot Technologies -verkkosarjaan! Nimeni on Eric Kavanagh, olen tämän päivän verkkoseminaarin isäntä, nimeltään “Säästä aikaa, rahaa ja ongelmia optimaalisten sääennusteiden kanssa.” siitä tässä näyttelyssä. Joten, Hot Technologies on tietysti foorumimme, jonka avulla ymmärrämme joitain hienoja tuotteita nykypäivän maailmassa, yritystoiminnan tekniikan maailmassa, mitä ihmiset tekevät heidän kanssaan, miten he työskentelevät, kaikenlaisia hauskoja juttuja.
Ja tänään aihe, kuten ehdotan, käsittelee ennustamista. Yrität todella ymmärtää mitä organisaatiossasi tapahtuu. Kuinka aiot pitää käyttäjän onnelliseksi riippumatta siitä, mitä he tekevät? Jos he tekevät analyysiä, jos tekevät todellista työtä, kohtaavat todellisia asiakkaita, joilla on transaktiojärjestelmiä, olipa tapaus mikä tahansa, haluat ymmärtää kuinka järjestelmät toimivat ja mitä tapahtuu, ja mikä on mitä hyvin puhutaan tänään. Se on hauskaa, koska ennustaminen ei ole jotain mitä haluan tehdä, aiheuttaen taikauskoa, kuten luulen, että jos ennustan liikaa, tapahtuu huonoja asioita, mutta se on vain minä. Älä seuraa minun esimerkkiä.
Joten, tässä ovat tänään esiintyjiämme, oikeassa yläkulmassa, Rick Sherman soittaa sisään Bostonista, kaverimme Bullett Manale IDERAsta ja oma tohtori Robin Bloor. Ja sen kautta, annan sen Robinille ja muistutan vain ihmisille: Kysy, älä ole ujo, rakastamme hyviä kysymyksiä, laita ne hyvin esiintyjillemme ja muille tänään. Ja sen kanssa, Robin, ota se pois.
Robin Bloor: Okei, no, kun olen paikassa, kuten he sanovat, ajattelin kertovan SQL-tarinan tänään, koska sen taustalla käydään keskustelua, jota jatketaan, ja se ei väistämättä ole ristiriidassa, koska Rick ei keskity tähän , ja ei ole ristiriidassa sen kanssa, mitä Rickillä on sanottavaa. Joten, SQL-tarina, on joitain mielenkiintoisia asioita SQL: sta, koska se on niin hallitseva. Katso, se on kirjoitusvirhe, SQL on deklaratiivinen kieli. Ajatuksena oli, että voisit luoda kielen, jolla pyydät mitä halusit. Ja tietokanta selvittää, miten se saadaan. Ja se on itse asiassa sujunut melko hyvin, mutta on olemassa joitain asioita, jotka on syytä sanoa siitä, seuraukset koko IT-alan perustamiselle deklaratiiviselle kielelle. Käyttäjä ei tiedä tai välitä tietojen fyysisestä järjestämisestä, ja se on hyvä deklaratiivisen kielen suhteen - se erottaa sinut kaikesta tästä ja jopa huolestuttaa sitä - kysy vain mitä haluat, ja tietokanta menee ja saa sen.
Mutta käyttäjällä ei ole aavistustakaan, vaikuttaako tapa, jolla he rakentavat SQL-kyselyä, kyselyn suorituskykyyn ja eikö se ole myöskään haittapuoli. Olen nähnyt satoja ja satoja riviä kestäviä kyselyitä, jotka ovat vain yksi SQL-pyyntö, tiedätte, alkaa “valitse” ja jatkuu vain alakyselyillä ja niin edelleen ja niin edelleen. Ja todella käy ilmi, että jos haluat tietyn tietokokoelman pois tietokannasta, voit pyytää sitä monin eri tavoin SQL: n avulla ja saada saman vastauksen, jos sinulla on jonkinlainen tuntemus tietoihin. Joten yksi SQL-kysely ei välttämättä ole paras tapa pyytää tietoja, ja tietokannat vastaavat melko eri tavalla niiden sisältämän SQL: n mukaan.
Ja niin, SQL vaikuttaa tosiasiallisesti suorituskykyyn, joten ihmiset, jotka käyttävät SQL: tä, pätee niihin, samoin kuin SQL: ää käyttäviin SQL-ohjelmoijiin, ja he harvemmin ajattelevat vaikutustaan, joka heillä on, koska suurin osa keskittymisestä on oikeastaan tietojen käsittelyyn eikä tietojen hankkimiseen, sijoittamiseen. Sama pätee myös BI-työkaluihin. Olen nähnyt SQL: n, joka purkaa tarvittaessa erilaisten tietokantojen BI-työkaluja ja jos on sanottava, että paljon siitä on, en haluaisi kirjoittaa SQL-kyselyjä niin. Sen joku on luonut pienen moottorin, jos haluat, että parametrit riippumatta heittävät jonkin verran SQL: tä, ja taas, että SQL ei välttämättä ole tehokasta SQL: tä.
Sitten ajattelin mainita impedanssien välisen yhteensopimattomuuden, ohjelmoijien käyttämä tieto on erilaista kuin tiedot lajitellessaan. Joten, DMS-järjestelmämme tallentaa dataa taulukoihin, organisoidut oliokoodit ovat enimmäkseen koodereita, nykyään ohjelmoivat oliokeskeisiä muotoja ja tilaavat tietoja objektirakenteisiin, joten se ei kartoita toisiaan. Joten, on välttämätöntä kääntää siitä, mitä ohjelmoija pitää tietojen olevan sitä, mitä tietokanta ajattelee, mitä tiedot ovat. Mikä näyttää siltä, että meidän on pitänyt tehdä jotain väärin, jotta näin olisi. SQL: llä on DDL tietojen määrittelemiseen, sillä on DML - tietojen manipulointikieli - valitse, projisoi ja liity tietojen hankkimiseen. Nyt on hyvin vähän matematiikkaa ja hyvin vähän aikaperusteisia juttuja, joten sen epätäydellinen kieli on, vaikkakin on sanottava, että sitä on laajennettu ja jatketaan edelleen.
Ja sitten saat SQL-esteongelman, joka on aina suoria kuin kaavio, siinä että monet ihmiset kysyivät kysymyksiä analyyttisistä syistä, kun he ovat saaneet vastauksen kysymyksen tietotermeihin, haluavat kysyä toisen kysymyksen. Joten siitä tulee valintaikkuna, hyvin, SQL ei rakennettu valintaikkunoille, se rakennettiin kysymään, mitä haluat kerralla. Ja sen tyyppi on sen syytä tietää, koska siellä on joitain tuotteita, jotka todella hylkäävät SQL: n, jotta käyttäjän ja tiedon välinen keskustelu olisi mahdollista.
Tietokannan suorituskyvyn suhteen - ja tällainen leviää kaikkeen - kyllä, CPU, muisti, levy, verkon yleiskustannukset ja lukitusongelma useammalle kuin yhdelle henkilölle, jotka haluavat yksinoikeudella käyttää tietoja tietyllä hetkellä ajankohta. Mutta myös huonot SQL-puhelut ovat todella kauheita, joita voidaan tehdä, jos todella optimoit SQL: n suorituskyvyn suhteen. Joten, tietokannan suorituskykytekijät: huono suunnittelu, huono ohjelman suunnittelu, samanaikainen työmäärä puuttuu, kuorman tasapainotus, kyselyrakenne, kapasiteetin suunnittelu. Se on datan kasvu. Ja muutamassa sanassa, SQL on kätevä, mutta se ei itseoptimoi.
Tämän jälkeen uskon, että voimme siirtää Rickille.
Eric Kavanagh: Hyvä on, Rick, anna minun antaa sinulle avaimet WebEx-autoon. Ota se pois.
Rick Sherman: Hyvä on. No, kiitos Robin, koska aloitimme esityksen alussa, grafiikkaani on edelleen melko tylsää, mutta hyvin mukana. Joten olen samaa mieltä kaikesta, josta Robin puhui SQL-puolella. Mutta mitä haluan nyt keskittää vähän, on tietojen kysyntä, joka menee hyvin nopeasti läpi, tarjonta kuten kyseisessä tilassa käytetyissä työkaluissa tai työkalujen tarve kyseisessä tilassa.
Ensinnäkin jokaisessa lukemassasi artikkelissa on joitain suuria tietoja, paljon tietoja, pilvestä tulevaa jäsentämätöntä tietoa, suuria tietoja kaikkialla, mitä voit kuvitella. Mutta tietokantamarkkinoiden kasvu on jatkuvasti tapahtunut SQL: llä, relaatiotietokanta todennäköisesti vuodesta 2015 lähtien, on edelleen 95 prosenttia tietokantamarkkinoista. Kolmella suurimmalla relaatiomyyjällä on noin 88 prosenttia markkinaosuudesta kyseisessä tilassa. Joten, puhuimme edelleen, kuten Robin puhui, SQL: stä. Ja itse asiassa, vaikka etsisimmekin Hadoop-alustaa, Hive and Spark SQL - jota poikani, joka tietotekniikan edustaja käyttää koko ajan nyt, on varmasti hallitseva tapa ihmisille saada tietoa.
Tietokannan puolella on nyt kaksi laajaa luokkaa tietokantojen käyttöä. Yksi on tarkoitettu toimiville tietokannan hallintajärjestelmille, joten yrityssuhteiden suunnitteluun, asiakassuhteiden hallintaan, Salesforce-toiminnanohjausjärjestelmiin, Oraclesiin, EPIC: iin, N4: een jne., Koko maailmassa. Ja Theres, on suuri määrä ja kasvava määrä tietoa, joka on tietovarastoissa ja muissa yritystietopohjaisissa järjestelmissä. Syy kaiken analysointiin riippumatta siitä, missä ja miten se otetaan, tallennetaan tai siirretään, ja siten tietokantojen, etenkin markkinoilla olevien relaatiotietokantojen, käyttö on valtava kysyntä ja lisääntynyt.
Nyt meillä on kysyntä, meillä on tulossa valtavia määriä tietoja. Ja en puhu oikeasti vain isoista tiedoista, puhun datan käytöstä kaikenlaisissa yrityksissä. Mutta tarjonnan puolella ihmisille, jotka pystyvät hallitsemaan näitä resursseja, meillä on ensin poissa käytöstä DBA-pula. Työllisyystilastoviraston mukaan DBA-työpaikat kasvavat vuosina 2014–2024 vain 11 prosenttia - nyt ihmiset, joilla on DBA-ammattinimikkeet, mutta puhumme siitä hyvin sekunnissa - verrattuna 40 plusprosenttiin vuotuinen tiedonkasvutila. Ja meillä on paljon DBA: ita; keskimäärin samassa tutkimuksessa puhuttu keskimääräinen ikä on melko korkea verrattuna muihin tietotekniikan ammatteihin. Ja sitten meillä on paljon ihmisiä, jotka lähtevät kentältä, eivät välttämättä eläkkeelle, vaan siirtyvät muihin näkökohtiin, siirtyvät johtoon tai muuhun.
Nyt osa syystä heidän poistumiseen johtuu siitä, että DBA-työ jatkuu entistä vaikeampana. Ensinnäkin, meillä on DBA-tietokannat, jotka hallitsevat itse useita erilaisia tietokantoja, paikalla sijaitsevia fyysisiä tietokantoja sekä erityyppisiä tietokantoja. Nyt se saattaa olla relaatiotyyppi tai ne voivat olla myös muun tyyppisiä tietokantoja. Mutta vaikka se olisi suhteellista, heillä voi olla yksi, kaksi, kolme, neljä eri myyjää, joita he todella yrittävät hallita. DBA: t osallistuvat yleensä tietokannan tai sovelluksen suunnitteluun. Robin puhui siitä, miten tietokannat tai sovellukset suunnitellaan, miten SQL suunnitellaan. No, kun puhuttiin datamallinnuksesta, ER-mallinnuksesta, laajennetusta ER-mallinnuksesta, ulottuvuuden mallinnuksesta, edistyneestä ulottuvuuden mallinnuksesta, mitä tahansa, yleensä sovellusohjelmoijat ja sovelluskehittäjät suunnittelevat lopputavoitteensa huomioon ottaen - he eivät suunnittele itse tietokantarakenteen tehokkuutta . Joten meillä on paljon huonoa suunnittelua.
Nyt en puhu kaupallisten yrityssovellusten toimittajista; heillä on yleensä ER-malleja tai laajennettuja ER-malleja. Mistä puhun, on, että jokaisen yrityksen sovelluskehittäjät rakentavat paljon enemmän liiketoimintaprosesseja ja sovelluksia - juuri niitä ei välttämättä ole suunniteltu käyttöönoton tehokkuudelle tai vaikuttavuudelle. Ja itse DBA: t ovat ylityöllistettyjä ja heillä on joskus vastuu ympäri vuorokauden, he saavat yhä enemmän tietokantoja. Mielestäni sillä on vähän tekemistä sen kanssa, että ihmiset eivät ymmärrä aivan mitä he tekevät tai miten he tekevät sen. Heidän oma pieni ryhmänsä ja ihmiset jatkavat ajatteluaan: "No kaikki nämä työkalut ovat aivan niin helppokäyttöisiä, että voimme vain jatkaa yhä useamman tietokannan käyttämistä heidän työmäärään", mitä niin ei ole.
Mikä johtaa meidät osa-aikaisiin ja vahingossa tapahtuviin DBA: iin. Meillä on pieniä tietotekniikkatiimejä, joilla ei ole välttämättä varaa omaan DBA: han. Nyt se pitää paikkansa pienissä ja keskisuurissa yrityksissä, joissa tietokantojen ja tietokantasovellusten laajennus on räjähtää viimeisen vuosikymmenen aikana ja kasvaa edelleen. Mutta se koskee myös suuria yrityksiä, jotka ovat tyypillisesti suorittaneet tietovarastojen analysointia, liiketoiminnan älykkyyden analysointia jo kauan, pitkään. Kauan sitten olemme hankkineet omistettuja DBA-hankkeita näihin hankkeisiin; emme koskaan saa enää erillistä DBA: ta. Oli vastuussa tietokannan suunnittelusta, mikä on hienoa, jos sen joku jolla on kokemusta.Mutta yleensä, DBA: t ovat sovelluskehittäjiä, he ottavat tämän roolin usein osa-aikaisena osana työtä, heillä ei ole siinä muodollista koulutusta ja suunnitellaan sitä lopputavoitteilleen, eivätkä suunnitella sitä tehokkuuden parantamiseksi.
Ja suunnittelun ja kehityksen välillä on paljon eroja verrattuna käyttöönottoon ja hallintaan. Joten, meillä on ”penniäkään viisas, punta typerää” pienellä säästöpankilla, hyppäämättä hankkeessa tarvittavien taitojen ja resurssien hankkimiseen. Luulen, että kaikki ovat peräisin "Nerden kosto" -kappaleestani. Nyt, sikäli kuin mitä ihmiset tarvitsevat, niin meillä on laajempi tietokantojen ja tietojen käyttö SQL: ssä. Meillä on rajoittava määrä DBA: ita - ihmisiä, jotka ovat taitavia ja asiantuntevia näissä viritys- ja suunnittelu- sekä hallinta- ja käyttöönotto-tilanteissa. Ja meillä on yhä enemmän osa-aikaisia tai vahingossa tapahtuvia DBA-tutkijoita, ihmisiä, joilla ei ole ollut muodollista koulutusta.
Joten, mitkä ovat jotkut muut asiat, jotka ovat myös tulossa kysymykseen siitä, että näitä tietokantoja ei myöskään viritetä tai hallinnoida? Ensinnäkin, monet ihmiset olettavat, että tietokantajärjestelmällä itsellään on tarpeeksi työkaluja hallitakseen itseään. Nyt työkalut ovat entistä helpompaa ja helpompaa tehdä - suunnittelu ja kehittäminen -, mutta se on erilaista kuin hyvä suunnittelu, hyvä hallinta, kapasiteetin suunnittelu, seuranta jne. Käyttöönottoa varten. Joten ensin ihmiset olettavat, että heillä on kaikki tarvitsemansa työkalut. Toiseksi, jos olet osa-aikainen tai vahingossa DBA, et tiedä mitä et tiedä.
Luulen unohtanut osan lauseista siellä, niin että monta kertaa he vain eivät ymmärrä, mitä heidän on edes tarkasteltava suunnittelussa tai kun he hallitsevat tai käyttävät tietokantoja. Jos se ei ole ammattisi, et aio ymmärtää mitä sinun täytyy tehdä. Kolmas kohta on se, että SQL on go-to-tool, joten Robin puhui SQL: stä ja siitä, kuinka huonosti SQL on joskus rakennettu tai usein rakennettu. Ja myös yksi lemmikistäni, joka piilee BI-tietojen varastoinnissa, tiedonsiirrossa ja tietotekniikan tilassa, on, että työkalujen käytön sijasta ihmisillä on taipumus kirjoittaa SQL-koodia, tallennettuja menettelyjä, vaikka he käyttäisivätkin kallista tietojen integrointityökalua tai kallista BI-työkalu, he usein käyttävät sitä vain tallennettujen menettelyjen suorittamiseen. Joten tietokannan suunnittelun ymmärtämisen ja SQL: n rakentamisen merkitys on entistä tärkeämpi.
Ja lopuksi on tämä siilomenetelmä, jossa meillä on yksittäisiä ihmisiä tarkastelemaan yksittäisiä tietokantoja. He eivät katso miten sovellukset toimivat ja ovat vuorovaikutuksessa keskenään. Ja he myös todella etsivät tietokantoja verrattuna sovelluksiin, joissa he käyttävät niitä. Joten tietokantaan saamasi työmäärä on kriittinen suunnittelussa, kriittinen sen virittämisessä, kriittinen yritettäessä selvittää, kuinka suunnitella kapasiteettia jne. Joten katsomalla metsää puista, ihmiset ovat rikkaruohoissa , tarkastelemalla yksittäisiä taulukoita ja tietokantoja eikä tarkastelemalla näiden sovellusten yleistä vuorovaikutusta työkuormassa.
Viimeinkin ihmisten on tarkasteltava avainalueita, joita heidän on tarkasteltava. Kun he suunnittelevat tietokantojen hallintaa, heidän on ensin mietittävä, kehitettävä sovelluskeskeisiä suorituskykymittareita, joten heidän on tarkasteltava sen lisäksi, kuinka tämä taulukko on rakennettu, kuinka se on erityisesti mallinnettu, mutta miten sitä käytetään? Joten jos sinulla on yrityssovelluksia, jotka johtuvat toimitusketjun hallinnasta, jos otat tilauksia verkosta, jos käytät BI: tä - mitä tahansa teetkin, sinun on tarkasteltava ketä käyttävät sitä, kuinka he käyttävät sitä, mitkä tietomäärät ovat , kun se tapahtuu. Mitä todella yrität etsiä, on odotusajat, koska ei väliä mitä, kaikki sovellukset arvioidaan sen perusteella, kuinka kauan jonkin tekeminen kestää, onko kyseessä henkilö vai vain tietojen vaihto sovellusten tai prosessorien välillä. Ja mitkä ovat pullonkaulat? Niin usein, kun yrität korjata ongelmia, tietysti yrität todellakin katsoa, mitkä ovat todelliset pullonkaulat - ei välttämättä kuinka kaikkea virittää, mutta kuinka päästä eroon ja siirtää esitystä odotusaikoihin ja suorituskykyyn - riippumatta sinun täytyy katsoa.
Ja sinun on todellakin erotettava tiedonkeruu, tapahtumat, tietokannan muunnosnäkökohdat analytiikan ohella. Jokaisella niistä on erilaiset suunnittelumallit, jokaisella on erilaiset käyttötavat ja jokainen niistä on viritettävä eri tavalla. Joten sinun on mietittävä, kuinka näitä tietoja käytetään, milloin niitä käytetään, mihin niitä käytetään, ja selvitettävä, mitä suorituskykymittareita ja mitkä ovat avainasiat, joita haluat analysoida kyseiseen käyttöön. Nyt kun tarkastellaan suorituskykyä, haluat tarkastella itse tietokantatoimintoja; haluat tarkastella molempia tietorakenteita, joten indeksit, osiointi ja muut tietokannan fyysiset näkökohdat, jopa tietokannan rakenne - olipa sen ER-malli vai mittamalli, rakenteellisesta riippumatta - kaikki nämä asiat vaikuttavat suorituskykyyn , etenkin tiedonkeruuanalyysin erilaisissa miinuksissa ja tapahtuvissa muunnoksissa.
Ja kuten Robin mainitsi SQL-puolella, tarkastelemalla SQL-asioita, joita nämä eri sovellukset ajavat näiden tietokantojen välillä, ja sen virittäminen on kriittistä. Ja tarkastellaan sovellusten yleistä työmäärää ja infrastruktuuriympäristöä, jota nämä tietokannat ja sovellukset käyttävät. Joten, että verkot, palvelimet, pilvi - riippumatta siitä, mihin he käyvät - tarkastelevat myös näiden sovellusten ja näiden tietokantojen vaikutusta siinä yhteydessä, kaikilla näillä on vuorovaikutuksessa kyky virittää tietokanta.
Ja lopuksi, kun tarkastelet työkaluja, haluat pystyä tarkastelemaan kolmea erilaista analytiikkaa, jotka liittyvät siihen. Haluat tarkastella kuvaavaa analyysiä: mitä tapahtuu ja missä, tietokantaan ja sovelluksen suorituskykyyn liittyen. Haluat kykyä tehdä diagnostista analysointia selvittääksesi paitsi mitä tapahtuu, myös miksi se tapahtuu, missä ovat pullonkaulat, missä ovat ongelmat, mikä toimii hyvin, mikä ei suju? Mutta kyky analysoida ja pohtia ongelma-alueita käsitelläkseen niitä joko suunnittelun tai minkä tahansa sinun täytyy tehdä.
Ja lopuksi, aggressiivisin tai ennakoivin analyysityyppi on tosiasiallisesti tehdä ennustava analyysi, ennustava analyyttinen mallinnus, mitä tahansa. Tiedämme, että tietokanta ja sovellukset toimivat tässä yhteydessä, jos lisäämme kapasiteettia, jos saamme enemmän käyttäjiä, jos teemme enemmän läpäisykykyä, mitä tahansa teemmekin, pystymme suunnittelemaan mitä, miten ja mihin se vaikuttaa tietokantaan, sovellusten avulla voimme suunnitella ja selvittää ennakoivasti, missä pullonkaulat ovat, missä odotusajat voivat kärsiä ja mitä meidän on tehtävä asioiden korjaamiseksi. Joten haluamme, että meillä on työkaluja, jotka pystyvät toteuttamaan suorituskykymittarit, seuraamaan suorituskykyä, kuten samoin kuin nämä kolme analyysityyppiä. Ja se on minun yleiskuvani.
Eric Kavanagh: Hyvä on, annan minun jakaa sen - muuten nämä ovat kahta hienoa esitystä - annan sen Bullett Manalelle viedäkseni sieltä. Ja ihmiset, älä unohda kysyä hyviä kysymyksiä; meillä on jo hyvää sisältöä jo. Ota se pois, Bullett.
Bullett Manale: Kuulostaa hyvältä. Kiitos, Eric. Joten, paljon mitä Rick ja Robin sanoivat, olen selvästi samaa mieltä 100 prosentilla. Sanoisin, että vedin tämän liukukannan ylös, koska uskon sen sopivan, en tiedä niille teistä, jotka olemme A-Team-faneja 80-luvulla, John Hannibal Smithillä oli sanonta, jonka he sanoivat aina: “Rakastan se kun suunnitelma tulee yhdessä ”, ja luulen, että kun puhut erityisesti SQL Serveristä, johon keskityttiin, mikä on tuote, josta tänään puhutaan, SQL Diagnostic Manager, se on ehdottomasti yksi niistä asioista, jotka sinulla täytyy olla; sinun on kyettävä hyödyntämään olemassa olevia tietojasi ja pystyttävä tekemään päätöksiä niistä, ja joissain tapauksissa et halua päätöstä; etsit jotain kertoaksesi sinulle, kun joku resursseja loppuu, kun resursseja loppuu, kun pullonkaulalla on sellaisia asioita.
Se ei koske vain tietyn mittarin seuraamista. Joten Diagnostic Manager -sovelluksen kanssa yksi asioista, jotka se menee erittäin hyvin, on auttaa sinua ennustamisessa ja ymmärryksessä erityisesti työmäärille ja aiottiin puhua tästä paljon tänään. Työkalu on suunnattu tiedonhallinnalle, DBA: lle tai toimivalle DBA: lle, joten monet asioista, joista Rick mainitsi, toimiva DBA on niin totta. Monissa tapauksissa, ellet ole DBA, on olemassa paljon kysymysmerkkejä, jotka sinulla tulee olemaan, kun on aika hallita SQL-ympäristöä, asioita, joita et tiedä. Ja niin etsit jotain, joka auttaa sinua, vie sinut läpi prosessin ja kouluttaa sinut myös prosessissa. Ja niin, on tärkeätä, että työkalu, jota käytät sellaisiin päätöksiin, antaa sinulle jonkinlaisen käsityksen syistä, miksi kyseisiä päätöksiä tehdään, eikä vain sanoa sinulle: "Hei, tee tämä."
Koska olen toimiva DBA, voin lopulta olla täysimittainen DBA, jolla on todellista asiantuntemusta ja tietoa tämän tittelin tueksi. Joten sanoin, kun puhut tietokannan ylläpitäjänä olemisesta - näytän aina sellaisen ensin, koska DBA: lla on joitain erilaisia rooleja ja riippuen organisaatiostasi, jolla olet, aiot olla, ne vaihtelevat paikasta toiseen - mutta tyypillisesti olet aina jollain tavalla vastuussa tallennuksesta, kyseisen tallennuksen suunnittelusta ja ymmärryksestä ennakoida, minun pitäisi sanoa, kuinka paljon tilaa tarvitset, onko se varmuuskopioillesi tai onko se itse tietokantoihin. Sinun on ymmärrettävä ja arvioitava se.
Lisäksi sinun on kyettävä ymmärtämään ja optimoimaan asiat tarpeen mukaan, ja kun käydään läpi ympäristön seurannan, on selvästi tärkeää, että teet muutoksia tarvittaessa ympäristön muuttuvien asioiden perusteella. itse. Joten asiat, kuten käyttäjien lukumäärä, esimerkiksi sovellusten suosio, tietokannan kausivaihtelut, tulisi kaikki ottaa huomioon ennustettaessa. Ja sitten tarkastellaan selvästi muita asioita siinä suhteessa, että pystymme toimittamaan raportit ja tarvittavat tiedot, koska ne liittyvät näiden päätösten tekemiseen. Monissa tapauksissa se tarkoittaa vertailevan analyysin tekemistä; se tarkoittaa kykyä tarkastella erityisesti tiettyä mittaria ja ymmärtää, millainen mittarin arvo on ajan mittaan ollut, jotta voit ennakoida, mihin se menee eteenpäin.
Joten sillä, jolla paljon diagnostiikkahallintatyökalulla on, on nämä ominaisuudet ja ihmiset käyttävät sitä päivittäin voidakseen tehdä esimerkiksi ennustamista, ja Ive on antanut tälle kapasiteettisuunnitelman määritelmän. Ja se on melko laaja ja tosiasiallisesti melko epämääräinen määritelmä, joka on vain prosessi, jolla määritetään tuotantokapasiteetti, jota organisaatio tarvitsee vastaamaan muuttuviin vaatimuksiin tuotteilleen, ja päivän päätteeksi on totta, mistä on kyse: Sen siitä, että pystyt ottamaan jollain tavalla tai toisella sinulla olevia tietoja ja ottamaan tietoja ja tekemään päätöksiä, joiden avulla voit siirtyä eteenpäin tietokantojen elinkaaren aikana. Joten asiat, jotka ovat syitä siihen, miksi ihmisten on tehtävä tämä, ovat tietysti ensisijaisesti ja useimmissa tapauksissa rahaa säästäviä. Yritysten tietysti päätavoite on ansaita rahaa ja säästää rahaa. Mutta samalla prosessissa tämä tarkoittaa myös kykyä varmistaa, että seisokkejasi ei ole. Ja kyky varmistaa, että vähennät mahdollisia seisokkien esiintymismahdollisuuksia, joten pidät sen tapahtumasta aluksi toisin sanoen, etten odota sen tapahtuvan ja reagoit sitten siihen.
Sen lisäksi, että pystyt yleisesti parantamaan käyttäjien tuottavuutta, tehostamalla niitä tehokkaammiksi, jotta voit tehdä enemmän liiketoimintaa, on selvästi avain tässä, joten nämä ovat tyyppisiä asioita, joita DBA tai joku ennustamiseen tai kapasiteettiin osallistuva Suunnittelussa on kyettävä kuljettamaan tietoja voidakseen tehdä näitä päätöksiä. Ja sitten kaiken kaikkiaan tämä auttaa tietysti poistamaan jätteet, ei vain jätteiden rahan määrän, mutta myös ajan ja vain yleensä resurssien suhteen, joita voidaan mahdollisesti käyttää muihin asioihin. Joten pystymme poistamaan jätteet siten, että sinulla ei ole vaihtoehtoisia kustannuksia, jotka ovat sidoksissa itse jätteeseen.
Joten, mitä sanottuna, minkä tyyppiset kysymykset saamme, jotka koskevat henkilöä, joka on DBA? Milloin tila loppuu? Se on iso, paitsi kuinka paljon tilaa nyt kulutan, mutta milloin loppuukin, trendien ja menneisyyden perusteella? Sama asia todellisten SQL-esiintymien, tietokantojen kanssa, mitä palvelimia voin yhdistää? Aion laittaa joitain virtuaalikoneisiin, mikä on järkevää mitkä tietokannat konsolidoida ja millä SQL-tapauksilla niiden pitäisi sijaita? Kaikentyyppisiin kysymyksiin on pystyttävä vastaamaan. Koska useimmissa tapauksissa, jos olet DBA tai toimi DBA, aiot vakiinnuttaa sen joskus urallasi. Monissa tapauksissa aiot tehdä niin jatkuvasti. Joten sinun on kyettävä tekemään nämä päätökset nopeasti, älä pelaa arvaamispelejä, kun kyse on siitä.
Puhuimme pullonkauloista ja siitä, missä niitä seuraavaksi tapahtuu, pystyen ennakoimaan sen jälleen kerran sen sijaan, että odottaisimme niiden toteutumista. Joten selvästi kaikista näistä asioista puhuttiin, järkevää siinä mielessä, että luotat historiallisiin tietoihin useimmissa tapauksissa pystyäkseen tuottamaan näitä suosituksia tai joissain tapauksissa pystymään itse laatimaan päätöksiä, jotta pystyt keksiä nämä vastaukset. Mutta se muistuttaa minua siitä, että kun kuulet radiomainoksia jollekin arvopapereita myyvälle henkilölle tai vastaavalle, sen aina ”aikaisempi suoritus ei ole osoitus tulevista tuloksista” ja sellaisia asioita. Ja sama asia pätee täällä. Sinulla on tilanteita, joissa nämä ennusteet ja nämä analyysit eivät välttämättä ole oikein oikeita. Mutta jos käsittelet asioita, jotka ovat tapahtuneet aiemmin ja tiedossa, ja pystyt ottamaan ja tekemään "entä jos" monilla tämän tyyppisillä kysymyksillä, joudut törmäämään, se on erittäin arvokas ja se aikoo pääset paljon kauemmas kuin arvaamispelin pelaaminen.
Joten tämäntyyppiset kysymykset ilmeisesti nousevat esiin, joten kuinka käsittelemme paljon näitä kysymyksiä Diagnostic Manager -sovelluksen kanssa, ensinnäkin meillä on ennustusominaisuudet, kykymme tehdä tämä tietokannassa, pöydässä sekä asema tai äänenvoimakkuus. Voin paitsi sanoa “Hei, olit täynnä tilaa”, mutta kuuden kuukauden kuluttua, kaksi vuotta nyt, viisi vuotta nyt, jos budjetoin sitä, kuinka paljon ajotilaa tarvitsen budjetoida varten? Nämä ovat kysymyksiä, jotka minun on pakko kysyä, ja minun on kyettävä käyttämään jotakin menetelmää sen tekemiseen sen sijaan, että arvata ja laittaa sormeni ilmaan ja odottaa nähdäkseni millä tavalla tuuli puhaltaa, mikä on paljon valitettavasti tapa, jolla paljon näitä päätöksiä tehdään.
Lisäksi kyky - näyttää siltä, että diani leikattiin sieltä hiukan - mutta pystyä tarjoamaan apua suositusten muodossa. Joten, yksi asia on näyttää sinulle kojelauta, joka on täynnä mittareita, ja osata sanoa: "OK, kaikki mittarit ovat täällä ja missä ne ovat", mutta sitten pystyä tekemään joitain tai ymmärtämään mitä tee, perustuen siitä on uusi harppaus. Ja joissain tapauksissa ihmiset ovat riittävän koulutettuja DBA: n rooliin voidakseen tehdä näitä päätöksiä. Joten meillä on työkalussa joitain mekanismeja, jotka auttavat siinä, jotka osoittavat sinulle hyvin vain sekunnissa. Mutta pystymme osoittamaan paitsi mitä suositus on, myös tarjoamaan jonkinlaisen käsityksen miksi suositus tehdään ja sitten myös päälle, että joissain tapauksissa pystytään todella keksimään skripti, joka automatisoi suosituksen. myös tämän asian korjaaminen on ihanteellista.
Siirtyminen seuraavaan täällä, joka näkee hyvin, sen vain yleisesti ottaen ymmärtäminen metritasolle on normaalia. En voi kertoa teille, mikä ei ole normaalia, jos en tiedä mikä on normaalia. Joten, jollain tapaa mitata tämä on avainta, ja sinun on kyettävä ottamaan huomioon monentyyppiset alueet, esimerkiksi - tai minun pitäisi sanoa aikarajat - palvelinryhmät, jotka pystyvät tekemään tämän dynaamisesti, hälytysperspektiivi, toisin sanoen keskellä yötä, huoltoikkunani aikana, odotan suorittimeni olevan käynnissä 80 prosentilla kaikkien ylläpitävien thats-tekojen perusteella. Joten haluaisin nostaa kynnysarvojani korkeammiksi noina aikoina verrattuna ehkä ehkä keskellä päivää, kun minulla ei ole yhtä paljon aktiivisuutta.
Nämä ovat joitain asioita, jotka ovat luonnollisesti ympäristöystävällisiä, mutta asioita, joita voit käyttää hallittavissa olevissa asioissa, jotta pystyt auttamaan sinua ympäristönsä tehokkaammassa hallinnassa ja helpottamaan sen tekemistä. Toinen alue on tietysti kyky tarjota vain raportteja ja tietoja voidakseen vastata tyyppisiin "mitä jos" -kysymyksiin. Jos Ive vain muutti ympäristöäni, haluan ymmärtää, mikä tämä vaikutus on ollut, jotta voin soveltaa samaa muutosta muihin ilmentymiin tai muihin tietokantoihin ympäristössäni. Haluan pystyä saamaan tietoja tai ammuksia, jotta voin tehdä muutoksen jollain mielenraudalla ja tietäen, että se tulee olemaan hyvä muutos. Joten pystyn tekemään tämän vertailevan raportoinnin, pystymme luokittelemaan SQL-tapauksiani, pystymme luokittelemaan tietokannani toisiaan vastaan sanomaan: ”Mikä on suurin CPU-kuluttajani?” Tai kumpi kestää eniten odotusten ja vastaavien asioiden suhteen? Joten paljon tästä tiedosta tulee olemaan saatavana myös työkalun kanssa.
Ja sitten viimeisenä, mutta ei vähäisimpänä, on vain yleinen kyky, että tarvitset työkalun, joka pystyy käsittelemään mitä tahansa tilanteesi tapaa, ja niin tarkoitan tällä sitä, että jos sinulla on suuri ympäristö, jossa on paljon Esimerkiksi, joudut todennäköisesti joutumaan tilanteisiin, joissa joudut vetämään sellaisia mittareita, jotka perinteisesti eivät ole mittareita, joita DBA haluaa jopa valvoa joissakin tapauksissa kyseisestä tilanteesta riippuen. Joten sinulla on työkalu, jonka voit, joka on laajennettavissa, voidaksesi lisätä ylimääräisiä mittareita ja voidaksesi käyttää näitä mittarit samassa muodossa ja tavalla, jota käyttäisit niitä, jos käyttäisit laatikkoa esimerkiksi metrinen. Joten kyky suorittaa raportteja, kyky hälyttää, lähtötilanne - kaikista asioista, joista puhuttiin - on myös tärkeä osa kykyä tehdä tämä ennustaminen ja tehdä siitä niin, että saat vastauksia, joita etsit voidaksesi tehdä nuo päätökset, eteenpäin.
Nyt tapa, jolla Diagnostic Manager tekee tämän, meillä on keskitetty palvelu, palveluryhmä, joka suorittaa, keräämään tietoja 2000 - 2016 esiintymistä vastaan. Ja sitten teemme sen, että otamme kyseiset tiedot ja laitamme ne keskitettyyn arkistoon, ja mitä sitten tietenkin tehdään sillä tiedolla, että teemme paljon, jotta pystymme tarjoamaan lisätietoja. Nyt tämän lisäksi - ja yksi niistä asioista, joita ei ole täällä - onko meillä myös palvelu, joka toimii keskellä yötä, joka on ennustava analyysipalvelumme ja joka jonkin verran romahtii ja auttaa ymmärtämään ja auttavat sinua DBA: na tai toimivana DBA: na, jotta pystyt antamaan tämäntyyppisiä suosituksia, pystymään tarjoamaan myös jonkinlaisen käsityksen perusviivoista.
Joten mitä haluaisin tehdä, ja tämä on vain nopea esimerkki arkkitehtuurista, täällä tapahtuva iso vieroitus ei ole mikään agentti tai palvelu, joka todella istuu hallinnoimissasi tapauksissa. Mutta haluaisin vain viedä sinut täällä olevaan sovellukseen ja antaa sinulle nopean esittelyn. Ja anna minun vain mennä ulos, ja saada se tapahtumaan. Joten kerro minulle, luulen Eric, voitko nähdä sen kunnossa?
Eric Kavanagh: Sain sen nyt.
Bullett Manale: OK, joten aion viedä sinut läpi joitain näistä eri osista, joista puhun. Ja pohjimmiltaan antaa alkaa sellaisista asioista, jotka ovat enemmän samankaltaisia kuin harhaoppi, jotain mitä sinun täytyy tehdä, tai tässä on jotain, joka on tulevaisuuden tulevaisuus ja aikoi antaa sinulle jonkinlaisen käsityksen siitä. Ja tämä kykenee todella ennakoimaan - tai minun pitäisi sanoa, dynaamisesti ennakoida - asioita niin kuin tapahtuu. Nyt raporttien tapauksessa yksi työkalussa olevista asioista on kolme erilaista ennusteraporttia. Ja esimerkiksi tietokannan ennusteen tapauksessa, mitä tekisin todennäköisesti tilanteessa, jossa voin ennakoida tietokannan koon tietyn ajanjakson ajan, ja minä vain annan teille pari esimerkkiä siitä. Joten aion ottaa tarkastustietokantani, joka on melko I / O-intensiivistä - se sai siihen paljon tietoa. Olemme saaneet, näkevät, tekevät hyvin tämän täällä, ja voimme vain valita terveystietokannan täältä.
Mutta asia on, että en vain näe, mitä tilaa tällä on, voin sanoa: "Katso, voidaan ottaa viimeisten vuosien arvoinen data" - ja aion kuunnella täällä vähän, minulla ei oikeastaan ole vuotta Tietojen arvoinen, minulla on noin kahden kuukauden arvoinen tieto - mutta koska valitsen tässä kuukausien otosnopeuden, pystyn ennakoimaan tai ennustamaan tässä tapauksessa seuraavat 36 yksikköä, koska näytteenottosuhteemme on asetettu kuukausille - Se on yksikkö, on kuukausi - ja sitten pystyisin sitten laatimaan raportin, joka näyttää pohjimmiltaan minulle, missä ennakoisimme tulevaa kasvuamme näiden kolmen tietokannan osalta. Ja voimme nähdä, että meillä on erilainen ero tai variaatio kolmen eri tietokannan välillä, etenkin niiden historiallisesti kuluttaman tiedon määrän suhteen.
Voimme nähdä, että täällä olevat datapisteet edustavat historiallista tietoa, ja sitten rivit, jotka toimittavat meille ennusteen, sekä numerot, jotka varmuuskopioivat tämän. Joten voimme tehdä sen pöyttasolla, voimme tehdä sen jopa asematasolla, missä voin ennakoida, kuinka suuria minun asemat saavat, mukaan lukien kiinnityspisteet. Pystymme ennustamaan samantyyppisiä tietoja ulos, mutta jälleen kerran, otostaajuudesta riippuen, voin määrittää, kuinka monta yksikköä ja mistä ottivat sen, mitä haluamme ennustaa. Huomaa myös, että meillä on erityyppisiä ennustetyyppejä. Joten saat paljon vaihtoehtoja ja joustavuutta, kun on aika ennustaa. Nyt, yksi asia on hyvin, sillä annamme sinulle tietyn päivämäärän ja voimme sanoa “Hei tänä päivänä, tässä voimme ennakoida sinun tietosi kasvavan.” Tämän lisäksi voimme tarjota sinulle myös muilla oivalluksilla, jotka liittyvät osaan analyysiä, jonka teemme ulkopuolella ja palveluun, kun se suoritetaan. Jotkut asiat, joita se tekee, on yrittää ennakoida asiat, jotka todennäköisesti tapahtuvat, perustuen historiaan, jolloin asiat tapahtuivat menneisyydessä.
Joten voimme nähdä täällä, tosiasiassa, ennuste antaa meille jonkinlaisen kuvan siitä todennäköisyydestä, että meillä on ongelmia koko illan ajan sellaisten asioiden perusteella, jotka ovat jälleen tapahtuneet aiemmin. Joten selvästi tämä on hienoa, varsinkin jos en ole DBA, voin tarkastella näitä asioita, mutta mikä vielä parempaa, jos en ole DBA, tämä on analyysivälilehti. Joten ennen kuin tämä oli täällä työkalussa, käyisimme läpi ja näyttäisimme tuotetta ihmisille ja he olisivat "Että hienoa, näen kaikki nämä numerot, näen kaiken, mutta en tiedä mitä tehdä" (nauraa) " sen seurauksena. ”Ja niin mitä meillä täällä on, on parempi tapa ymmärtää, jos aion ryhtyä toimiin suorituskyvyn parantamiseksi, jos aion ryhtyä toimiin jopa auttaakseni minun terveyteni Ympäristö, mahdollisuus saada arvostettu tapa antaa näitä suosituksia sekä hyödyllisiä vinkkejä informaation saamiseksi lisätietoja suosituksista ja joilla on jopa ulkoiset linkit joihinkin tietoihin, mikä näyttää minulle ja vie minut syihin, miksi nämä suositukset on annettu.
Ja monissa tapauksissa kyky tarjota komentosarja, joka automatisoi, kuten sanoin, näiden ongelmien korjaamisen. Nyt osa siitä, mitä täällä tehtiin tämän analyysin kanssa - ja minä näytän sinulle, kun menen konfiguroimaan tämän ilmentymän ominaisuuksia ja menen analyysin kokoonpano-osioon - meillä on paljon erilaisia luokkia, jotka on lueteltu tässä, ja osa siitä, meillä on hakemiston optimointi ja kyselyjen optimointi. Joten, arvioimme paitsi mittarit itse, ja niin, mutta myös asioita, kuten työmäärät ja hakemistot. Tässä tapauksessa tehkää todellakin joitain lisähypoteettisiä hakemistoanalyysejä. Joten, se on yksi niistä tilanteista, joissa en halua monissa tapauksissa en halua lisätä hakemistoa, jos minun ei tarvitse. Mutta jossain vaiheessa kyseessä on tippauskohta, jossa sanon: ”No, taulukko on tulossa koon tai tyyppisten kyselyiden kanssa, jotka ovat käynnissä työmäärän sisällä, on nyt järkevää lisätä hakemisto. Mutta se ei olisi ollut järkevää ehkä kuusi viikkoa ennen. ”Joten tämä antaa sinulle mahdollisuuden saada dynaamisesti näkemyksen asioista, jotka todennäköisesti, kuten sanoin, parantavat suorituskykyä ympäristössä tapahtuvan, työkuormituksen sisällä tapahtuvan ja tehdä sellaisia asioita.
Ja niin saat täältä paljon hyvää tietoa sekä mahdollisuuden optimoida nämä asiat automaattisesti. Joten, tämä on toinen alue, jolla voisimme auttaa, mitä me kutsumme ennustavaan analyysiin. Nyt, minun on sanottava, että meillä on myös muita aloja, joiden mielestäni yleensä vain autat sinua tekemään päätöksiä. Ja kun puhumme päätöksenteosta, pystymme jälleen kerran tarkastelemaan historiallisia tietoja, tarjoamaan jonkinlaisen käsityksen päästäksemme sinne, missä meidän on oltava parantamassa sitä suorituskykyä.
Nyt yksi niistä asioista, jotka voimme tehdä, on, että meillä on lähtötason visualisoija, jonka avulla voimme valikoivasti valita minkä tahansa metrin haluaisimme - ja annan minun löytää täältä kunnollisen - aion siirtyä SQL-prosessorin käyttöön, mutta asia on, että voit mennä takaisin useiden viikkojen aikana, kun haluat maalata näitä kuvia, jotta voit nähdä, milloin poikkeavasi ovat, nähdä yleisesti ottaen, missä tämä arvo kuuluu ajanjaksoihin, jolloin olemme keränneet tietoja. Ja sitten, tulet myös huomaamaan, että kun menemme itse varsinaiseen instanssiin, meillä on kyky määrittää perusviivat. Ja perusviivat ovat todella tärkeä osa sitä, että pystymme automatisoimaan asiat ja samaan tapaan saada ilmoituksen asioista. Ja haaste, kuten useimmat DBA: t sanoisivat sinulle, on, että ympäristösi ei aina toimi samalla tavalla koko päivän ajan, iltaan verrattuna ja mitä ei, kuten aiemmin mainitsimme esimerkissä ylläpitoaikojen aikana, kun on korkea suorittimen taso tai mikä tahansa mitä voi tapahtua.
Joten tässä tapauksessa näillä todellisilla perusviivoilla voi olla useita perusviivoja, joten minulla saattaa olla perustiedot esimerkiksi thats huoltoaikani aikana. Mutta pystyin yhtä helposti luomaan lähtökohdan tuotantotunneilleni. Ja asia on tehdä, kun siirrymme SQL-ilmentymään ja meillä on tosiasiallisesti nämä useita perusviivoja, niin voimme ennakoida ja pystyä suorittamaan jonkin tyyppisiä automatisointeja, jonkin tyyppisiä korjauksia tai vain varoittamaan yleensä, eri tavoin niille ajanjaksoille. Joten yksi näistä asioista, jotka näet täällä, ovat nämä luomamme perusviivat, jotka käyttävät historiallista tietoa tarjoamaan analyysi, mutta mikä tärkeintä, voin muuttaa näitä kynnysarvoja staattisesti, mutta voin automatisoida myös nämä dynaamisesti. Joten kun ylläpitoikkuna tai minun pitäisi sanoa, että ylläpidon perustasoikkuna tulee esiin, nämä kynnysarvot vaihtuvat automaattisesti tiettyihin kuormiin, joita kohtaan kyseisen ajanjakson aikana, ehkäpä keskellä päivää, kun kuormani eivät ole Paljon, kun työmäärät eivät ole yhtä vaikuttavia.
Joten, jotain muuta pitää mielessä lähtötason suhteen. Nämä ovat tietenkin todella hyödyllisiä sinulle, kun ymmärrät myös mikä on normaalia ja että pystyt myös ymmärtämään, sitoutumaan, kun aiot myös loppua resursseista. Nyt toinen väline, joka meillä on työkalussa, auttaa sinua tekemään päätöksiä, lisäksi perustiedot ja pystymään asettamaan hälytyksiä noiden perusviivojen ja dynaamisesti luomiesi kynnysten ympärille, kuten aiemmin sanoin, pystyyn vain lukemaan lukemattoman määrän raportteja, jotka auttavat minua vastaamaan kysymyksiin meneillään olevasta.
Joten esimerkiksi, jos minulla olisi 150 tapausta, joita hallitsen - tapauksessani minulla ei ole, joten meidän on pelattava teeskentelypeliä - mutta jos minulla olisi kaikki tuotanto-esiintymät ja minun piti ymmärtää missä olen alue Tarvitsen huomion toisin sanoen, jos minulla on vain rajoitetusti aikaa suorittaa jonkin tyyppistä hallintoa suorituskyvyn parantamiseksi, haluan keskittyä avainalueisiin. Ja niin, sanotun perusteella voin sanoa: ”Järjestä kyseisen ympäristön perusteella esiintymät toisiaan vastaan ja antaa minulle kyseinen sijoitus kilpailuputken kautta.” Joten onko levyn käyttö, muistin käyttö, odottaako se, Pystynkö vastausaikaan vastaamaan - tai minun pitäisi sanoa ristiriita - näitä tapauksia toisiinsa nähden. Ilmeisesti tapaus on kunkin luettelon yläosassa, jos se on sama esiintymä, luultavasti jotain, mihin todella haluan keskittyä, koska se ilmeisesti on jälleen luettelon kärjessä.
Joten, työkalussa on paljon raportteja, jotka auttavat sinua ympäristön luokittelussa ilmentymistasolla; Voit tehdä tämän myös tietokantatasolla, missä voin luokitella tietokannani toisiaan vastaan. Erityisesti asettamillesi kynnysarvoille ja alueille voin jopa asettaa täällä yleismerkkejä, jos haluan, keskittyä vain tiettyihin tietokantoihin, mutta asia on, että voin vertailla tietokantojani samalla tavalla. Sikäli kuin muun tyyppiset vertailevat analyysit ja tämän työkalun iso analyysi ovat, meillä on lähtökohta-analyysi. Joten jos vierität alas palvelunäkymään täällä, huomaat, että kyseessä on perustilastoraportti. Nyt tämä raportti auttaa luonnollisesti meitä ymmärtämään paitsi mittarien arvoja, myös tietyn tapauksen osalta voin mennä ulos, ja minkä tahansa näiden mittareiden kohdalla pystymme tosiasiallisesti tarkastelemaan näiden mittarien perusviivoja.
Joten mikä se voisi olla, prosenttina tai mitä tahansa voisin mennä sanomaan: "Katsotaan tämän perusviiva jaoteltu viimeisen 30 päivän aikana", jolloin se näyttää minulle todelliset arvot perustasoon nähden ja Pystyisin tietysti tekemään joitain päätöksiä käyttämällä näitä tietoja, joten tämä on yksi niistä tilanteista, joissa päätöksenteko riippuu siitä, mikä kysymys se on, jonka kysyt silloin. Mutta tämä auttaa tietysti sinua monissa kysymyksissä. Toivon, että voisin sanoa, että meillä oli yksi mietintö, joka tekee kaiken ja on sellaista kuin helppo mietintö, jossa painat ja painat ja vastaat vain kaikkiin "mitä jos" -kysymyksiin, joihin voit koskaan vastata. Mutta todellisuus on, että sinulla on paljon ominaisuuksia ja paljon vaihtoehtoja, jotta voit valita näistä pudotusvalikoista pystyäksesi muotoilemaan etsimäsi "entä jos" -tyyppiset kysymykset.
Joten suuri osa näistä raporteista on suunniteltu vastaamaan tällaisiin kysymyksiin. Ja niin, on todella tärkeää, että nämä raportit ja lisäksi kaikki asiat, jotka olemme jo osoittaneet sinulle työkalussa, kuten aiemmin mainitsin, joilla on joustavuus sisällyttää uusia mittareita, joita voidaan hallita, jopa pystyä luomaan laskurit, tai SQL-kyselyitä, jotka on sisällytetty kyselyväleihisi, jotta voin auttaa minua vastaamaan näihin kysymyksiin, että voit lisätä kyseiset asiat kentästä, jota emme odottaneet tarkkailevan. Ja pystyt sitten tekemään kaikki samat asiat, jotka juuri näyttelin sinulle: perustiedot, suorittaa raportteja ja luoda raportteja siitä mittarista, ja pystyä vastaamaan ja tekemään paljon näitä erityyppisiä asioita, joita näytän sinulle täällä.
Nyt tämän lisäksi - ja yksi asioista, joita olemme viime aikoina ilmeisesti törmänneet melko vähän - on ensin, jokainen, jokainen kääntyi tai vaihtaa virtuaalikoneisiin. Ja nyt meillä on paljon ihmisiä, jotka ovat menossa pilveen. Ja siellä on paljon kysymyksiä, joita esiintyy tällaisten asioiden ympärillä. Onko minusta järkevää siirtyä pilveen? Säästänkö rahaa siirtymällä pilveen? Kuinka paljon rahaa voin säästää, jos laitoisin nämä asiat VM: hen, jaettujen resurssien koneeseen. Tämän tyyppisiä kysymyksiä ilmeisesti tulee myös esiin. Joten, paljon näitä asioita pidetään mielessä, Diagnostic Manager -ohjelmalla voimme lisätä ja vetää sekä VMwaren että Hyper-V: n virtualisoituista ympäristöistä. Voimme myös lisätä pilvessä olevia ilmentymiä, joten ympäristömme, kuten esimerkiksi Azure DB, tai jopa RDS, voimme vetää tietoja myös näistä ympäristöistä.
Joten siellä on paljon joustavuutta ja paljon kykyä vastata niihin kysymyksiin, jotka liittyvät muihin ympäristötyyppeihin, joihin ihmiset näkevät lähtevän. Ja näiden asioiden ympärillä on vielä paljon kysymyksiä, ja kun näemme ihmisten vakiinnuttavan niitä ympäristöjä, heidän on pystyttävä vastaamaan myös näihin kysymyksiin. Joten, tämä on aika hyvä kuvaus, sanoisin, Diagnostic Managerista, koska se liittyy tähän aiheeseen. Tiedän, että liiketiedustelun aihe tuli esiin, ja meillä on myös työkalu yritystiedusteluun, josta emme tänään puhuneet, mutta se tarjoaa myös sinulle käsityksen vastata tämän tyyppisiin kysymyksiin, koska ne liittyvät kuutioisi ja myös kaikki nämä erityyppiset asiat. Mutta toivottavasti tämä on ollut hyvä yleiskatsaus, ainakin siltä osin kuin tämä tuote voi auttaa hyvän suunnitelman laatimisessa.
Eric Kavanagh: Hyvä kamaa. Joo, heittää sen Rickille, jos hän on edelleen siellä. Rick, onko sinulla kysyttävää?
Rick Sherman: Kyllä, niin ensin, tämä on hienoa, pidän siitä. Pidän etenkin laajentamisesta VM: iin ja pilviin. Näen paljon sovelluskehittäjiä ajattelevan, että jos se on pilvessä, heidän ei tarvitse virittää sitä. Niin-
Bullett Manale: Eikä, meidän on silti maksettava siitä, eikö niin? Sinun on silti maksettava kaikesta siitä, mitä ihmiset asettavat pilvelle, joten jos sen huono toiminta tai jos se aiheuttaa paljon suorittimen jaksoja, sen on maksettava enemmän rahaa, joten ei, sinun täytyy silti mitata tämä tavara, ehdottomasti.
Rick Sherman: Kyllä, olen nähnyt pilvessä paljon huonoja malleja. Halusin kysyä, käytetäänkö tätä tuotetta myös - tiedän, että mainitsit BI-tuotteen ja sinulla on tonnia muita tuotteita, jotka ovat vuorovaikutuksessa keskenään - mutta aloittaisitteko SQL-suorituskyvyn, tämän työkalun yksittäisten kyselyiden tarkastelun? Vai olisiko siihen käytetty muita työkaluja?
Bullett Manale: Ei, tämä olisi ehdottomasti. Se on yksi niistä asioista, joita en peittänyt ja tarkoitin, on kyselyjen osa siitä. Meillä on paljon erilaisia tapoja tunnistaa kyselyn suorituskyky, riippumatta siitä, liittyykö kysymys, erityisesti odotuksiin, kuten näemme tässä näkymässä, vai liittyykö kyselyjen resurssien kulutukseen kokonaisuudessaan, lukuisilla tavoilla, joilla voimme analysoida kyselyä esitys. Se onko sen kesto, CPU, I / O ja jälleen kerran, voimme myös katsoa itse työmääriä antaakseen jonkinlaisen käsityksen. Voimme antaa suosituksia analysointiosassa ja meillä on myös verkkopohjainen versio, joka tarjoaa tietoja kyselyiden ympärillä. Joten voin saada suosituksia puuttuvista indekseistä ja kyvystä tarkastella suoritussuunnitelmaa ja kaikenlaisia juttuja; se on myös kyky. Joten ehdottomasti voimme diagnosoida kyselyt seitsemällä tapaa sunnuntaihin (nauraa) ja pystyä tarjoamaan kyseisen näkemyksen teloitusten lukumäärästä, olipa kyse sitten resurssien kulutuksesta, odotuksista, kestosta ja kaikesta tästä hyvää.
Rick Sherman: Okei, hienoa. Ja mitä sitten kuormitus itse instansseihin koko tämän valvonnan avulla?
Bullett Manale: Se on hyvä kysymys. Haaste vastaamalla tähän kysymykseen on, onko se riippuvainen, aivan kuten muuallekin. Paljon mitä työkalumme tarjoaa, se tarjoaa joustavuutta ja osa siitä joustavuudesta on se, että saat kertoa sille, mitä kerätä ja mitä ei kerätä. Joten esimerkiksi itse kyselyjen kanssa minun ei tarvitse kerätä odotustietoja, tai voin. Voin kerätä tietoja kyselyihin, jotka ylittävät tietyn ajan, suorituksen. Esimerkiksi siitä, että jos menisin konfigurointipyynnön valvontaan ja sanoisin: "Muutetaan tämä arvo nollaan", todellisuus on, että työkalu kerää vain periaatteessa kaikki suoritettavat kyselyt, mikä ei todellakaan ole henki miksi se on siellä, mutta yleisesti ottaen jos haluaisin toimittaa täydellisen näytteen kaikista kyselyistä, voisin tehdä sen.
Joten, se on hyvin suhteessa siihen, mitkä asetukset ovat yleensä tyhjästä. Se on missä tahansa noin 1–3 prosenttia yläpuolella, mutta siellä ovat muutkin sovellettavat ehdot. Se riippuu myös siitä, kuinka paljon sataman kyselyitä suoritetaan ympäristössäsi, eikö niin? Se riippuu myös näiden kyselyjen keräämismenetelmästä ja siitä, mikä SQL-versio se on. Joten esimerkiksi SQL Server 2005 ei aio pystyä vetäytymään pitkittyneistä tapahtumista, kun taas niin me vetäisimme jälkeä tehdäksemme sen. Joten se olisi hiukan erilainen tapa, jolla me keräämme kyseisiä tietoja, mutta se sanoi, kuten sanoin, että olemme olleet jo noin vuoden 2004 ajan tämän tuotteen kanssa. Se on ollut jo pitkään, meillä on tuhansia asiakkaita, joten viimeinen asia, jonka haluamme tehdä, on suorituskyvyn seurantatyökalu, joka aiheuttaa suorituskykyongelmia (nauraa). Ja niin yritämme välttää siitä niin paljon kuin mahdollista, mutta yleisesti ottaen noin 1–3 prosenttia on hyvä nyrkkisääntö.
Rick Sherman: OK, ja se on melko matala, joten se on loistava.
Eric Kavanagh: Hyvä. Robin, onko sinulla kysyttävää?
Robin Bloor: Olen pahoillani, olin hiljainen. Sinulla on monen tietokannan ominaisuudet, ja olen kiinnostunut siitä, miksi voit tarkastella useita tietokantoja, ja siksi tiedät, että suurempi resurssipohja on mahdollisesti jaettu eri virtuaalikoneiden välillä ja niin edelleen ja niin edelleen. Olen kiinnostunut siitä, kuinka ihmiset todella käyttävät sitä. Olen kiinnostunut siitä, mitä asiakkaat tekevät sen kanssa. Koska se näyttää minusta, se on varmasti, kun sekaisin tietokantoja, jotain, mitä minulla ei koskaan ollut käsillä. Ja harkitsin vain koskaan yhtä tapausta millä tahansa merkityksellisellä tavalla milloin tahansa. Joten miten ihmiset käyttävät tätä?
Bullett Manale: Yleisesti ottaen puhut yleensä vain itse työkalusta? Kuinka he käyttävät sitä? Tarkoitan yleensä sitä, että ympäristöstä voi olla keskittyä. Heillä on mielenrauha ja tietävät, että jos he tuijottavat näyttöä ja näkevät vihreän, he tietävät, että kaikki on hyvää. Sen jälkeen, kun ongelmia tapahtuu, ja tietysti suurin osa tapauksista DBA-näkökulmasta, monta kertaa nämä ongelmat tapahtuvat, kun ne ovat konsolin edessä, joten heille voidaan ilmoittaa heti, kun ongelma ilmenee. Mutta lisäksi, kyky ymmärtää, milloin ongelma tapahtuu, kyetä pääsemään tiedon ytimeen, joka tarjoaa heille joitain epäselvyyksiä siitä, miksi se tapahtuu. Ja niinhän on mielestäni suurin osa: olla ennakoiva suhteessa siihen, ettei olla reagoiva.
Suurin osa DBA-asioista, joista puhun - en tiedä, että heistä on suuri prosenttiosuus - ovat valitettavasti edelleen reaktiivisessa ympäristössä; he odottavat kuluttajan lähestyvän heitä kertomaankseen heille ongelman. Ja niin, näemme, että monet ihmiset yrittävät irtautua siitä, ja mielestäni on suuri osa syystä, miksi ihmiset pitävät tästä työkalusta, että se auttaa heitä olemaan proaktiivisia, mutta tarjoaa myös heille käsityksen siitä, mitä tapahtuu , mikä ongelma, mutta monissa tapauksissa se, mitä ainakin löydämme - ja ehkä sen vain DBA: t kertovat meille tämän -, mutta DBA: t, havainto on aina heidän ongelmansa, vaikka sovelluksen kehittäjä kirjoitti hakemuksen joka ei kirjoittanut sitä oikein, he ovat niitä, jotka aikovat syyttää, aiheuttavat heidän ottavan kyseisen sovelluksen järjestelmiinsä tai palvelimiinsa ja sitten kun suorituskyky on huono, kaikki osoittavat DBA: lle sanovan: "Hei se on sinun syytäsi".
Joten tätä työkalua käytetään monta kertaa auttamaan DBA: n tapauksen sanomisessa: "Hei, tässä on ongelma, eikä siinä ole minä." (Nauraa) Meidän on parantaa tätä, olipa kyse sitten kyselyjen vaihtamisesta tai mistä tahansa. Joissain tapauksissa se putoaa heidän ämpäriinsä heidän vastuunsa suhteen, mutta ainakin välineellä, jolla pystytään auttamaan heitä ymmärtämään tämä ja tietämään se, ja tekemällä se oikea-aikaisesti, on selvästi ihanteellinen lähestymistapa.
Robin Bloor: Joo, useimmat sivustot, joihin olen perehtynyt, mutta on kulunut jonkin aikaa siitä lähtien, kun olen käynyt siellä katsellen erilaisia monen tietokannan sivustoja, mutta enimmäkseen se, mitä aikaisemmin löysin, oli, että olisi DBA: ita, jotka keskittyisivät kouralliselle tietokantoja. Ja ne olisivat tietokantoja, että jos ne koskaan menisivät alas, se olisi todellinen iso ongelma yritykselle ja niin edelleen ja niin edelleen. Ja toiset, he vain keräävät tilastot silloin tällöin nähdäkseen, että heillä ei loppunut tilaa ja he eivät koskaan katso niitä. Ja kun teit demoa, katsoin tätä ja ajattelin hyvin, tavalla tai toisella, jatkat, tarjoamalla jotain tällaista tietokantoille, joista usein kukaan ei välittänyt liikaa, koska niillä on tiedon kasvu , myös sovellusten kasvu on toisinaan. Laajennat DBA-kattavuutta melko dramaattisesti. Joten se, mistä kysymys todella kuuluu, onko se, että tämänkaltaisilla työkaluilla päädyt melko paljon antamaan DBA-palvelun jokaiselle tietokannalle, joka on yritysverkossa?
Bullett Manale: Tosiaankin, tarkoitan, haaste on, että kuten sanoit melko kaunopuheisesti, se on kuin joitain tietokantoja, joista DBA: t välittävät, ja sitten ne, joista ne eivät välitä yhtä paljon. Ja tapa, jolla tämä tietty tuote, tapa, jolla se lisensoidaan, on tapauskohtainen. Joten, luulen sinun sanovan, että on kynnys, kun ihmiset päättävät ”Hei, tämä ei ole tarpeeksi kriittinen esimerkki, että haluan hallita sitä tällä työkalulla.” Toisin sanoen, meillä on muitakin työkaluja, jotka ovat enemmän Luulen, että tarjoamme palveluja niille vähemmän tärkeille SQL-tapauksille. Yksi niistä olisi kuin inventaariopäällikkö, jossa teemme kevyitä terveystarkastuksia tapauksia vastaan, mutta sen lisäksi, että teemme löytöjä, tunnistamme uusia tapauksia, jotka on tuotu verkkoon, ja sitten siitä kohdasta, DBA: na voin sanoa: “OK, täällä on uusi SQL-esimerkki, onko se nyt Express? Onko se ilmainen versio vai onko yritysversio? ”Tämä on luultavasti kysymys, jonka haluan kysyä itseltäni, mutta toiseksi, kuinka tärkeä tämä esimerkki on minulle? Jos se ei ole niin tärkeätä, voin saada tämän työkalun menemään ulos ja tekemään sen, geneerinen, mitä kutsun yleisiksi terveystarkastukseksi siinä mielessä, että ne ovat tyypillisiä asioita, joista olen tärkeä DBA: täyttävätkö asemat? Vastaako palvelin ongelmiin? Tärkeimmät asiat, eikö niin?
Diagnostic Manager -sovelluksella työkalu, jonka juuri näyttelin sinulle, on se menemässä kyselytasolle, se menee indeksien suositukseen, tarkastelee suoritussuunnitelmaa ja kaikkea muuta hyvää, kun taas tämä keskittyy pääasiassa kuka omistaa mitä, minkä omistaan ja kuka vastaa siitä? Mitä huoltopaketteja ja pikakorjauksia minulla on? Ja toimivatko palvelimeni tärkeimpien ainesosien kanssa, joita pidän terveeksi SQL-esimerkiksi? Joten kysymykseen vastaamiseksi on vähän sekoitusta. Kun meillä on ihmisiä, jotka katsovat tätä työkalua, he katsovat yleensä kriittisempää tapausjoukkoa. Toisin sanoen, meillä on joitain ihmisiä, jotka ostavat jokaisen hallussaan olevan tapauksen ja hallitsevat sitä, joten se vain riippuu. Mutta kerron teille kaiken kaikkiaan, että heidän ihmistensä, jotka pitävät ympäristöään, on ehdottomasti kynnysarvo, jotta niillä olisi tällainen työkalu näiden tapausten hallitsemiseksi.
Robin Bloor: Okei, toinen kysymys ennen kuin annan sen Ericille. Vain teollisuuden katselusta muodostuu vaikutelma, että tietokannoilla on vielä elämä, mutta kaikki tiedot kaatavat kaikkiin näihin tietojärviin ja niin edelleen ja niin edelleen. Että hype todella on, ja hype ei koskaan kuvasta todellisuutta, joten olen kiinnostunut siitä, millainen todellisuus sinä näet siellä? Ovatko organisaation tärkeät tietokannat, kokevatko he perinteistä tiedon kasvua, jonka ajattelin käyttäneen 10 prosenttia vuodessa? Vai kasvavatko he enemmän? Onko näiden tietokantojen suurista tiedoista ilmapallo? Mikä kuva näet?
Bullett Manale: Luulen, että monissa tapauksissa tietyt tiedot siirrettiin muihin segmentteihin, joissa on järkevämpää, kun muita käytettävissä olevia tekniikoita on. Viime aikoina jotkut suuremmista datasta. Mutta nämä tietokannat, sanoisin, että on vaikeaa yleistää monissa tapauksissa, koska kaikki ovat hieman erilaisia. Yleisesti ottaen kuitenkin näen eroja. Näen, kuten sanoin, että ihmiset siirtyvät joustaviin malleihin monissa tapauksissa, koska he haluavat kasvattaa resursseja eikä niinkään muilla aloilla. Jotkut ihmiset ovat siirtymässä isoihin tietoihin. Mutta käsitystä on vaikea saada tuntemaan, koska yleensä kaikilla puhuvilla ihmisillä on perinteiset tietokannat ja he käyttävät sitä SQL Server -ympäristössä.
Toisin sanoen, sanoisin itse SQL: n suhteen, uskon ehdottomasti silti sen kasvavan markkinaosuuden. Ja mielestäni siellä on paljon ihmisiä, jotka ovat edelleen menossa SQL: n suuntaan muista paikoista, kuten Orackelta, koska se on edullisempaa ja näyttää olevan selvästi, kun SQL-versiot kehittyvät - ja näet tämän viimeisimpien asioiden kanssa, jotka ovat menossa SQL: n kanssa salaus ja kaikki muut ominaisuudet, jotka tekevät siitä ympäristön tai tietokantaalustan - mikä on tietysti erittäin operatiivisen kriittinen kyky, luulen. Joten luulen näkeväni myös tämän. Missä näet muutoksen, se tapahtuu edelleen. Tarkoitan, että se tapahtui 10 vuotta sitten, luulen, että se tapahtuu edelleen SQL Server -käytännössä, missä ympäristö kasvaa ja markkinaosuus kasvaa.
Robin Bloor: OK, Eric, oletan että yleisöllä on kysymys vai kaksi?
Eric Kavanagh: Joo, annan heittää yhden pikakortin sinulle. Se on melko hyvä kysymys. Yksi osallistujista kysyy. Voiko tämä työkalu kertoa minulle, tarvitaanko taulukko hakemistoa kyselyn nopeuttamiseksi? Jos on, voitko näyttää esimerkin?
Bullett Manale: Joo, joten en tiedä, onko minulla jotain erityistä hakemiston lisäämistä varten, mutta voit nähdä täällä, meillä on täällä pirstoutussuosituksia. Uskon vain, että meillä juuri oli ja tämä oli osa diagnostiikkahallintaa, joka tarjosi web-pohjaisen version, jossa sen mukaan minulle puuttuu hakemisto. Ja voimme tarkastella näitä suosituksia ja kerro meille siitä mahdolliset hyödyt indeksoimalla kyseiset tiedot. Toinen asia, jonka haluan vain mainita, on, että kun teemme suosituksia, monille niistä, skripti rakennetaan sitä varten. Se ei ole hyvä esimerkki, mutta voisit nähdä kyllä, tilanteet, joissa hakemisto - joko kaksoishakemisto tai indeksin lisääminen - parantaisi suorituskykyä, ja kuten aiemmin totesin, teemme paljon että hypoteettisen hakemistoanalyysin avulla. Joten se todella auttaa ymmärtämään työtaakkaa, pystyä soveltamaan sitä suositukseen.
Eric Kavanagh: Se on hienoa tavaraa, ja tämä antaa minulle hyvän segan loppukommentteihini täällä. Myös Robin ja minä ja Rick olemme kuulleet monien vuosien ajan, he puhuvat itsehienosäätävistä tietokannoista. Se on itse virittävä tietokanta! Voin kertoa sinulle vain: älä usko heihin.
Bullett Manale: Älä usko hype.
Eric Kavanagh: Jotkut pienet pienet asiat saattavat tapahtua dynaamisesti, mutta jopa kannattaa tarkistaa se ja varmistaa, että se ei tee jotain mitä et halua sen tekevän. Joten jo jonkin aikaa tarvitsin tämänkaltaisia työkaluja tietokannan tasolla tapahtuvien tapahtumien ymmärtämiseksi ja kuten Robin sanoi, tietojärvet ovat kiehtovia käsitteitä, mutta todennäköisesti niillä on yhtä suuri mahdollisuus niiden haltuunottoon kuin olemassa on. Loch Nessin hirviö milloin tahansa pian. Joten sanoisin vain jälleen, että todellisessa maailmassa on paljon tietokantatekniikkaa, tarvitsemme ihmisiä, DBA: ita, katsomaan näitä juttuja ja syntetisoimaan ne. Voit kertoa, sinun on tiedettävä, mitä olet tekemässä, jotta nämä asiat toimisivat. Mutta tarvitset työkalut antaaksesi sinulle tietoja tietääksesi mitä olet tekemässä. Joten lopullinen asia on, että DBA: lla menee hienosti.
Ja suuret kiitokset Bullett Manalelle ja ystävillemme IDERAssa. Ja tietysti Rick Sherman ja Robin Bloor. Arkistoimme kaikki nämä verkkolähetykset, joten hyppäämme verkkoon insideanalysis.com tai kumppanisivustollemme www.techopedia.com saadaksesi lisätietoja kaikesta tästä.
Ja sen kanssa, hyvästi jäähyväiset, ihmiset. Kiitos vielä kerran, puhu hyvin seuraavalla kerralla. Pitää huolta. Hei hei.