Suorituskykypelaaminen: hyvästellä latenssia

Tekijä Techopedia Staff, 9. toukokuuta 2016

Takeaway: Isäntä Eric Kavanagh haastattelee Mark Madsenia, Dez Blanchfieldiä ja Bullett Manaalia latenssista ja suorituskyvystä.

Et ole tällä hetkellä kirjautunut sisään. Kirjaudu sisään tai kirjaudu sisään nähdäksesi videon.

Techopedian sisältökumppani

Techopedia Staff on sidoksissa Bloor-konserniin, ja heihin voidaan ottaa yhteyttä käyttämällä oikealla olevia vaihtoehtoja. Tietoja siitä, miten työskentelemme alan yhteistyökumppaneiden kanssa, napsauta tätä.

• Profiili
• Verkkosivusto

Eric Kavanagh: Hyvät naiset ja herrat, hei ja tervetuloa jälleen kerran Hot Technologiesiin! Todellakin! Nimeni on Eric Kavanagh, tämä on Hot Tech -show, yhteistyö Techopedian hyvien ystävien kanssa. Hyödynnä Techopedia.com-verkossa viimeisimmät tiedot yritystoiminnan tekniikan laajalta kentältä; ne tietysti kattavat myös kuluttajien tavaroita. Keskitymme tässä ohjelmassa olevaan yritykseen, joten teemme sen tänään.

Sinulla on paikka todella ja riittävästi minusta, lyö minut Twitteriin @eric_kavanagh, rakastan Twitteriä, rakastan näiden asioiden tarkistamista, se on loistava tapa pitää yhteyttä ihmisiin ja käydä hyviä keskusteluja ja yksipuolisia -keskusteluja.

Joten mistä me puhumme? Tämä vuosi on kuuma, tämä on koko mahdollisuuksien universumi, jota tarkastelemme tänään tiedonhallinnan maailmassa, ja mitä tänään puhumme, tulee kyselyihin, se nopeuttaa kyselyitä.

Luulen unohtaneeni mainita otsikon ”Performance Play: Sano hyvästit latenssille”. Kuka haluaa latenssin? Kukaan ei halua latenssia. Latenssi on silloin, kun istut siellä, napsautat painiketta ja odotat, että jotain tapahtuu, ja kukaan ei halua sitä. Lapset eivät pidä siitä, eivät he usko, että se on siistiä, aikuiset eivät myöskään pidä siitä. Verkon nopeus on meitä kaikkia pilaa ja haluamme asioita nopeasti, haluamme asioita nyt, ja puhumme kaikesta tästä tänään näyttelyssämme.

Analyytikko Mark Madsen on tänään kanssamme kolmannesta luonnosta, yksi vakituisista virkamiehistämme. Uusi tietoteknikomme Dez Blanchfield soittaa Sydneystä, Australiasta. Ja sitten Bullett Manale, kyllä, se on hänen nimensä, oikeastaan ​​sen pitäisi olla kaksi T: tä. Bullett Manale on vieraana Iderasta, erittäin, erittäin mielenkiintoisesta yrityksestä, joka tekee paljon tavaraa. Tiedän heistä jo yhden, josta he ostivat yrityksen nimeltä Precise jonkin aikaa sitten. Tiesin heidän toimitusjohtajansa nimeltä Zohar Gilad. Kuinka se on nimelle? Hän oli yksi helvetin fiksu kaveri.

Ihmiset, sinulla on merkittävä rooli tässä webcast-lähetyksessä esittämissasi kysymyksissä, joten älä ole ujo, lähetä kysymyksesi milloin tahansa - voit tehdä niin käyttämällä webcast-konsolin Q&A-komponenttia, se on alhaalla oikeassa alakulmassa. Voit myös keskustella minulle, ja juttelen sen puhujien kanssa. Meillä on jo joku soittamassa Italiasta, ”Ciao, ciao. Tule stai? ”Hyvä on, että aion työntää Markin ensimmäisen rivin, annan kannen Markille. Mark, sinulla on nyt WebEx. Ota se pois, lattia on sinun.

Mark Madsen: Kiitos, Eric. En aio aloittaa keskeltä, aloitan kuitenkin alussa. Joten vain muutama kommentti keskustelun aloittamiseksi Dezin ja Ideran kanssa, eräänlainen valtion tila, jossa on kehitystä, sekä tietokannat ja toiminnot. Ja tiedät, jos tarkastellaan tällaista, meillä on tällaisia ​​kahdenlaisia ​​ongelmia edelleen tietokanta- ja sovellusmarkkinoilla, koska kehittäjät näkevät DBA: t ihmisinä, jotka vaivaavat niitä. Sinun on rakennettava tietomalleja, et voi käyttää sitä, et voi luoda sitä, et voi laittaa hakemistoa tietokannan jokaisen taulukon jokaiseen sarakkeeseen nopeuttaaksesi sitä. Ja tietysti, miksi tarvitsemme malleja? Se on vain tietorakenteita, jos muutamme niitä, etkö voi vain kirjoittaa niitä sarjamuodossa?

Ongelmana on, että kehittäjät tietävät koodin ja sovellukset, mutta kaksi asiaa, jota he eivät usein tiedä, ovat samanaikaisuus, samanaikainen ohjelmointi ja tietokannat sekä niiden alla olevat käyttöjärjestelmät. Olen ollut ytimen kehittäjä, käyttöjärjestelmiä ja tietokantoja, ja voin sanoa, että samanaikaisuus ja rinnakkaisuus ovat todella vaikeita, ja niin monet asiat, jotka opit saamaan hyvän suorituskyvyn koodistasi, todella alkavat hajota, kun olet työskentely tietokannan kanssa. Ja suorituskyky näyttää hyvältä, testiympäristö näyttää hyvältä ja Q&A -ympäristö, ja sitten se osuu oikeaan järjestelmään, ja sitten yhtäkkiä se ei ole niin suuri. Koska koodi on monipuolinen, miten koodi toimii tietokannan kanssa, miten se toimii ympäristön kanssa, ja todella yksinkertaisilla pienillä käytännöillä voi olla rajuja vaikutuksia käytetystä mittakaavasta riippuen.

Ja kun aloitat puhumisen ulkoisista sovelluksista, tietenkin ulkoisesti kohtaavat sovellukset, web-sovellukset, voivat olla todella vaikeita, koska asiat ovat hienoja, kunnes yhtäkkiä ne tasoittuvat, ja eivät ole. Osat nämä mielenkiintoiset tasangot, joiden ymmärtäminen vaatii paljon vivahteita.

Asioiden kääntöpuoli on DBA-näkymä. DBA: n näkemyksen mukaan toimintaa on olemassa, he viettävät suurimman osan ajastaan, 80–90 prosenttia, opissa, ja ehkä 10–20 prosenttia, jotka käsittelevät etukäteen tapahtuvaa kehitystyötä. Tästä näkökulmasta joko maksat nyt tai maksat myöhemmin, ja jos vietät kaiken aikaasi etukäteen, sinulla on myöhemmin paljon paremmat mahdollisuudet kuin kehitys, joka yleensä tutkii ominaisuutta tilaa, ja yritetään selvittää, kuinka parasta tehdä asioita. Ja niin meillä on ongelmia, ja nyt meillä on yhteensopimattomia menetelmiä - jatkuva käyttöönotto, sovellusten käyttöönotto aina kun ne ovat valmiita, koodin työntäminen määräajoin, työskentely kaupassa, joka harjoittaa kehitysohjelmia. Tällainen asia nopeuttaa kehitystä, mutta kaikki tietokannan ympärillä olevat käytännöt ja mitä DBA: t tekevät ja mitä järjestelmän päälliköille on koulutettu, IT-käytännöt eivät ole pysyneet tahdissa.

Jos mietit sitä, suurin osa DBA: sta toimii muutoksenhallintaympäristössä verrattuna jatkuvaan käyttöönottoympäristöön. Kyse on vakaudesta ja hallinnasta verrattuna muutoksen nopeuteen ja palautuvuuteen. Jatkuva käyttöönotto, jos et pääse takaisin muutoksesta, olet pulassa, joten kaiken on rakennettava helposti vaihdettavaksi ja koodinvaihtoon, mikä ei oikeastaan ​​ole tapa, jolla relaatiotietokanta, kehityskäytännöt ja hallintakäytännöt ovat toimineet .

Olet myös törmännyt näihin ongelmiin, joiden mukaan sinun on oltava aktiivisempaa, jos pystyt DBA: na, koska siihen mennessä, kun kuulet ongelmasta, satatuhatta ihmistä täyttää valituslomakkeet verkkosivustollasi. Tämän vuoksi tarvitset joitain uusia asioita, joita et pääse pois vanhasta ympäristöstäsi. Tiedät esimerkiksi paremman seurannan ja hälytyksen. Samalla tietokannat ovat moninkertaistuneet, meillä on enemmän sovelluksia kuin koskaan tukea enemmän asioita kuin koskaan, ne ovat sisällä, he ovat ulkopuolella, he ovat kaikkialla. Ja itsenäisempiä tietojoukkoja analyysejä varten ihmiset perustavat tietokantoja kaikkialle, koska tietysti se on nyt helppoa, voit perustaa virtuaalikoneen. Jos sinulla on pilvipalveluntarjoaja tai sisäinen pilvi, voit heti poputtaa asiat, ja tämä muuttaa koko hankintapolkuasi.

Vanha hankintapolku oli: "Minulla on aikaa hankkia palvelin, työntää se telineeseen, varata tilaa, saada tallennustilaa, saada tietokanta asennettua ja tehdä asioita", kun taas joku pyyhkäisee luottokortin ja menee viiteen minuuttiin. Jos teet niin, se moderni kehitysympäristö toimii hyvin erilaisella tahdilla, joten tietokantojen luominen on helppoa, ja se vain luo tämän leviämisongelman, kuten ei mitään aiemmin nähtyä. Ja tämä on jatkunut jo kymmenen vuotta, tämä ei ole uutinen kenellekään, mutta se tarkoittaa myös, että toimintaympäristöt ovat kasvaneet monimutkaisiksi.

Koko asiakaspalvelinympäristö on todella muuttunut, koska se ei ole enää asiakaspalvelinmaailma. Tuolloin sinulla oli palvelin, sinulla oli tietokanta. Jos jotain oli vialla, tiesit mihin palvelimeen mennä, osaa hallita sen resursseja, koska paras tapa oli yksi tietokanta, yksi palvelin. Virtualisointi alkoi hajottaa eron toisistaan, pilvi hajottaa sen vielä enemmän, koska se mitä luulet olevan tietokantapalvelin, on vain ohjelmisto. Joten ympäristö ei ole todellinen. Se, mikä sisältää ympäristön, joka on todellisuutta, ja se voi olla kappaleterä tai paloiksi leikattu iso palvelin, et todella tiedä.

Kaiken tietokannan hallinnan ja suorituskyvyn hallinnan ympärillä, ja mitä tietokantoja on rakennettu tiukalle yhden palvelimen tai kourallisen palvelimien ja parin tietokannan hallintaan, et voi hallita kaikkea. Istut siellä koneella, mutta virtuaaliset johtajat eivät voi jakaa kaistanleveyttä helposti, joten muisti ja prosessori voivat kaikki olla hyvin, mutta pullonkaula on resurssilla, jota ei voida käsitellä, ja sitten kun Yrität korjata sen, vanha malli olisi ollut kovaa työtä, hankkinut isompi palvelin ja tehdä jotain sellaista, nyt se voisi olla todella yksinkertainen, lisää vain virtuaalikurssi, lisää vain muisti VM: ään ja se on ratkaistu. Mutta mitä tapahtuu, jos VM on täynnä palvelinta ja sen on siirrettävä? Tai mitä tapahtuu, jos olet AWS-järjestelmän kokoinen ja enimmäiskoko on saavutettu, nyt minne menet?

Joten sinulla on kaikki nämä ongelmat, joissa ympäristö on nyt osa tietokantaa, pakatut ympäristön tietokannalla, kaikilla erityisillä resursseilla, kaikella sovelluksessa, joka on osa kokoonpanoa, kokoonpano työntyy ulos. Tämä on tietokantaympäristöstä, sitä on paljon vaikeampi hallita ja hallita.

Jos katsot mitä tietokantakeskukset ovat tehneet, he ovat istuneet kätensä, eikö niin? Olemme siirtyneet pois ajatuksesta käsitellä tietokantoja ja palvelimia lemmikkien tavoin. Palvelimilla on nimiä, sinä kohdella heitä kuin he ovat yksilöllisesti ainutlaatuisia asioita, kohdella heitä kuin karjaa, se hoitaa laumaa. Ja ongelma karjojen hallinnassa on se, että jos et hallitse niitä, ne voivat lopulta hämmentää, ja masennus ei ole hyvä asia. Tarvitsemme parempia seurantavälineitä, tarvitsemme parempia tapoja käsitellä näitä asioita ja tiedämme mitä asia on vaikuttanut. Vanhassa mallissa se oli helpompaa, koska operaattorisi ja kaikki ohjausjärjestelmäsi kertoivat sinulle, mutta kun palvelimesi nimi on UPC-koodi, se on vaikea selvittää.

Sinulla ei ole varaa vääriin hälytyksiin, sinulla ei ole varaa asioihin, joissa sanotaan: "Tässä koneessa on ongelma ja koneessa on 30 tietokantaa." Sinulla ei ole varaa olla, että asioilla ei ole historiaa. Valvontakonsolit ovat hienoja, kun ne syttyvät, mutta jos punainen valo muuttuu taas vihreäksi, et tiedä miksi, ja sinulla ei ole historiaa palata takaisin tutkimaan, mikä johti siihen ja mitä tilanne oli, olet pulassa. Tarvitsemme järjestelmiä, jotka seuraavat meidän puolestamme, tarvitsemme parempaa seurantaa, käsittelemään niitä historiallisia jaksoittaisia ​​ongelmia, jotka ylläpitävät tietohistoriaa.

Parempia asioita ja yksinkertaisia ​​mittakynnyksiä, jotka antavat meille avaintiedot, mutta eivät johda meitä suoraan siihen, mikä on normaalia, mikä on epänormaalia ja kuinka usein nämä ongelmat ilmenevät. Se mitä puhumme oikeastaan ​​on yhdistelmä seurantaympäristöä ja suorituskykyä, ja myyjät ovat istuneet kätensä. He eivät ole antaneet meille parempia työkaluja. Meillä on järjestelmiä, joissa on enemmän prosessoria ja muistia kuin tiedämme, mitä sillä kaikella on tekemistä, ja silti luotamme silti manuaalisiin interventiomalleihin, emme ole laittaneet konetta toimimaan, opastamaan, saamaan meidät kohtaan ongelmia, emme ole päässeet tähän uuteen tyyliin, joka on: "Täällä on ongelma, voit tehdä tämän korjataksesi" tai "On suorituskykyongelma, se on oikeastaan ​​tämän nimenomaisen SQL-käskyn avulla. Tässä on kolme asiaa, jotka voisit Korjaa tämä SQL-käsky. ”Heuristiikan soveltaminen, koneoppimismallien soveltaminen, jotka voivat tarkastella järjestelmän käyttötapoja havaita ongelmia ja välttää vääriä ilmoituksia. Laitteen käyttäminen suorittamaan mitä kone parhaiten tekee, lisätä DBA: ta tai lisätä henkilöä, jonka on käsiteltävä suoritusongelmia.

Se on uusi tapa, vanhaan tyyliin nähden. Tässä tietokannassa on ongelma, asiat ovat hitaita, ja siksi meillä on uusia tekniikoita, uusia tapoja tehdä se, ja meidän pitäisi soveltaa niitä, ja siihen markkinat ovat menossa. Näet, että se alkaa vilkkua, ei suurten toimittajien, mutta kolmansien osapuolien kanssa, ja tämä heijastaa jotain, joka tapahtui 20 vuotta sitten, kun tietokantatoimittajat eivät toimittaneet yhtä asiaa järjestelmien hallintaan. Joten se on sellainen, mikä markkinoiden suunta on, ja sen kanssa haluaisin kääntää sen takaisin Ericille.

Eric Kavanagh: Okei, annan sen Dezille. Ja Dez, ota se pois, lattia on sinun.

Dez Blanchfield: Kiitos, Mark. Olet tehnyt upeaa työtä peittämällä sen tekninen osa. Aion käsitellä sitä hiukan eri näkökulmasta korostaaksesi mitä tapahtui muualla maailmassa, siltä osin kuin on vaikutusta yrityksiin ja niitä ympäröiviin tietokantoihin. Annan minun hypätä ensimmäiseen diaani.

Niiden takana, jotka olet juuri kattanut asioiden tekniseltä puolelta ja kehittäjäpuolelta, näen yritysten joutuvan kohtaamaan erityisesti tietojen ja tietokantojen haasteet, ja meillä on selvästi ollut merkittävä muutos kohti tämä iso datan käsite, mutta tosiasiallisesti tietokannat ovat edelleen sydän ja sielu siellä, missä organisaatiot säilyttävät yritystietonsa, ja se on etuovesta aina takaisin toimistoon. Jokaiseen organisaation osaan liittyy jonkinlainen tietokanta, ja sitä tukee tietokanta. Hyvin harvoin käyn joko projektikeskusteluja tai jonkinlaista innovatiivista strategista keskustelua organisaatiossa, jossa tietokannan tai tietokantajärjestelmän aihe ei tule esiin, ja aina on kysyttävää juuri kuultujen asioiden tyypeistä, suorituskyvystä ja turvallisuudesta. Kuinka kehitys tulee lähestymään tätä haastetta, mihin tietokannat sopivat ja tietoisuuteen ympäristöistä ja sovelluksista ympäristöissä puhutaan, entä laitteet ja liikkuvuus?

Se on silti erittäin, erittäin kuuma aihe, ja se on ollut jo kauan, pitkään asioiden grandiossa niin pitkälle kuin moderni tekniikka menee. Tähän pisteeseen uskon, että tosiasia on, että melkein kaikki, mitä teemme päivittäisessä elämässämme, jokapäiväisessä elämässämme, eli jota tukee nyt jonkinlainen tietokanta. Kun ajattelemme kaikkia ympärillämme olevia asioita, olivatpa ne sitten lasku, joka tulee postissa päivittäin jostakin ostamastamme palvelusta, sen väistämättä tulostaa järjestelmä, joka puhuu tietokantaan, ja olemme siellä. Puhelimissamme on tietokannat, joissa on yhteystiedot, puhelulokit ja muut asiat.

Mihin menemmekin, keskustelun ja käyttämämme järjestelmien takana on jonkinlainen tietokanta. Useimmiten ne ovat melko läpinäkyviä meille, mutta tosiasia on, että ne ovat olemassa. Joten ajattelin kattaa vain nopeasti, miksi tästä on tullut pieni ongelma hyvin lyhyessä ajassa. Alussa tietokannan käsite tuli tältä ihanalta herralta, Edgar Coddilta. IBM: n palveluksessa hän muutti maailmaa tiedonhallinnan kannalta luomalla konseptin, jota kutsumme nyt relaatiotietokantaksi.

Aluksi tietokanta oli tietokanta ja elämä oli hyvää, se oli melko suoraviivaista sekä sarakkeissa että viitteissä ja niin edelleen, sekä taulukoissa ja ohjelmistojen kehittämisessä oli melko suoraviivaista, eikä suorituskyky ollut oikeastaan ​​niin suuri kysymys - se oli uusi jännittävä tekniikka. Pääsimme tietokantoihin jollain päätelaitteella, ja voit todella luoda niin paljon tuhoa suuryksikön 3270-terminaalin lopussa ja aina muun tyyppisten päätelaitteiden kanssa, nämä muut järjestelmät tulivat mukana. Ja useimmissa tapauksissa vanhan tyylin päätelaitteet olivat hyvin samankaltaisia ​​kuin nykyiset verkkoympäristöt. Toisin sanoen, että täyttäisit lomakkeen itse päätelaitteen näytöllä ja painat Enter-painiketta ja sen mennessä, se menisi ampua pois yhtenä pakettina pyynnönä, ja taustajärjestelmä käsittelee sen. Näin tapahtuu pääasiassa selaimessa näinä päivinä, kun kirjoitat linkin selaimeen ja että muoto ei yleensä mene reaaliajassa takaisin järjestelmään, vaikka AJAX: n kanssa nykyään se ei ole täysin tapaus.

Mutta sitten tapahtui jotain, tulevaisuus saapui, ja viime aikoina Internet ja melkein eilen sekunnissa web 2.0 ja aivan nurkan takana meillä on esineiden Internet. Ja tulevaisuuden tapahtumassa tietokantojen maailma on juuri räjähtänyt, ja vuorovaikutuksesta tietokantojen kanssa tuli vain asia, jonka me kaikki oletusarvoisesti teimme, ei ollut tapausta, että menisit jonnekin tekemään jotain, kuten ostamaan lipun lentokoneelle, ja haluat matkustaa planeetan toiselle puolelle, jonkun piti kirjoittaa terminaaliin kaikki tietosi ja mennä tietokantaan ja tulostaa lippu.

Lähes kaikki, mitä teemme nyt, onko kyseessä ohjaamon hakeminen Googlessa sovelluksen kanssa, hyppääminen verkkopankkipalvelussa, kaiken, mitä teemme päivittäin, jonkinlaisen järjestelmän avulla, sen käyttö perustuu tietokantaan. Ja kun Internet tuli mukana, sitä oli hiukan helpompi tuoda meille, jokapäiväiseen elämäämme selaimen kautta, ja sitten web 2.0 tuli mukana ja asiat muuttuivat mobiileiksi, ja asioiden mittakaava vain räjähti. Itse asiassa suosikki linjani tässä aiheesta on, että "Internet yhdisti kaiken, Web 2.0 teki siitä mobiili- ja sosiaalisen, ja asiat muuttuivat erittäin, erittäin isoiksi ja nyt meillä on Internet ja asiat, ja IoT … Yikes !!" Emme ole edes alkaneet kuvitella esineiden Internetin vaikutusta maailmaan tietokantajärjestelmiin.

Joten nykyaikaisesti terminaaliksi ajattelusta on tullut tosiasiallisesti näitä asioita, se on matkapuhelin, se on erityyppinen tabletti, joko henkilökohtainen kuluttaja- tai yritysluokan suuri näytön tabletti, se on kannettava tietokone ja se on perinteinen työpöytä jossain muodossa. Siinä yhdessä kuvassa voit nähdä melkein kaikki käyttöliittymämuodot, joita puhumme tietokantajärjestelmiin ja sovelluksiin, jotka käyttävät niitä, pienistä laitteistamme käsissämme, jotka kävelevät ympäri ja joihin näyttää olevan liimattu, kaikki tien läpi hiukan isompiin versioihin, iPadeihin ja muihin tableteihin ja Microsoft Surfaceihin, päivittäisiin kannettaviin tietokoneisiin, jotka ovat aina muuttumattomia ammatillisissa ympäristöissä ja niin edelleen. Ihmisillä on tapana hankkia kannettava tietokone eikä kiinteää työpöytää, mutta he ovat mielestäni nykyaikainen päätelaite ja osa syytä siihen, että tietokannat kokevat kaikenlaisia ​​haasteita elämämme hallinnointitehtävissä, eivät vain kehitystä.

Joten oletan, että se on yksi suurimmista haasteista, joita yritykset kohtaavat edelleen päivittäin. Jokaisen mielestä tietokannat olivat ainoat ongelmamme, he eivät ole. Joten mistä kaikesta on hätää? No kun siirrymme päästä toiseen kaikkien tietokantoihin liittyvien asioiden kanssa, kaupallisesta mielestä, ja Markin tekniset komponentit kattoivat erittäin hyvin, mutta kaupallisessa mielessä organisaationa ajattelemme tietokantoja. Olemme tekemisissä asioiden kanssa perussuunnittelusta ja kehityksestä aina. Yrityksen alkaessa he ajattelevat sovellusten kehittämistä, valmiuksien kehittämistä tai jopa olemassa olevan sovelluksen toteuttamista jossain muodossa. Jonkinlaisen suunnittelun ja kehityksen on tapahduttava, ja on pohdittava paljon, miten nämä tietokantajärjestelmät otetaan käyttöön, tuetaan ja hallitaan sekä esityksiä seurataan ja niin edelleen.

Tietokantaympäristön ja sovellusten integrointi sekä API-tyypit, nyt tarjottavat käyttötyypit ovat entistä haastavampia ja monimutkaisempia. Päivittäinen hallinto, tuki ja varmuuskopiot ovat taas asioita, jotka mielestämme ratkaistiin, mutta sitten yhtäkkiä asteikko kasvoi paljon ja asiat liikkuivat nopeammin, ja volyymi on niin paljon suurempi; Ympäristöjen koon mukaan tietokantajärjestelmien oli tuettava liiketoimien liikkumisen nopeutta.

Ajattele tietokantaa erittäin, erittäin korkean taajuuden kaupankäyntiympäristössä. Ei vain ole mitään tapaa, jolla ihmiset voivat seurata sitä, se on vain koneiden ryhmä, joka taistelee toista koneiden ryhmää vastaan ​​harjoittamaan suurta taajuutta käyvää kauppaa, ostamista ja myyntiä sekä mitä nämä tapahtumat tapahtuvat. Ajattele nykyajan skenaariota, kuten Netflix-elokuvan varhainen julkaisu, jossa et puhu vain sadoista tai tuhansista tai jopa sadoista tuhansista, mahdollisesti miljoonista ihmisistä, jotka haluavat nähdä kyseisen elokuvan heti sen julkaisun jälkeen. Kaikki nämä tiedot kaappaavat, jäljitetään ja kirjataan ja analysoidaan tietokantaalustalla.

Ja sitten siellä on aina päällä oleva maailma, jossa elämme nyt, ympäri vuorokauden, ei vain seuraa aurinkoa, vaan myös aina joku keskiyöllä haluaa tehdä jotain, ja työajat seuraavat aurinkoa ympäri maailmaa. Joten käytettävyys ja saatavuus ovat oletuksena, ovat nyt ilmapiiri, koska seisokin pitäminen ei todellakaan ole hyväksyttävää. Ja redundanssi, jos on suorituskykyongelmaa tai tarvitsemme ylläpitoikkunaa päivityksen tai korjaustiedoston tai tietoturvan toteuttamiseksi, meidän on kyettävä leikkaamaan tietokantaympäristöstä toiseen ja tekemään se saumattomasti ja automaattisesti.

Turvallisuus ja standardit ja noudattaminen, myöhässä, etenkin GFC: n maailmassa, on tapahtunut melko suuria asioita, ja siksi meillä on koko joukko uusia haasteita, joihin on vastattava noudattamisen, turvallisuuden ja standardien täyttämisen suhteen, ja tarvitsemme pystyä raportoimaan niistä reaaliajassa, mieluiten kojetaulun muodossa. Emme halua lähettää apinajoukkoa tietokeskukseen yrittämään löytää asioita, tarvitsemme järjestelmän kertomaan meille heti, reaaliajassa.

Ja kaksi suurta hauskaa, joista melkein kukaan ei koskaan puhu, työnnämme ne yleensä maton alle ja toivomme, etteivät he koskaan nosta rumaa päätään, vaan katastrofien palauttaminen ja liiketoiminnan jatkuvuus - nämä ovat myös asioita, joiden pitäisi, yleensä tapahtuu automaattisesti, jos tarvetta ilmenee.

Voisimme viettää päiviä puhumalla tyypeistä asioista, jotka voivat mennä pieleen tietokantaympäristöissä ja joihin ihmiset yleensä ovat reagoineet, mutta nyt tarvitsemme järjestelmiä ja työkaluja tehdäksemme sen meille. Yksi esimerkki on tietosuojarikkomus, ja niin ajatellessamme tietokantoja, kysyn tätä kysymystä melko avoimesti eri muodoissa: mitä tapahtuu tietokantoille, kun otamme silmämme pois pallasta, ja jotain kriittistä menee pieleen? Varsinkin jos ei ole järjestelmää, joka tarkkailisi suorituskykyä ja tietoturvaa sekä muita tärkeitä tietokantojen käynnin näkökohtia.

No, mitä voi tapahtua, tämä on kuvakaappaus joihinkin viimeisten kahden tai kolmen vuoden rikkomuksista. Nämä ovat aina tulleet tietokantajärjestelmästä, ja ainakin turvallisuuteen tai hallintaan tai pääsyyn on liittynyt jokin ongelma, ja vasemmassa yläkulmassa olemme tarkastelemassa 152 miljoonaa Adobe-tiliä, joissa kaikki yksityiskohdat näistä asiakkaista oli rikottu. Ja jos kyseessä olisivat olleet asianmukaiset työkalut tapahtuman seuraamiseksi ja sieppaamiseksi sekä turvallisuuden hallitsemiseksi, olemme ehkä välttäneet joitain niistä, pari ensimmäistä sataa varastettua tietuetta olisi saattanut hälyttää meitä, ja meillä olisi pysäytti seuraavat sata viisikymmentä miljoonaa.

Sitten päästämme läpi koko matkan avainkysymykseen, joka on johdattu meille: miksi tarvitsemme parempia järjestelmiä? Miksi emme voi vain heittää lisää kappaleita tähän asiaan, että olemme hyvin ja todella ylittäneet kärkipisteeni mielestäni, ja varmasti uskon, että on olemassa tapaus, joka on osoitettu myöhässä, että heittää enemmän DBA: ta, järjestelmänvalvojaa ja enemmän ihmisiä tämä asia ei korjaa ongelmaa. Tarvitsemme parempia työkaluja ja parempia järjestelmiä.

Tässä on viisi tärkeintä syytä, joiden mielestäni tuen tätä, ja ne on järjestetty tärkeysjärjestykseen sen perusteella, mitä näen näissä yksityisyrityksissä ja valtioissa, joissa hallitaan ympäristöä, haasteisiin, joita he kohtaavat tietokantaympäristöjen kanssa, ja hallita niitä.

Turvallisuus ja noudattaminen - numero yksi. Tiedätkö, että hallitset kenellä on käyttöoikeus, missä heillä on käyttöoikeus, kun heillä on käyttöoikeus, kuinka usein heillä on käyttöoikeus, mistä he ovat saaneet sen. Mahdollisesti niihin laitteisiin, joita he ovat tosiasiallisesti koskettaneet, ja tyyppeihin, joita he ovat katsoneet, ja vaatimustenmukaisuudesta, joka ympäröi sitä. Se, että ihmiset saavat raportteja 30 päivää myöhemmin kertomaan meille, ovatko asiat kunnossa, ei enää ole enää tarkoituksenmukaisia, sen on tapahduttava reaaliajassa.

Suorituskyky ja seuranta - se ei tunnu olevan brainer, mutta ei aina. Käytämmepä sitten avoimen lähdekoodin työkaluja tai joitain kolmansien osapuolien kaupallisia työkaluja, emme aina ole unohtaneet venettä monin tavoin vaaditulla suorituskyvyn seurannan tyypillä ja tarvittavilla yksityiskohdilla sekä kykyllä ​​reagoida ajoissa .

Tapahtumien havaitseminen ja niihin reagoiminen - sen on oltava reaaliaikainen välitön asia, ja tarvitsemme aina järjestelmän, joka tekee sen meille tai ainakin hälyttää meille nopeasti, jotta pystymme käsittelemään sitä, jotta harvat esiin tulevat asiat käsitellään nopeasti, ja älä kaskadin käsistä.

Johtaminen ja hallinto - uskomme jälleen kerran, että nämä ongelmat on ratkaistu, he eivät ole. Tavoitteena tietokantaryhmien, etenkin DBA-ryhmien, kohtaamat asiat, joissa järjestelmän tulisi huolehtia asioistamme meille, emme ole vielä ratkaisseet tätä ongelmaa, se on silti todellinen asia.

Ja heti suunnittelusta ja kehityksestä, kun aloitamme näiden työkalujen rakentamisen, rakennamme tietokantaympäristöjä, pystymme heittämään asianmukaiset työkalut kehittämiseen ja testaamiseen sekä integraatioalustoihin. Tämä ei ole silti meille helppoa, ja koko tämä matka ajaa meidät eräänlaiseen viestiin, että mielessämme tarvitsemme parempia järjestelmiä ja parempia työkaluja auttamaan meitä saavuttamaan tarvitsemiemme tulokset. tietokantaympäristömme, joten yritykset, jotka lisäävät arvoa asiakkaidemme kautta. Emme voi vain heittää enemmän kappaleita ja enemmän DBA: ita, asteikko on liian suuri, nopeus on liian nopea ja tilavuus on liian suuri. Sen avulla Eric voin siirtyä takaisin sinulle.

Eric Kavanagh: Rakastan sitä, meillä on paljon maata peitettynä siellä, paljon mahdollisia johtoja, ja menemme eteenpäin ja luovutamme heidän avaimet Bullettille vain sekunnissa.

Bullett Manale: Hyvä on.

Eric Kavanagh: Otetaan, otamme sen pois ja Bullett, nyt annan sen sinulle, ja lattia on sinun.

Bullett Manale: Hyvä on, kiitos. Mielestäni on tehty paljon hyviä asioita. Halusin puhua vain sekunnin ajan nopeasti Iderasta, kuka me olemme, ja sitten hyppäämme sisään. Aion puhua työkalusta, jonka mielestäni monet näistä jutteista puhumme, voimme eräänlainen joukko ja sellainen keskustelu joistain alueista, joilla nämä kohdistuvat tämän työkalun kanssa, Diagnostic Manager -tuote.

Nyt se, mitä haluan tehdä ensin, on vain eräänlainen antaa sinulle vähän taustaa siitä, kuka Idera on; olemme olleet olemassa noin vuodesta 2003, joten olemme aloittaneet vain SQL Server -työkaluilla, ja siihen keskitymme tänään, se olisi Diagnostic Manager -tuote. Mutta voit nähdä kaikki ämpäri asioita, joita meillä on täällä, ja olemme äskettäin, kuten aiemmin mainittiin, ostaneet tarkkaa ja hankinnan kautta meillä on myös Embarcadero, ja niin meillä on aika hyvä tuotevalikoima.

Suorituskyvyn seurannan kannalta SQL Serverin suhteen tuote, josta haluan puhua ja joka yhdenmukaistaa nämä keskustelemasi aiheet, on Diagnostic Manager. Nyt tämä on tuote, joka on ollut olemassa jo melko lähellä Ideran päivien alkua, ja minulla on ollut onni olla osa tätä noin vuoden 2005 jälkeen. Ja olen nähnyt paljon muutoksia SQL Server, siirtyy fyysisestä virtuaaliseen, kaikki sellaiset asiat, joita on tapahtunut, ja myös DBA: n tarpeet ympäristön kasvaessa ja tällaiset asiat.

Aloitin siitä, että tuotteemme tyypillinen käyttäjä on DBA, ja joten kun puhumme ensimmäistä kertaa ihmisille mahdollisille asiakkaille, se on enimmäkseen DBA: ita, josta puhumme. Emme puhu IT-päälliköiden tai johtajien kanssa, se voi jossain vaiheessa päästä tälle tasolle, mutta alussa on, että DBA: lla on ongelma, DBA yrittää korjata ongelman, ja monta kertaa me Menen hakemaan ja kokeilemaan tuotetta osana tätä. Saat joko tiedonhallinnan tai DBA: n tai toimivan DBA: n, tyypin, joka on onni ollakseen huoneen teknisin tietyissä tapauksissa. Nyt kun pääset tietenkin suurempiin yritysympäristöihin, saat täysimääräiset DBA-tiedostot, jotka yleensä käyttävät työkalua. Ja menin eteenpäin ja lisäin vain pienen sumun täällä Wikipediasta. Se tyyppi menee DBA: n vastuiden yli, kuten Wikipedia sanoo, he tekevät.

Jos käydään läpi luettelon täällä, paljon näitä asioita, en aio lukea sitä pois, mutta saat paljon tyypillisiä asioita, joista ajattelit, ja sitten yhdellä niistä olet seurannut ja tietokannan suorituskyvyn optimointi, ja se on aika iso. Ja mikä on mielenkiintoista, on se, että kun puhut DBA: n kanssa, heitä syytetään aina ensin, kun kyse on ongelmista, ja se ei välttämättä ole heidän syytä, mutta kun on suorituskykyongelma, yleensä sovelluksella, joka on sidottu DBA-tietokantaan, he ovat syyllisiä, joten he etsivät aina syitä, miksi se ei ole heidän syytä. Monissa tapauksissa he voivat käyttää tätä työkalua, Diagnostic Manager, auttaa heitä tekemään.

Mutta päivän päätteeksi myös, jos tietokanta ei toimi, niin paljon muilla asioilla ei ole oikeastaan ​​merkitystä, sovelluksesi eivät toimi, niin sillä ei ole väliä monille asioita. Ensinnäkin, haluamme pystyä varmistamaan, että käyttäjän kokemus sellaisesta kuin me sen tiedämme, ei vähene, se on jotain, jota DBA: t pyrkivät aina. Ja luulen, että jos tarkastellaan syitä siihen, miksi ihmiset yleensä ostavat ja käyttävät SQL Diagnostic Manager -tuotetta, se on yksi ensimmäisistä syistä, joka ei todennäköisesti ole tärkein, ei viimeinen tai vähiten, mutta se on tavallaan yhtä lailla, ja riippuen siitä, kenen kanssa puhut, näistä syistä melkein yksi tai kaksi niistä on aina olemassa, ympärillä on jonkinlainen tarve.

Mutta ensimmäinen on vain mahdollisuus saada keskitetty näkymä ilmentymistä SQL: nä, jota he hallitsevat. Ja hauska asia on, että monissa tapauksissa, jos kysyt DBA: lta ”Kuinka monta tapausta hallitset?” Lukumäärä muuttuu niin usein, että he eivät ole tosi varmoja joissakin tapauksissa. Tarvitset siis jotain muutakin kuin vain sen, että pystyt heittämään kaiken näytölle. Haluat tarttua tietoihin, haluat ymmärtää ne ja niin, että se on yksi niistä asioista, joista Diagnostic Manager voi ehdottomasti auttaa, on pystyä tarjoamaan sinulle tällainen näkymä ympäristöön.

Eikä se ole vain näkymä ympäristöön, vaan se, että tietokannan ylläpitäjä DBA on tyytyväinen ja se on konsoli, joka on DBA-keskeinen, jos haluat. Se on tehty tietokannan järjestelmänvalvojalle. Siellä on paljon seurantatyökaluja, siellä on runsaasti suorituskykytyökaluja, mutta kuten totesin, päivän päätteeksi DBA haluaa työkalun, joka on suunniteltu DBA: lle, koska siellä on paljon erityisiä asioita, joita he tekevät heidän päivittäin.

Ja sanotulla tavalla, sinulla SCOM, sinulla HPF, sinulla kaikki nämä muut tekniikat, mutta he haluavat jotain, joka on erityistä tekemälleen. Uskon, että voimme auttaa tällä alalla tällä tuotteella, näet, kun pääsemme siihen hetkessä. Toinen asia, jota näemme DBA: n kanssa, joka on ehdottomasti yksi niistä asioista, jota koskemme myös aikaisemmin, on, että heidän on kyettävä näkemään mitä tapahtuu, ja heidän on pystyttävä tarkastelemaan koko yritystä ja tuntea mielenrauhaa tietäessäsi mitä tapahtuu. Mutta samaan aikaan he eivät istu siellä katsellen konsolia.

Muistatko kaikki ne luetteloruudut, jotka näit luettelossa, jotka juuri vetin? Heidän on myös tehtävä nämä muut asiat, joten kyse ei ole vain tulipalojen odottamisesta. Useissa tapaamisissa järjestetään kokouksia tai suuri osa tietokannan ylläpitäjään liittyvistä ylläpitoikkunoista on käynnissä keskellä yötä nukkuessaan, joten heidän on kyettävä palaamaan takaisin katsomaan mitä tapahtui. . Monissa tapauksissa, jos et tartu jotain, kun se tapahtuu, kun ongelma on poistunut tai ainakin SQL Serverillä, siitä tulee eräänlainen ongelma, jossa käsittelet tilannetta, jossa et sinulla on enää jäännöksiä tästä ongelmasta. Ja nämä ongelmat katoavat, samoin kuin jäännökset, mikä tarkoittaa, että sinun on tehtävä vähemmän vianmäärityksiä, ja sinulla on vähemmän tietoa työskenneltäväksi.

Tästä huolimatta, se on ehdottomasti yksi niistä asioista, joista Diagnostic Manager voi auttaa, on antaa sinulle kyseinen näkemys menneisyydestä kysyäkseen menneisyyden tietoja ”Minulla oli hälytys estotoimien kanssa, oliko minulla ongelmia lukkiutumisen kanssa, oliko meillä asioita, jotka olivat tapahtumassa resurssejamme suhteen? ”Voin palata takaisin ja kysyä näitä tietoja. Voin tutkia tiettyjä ajankohtia. Pystyn tekemään kaikki nämä asiat suoraan työkalusta.

Kaikista noista asioista huolimatta siitä, onko kyseessä sisäinen vai ulkoinen sovellus, DBA haluaa tietää, koska he haluavat nähdä, mikä aiheuttaa ongelman. Sillä ei ole väliä, onko joku organisaation sisällä vai joku organisaation ulkopuolella kirjoittanut koodin; he haluavat silti pystyä eristämään sen, jotta he tietävät ongelman tapahtuvan, ja he tietävät mistä se tulee.

Joten suorituskyky ja vastuuvelvollisuus ovat avaintekijä tuotteemme toiminnassa. Voimme toimittaa kaikki nämä yksityiskohdat, ja mikä on hienoa, onko sinulla kyky porata alas. Jos pullonkaula on, voit liittää sen sovellukseen, käyttäjään, tietokantaan ja kyselyyn. Ja jälleen kerran, se on eräänlainen savustusase. Mitä kysely suoritetaan, mitä se tekee? Eikä kyse ole vain kyselystä itsestään, sillä se suorittaa itsessään, mutta myös kysely pahenee ajan myötä? Ja niihin asioihin voidaan myös vastata, tuotteella, joka on ehdottomasti jotain, jos yrität olla aktiivinen, on hienoa pystyä sanomaan: "Hei, tässä on kysely, joka meni huonosti, mutta poika katso sitä kun se kulkee pidemmälle, voimme nähdä sen juoksevan entistä pahemmin, voin tehdä asialle jotain. "

Jos siirrymme seuraavalle alueelle täällä; ja tämä on todennäköisesti - sanoisin, että tämä on yksi isoista. Yksi kysymyksistä, joita esitän, kun näytän tuotteemme, kysyn aina tietokannan järjestelmänvalvojalta "Kuinka kuulet SQL Server -tietokantoihisi liittyvästä ongelmasta?" Ja se on erittäin hauskaa, koska suurimman osan ajasta - nyt myönnetty, suurimman osan ajasta he katsovat tuotteitamme, koska monissa tapauksissa he yrittävät ratkaista tietyn tarpeen. Mutta on mielenkiintoista kuulla alkuperäisen tyyppinen asia - ainakin SQL Serverin kanssa, että se oli sellainen - tiedätkö, SQL Serverin alkuaikoina sinulla oli SQL Server ja sitten sinulla Oracle. Ja kaikilla oli Oracle, ja SQL Server oli tavallaan kuin paremman ilmaisun puutteesta tietokantojen punapäätärinen lapsenlapsi, kun se ensimmäisen kerran käynnistyi.

Ja sitten kun Microsoft lisäsi sille uusia ominaisuuksia, siitä tuli hiukan enemmän yritystyökalua. Ja on selvää, että siitä on kulunut pitkä matka. Mutta asia on, että kerran voit väittää, että tietokantoja ei pidetty kriittisinä päivän aikana. Ja se on muuttunut ajan myötä. Nyt sen vuoksi monissa tapauksissa ihmiset yrittävät saada kätensä ympäri ja sanovat: “Tiedätkö mitä? Minulla on kaikki nämä SQL Server-tietokannat, yritän saada sen käsiteltäväksi. "Sen sijaan, että kuulen ongelmia asiakaspalvelusta tai kuulemme tiettyjen ihmisten ongelmista, jotka - kuten itse käyttäjät, - He etsivät tapoja kiertää sitä. He etsivät tapoja saada ne tietoisiksi näistä tilanteista ennen kuin ne koskaan tapahtuvat.

Ja niin Diagnostic Manager -sovelluksen kanssa, se on yksi niistä asioista, jota yritämme myös tehdä, että ainakin pystytään tekemään siitä, että DBA on ensimmäinen, joka tietää näistä tilanteista tai ongelmista, jotta he voivat tehdä jotain siitä, joko heti, kun ne tapahtuvat, tai viedä se vielä askeleen pidemmälle, analysoimaan näitä järjestelmiä, joita se seuraa. Ja pystymme antamaan sinulle ennakoivia neuvoja, jotka parantavat kyseisen esiintymän suorituskykyä, ja pystyä tekemään sitä säännöllisesti. Meidän on esimerkiksi lisättävä hakemisto, joka perustuu työmäärään; tämäntyyppiset asiat, työkalut, jotka myös kykenevät. Joten näemme paljon sitä työkalussa.

Toinen asia ja viimeinen asia tässä luettelossa, joka on tavallaan enemmän yleinen kuvaus, mutta se on jotain ehdottomasti huomionarvoista. Ja etenkin kun joudut suurempiin yritystyyppisiin tilanteisiin, joissa on paljon tapauksia, tapahtuu aina hämäriä asioita, joita haluan valvoa, jos olen tietokannan järjestelmänvalvoja. esimerkki. Joten mitä yritämme tehdä, on ennakoida sen suhteen, mitä tyypillinen DBA aikoo seurata.

Tämän sanottua voisit myös suhteessa - siellä tulee aina olemaan jotain uutta. Joten tarjimme tavan, jolla voit lisätä mittasuhteet, joita tarvitset seurata ja hallita, kun asennuskohta voidaan lisätä. Joten kaikki PerfMon-laskurit, WMI-laskurit, SQL Server -laskuriobjektit; kaikki nämä voidaan sisällyttää työkaluun. Sinulla on mahdollisuus lisätä lisäkyselyjä, jotka voidaan sisällyttää äänestysväleihisi.

Ja viimeinen asia, joka on myös syytä huomata, on se, että voimme lisätä ja itse kommunikoida sekä vCenterin että Hyper-V: n kanssa voidaksemme vetää mittarit näistä ympäristöistä. Koska yksi niistä asioista, jotka olemme tunnistaneet DBA: n kanssa, on, että ne eivät yleensä ole osa erityistä toimintaa. Ja heillä ei välttämättä ole, vCenter-ympäristöä, joka on heille käytettävissä, tai sellaisia ​​asioita, jotka heillä on käytettävissä.

Ja niin ongelma on, että jos he käsittelevät SQL Server -ilmentymää ja heille on osoitettu resursseja, mutta kyseinen ilmentymä on virtualisoitu, voi näyttää siltä, ​​että heillä on kaikki resurssit maailmassa, kun he vain seuraavat vieraskäyttöjärjestelmässä. Todellisuus on, että isäntäkoneessa voi olla 30, 40 tai 50 tai 100 muuta VM: tä, joita he yrittävät käyttää, ja heillä on samat resurssit. Ja ainoa tapa tosiasiallisesti nähdä se on kommunikoida muille ympäristöille ja niille rajapinnoille, tässä tapauksessa mitä teemme.

Sinulla on mahdollisuus lisätä nämä muun tyyppiset laskurit työkaluun. Nyt ei ole kyse vain siitä, että voimme seurata näitä laskuria, vaan kyse on myös mahdollisuudesta tehdä nämä uudet laskurit, jotka esität tuotteellesi, tehdä niistä osa työkalua, ikään kuin ne olisivat laatikon ulkopuolella. . Valmiiton asia, jota haluat seurata; joten se tarkoittaa, että pystymme sisällyttämään ne kojelautaan. Se tarkoittaa kykyä lisätä ne omiin räätälöityihin raportteihisi, kyky selvästi asettaa kynnysarvot ja hälyttää heille, mutta myös perustella ne ja kyetä asettamaan kynnysarvot jollain tiedolla, mihin ne voidaan asettaa sellaisten asioiden perusteella kuin sinun perusviivat ja mikä on normaalia. Joten, sinulla on paljon sellaisia ​​asioita, jotka ovat myös tuotteessa.

Se mitä olen tavallaan antanut sinulle, on se, jota kutsun "Diagnostic Manager -sovelluksen ydintoimituksiksi", ja voin edetä ja antaa sinulle vain vähän makua tästä tutustumalla tuotteeseen. Aion tehdä jaa näytöni, okei, ja vetää vain tämän yli. Joten mitä näet, tämä on Diagnostic Manager -konsolin konsoli. Ja kuten aiemmin mainitsin, menemällä ensimmäiseen ydintoimitukseen, pystymme katsomaan asioita sellaiselta yritystason näkökulmalta. Työkalussa on paljon erilaisia ​​esimerkkejä siitä. Meillä on eräänlainen pikkukuvanäkymä; meillä on enemmän ruudukkoa vastaava näkymä. Meillä on joustavuuden suhteen myös sinulla on myös verkkopohjainen konsoli. Verkkopohjaisella konsolilla on muita käytettävissäsi olevia näkymiä, kuten avainkortit ja vastaavat. Mutta asia on, että sinulla on kyky sellaisenaan katsoa ja nähdä asioita Mutta kun ongelmia ilmenee, kaivaudut hiukan kauempana työkaluun ja näet tosiasiallisen ongelman Lems, ja jollain tapa ymmärtää ja tietää mitä tapahtuu. Ja se on tietenkin erittäin tärkeää.

Nyt siinä suhteessa, että pystymme todella näkemään, mitä tapahtui aiemmin; Jos tarkastelen ongelmaa, joka tapahtui eilen tai viikko sitten, niin tiedät, että tässä tilanteessa sinun on voitava mennä tiettyyn SQL-esiintymään. Ja hyvä uutinen on, että jos tiedät, mihin aikaan kyseinen ongelma tapahtui tuotteessa, voit siirtyä suoraan historiaselaimeen. Ja voin osoittaa tietyn kellonajan; se voi olla peräisin pari viikkoa sitten, se voi olla eilen. Mutta mistä päivästä valitsen kalenterista, minulle esitetään sitten erilaiset kyselyvälit. Tässä tapauksessa nyt näen tosiasiallisesti sen, mitä olisin nähnyt, jos katselin konsolia 20. huhtikuuta kello 13.37.

Joten voin palata ajassa taaksepäin, ja sitten kun teen sen, kaikki täällä näkyvät eri välilehdet heijastavat kyseistä ajankohtaa, mukaan lukien kyselyt, jotka ovat saattaneet olla menossa huonosti, mukaan lukien ehkä, jos Minulla oli istuntoja estämisen kanssa. Kaikki sellaiset asiat näkyisivät työkalussa, ja se antaa minun tietenkin hyödyntää tätä historiallista tietoa voidakseni korjata ongelman. Kun nyt puhumme historiasta, tässä huomion arvoinen asia on se, että se ei ole vain historian käyttäminen ongelmien korjaamiseksi. Tuo historia on luonnollisesti erittäin arvokas muista syistä. Yksi isoista on kyetä tekemään päätöksiä tehokkaasti ja pystymään tekemään päätöksiä nopeasti, oikeilla tiedoilla. Joten koko tuo historia, kaikki keräämämme tiedot, voimme raportoida vastaan.

Jos joku tulee luokseni ja sanoo: "Sain tämän todella hienon uuden sovelluksen. Se muuttaa maailmaa sellaisena kuin tiedämme sen. Voi, muuten se vaatii tietokannan, ja voi muuten se kiinnittää todellakin I / O koneessa, jossa tietokanta on. " Jos tiedän, että keskustelen siihen, voin hyödyntää näitä tietoja voidakseen antaa kaikkien tuotantopalvelimieni sijoituksen, joka perustuu ehkä seitsemään viimeiseen keräyspäivään. Pystyisin nopeasti päättelemään, mitkä tapaukset ovat järkevimpiä käyttää tietokantaa. Joten juuri tällainen historiallinen tieto on myös selvästi erittäin arvokasta.

Itse kyselyjen suhteen; kyselyjen tarkastelussa meillä on paljon erilaisia ​​tapoja tehdä tämä työkalulla. Ja jota haluan tarkastella, on kyselyn odotusnäkymä, koska kysely odottaa näkymää on erittäin hyödyllinen arvioitaessa. Jos minulla on pullonkaula, jota tapahtuu, pystyä tunnistamaan olennaisesti kaikki eri alueet, jotka vaikuttavat kyseiseen tiettyyn kyselyyn; ei vain itse kyselyn ja kyselyn vaikutuksen, mutta tiedät myös, mistä sovelluksesta se tuli, mistä istunnosta se tuli, mikä käyttäjä kutsui sitä ja kaikki nämä asiat, voin nähdä selvästi, että tiedot reaaliajassa, mutta minulla on myös kyky tarkastella näitä tietoja menneisyydestä. Ja niin se on yksi asioista tässä, ja potkaisin käsikirjoituksen, mutta minun on odotettava, että se ilmaantuu.

Odotettaessa sitä haluan - ja tiedän, että olemme lyhyessä ajassa, joten halusin jutella jonkin verran myös varoitusilmoituksen ennakoivasta ilmoittamisesta. Ja kun puhut sellaisista asioista, kuten sanoin, ennakoiva osa, siellä on paljon työkaluja, jotka varoittavat. Vaikea osa ei ole sähköpostin lähettämistä. Vaikea osa ei kirjoita tapahtumalokiin tai luo SNMP-ansaa. Vaikea osa tietää, milloin hälytys on lähetettävä oikeaan aikaan. Ja niin sen mukana tulee paljon, että joudut tekemään laskelmia, ymmärtämään: "Mikä se on kyseisestä tapauksesta ja mikä on normaalia, kun se liittyy kyseiseen esiintymään?"

Ja niin kaikille niille mittareille, joiden kanssa on järkevää tehdä niin, me perustimme ne mittareihin. Näytämme sinulle lähtötason, näytämme sinulle kynnysarvon, johon se on tällä hetkellä asetettu. Ja sitten toinen hieno asia siinä, että sanotaan, asetan kynnysarvoni tässä tapauksessa kuuteen ja kymmeneen juuri tämän esimerkin kohdalla. Kuuden viikon kuluttua, jos palaan takaisin tähän tapaukseen, tämä perustaso voi muuttua täysin, koska yksi asioista, joita teemme laskettaessa perustasoa, on oletusarvoisesti liikkuva seitsemän päivän laskelma. Joten se antaa minulle aina ajantasaisen version perustasosta. Ja mitä tapahtuu, jos perustaso nousee kynnysarvoihini? Tässä tapauksessa voin nähdä ja hälyttää suosituksia, joissa sanotaan pohjimmiltaan: "Hei, sinulla on kynnysarvo, joka on todennäköisesti asetettu väärin, joka liittyy mihin näemme kynnysarvon olevan ja selvästi missä lähtötaso on, olet todennäköisesti menossa saada hälytys jostakin, mikä on normaalia. "

Joten sen sijaan, että käsittelisin oiretta normaalille asialle, pystyn tunnistamaan sellaisen tilanteen, jossa todellinen kynnysarvo on asetettu väärin. Ja mitä sen avulla voin tietysti tehdä, on asettaa kynnysarvot sen mukaan, mihin saan hälytyksen. Tiedän, että se on pikemminkin toimintakehotus verrattuna tutkimukseen nähdäkseni, onko kyse todella ongelmasta. Ja mielestäni osa työkalusta on todella hyödyllistä lähtötason kannalta ja laskentakyvyn kannalta.

Nyt tällä tuotteella sinulla on mahdollisuus tosiasiallisesti useisiin perusviivoihin; voit asettaa ne eri ajanjaksoiksi, ja voit dynaamisesti säätää kynnysarvoja perusviivojen perusteella, mikä on myös erittäin tärkeä osa sopeutumista muutoksiin, joita tapahtuu päivittäin SQL Server -esimerkkeihisi . Nyt, tässä tapauksessa tässä, peitämme tavallaan paljon kynnysarvojen asetuksia ja näytämme sinulle perusviivat. Mutta mitä tulee todellisiin hälytyksiin, itse ilmoitus, Diagnostic Manager -sovelluksen hieno asia, on se, että se tarjoaa sinulle useita hälytysprofiileja. Joten jos sinulla on esimerkiksi päivystysprofiili, joka on 2: 00–5: 00, niin minulla voi olla juuri kyseiselle aikavälille erityinen profiili ja voin asettaa täällä kaikki ehdot ja asianmukaiset asetukset vastaukseksi.

Nyt vastauksessa on se, että joissain tapauksissa kyllä ​​voin lähettää sähköpostia tai voin ampua ja luoda SNMP-ansaa tai kirjoittaa tapahtumalokiin. Meillä on paljon muita asioita, joita voimme tehdä, mutta kun puhun DBA: n kanssa, he todella pitävät siitä, että useimmissa tapauksissa suuri osa suoritetusta työstä on toistuvia. Se on juttuja, jotka he tietävät tarkalleen, kun ongelma tapahtuu, mitä tehdä sen korjaamiseksi. Heidän on vain mentävä ja puututtava asiaan. Ja niin kasvaessaan ympäristöäsi, kun sinulla on enemmän tapauksia, siitä tulee paljon vaikeampaa. Joten yksi niistä työkaluissa tekemistä asioista, jotka mielestäni on huomionarvoista, onko sinulla kyky asettaa ehto, mutta perustuen siihen ehtoon voida asettaa vastaus komentosarjan suorittamiseen, job, suorittaa suoritettavan. Ja asia on, jos päätät suorittaa komentosarjan, voin käyttää parametreja sen komentosarjan sisällä, joka on suorituksen aikana, täynnä todellisia tietoja.

Joten jos tietyssä tietokannassa on ongelmia, skripti suunnitellaan toimimaan juuri sitä tietokantaa vastaan, jossa ongelma esiintyy. Joten voit käsitellä ongelmia dynaamisesti automatisoidulla tavalla, ja silloin voin silti vastaanottaa sähköpostia palatakseni ja kertoakseni minulle, että "hei oli ongelma, mutta muuten, se korjattiin". Skripti ajettiin, ja DBA: na tiedät siitä, mutta sinun ei oikeastaan ​​tarvinnut mennä sisään ja puuttua asiaan. Nyt samalla proaktiivisuuteen liittyvällä huomautuksella meillä on tietysti täällä myös toinen ominaisuus, joka on "Analysoi" -ominaisuus. Ja mitä tämä tekee, se tekee säännöllisen tarkistuksen SQL-esiintymää vastaan. Ja joissain tapauksissa se tekee syvemmän sukelluksen mitä etsii. Suoritetaan esimerkiksi hypoteettinen hakemistoanalyysi. Lisäänkö hakemisto? Poistanko hakemiston? Ja kaikki sellaiset asiat tietysti auttavat performanssissani, mutta jälleen kerran on kyse proaktiivisuudesta. Kyse on siitä, että pystymme tekemään päätöksiä ennen tavaroiden taukoja ja saamaan sen toimimaan paremmin. Ja niin, monissa tapauksissa, sitä todella yritämme tehdä täällä.

Palaa takaisin Query Waits -kohtaan, josta puhumme aiemmin; kuten näet, täällä on iso piikki. Suoritin aiemmin käsikirjoituksen, joka aiheutti vain jonkinlaista odotusaktiivisuutta, ja kuten aiemmin mainitsin, meillä on todella ainutlaatuinen tapa, jolla voit tutkia näitä tietoja. Jos haluan nähdä, mikä sovellus se oli; Näen, että se tuli NoSQL-sovelluksesta. Voisimme nähdä tietokannan, johon se oli sidottu, istunnon, käyttäjän, ja sitten haluavani järjestää tämän myös odotusteni suhteen. Joten voin sanoa, että kaikista tuon ajanjakson aikana tapahtuneista odotuksista tapahtui eniten? Ja jos huomaan, että kun se tapahtuu eniten, niin todella hieno asia on, että voin porata tuon odotustyypin ja näen kaikki komennot. Jos katsot tätä, he saivat odottamisen tapahtumaan. Ja näen myös ensisijaisesti, mikä sovellus se oli, joka sai sen odottamaan.

Joten se tulee ulos kuin kipeä peukalo. Voin heti mennä sanomaan: "Tämä on sovellus, joka aiheuttaa pullonkaulani. Mikä sitten oli kysely, jota ajettiin? Mikä käyttäjä suoritti sen? Minkä tietokannan kanssa se toimi?" Ja niin edelleen. Joten toivottavasti sillä on järkeä, ja se auttaa myös varmistamaan, että sinulla ei ole viivettä ympäristössäsi, koska se liittyy tietokantoihisi. Toivottavasti tästä on apua. Aion jatkaa tässä vaiheessa ja välittää sen takaisin, ja luulen voimme jatkaa sieltä.

Eric Kavanagh: Toki asia. Joten luulen heittävän sen vain päivän asiantuntijoillemme. Mark, ehkä haluat ensin kommentoida ja kysyä muutama kysymys. Sitten Dez, voit soittaa sisään.

Mark Madsen: Kyllä, kiitos, nauttin siitä todella. Se on paljon älykkäämpi seuranta kuin olen tottunut näkemään. Olen kiinnostunut tämän takana olevien tietojen hallinnasta; niiden metrien hallinta, joita voit seurata, ja tiedät, esimerkiksi kojetauluilla etsiessään esimerkiksi perusviivojen siirtämistä, joka on yksi lemmikkisi kivun pisteistä. Kuinka käsittelet näitä tietoja, ja sen toinen osa on, kuten tiedät, lähtökohtaisissa mittareissa, kuten sellainen muutos - pystytkö myös siirtämään kynnysarvot automaattisesti, niin että minun ei tarvitse palata takaisin ja nollata kynnysarvot käsin, kun perustaso muuttuu?

Bullett Manale: Teet, ja niin hieno asia siinä, että voit päättää siitä. Voit tehdä kumman tahansa. Voin asettaa kynnyksen ja tehdä siitä staattisen asetuksen tai voin tarkistaa ruudun sanoa: "Tee tästä dynaaminen kynnysarvo, joka muuttuu perusviivojeni muuttuessa." Ja minulla on kyky ja työkalu asettaa oletusikkuna. Mutta silloin, kun minun on tarpeen, minulla saattaa olla erillinen perusvirta-ikkuna esimerkiksi ylläpitoikkunastani kello 2:00, sanotaan esimerkiksi 5:00 am, koska verotan Suorittimen prosessori, asemani ja kaikki muu, koska silloin teemme kaikki kunnossapidot. Se sitten automaattisesti, jos olisin valinnut sen tekemään niin, säätäisi kynnysarvot automaattisesti sen ulkopuolelle, mikä on normaalia niille mittareille, jotka Valitsen sen tekemisen. Sen avulla voisin tehdä sen. Periaatteessa työkalussa on kyky asettaa aikaikkunat, jotka ovat lähtötason ikkunat, ja kutakin ikkunaa voidaan käsitellä erillisenä kokonaisuutena suhteessa dynaaminen perusviivojen säätö, joka voidaan tehdä, ja voit lisätä niin monta ikkunaa perustasoon kuin yo sinun on, jos se on järkevää. Sinulla voisi olla viikonloppuikkuna, viikonpäivä työaikana, ylläpitoikkuna, joka tapahtuu keskellä yötä ja niin edelleen ja niin edelleen.

Mark Madsen: Kiitos.

Bullett Manale: Palaan kysymyksen ensimmäiseen osaan, ja meillä on, ja keräämme kaikki nämä tiedot. En todellakaan puhunut arkkitehtuurista, mutta meillä on taustatietovarasto, että sinulla on täydellinen hallinta näiden tietojen säilyttämisessä, mutta meillä on myös palvelu, joka toimii keskellä yötä ja menee ja tekee kaikki lähtötilannelaskelmamme ja se ottaa tämän tiedon, kerää ja tekee siitä järkevän. Ja tietysti, tämän lisäksi, sinulla on myös lukuisia raportteja, joita voimme käyttää raportoimaan lähtöviivoja vastaan, tietyille mittareille. Ja sinulla on jopa mahdollisuus vertailla saman palvelimen perustasoja samassa mittayksikössä eri ajanjaksoina. Voit nähdä, onko tapahtunut eroja, tai mikä on delta. Siellä on myös paljon sellaisia ​​vaihtoehtoja.

Eric Kavanagh: Dez.

Dez Blanchfield: Yksi nopea kysymys, joka minulla on sinulle - siellä on laaja kirjo mitä tämä työkalu voi tehdä. Näetkö sen käyttöönoton varhaisessa kehitysvaiheessa vai onko se edelleen ensisijaisesti tuotantoympäristön työkalu? Toisin sanoen, saavatko kehittäjät pääsyn ja käyttävät sitä varhaisen kehitystyönsä kautta ja testaavatko sitten integrointivaihetta? Vai käytetäänkö sitä edelleen pääasiassa tuotantoympäristöissä?

Bullett Manale: Sanoisin, että suurimman osan niistä näemme sen tuotantoympäristöissä. Se riippuu tilanteista, mutta suurimmaksi osaksi sanoisin ensisijaisesti tuotannon ja teemme - ja on myös totta, että mainitsemme, että meillä on erilainen hinnoittelu dev- ja testiympäristöihin, joten se on hieman houkuttelevampi. Me näemme ihmisten käyttävän sitä niissä ympäristöissä, mutta sanoisin, että jos minun pitäisi antaa sinulle vastaus tavalla tai toisella, sanoisin, että se on lähinnä edelleen tuotantoympäristöjä, joissa näemme ihmisten tekevän investointeja tähän tuotteeseen .

Dez Blanchfield: Toki, kyllä, ja oli mielenkiintoista kuulla, että sinulla on erilaisia ​​hinnoittelupisteitä, koska tietysti työpaikat ovat erilaisia ​​ja mitä raskaampia työpaikat ovat, jos kaikki todellinen työ tehdään. Mutta näen paljon organisaatioita, etenkin julkishallinnossa ja varmasti puolustuksessa, joissa kehitys on nyt samantasoista investointeihin työkaluihin ja järjestelmiin kuin tuotantoympäristöihin, koska ne tekevät paljon enemmän etukäteen tehtäviä testauksia. Esimerkiksi puolustuksessa on ryhmiä, jotka suorittavat miljardeja testejä, satoja miljardeja testejä sovelluksille ja järjestelmille ja työkaluille ja seuraavat niitä ennen kuin ne edes menevät integraatiotestaukseen, koska he haluavat varmistaa, että olemassa on rakennettu koodi ja tietokanta se istuu sen alla. Se joutuu sadan miljoonan iteraatioon tai jotain, kun olet ampumassa kenttällä jollekin, se ei mene "räjähtää".

Bullett Manale: Toki.

Dez Blanchfield: Kokemukseni mukaan vanhan koulun tietokantamaailmassa ajattelen, että tietokantaympäristö on jotain, joka vain jäi tietoihin ja joista jotkut tietävät, nähdään hyvin harvoin ja niistä puhutaan hyvin harvoin, joten kun saamme pisteen nyt työkalujen ja sovelluksia kehitetään, etenkin analyyttisten alustojen kanssa, ne ovat nyt matkapuhelimissamme ja laitteissamme. Näetkö asiakkaiden johtavan tietokannan suorituskyvyn ja tietokannan hallinnan keskustelua tavallisempaan päivittäiseen keskusteluun pelkästään puhdasta tekniikkaa vastaan? Ja tiedän, että mainitsit aikaisemmin, että puhut pääasiassa DBA: ien kanssa, mutta onko nyt olemassa suuntaus, jossa se on yleisessä sanastoon, näetkö ihmisiä, joissa he keskustelevat näistä aiheista, toisin kuin pelkkää nörttiä?

Bullett Manale: No, se on vaikea sanoa. Tarkoitan, kuten useimmiten sanoin, ihmisiä, joiden kanssa myymisprosessissa olemme joka tapauksessa tekemisissä, ovat ammattilaiset, jotka ovat DBA: t. Joten kysymyksesi suhteen sanot vain: "Tietääkö IT-organisaation ihmiset yleensä tietokannasta tietokantaa?" Luulen, että kysymys on ja sanoisin todennäköisesti, että vastaus on "kyllä". En luultavasti näe sitä niin paljon päivittäin perustuen siihen, missä olen, mutta luulen, että jos ymmärrän kysymyksesi, se olisi vastaukseni.

Dez Blanchfield: Kyllä, se on okei. Se on luultavasti ladattu kysymys, anteeksi, koska ilmeisesti teidän tärkeimmät intressit maailmassane ovat asioiden tekninen puoli. Olen utelias siinä, että päivittäisessä toiminnassani näen organisaatioiden alkavan tuoda tämä keskusteluun hyvin varhain. Joten kun he puhuvat uusista aloitteista, uusista hankkeista, uusista työohjelmista, yksi heti tulevista asioista on "Kuinka seuraamme sitä, miten seuraamme sitä, miten käsittelemme asioita, kun ne ilmenevät, toisin kuin käynnistäminen, elävä? "

Bullett Manale: Sanoisin, että -

Dez Blanchfield: Anteeksi, mene eteenpäin.

Bullett Manale: Aioin sanoa, että näen suuntauksen, jonka minun pitäisi sanoa - tiedätkö, monta kertaa aiemmin saisit: "Meillä oli ongelma, joten tarvitsemme nyt työkalun. " Ja mielestäni näemme hiukan enemmän hyväksyntää sen suhteen, että työkalu on paikoillaan ennen ongelman ilmenemistä, jos se on järkevää. Joten sanoisin, että siitä tulee ehdottomasti normaalimpaa, tiedät: "Hei, tarvitsemme seurantatyökalua, tarvitsemme jotain." Ja ihmiset varmasti näkevät tämän tuotteen arvon, koska kuten aiemmin totesit, vain lisäämällä DBA: t ja lisäämällä uusia ilmentymiä, tarvitset jotain, joka hallitsee sitä. Tarvitset jotain, joka auttaa hallitsemaan sitä, ja siksi näemme myös paljon hyväksyntää tämän tuotteen ympärillä tai meillä on.

Dez Blanchfield: Nopea kysymys. Missä tämän täytyy elää? Pitääkö sen istua lähiverkon läpikotaisin, datakeskuksen sisällä, mahdollisimman lähellä tietokantaympäristöjä, vai onko se mukava sijoittaa jonnekin, mahdollisesti pilveen, kolmannen osapuolen pilveen, jolla on jonkinlainen joko VPN-tunneli tai etäyhteys eri ympäristöihin? Missä sen täytyy istua ympäristön ja seurannan suhteen?

Bullett Manale: Arkkitehtuurin kannalta on olemassa tausta-arkisto ja se on SQL Server-tietokanta. Meillä on konsoli, joka voi olla joko rasva asiakas tai ohut asiakas; annamme sinulle mahdollisuuden molemmista. Ja meillä on myös ohut asiakas, joka on todellakin suunnattu erityisesti mobiililaitteille. Mutta suhteessa siihen, missä tämä voi todella istua; se voi istua ympäristössä, ja siitä todellakin vaikein osa on, koska suuri osa kerättävistämme tiedoista vaatii joissakin tapauksissa tai monissa tapauksissa hallinnollisia oikeuksia. Nyt emme saa sinua tekemään niin; Jos haluat, voit kerätä tietoja ja vain asioista, joita emme voi kerätä, koska meillä ei ole järjestelmänvalvojan oikeuksia, annamme sinun vain nähdä näitä tietoja, jos se on sinun tekemäsi valinta.

Aromista riippuen, kuten jos puhut AWS: stä, joissakin ympäristöissä, se toimii paremmin kuin toiset, mutta varsinaiseen ympäristöön saakka, mikä tahansa, tarvitaan tyypillisesti joko SA-todennuksen avulla tietojen kerääminen esiintymistä vastaan. Tai jos kyseessä on epäluotettava verkkotunnus, niin yleensä kun haluat tehdä sen, mutta useita verkkotunnuksia; niin kauan kuin heidän välilläan on luottamus, voimme kerätä niitä vastaan. Sillä ei ole väliä, onko se LAN-verkossa vai WAN-verkossa, itse kokoelma on melko vähäinen kerättävän tiedon määrän suhteen. Jos meillä on riittävä koko WAN-yhteyttä, se ei ole ongelma. Olen nähnyt ympäristöjä, joissa heillä on sivuliikkeitä, joissa heillä on SQL-palvelimia kaikkialla Yhdysvalloissa. Ja se on yksi palvelin jokaisessa näissä eri paikoissa, ja he seuraavat sitä keskitetysti. Hankala osa on vain varmistaa, että sinulla on kunnollinen määrä yhteyksiä tehdäksesi niin. Toivottavasti se vastaa kysymykseesi, se oli tavallaan koko kartalla.

Dez Blanchfield: Se on ehdottomasti. Kiitos. Joten, kaksi nopeaa kysymystä, jotka ovat tulleet osallistujien läpi tänä aamuna; yksi on: mikä on vaikutusta - usein näemme järjestelmänvalvontatyökalujen tuottavan kuorman itse seuraamalla vain asioita, joten kysymys oli, pahoillani, että se vieriti nyt näyttöäni, mutta vain sanamuotoon; tuotammeko kuormaa itse? Onko työkalulla mitattavissa olevia vaikutuksia, vain seurataan ympäristöä, vai onko sillä vähäinen vaikutus?

Bullett Manale: Aina tulee olemaan pieni vaikutus, koska sen on kysyttävä SQL Server -ilmentymää tietojen palauttamiseksi. Kysymyksesi, kuten sanoit, on "Onko se merkityksetön vai onko se merkittävä?" Ilmaisimesta osoittavan laatikon ulkopuolella se on merkityksetön. Olemme tehneet tätä jo, kuten sanoin, jo jonkin aikaa. Meillä on yli 20 000 asiakasta, ja voin vakuuttaa teille, että mikäli sillä on merkittäviä vaikutuksia suorituskykyyn, emme toimi. Tämän ansiosta käyttäjän annetaan myös päättää, mitä he haluavat seurata. Joten mielestäni on tärkeätä mainita, että jokainen ympäristö on hiukan erilainen.

Esimerkki olisi kyselyiden seurantakomponentin kanssa yksi niistä asioista, jotka meillä on kyky tehdä, onko voimme asettaa kynnyksen sille, mitä pidät normaalisuusrajana. Joten se voisi perustua kyselyn suorittamisen aikaan. Se voisi perustua suorittimeen, I / O, mutta sanotaan esimerkkinä, että olen asettanut suorittamisajani nollaan millisekuntiin. Tosiasiallisesti sanon, että työkalu on kerätä kaikki kyselyt, jotka ovat kuluneet viimeisestä vetämisvälistä lähtien, ja tehdä myös tämä osa historiallisesta kokoelmassani.

Nyt kun teemme niin, aiomme kerätä mitä tahansa kyselyjä, joita olimme laatikolla suorittaneet viimeisen äänestyksen jälkeen. Nyt se on valinnainen, ja käyttäjällä on kyky tehdä se. Sanommeko: "Se mitä sinun pitäisi tehdä"? Ei. Mutta annamme myös sinulle mahdollisuuden tehdä se, jos haluat tietonäytteen, jonka avulla voit kerätä näitä tietoja. Joten yleisesti ottaen sinulla on keinot -työkalulla, joka asettaa sen ja virittää sen haluamallasi tavalla, mikä sopii sinulle. Mutta sinulla on kyky avata se todella haluamallasi tavalla ja kerätä paljon lisätietoja, joita et välttämättä välttämättä säännöllisesti kerätä, jos se on järkevää.

Dez Blanchfield: Kyllä, ehdottomasti. Tiedän, että juoksemme hiukan kauan, mutta haluan heittää sinulle kaksi todella hienoa kysymystä ennen kuin kietoan. He molemmat tulevat suoraan minuun, mutta mielestäni on parasta, jos vastaat heille. Kysymys yleensä oli: "Mikä on työkalun ulottuvuus olemassa olevien järjestelmien tuntemiseen?" Joten voimmeko vain kytkeä tämän pistorasiaan ja saada se automaattisesti tunnistamaan olemassa olevan alustan ja tiedämme, mikä on kyseisen alustan normaalia, ja heti nousee kuten Mark puhui aikaisemmin? Jotkut alustatietoista alustoista asettamalla, tiedät, en tiedä, se voi olla Microsoft Dynamics. Mikä on alustan tietämyksen laajuus normaalin ja joissain nykyisistä hyllytyökaluista, joita käytetään liiketoiminnan ympärillä?

Bullett Manale: Sanoisin, että yleisesti ottaen, kun alamme kerätä tietoja SQL-ilmentymästä, työskentelemme aluksi parhaiden käytäntöjen kanssa, kynnysarvojemme ja niiden mukaan, mihin ne on asetettu. Tästä huolimatta tunnustamme myös, että kuka tahansa puhut parhaiden käytäntöjen kannalta, jokainen ympäristö on erilainen. Mitä teemme alun perin, keräämme vain tietoja, ja mitä suosittelemme ihmisille, voit kokeilla tuotetta 14 päivää pidempään, jos tarvitset. Mutta noin kahden päivän kuluttua alat nähdä perustiedot täyttyvän. Kun sillä on tarpeeksi näytetietoja työskennellä, se alkaa tarjota sinulle kontekstin perustason suhteen, missä alue on, ja kaiken muun sellaisen. Sitten, jos haluat, voit asettaa kynnysarvot automaattisesti kerättyjen tietojen perusteella. Alkuperäisen keräyksen ja äänestysten tekeminen vie vähän, jotta pystymme alkamaan määrittämään, mikä on normaalia, jotta voit aloittaa kynnyksensiirron.

Mutta mielestäni on syytä huomata myös se, että kun muutat näitä kynnysarvoja, se voidaan tehdä tapauskohtaisesti ryhmäkohtaisesti. Se voi olla erityinen yhdelle ilmentymälle tai voit tehdä sen kaikkia kaikkia esiintymiäsi vastaan, samoin kuin kykyä luoda asioita, kuten malleja, jotta voit sanoa: "Tämä on tuotantoilmentymä, mutta haluan tämän mallin osoittaa sille. " Ja joten kun uusi tuotantoesimerkki tulee verkkoon, sovellamme näitä kynnysarvoja automaattisesti siihen, koska siinä on samantyyppinen laitteisto ja sillä on yleensä samat työkuormat, joten voisimme tehdä sen myös tällä tavalla. Toivottavasti se auttaa kysymyksen kannalta.

Dez Blanchfield: Se on ehdottomasti. Itse asiassa vastasit tosiasiallisesti toiseen kysymykseen, joka juuri tuli minulle, ja se oli: "Onko olemassa kokeilulataus?" Voin vastata siihen, tiedän. Olen varma, että vahvistat, että lataus on ilmainen, ja luulen, että sanoit, että se oli 14 päivää verkkosivustolta. Voit ladata sen ja pelata sen kanssa. Luulen kuitenkin nopeasti, että "Millaista ympäristöä tarvitsen, jotta voin suorittaa kokeilun? Voinko käyttää sitä kannettavalla tietokoneellani ja pelata sen kanssa vai tarvitsenko todella palvelinta?"

Bullett Manale: Tärkein asia, jota se tarvitsee, on arkisto, SQL Server-tietokanta, joka on vähintään 2005. Muuta kuin joitain, on joitain minimaalisia resurssivaatimuksia, .NET-vaatimus, ja siinä se on. Joten on kyse vain tuotteen asentamisesta ja tietokannan luomisesta.

Dez Blanchfield: Täydellinen. Viimeinen kysymys, jonka heitän sinulle, koska olemme vain myöhässä, mutta nopeasti, noin kaksi tai kolme ihmistä kysyi minulta: "Pitäisikö minun olla DBA, jotta pystyn oikeasti nousemaan ja ajamaan tämä, ja pelaatko sen kanssa? ”

Bullett Manale: Ei. Sanoisin, että jos olet DBA, sinulla on työkalun eri käyttötarkoitukset. Tarkoitan, että on todennäköisesti vähän enemmän arvoa, jos olet kokenut DBA. Näet paljon syvempää työkalua, jonka pystyt hyödyntämään. Mutta myös uutena DBA: na tai edes henkilönä, jolla ei ole DBA: ta, meillä on paljon suosituksia, ja olen tällä sivulla juuri nyt. Nämä suositukset esitetään säännöllisesti, ja erittäin hieno asia suosituksissa on, että ne antavat sinulle syyt suositusten tekemiseen. Mutta lisäksi heillä on myös linkkejä ulkoiseen sisältöön, jotka kuvaavat yksityiskohtaisemmin syitä, miksi myös nämä suositukset tehdään. Joten se linkittää ulkoisiin Microsoftin verkkosivustoihin, blogeihin ja kaikenlaisiin sellaisiin juttuihin, se on ulkoista.

Mutta vastaamiseksi kysymykseesi, se on sellainen, että tiedät, jos olet vanhempi DBA, täällä on asioita, luultavasti hyödynnät sitä, mitä et luultavasti olisi aloittelijana DBA. Mutta silloin se on myös eräänlainen oppimisväline, koska kun käyte läpi näitä suosituksia, alatte poimia joitain näistä asioista yksin suosituksia käyttämällä.

Dez Blanchfield: Fantastinen. Kiitos. Nautin demo-osasta. Esitys oli hieno. Demo oli upea. Nopeasti muistista, verkkosivustollasi on koko resurssikeskus, jota suosittelen ihmisille myös katsomaan. Muistan käynyt läpi eilen illalla saadakseni yksityiskohtia. Sinulla on koko joukko asioita, vain blogeistasi, tietoistasi ja keskusteluistasi muistiin saakka, sinulla on myös suurin osa tuotteesi dokumentaatiosta verkossa, eikö niin?

Bullett Manale: Kyllä, se on totta, ja mielestäni viittaatte sivustoon community.idera.com. Ja sitten yksi asia, jonka mainitsen myös, aiemmin kysyit: "Tunnistetaanko se ympäristöä?" Uusien ilmentymien tai ilmentymien lisäämisen suhteen meillä on toinen työkalu, joka etsii ilmentymät. Ja kyse on varastosta ja varaston hallinnasta. Haluan vain eräänlainen osoittaa teille siihen suuntaan, tapausten tosiasiallisen löytämisen kannalta. Mutta niin kauan kuin suorituskyky ja seuranta, kaikki sellaiset asiat, joista puhimme, siellä Diagnostic Manager toimisi.

Dez Blanchfield: Fantastinen. Katso, hyvä kattavuus. Nautin todella esityksestänne. Rakastin live-esitystä, ja kaikki on minusta tänä aamuna, koska tiedän, että olemme menneet luultavasti 10 minuutin ajan. Eric, välitän sinulle takaisin.

Eric Kavanagh: Hyvä on. Rakastin vain demoa. Olen iloinen, että teit demon. Olen iloinen, että meidän on otettava tämä kiva ja vaikea katsaus läpi kysymykset ja vastaukset.

Bullett Manale: Hienoa.

Eric Kavanagh: Koska tämä antaa ihmisille kuvan siitä, mitä katsot, ja se todella hämmentää minua ajattelemaan, että opimme vielä puhumaan näiden tietokoneiden kanssa, kun pääset siihen. Tarkoitan, että tämä diagnoositaso on melko hienostunut, ja se paranee joka päivä. Saamme paljon enemmän tietoa siitä, mitä todella tapahtuu. Mutta tarvitset todella ihmistä, jolla on huomioimatta nämä asiat, lukemassa sitä, laittamalla kognitiivinen kyky taakse mitä teet, eikö niin?

Bullett Manale: Kyllä, tarkoitan monissa tapauksissa - toivon, että voisin kertoa teille, että tämä on DBA-laatikko, mutta aivan liian monia asioita on meneillään. Tarkoitan, että annamme opastusta ja autamme, mutta päivän päätteeksi se vaatii ihmisiä tekemään päätöksiä esittämistämme tiedoista. En usko, että se muuttuu pian.

Eric Kavanagh: No, se on hyvä uutinen todellisille ihmisille, ihmiset.

Bullett Manale: Se on totta.

Eric Kavanagh: Haluat, että joku seuraa tätä, joukkue tarkkailee tätä, ja opit, kuten olet kuullut täältä Bullettilta, katsomalla näitä suosituksia, jotka aiot poimia mitä tapahtuu. Arvaan sen historian perusteella ja luulen, että olet käsitellyt tätä, Bullett, mutta hyvin nopeasti, että historia antaa sinun tunnistaa merkittävät mallit ja siten pystyä tunnistamaan ne, kun ne tapahtuvat tulevaisuudessa, eikö niin?

Bullett Manale: Se on totta. Yksi asioista, joita voimme tehdä, on seurata kyselyn suorituskykyä ajan myötä. Voimme myös selvästi katsoa muita asioita, kuten perusviivoja, ja nähdä niiden siirtyvän, ja tietenkin saada hälytyksiä ja vastaavia asioita, kun se tapahtuu, joten sinulla on ehdottomasti tämä kyky.

Eric Kavanagh: Se kuulostaa hyvältä, ihmiset. Emme olisi olleet kauan täällä, mutta halusin päästä niihin kysymyksiin. Kiitos paljon aikaa ja huomiosta. Arkistoimme kaikki nämä verkkolähetykset. Hyppää verkkoon Techopedia.com tai InsideAnalysis.com, näet linkit molemmista paikoista.

Ja sen kanssa olemme jäähyväiset. Kiitos vielä kerran, ihmiset, otamme sinuun yhteyttä ensi viikolla, kolme uutta verkkolähetystä ensi viikolla, tiistaina, keskiviikkona, torstaina. Joten puhumme kanssasi ensi viikolla, ihmiset. Pitää huolta. Hei hei.

Techopedian sisältökumppani

Techopedia Staff on sidoksissa Bloor-konserniin, ja heihin voidaan ottaa yhteyttä käyttämällä oikealla olevia vaihtoehtoja. Tietoja siitä, miten työskentelemme alan yhteistyökumppaneiden kanssa, napsauta tätä.

• Profiili
• Verkkosivusto