Av Techopedia Staff, 22. februar 2017
Takeaway: Vert Eric Kavanagh diskuterer databasestyring med Dr. Robin Bloor, Dez Blanchfield og IDERAs Binh Chau.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Ok, mine damer og herrer. Hei og velkommen igjen. Det er en onsdag, klokken er østtid og de siste årene betyr det at det er tid for Hot Technologies. Det er riktig, dette er vårt show med våre venner Techopedia - Techopedia.com. Sjekk dem ut på nettet. De får monstertrafikk, 1, 5 millioner unike besøkende i måneden. Det er mye nettrafikk. Temaet i dag, "DBAs drøm: Oppdagelse og ledelse over hele miljøet." Ja, det er et stort tema, spesielt for større organisasjoner. Det er et lysbilde om ditt virkelig, og nok om meg, slo meg opp på Twitter @eric_kavanagh, jeg prøver alltid å følge tilbake og delta i samtale der ute.
Igjen, vi snakker om databaseteknologier i dag og virkelig kunne forstå hva som foregår i et bredt landskap av databaseforekomster. Som mange av dere vet, når du begynner å vokse organisasjonen din, får du mange flere av disse tilfellene der ute og å holde et grep om det kan være litt av en interessant utfordring. Jeg husker faktisk for flere år siden, jeg hadde en flott samtale med en fyr som var direktør for datastyring for CIOs kontor ved Forsvarsdepartementet. Og jeg fortalte ham alle disse interessante tingene, vi hadde denne gode samtalen, og jeg fortalte ham min bakgrunnshistorie om lobbyvirksomhet for åpenhet i føderale utgifter, og han lo og sa: "Å, så det er huset ditt hvor jeg skulle sende det neste rovdyr drone streik. "Han sa, " Åpenhet i føderale utgifter? Jeg vet ikke engang hvor mange Oracle-lisenser jeg har her. ”Da jeg hørte det, kunne jeg virkelig sette pris på størrelsen på utfordringen som noen organisasjoner står overfor.
I disse dager er det mange interessante verktøy - vi får høre om det i dag - for å forstå hva som flyr rundt der ute, men selv for 20 år siden, var det en virkelig alvorlig utfordring. Når det gjelder organisasjoner på størrelse med DOD, kan du bare forestille deg at å få tak i det som kommer til å spare mye penger, det vil spare mye tid, det vil løse noen styringsproblemer; du ender med å løse flere utfordringer på en gang hvis du gjør denne typen ting riktig. Vi lærer om det i dag.
Vi har vår egen Dr. Robin Bloor på, sjefanalytiker for The Bloor Group. Vi har Dez Blanchfield, dataforskeren vår, som ringer inn fra under, Sydney, Australia. Og Binh Chau, senior produktsjef i IDERA, er også på banen.
Vi gjør #HOTTECH som hashtaggen - føl deg fri til å tweet bort under showet. Og vi stoler på dere for gode spørsmål, så vær ikke sjenert: still spørsmål når som helst ved å bruke spørsmål og svar-komponenten på webcastkonsollen eller det chattevinduet, uansett. Og med det skal jeg overlevere det til Dr. Robin Bloor. La meg gi ham nøklene til WebEx. Der går den, og tar den bort.
Dr. Robin Bloor: OK. Vel, her går vi, la oss gå videre til det første lysbildet. I Italia kaller de dem Stanlio og Olio, Laurel og Hardy. Tilbake på 1990-tallet, da alle var bekymret for år 2000, ble jeg involvert i flere år 2000-prosjekter. Og jeg dro til - la oss kalle dem et stort forsikringsselskap - og de oppdaget at de hadde over 500 applikasjoner som de ikke visste eksisterte på stordammen. De tok en oversikt over stordammen. Vel, i disse dager ble miljøvenlige miljøer langt bedre ivaretatt enn noe som kom senere, jeg mener, det er bare ikke noe spørsmål om det.
Jeg var veldig lamslått og jeg snakket med folk i organisasjonen, og de sa at det ikke var noe sentralt omfattende … det var ingen som var ansvarlige for å vite den informasjonen, du vet, i utgangspunktet. De tok aldri varelager over eiendelene sine. Og en database er en eiendel uten usikre vilkår, fordi den inneholder data og data er verdifulle. Hvor mange tilfeller er spørsmålet, og hvor er de egentlig? Dette er bare "Hva er en database?", Og grunnen til at jeg tenker sånn, en database er et skap som du kaster data i. Og jeg snakket med et nettsted nylig som hadde tusenvis av forekomster av Oracle. Oracle er en database som krever en DBA hvis du bruker den på en sofistikert måte.
Jeg spurte litt om det, og de sa at de, omtrent, jeg tror det handler om syv eller åtte DBAer i hele organisasjonen. Og jeg sa, du vet, "Hvem passer på de andre tusenvis av tilfeller?" Og de sa: "Vel, hva som skjedde der er at folk bare bruker det som et filsystem. Vi har en rekke databaser som er i store klynger der ytelsen virkelig betyr noe, og de har DBAer som står over dem hele tiden. Og så har vi tusenvis av andre databaser som ingen ivaretar i det hele tatt. ”Og jeg spurte dem nøyaktig hvor mange databaser, og de kom opp med, “ Vel, forrige gang Oracle reviderte det. ”De gjorde ikke revisjoner selv, du vet, noe som er litt interessant.
Men, du vet, det er grunner til å bruke en database. En database implementerer en datamodell. Den er der for å dele data: kan administrere flere samtidige forespørsler om data, implementere en sikkerhetsmodell, er ACID-kompatibel, er elastisk eller kan settes opp til å være spenstig, vet du. Det er grunnen til at vi har databaser. Men, du vet, det er ikke uvanlig å møte nettsteder med tusenvis av forekomster av SQL Server eller Oracle, og de fleste av dem blir bare brukt som filsystemer, i utgangspunktet. Og hvorfor skulle du opprette en ny forekomst, egentlig?
Jeg vet om utviklerteam at hvis de bygger en ny applikasjon, bygger de den i en silo slik at en gitt ny applikasjon vil ha en egen database. De ville ikke nødvendigvis prøve å lage et datalag av ting - jeg tror ikke det er god praksis. Men der igjen, vet du, hvis du har et veldig komplisert miljø, blir det veldig, veldig vanskelig å prøve å sette sammen alle databasene som er relatert til hverandre når det gjelder å ha data i dem der det er relasjoner. Forekomster blir opprettet for kopier.
Du vet, du kan ha hot standbys eller kopier for tilgjengelighetsformål, men du har også kopier eller semi-replikker i datamars. Og når datavarehusverdenen ble introdusert, spørsmålet om, du vet, hvor mange datamarkter som var der ute, og folk bare brukte dem som klonfiler, tok data ut av datavarehuset og ikke bryr seg særlig om ytelsen i føler at de bare vil gjøre som standardytelse. De fleste av disse menneskene visste sannsynligvis ikke engang at du faktisk kunne stille inn databaser. Jeg har sett design som har sharded data i karakteristiske masser for distribusjon.
Du vet, du får ofte denne replikasjonssituasjonen der du har flere depoter i en organisasjon, og de har hver en database, og hver er en skjær av en sentral database. Du får forekomster fra skjæring. Dårlige designbeslutninger - Jeg har sett at noen virkelig bisarre design foregår når det gjelder databaser der folk har laget separate databaser uten god grunn. Og som jeg har nevnt, databaser er filsystemer.
Og så er det test- og utviklingsmiljøene som må stilles opp og falle ned, men de teller alle som databaserte forekomster, og alle av dem trenger forresten å ha sikkerhet og alle de andre tingene som databasen forhåpentligvis gir. Forholdshensyn - en arbeidsmengde i en database kan bare optimaliseres for en bestemt forekomst. Hvis du virkelig er interessert i å ha absolutt den beste ytelsen, er det ikke nødvendigvis å gi deg den typen optimalisering å ha data avskåret i en mengde databaser.
Det er en grunn til ikke å lage falske forekomster av data. Blandede arbeidsmengder på den samme databasen som kontrapunktet kan føre til dårlig ytelse - spesielt bemerket av OLTP og stor spørretrafikk bare ikke blandes, aldri har blandet og sannsynligvis aldri vil blandes. Det er vanligvis best å konsolidere en database på servernivå i stedet for å ha flere VM-er. Men VM-er gir isolasjon; for noen mennesker er det en designbeslutning å isolere data fra andre data, slik at du vet om applikasjonen mislykkes, eller hvis databasen mislykkes, den ikke får søknaden min ned.
Problemet med det er selvfølgelig at du ender opp med å komme til neste punkt, som er databaselisensavgift. Disse varierer, men jeg har sett databaselisensavgifter bli et designkriterium fordi noen ikke ønsket å sprengte et bestemt antall, og derfor folk som designer systemer dårlig bare på grunn av måten databaselisensen fungerer på. Og det er den andre tingen: hvis du begynner å konsolidere alle databasene dine, er det verdt å merke seg at DBA-er er dyre. Det er ikke en så enkel ting å gjøre.
Et enkelt syn på verden - og dette er det siste lysbildet - det er et datalag, det er et transportlag og det er et prosesseringslag. Og all maskinvaren sitter under det. Det er egentlig ikke mulig å optimalisere datalaget uten å vite nøyaktig hva som er i det og hvorfor.
Og når det er sagt, skal jeg gi videre til min venn nedenunder, Dez Blanchfield.
Dez Blanchfield: Takk, Robin. La meg bare få sortert musen min her. Så jeg kommer til å gi oss et par anekdoter i dag fordi dette er et enormt tema og jeg kunne tilbringe to uker med en tavlemarkør og ha det moro med det, fordi jeg har hatt nesten tre tiår med opp- og nedturer i dette rommet .
Men først et mentalt visuelt bilde. Når jeg tenker på utfordringen vi snakker om i dag - og egentlig snakker vi om databasevekst, replikering og spredning og alle utfordringene som følger med det - ville jeg bare sette dette bildet av en gigantisk eik i vår sinn. Dette er berømte vakre trær, de starter som en liten eikenøtt, men de vokser til disse behemoths. Og når de gjør det, er de veldig store og rotete. Og som du kan se fra dette bildet, som en visuell metafor, hvis du vil, du vet, grener som går overalt og så kvister som kommer av disse og forlater på slutten av disse, og de er i tilfeldige, kaotiske former, og det er bare den biten vi kan se over bakken.
Jeg tenker på de som data i databasen, og under at det er en struktur med røtter og de tapper inn alle slags retninger. Men det virker veldig rent og fornuftig på overflaten av bakken der det er fint og flatt, men realiteten er at den er like gal under bakken som den er over bakken; vi ser det bare ikke. Og jeg bruker ofte dette når jeg begynner å tenke på hvordan jeg skal beskrive utfordringene vi snakker om i dag til organisasjoner fra styrerommet til teknologiene for å prøve å få dem til å visualisere hva som faktisk skjer i organisasjonene deres. Fordi det er så lett å se på en dataskjerm og se disse vakre feltene med rader og kolonner og tenke: "Vi har fått ordnet det, det er ikke så farlig." Men det er ikke tilfelle i det hele tatt. Og så er det på det tidspunktet jeg vanligvis treffer denne ene linjen som sier at databaser i tankene mine er som eikenøtter, du vet, de begynner i det små og vokser, men før du vet ordet av det, har du en skog med gigantiske eiketrær, og dermed det visuelle.
Så to anekdoter bare for å dele et scenario som vokste ut av kontroll og bare ikke kunne fikses, og så en annen som gjorde en lignende ting, men som kunne fikses, og jeg vil trekke frem nøkkelpunktet i dagens diskusjon rundt hvordan vi kom til det.
Det første var et scenario der en CIO med størst intensjon over tid uforvarende forårsaket en av de mest uventede og uønskede viltvoksene som bare vokste utenfor kontroll. Det var et scenario der en regjeringsorganisasjon med tusenvis av ansatte, veldig teknisk kyndige medarbeidere, krevde tilgang til systemene og verktøyene de kunne begynne å samarbeide med og automatisere mye av prosessene sine. De ønsket å komme seg vekk fra papirskjemaer, og de ønsket å lage online systemer, de ønsket å fange data og spore dem og overvåke dem og rapportere dem tilbake og presentere dem tilbake til sine jevnaldrende.
Og det er alle slags ting, det er ting fra folk dukker opp til kontorene deres og klokker på og logger seg på for sikkerhetsmessige formål helt til hvem som bestilte hva på kafeteriaen ved lunsjtider. Og så bestemte en velmenende CIO at Lotus Notes var en god ide fordi han hadde vært på en serie seminarer og IBM hadde gjort en god jobb med å slå den, og i riktig scenario ville det ha vært en flott avgjørelse, hadde det er gjort under kontroll. Men det som skjedde var i stedet for å overlate Lotus Notes til et team av tekniske mennesker for å sortere redskap i et miljø og deretter stille opp fornuftige verktøy og så videre og gi litt kontroll og styring rundt det, det som faktisk skjedde var at det ble distribuert til standarden driftsmiljø, SOE, slik at hvert skrivebord ble en server.
Og så ga de opplæring og praktiske notater og dokumentasjon for hele denne prosessen, og alle plutselig skjønte folk: "Ja, jeg har Lotus Notes på skrivebordet mitt!" Hva betyr dette, tror du? Vel, det betydde at tusenvis av veldig teknisk kunnskapsrike ansatte ble lært hvordan man skripter og skrev apper, effektivt, i Lotus Notes, lage små databaser som egentlig så ut som regneark, rader og kolonner og felt, og presentere dette lille nettgrensesnittet gjennom Domino.
Hvis jeg ønsket å fange informasjon om noe, kunne jeg bare lage en liten form og i et regneark-type grensesnitt, legge den inn i en fil, lage en liten Lotus Notes-database bak den og presentere den som en webapp og begynne å samle informasjon. Og det hørtes bra ut til det hadde kjørt i flere år, og plutselig de skjønte, våknet noen og sa: "Vel, vent på, hvorfor vises det 10.000 nye databasedrevne apper på LAN, og spesielt de siste 12 måneder? Hva skjer? ”Det som skjedde var at du i utgangspunktet ga folk en pistol, og den ble lastet og sikkerheten var av, og selvfølgelig skjøt de seg selv i foten.
Og det er dette flotte bildet her som jeg vanligvis tryller frem i tankene mine om en italiensk kunstner som gjør denne rare tingen der han får lastebil med hø og halm og dumpet midt i et kunststudio og deretter får en kurator for kunststudioet. å tilfeldig skyve en nål midt i den. Og så tilbringer han dager på live fôr, på kamera, går gjennom halmen og leter etter nålen i høystakken, som den var. Inntil etter hvert, etter timer og dager, finner han det og hopper opp og ned og blir spent. Og uansett, italiensk kunstner, hva kan du gjøre? Men det er ganske humoristisk, og hvis du noen gang har sett det på nettet, eller hvis du ser det på nettet, vil du finne det veldig katartisk.
Her er et mareritt-scenario der en velmenende teknisk person ga forretningsfolk - veldig teknisk kyndige forretningsfolk - et verktøy som skulle gjøre livet lettere. Men kort tid hadde vi spørsmål som hvem som sikkerhetskopierer dem, hvem som overvåker og støtter dem, hvor er disse dataene, hvilken struktur er dataene i, hvem som politiserer skjemaene, hva om jeg vil lage en annen versjon, hvilke data er i disse versjonene, kan jeg gjøre en integrasjonsreise for disse tingene?
Du kan trekke dine egne konklusjoner om hvordan det gikk, men det gikk ikke bra, og du kan forestille deg at bare hundrevis av terabyte med data, og ikke sikkerhetskopiert, sitter på, effektivt, PC-er eller bærbare datamaskiner på skrivebord, noen systemer som ikke engang var tilgjengelige fordi folk ikke skjønte når de stengte av den bærbare datamaskinen klokken 05:30 og tok den med hjem for å gjøre arbeid som ingen på LAN-en kunne få til den applikasjonen. Det endte ikke bra. Og en god del data måtte ryddes opp og manuelt manipuleres og føres tilbake til et fornuftig system; mesteparten av det ble bare utslettet og fjernet, fordi det bare ikke kunne tillates å spre seg videre.
Så min andre anekdote med ting på en veldig annen reise. Se for deg et scenario, du har dev, test, integrasjoner, systemintegrasjoner, tester av brukeraksept, produksjon, katastrofegjenoppretting, sikkerhetskopiering og sikkerhetskopi en til 99 og utover, du har oppgraderinger, oppdateringer og deretter demonstrasjonsmiljøer fra en til 99 og mer. Og plutselig sitter du der og fortsetter: "Vent, hva skjer, heng på, hvem bruker hva?" Du vet, dette er et mareritt som potensielt venter på å skje.
Men i dette scenariet det som skjedde, hadde jeg muligheten til å gå inn i en organisasjon som ønsket å hente ut en forretningsforvaltningsenhet fra sin kjernebankplattform og stå fram som en egen organisasjon i hovedsak en oppstart i en bedrift. Utfordringen var å ta vår forretningsforvaltning for formuestyring og alle menneskene og teknologien og dataene rundt dem i de offentlige tjenestene, lage en oppstart i vårt eget selskap og snekre den av slik at den kan kjøres på sitt eget merke.
Dette er en global leder innen bank, som jeg ikke vil navngi. Vi måtte hente ut selve virksomhetsenheten for formuestyring og alle tingene rundt den. Så alt i sin helhet, alt personalet, den fysiske infrastrukturen og flytte det inn i et nytt kontorlokale. Alle forretningssystemene, all programvaren, alle dataene, alle lisenser, kaller du det. Vel, du kan tenke deg at det så ut som et mareritt å starte med.
Og for å sette litt sammenheng rundt det, snakker vi om 78 systemer i den opprinnelige bankplattformen som støtter rundt 14 kjerneprodukter, som kan være omtrent tusen forskjellige tilbud. Hundrevis og hundrevis av live databaser i bruk, og når jeg sier i bruk, måtte vi flytte dem på stedet, så på en fredag ettermiddag ville de være i ett miljø, på mandag forventes de å være et annet sted og på lørdag og søndag måtte de ha dette krysset der transaksjoner gikk fra ett system til venstre, la oss si, for å visualisere det, til et annet system til høyre.
Rundt 15.000 kunder med utallige poster hver, og et ETL-mareritt fordi ingen av de 78 systemene på den ene siden ble matchet av systemer på den andre siden. Vi hadde helt ny bankplattform, nye systemer, ny programvare, nye databaser og nytt skjema. Så metadata, felt, rader, kolonner, poster, tabeller, du nevner det, ingenting stemte. Det er 14 forskjellige aktive utviklingsteam, ett for hvert produkt. Og da vi bygde dette miljøet, fant vi ut at da vi hadde utviklingstest, integrasjon, systemintegrasjon, test av brukeraksept, produksjon, katastrofegjenoppretting, demonstrasjonskopier, sikkerhetskopier, oppgraderinger, lapping - savnet jeg til og med en der - trening, for eksempel og utdanning, var det 23 versjoner av hvert av disse miljøene for hvert utviklingsteam.
Nå sitter du der, og plutselig begynner blodet å kramme og huden din blir kald og håret ditt står - det kan aldri ende godt. Vel, det viste seg, det endte veldig bra fordi det aller første vi gjorde, før vi til og med startet teknologidepartementet, var at vi gikk og fikk de riktige verktøyene. Og vi brukte verktøy, og ikke nødvendigvis mennesker, men folk som kjører verktøy. Vi brukte verktøy for å kartlegge dataene, vi brukte verktøy for å kartlegge databasene de bodde i, vi kartla alle metadata, skjemaene og helt ned til rader, kolonner, post og felt.
Vi visste hva vi kom fra, og deretter korrelerte vi det til kartet over hva vi satte på plass så langt bankbankplattformen så ut, og vi hadde en en-til-en-korrelasjon. Og alt som falt av i midten, opprettet vi et datarom der vi ville gå gjennom og manuelt kartlegge dem. Men før vi utførte installasjoner og installasjoner av disse miljøene i den nye verdenen, sørget vi for at hver enkelt post, hvert eneste bord, hvert felt, hver rad, hver kolonne, hver database og alle metadata rundt det, alle tillatelser og kontroller ble kartlagt, fra en til en. Og vi flyttet ikke en eneste ting før den korrelasjonen ble gjort.
Og så gikk ETL-stykket fra å være et mareritt til en ganske smertefri prosess med bare å validere kontrollene og prosessene som ble fulgt. Og vi kunne gjøre dette med jevne mellomrom, nesten hver time. Vi holdt på med overgang fra produksjon på den gamle verden til nye miljøer med dev, test, integrasjon osv., I den nye verden. Og dagen vi gikk live, etter en fem måneders prosess for å gå live etter en måned med testingen, og deretter om seks måneder var det online og aktivt, vi hadde bare ett problem, og problemet var at noen glemte passordet og det måtte tilbakestilles. Det var det eneste problemet hadde, og som egentlig skapte omtrent en times stress av folk som trodde at noe hadde gått galt - det viste seg at passordet gikk ut og de glemte hva det var og måtte tilbakestille det.
Du kan forestille deg det scenariet, sammenlignet med Lotus Notes-miljøet der noen hadde store intensjoner, men ikke tenkte gjennom utfordringen, og neste ting vi måtte gå og prøve å kartlegge alle disse dataene og hoveddelen av den måtte avskrives og det var bare et stort tap av tid og krefter og ressurs og moral. Til et scenario der vi, når det er riktig planlagt og riktig utført og levert riktig med de riktige verktøyene, fikk et flott resultat.
Og så dette punktet bringer meg til denne ene linjen - før jeg overlater til vår kollega å snakke om hva IDERA har for å løse akkurat denne utfordringen - er at i dagens verden hvor stadig systemer drives av databaser, er det ikke bare et pent, men for meg er det et faktum, det er en nødvendighet at smarte verktøy etter min erfaring er den eneste måten å administrere dataoppdagelse, datahåndtering i skalaen og hastigheten som vi beveger oss.
Og hvis det gjøres riktig, som den andre anekdoten som jeg nettopp delte forhåpentligvis illustrert, kan det være en veldig smertefri og veldig sømløs prosess. Ikke bare i nye prosjekter, men å få armene rundt et nåværende miljø og sikre at du når som helst og hver dag kan spore og spore hva som skjer i organisasjonen din, hvilken database som er der, hvilke versjoner av databasen du kjører og hvem som bruker hva.
Og med det formål vil jeg overlate til vår medarbeider fra IDERA, og jeg ser frem til å høre hva de har å tilby på bordet og hvordan de vil løse akkurat denne utfordringen.
Binh Chau: Flott takk, Dez. Kan dere høre meg greit? OK, takk. Hei alle sammen, jeg er Binh Chau med IDERA. I dag skal jeg snakke litt om produkter som vi har kalt SQL Inventory Manager, og det snakker om oppdagelsen og muligheten til å inventar dine SQL Server-forekomster og databaser der ute og på en slags måte få tak i det du har i miljøet og snakk om noen andre ting som Dez og Robin snakket om med tanke på databasespredning og behovet for data i disse dager.
Med det, her er noen betraktninger som du har hørt, tror jeg, anekdotisk gjennom de to historiene som Dez beskrev. Men i dag er det så mye behov for data og forretningsgrupper der ute og forretningsgrupper der ute som snurrer opp egne applikasjoner og servere, spesielt med SQL Server, ikke sant? Fordi du enkelt kan spinne opp en SQL Express-versjon eller BI-tjenester, at det bare er SQL-spredning som skjer hos mange organisasjoner, fra det lille til det store.
Mange ganger er ikke DBA-er klar over at noen bestemte seg for å starte, du vet, opprette en instans i stedet for bare å sette en database på en eksisterende forekomst. De er ikke klar over disse tingene før det potensielt er noe problem og noen ringer DBA: "Å nei, søknaden min sluttet å fungere, den klarer ikke å koble seg til en database, hva skjer?" Og du vet når DBA spør noen spørsmål de oppdager, "Hei, denne var ikke på radaren vår, vi var ikke klar over den."
En annen er lisenskostnader, ikke sant? Microsoft SQL Server-lisens: det fungerer slik at du ikke har noen spesifikk nøkkel for det antall forekomster du har. Du kan distribuere og deretter gjøre en revisjon. De gjør en tilsyn senere og oppdager slags hvor mange lisenser du faktisk trenger. Og hvis de gjør en revisjon og ikke er klar over de ukjente serverne, kan det føre til en kostbar revisjon. Det er en god ting å ha verktøyet eller ha et varelager på forhånd for å vite hva lisensen din koster, og å kunne ikke bare vite, men også klare det.
Og det jeg nettopp snakket om, hvis du ikke er klar over en server mange ganger, hvis ting går bra, er alt bra, men den eneste gangen du blir oppmerksom på noe, er når det er et problem. Og slik at det kan føre til produksjonsavbrudd eller kanskje ikke serveren ble opprettholdt, og du fikk ikke en oppdatering på serveren, og det skaper et problem.
Noen av spørsmålene en DBA-type må stille seg dag for dag, er at de står overfor, du vet, de kan være administrative eller strategiske, men noen ting som, Microsoft har nettopp gitt ut en kritisk systemoppdatering, hvor mange systemer der ute vil trenge dette nye lapp? Hvem kommer til å bli påvirket av nedetid hvis jeg trenger å ta systemet ned for å lappe det? Hvordan kan jeg enkelt komme til den informasjonen? Må jeg gå inn i et regneark? Må jeg gå inn på flere systemer for å finne det? Må jeg nå ut til de forskjellige forretningsgruppene for å få den listen? Det er veldig vanskelig å dele det.
En annen god er i utgangspunktet, noen kommer og de sier: Jeg trenger en ny database. Det kommer til å kreve X-størrelse, og den trenger å ha så mye kapasitet, og så vil de vite, hvor kan jeg sette den? Uten å vite hva som er i landskapet ditt, er det vanskelig å fortelle dem, ok, vi kan legge det her, her eller her. Du må slags gå og gjøre de manuelle sjekkene dine som er nødvendige for å få det til. Og vi snakket om revisjonen, og også den useriøse serveren.
Hvis du har en useriøs server der ute, vet du ikke hvilken tilstand den er i, om den er sikkerhetskopiert, om den har alle de oppdateringene. Noen ganger kan det hende at du ikke blir klar over disse tingene før det er noe problem, noe som vil være dårlig.
Dette er slags utfordringer, spørsmålene, DBA-ansiktet en dag til dag, hva som blir kastet på dem. Så jeg ønsket å introdusere deg SQL Inventory Manager, som er et produkt som vi har der ute. Det gjør et par ting. Det gjør oppdagelse, som i utgangspunktet er slags å gå ut i miljøet for å se hva SQL Server er der ute i miljøet. Og så kan den også automatisk oppdage, så i utgangspunktet, når du har kjørt en oppdagelse, kan du stille den til å gå der ute hver dag eller ukentlig - uansett tidsramme du vil - for å oppdage nye tilfeller der ute.
Og så kan du også få det til å registrere disse tilfellene automatisk, slik at du kan begynne å overvåke dem og sjekke om helsetilstanden deres er, og så kan du begynne å katalogisere og inventarere disse tilfellene, slik at du kan ha en god oversikt over SQL Server-landskapet. Hva er der ute, hva er produksjon, hva som er utvikling, hva som er katastrofegjenoppretting, hva som er mindre kritisk og du vet, hvilke applikasjoner som kjører på dem. Og du kan også få varsler om når ting, når helsekontrollen svikter, så i utgangspunktet hvis serveren går ned eller i tillegg til en rekke ekstra ting du kan verktøyet selv.
Eric Kavanagh: Du blir litt myk, bare så du vet det.
Binh Chau: Beklager, er dette bedre? Det jeg vil gjøre var å ta dere gjennom en demo, vise dere hva det gjør. Vent litt, la meg dele skjermen min først. Ser dere webgrensesnittet? Dette er SQL Inventory Manager-grensesnittet. Skjermen som jeg viser deg her, det er et nettbasert grensesnitt. Skjermbildet som jeg viser deg her, er vår oversikt over databaser. Over hele toppen kan du se at vi har fått forskjellige. Så "oppdaget" er i utgangspunktet alle tilfeller det oppdages i nettverket. Og hva det kommer til å vise meg er i utgangspunktet.
Eric Kavanagh: Du begynner å bryte opp bare litt der. Det kan være lurt å legge telefonen ned og sette den på høyttaleren. Gå videre.
Binh Chau: Denne Discovery-skjermen vil vise deg alt som Inventory Manager oppdaget i nettverket ditt. Her oppdages det som 1 003 servere der ute. Og den vil fortelle deg versjonen, utgaven, om den kan finne den, når den ble oppdaget og hvordan den ble oppdaget. La oss si at jeg for eksempel velger å ignorere noen av disse, noe som betyr at du kanskje vil ignorere Developer Edition fordi de ikke er så viktige for meg fordi de bare er Developer Edition; Jeg kan velge å ignorere disse, og det vil sette dem på Ignorer-fanen, så neste gang jeg kjører Discovery, vil den ikke vise det for meg igjen. Nå kan jeg fylle ut for å gjøre automatisk registrering eller jeg kan registrere manuelt.
Og så her har jeg valgt å overvåke seks forekomster. Og her er det logget inn, og det kommer til å utføre periodiske kontroller av disse, og så er det flere kontroller, alt her fra, du vet, det sjekker hvert 30. sekund for å se om serveren er oppe eller nede, og den gir deg en slags oversikt over hva den staten er. I utgangspunktet her forteller det meg at jeg har en server som er nede og disse fem som er oppe. Det forteller meg også hvilke serverutgaver, antall databaser, statusen til databasene, eventuelt tilleggsbeholdning eller metadata rundt den serveren. Jeg kan også komme til lisensvisning herfra. Her gir det meg noe av Microsoft-lisensinformasjonen jeg trenger hvis jeg ville komme foran å få en total eller et sammendrag før en Microsoft-revisjon.
Her er antall kjerner, antall stikkontakter, mulig kjernelisens som var noe som Microsoft introduserte fra og med 2012. Det var vår Instance-visning. Oversiktssiden vår, dette er den slags siden du vil åpne opp til. Dette vil vise deg helsekontrollene eller anbefalingene den har, som akkurat nå, det forteller meg at jeg har ni databaser som ikke har nåværende sikkerhetskopi. Jeg kan klikke inn der for å gå ned til detaljene i hvilke databaser det er, og jeg kan gå inn og ta en handling på dem hvis jeg måtte. Det forteller meg alle de beste databasene etter størrelse, topp databaser etter aktivitet. Jeg kan klikke meg inn på den aktuelle serveren og få mer informasjon om den.
Eric Kavanagh: Mens det er rullerende, er det du viser oss her muligheten til å se virkelig alt som er koblet til nettverket, er det ikke?
Binh Chau: Rett. Dette viser alt jeg har valgt å overvåke ved hjelp av Inventory Manager. Dette er en SQL Server, den viser meg her alle applikasjonene som er koblet til serveren. Igjen kan jeg hente inn alle databasene som er tilknyttet denne serveren. Over her kunne jeg merke ting. Jeg kan opprette en tag for akkurat denne serveren, enten det er et nøyaktig domene. Vi har kunder som bruker den til, for eksempel, de vil merke produksjonsservere eller gjeldsservere sine, og så kan de på en måte få en fullstendig rapport om hvordan ting er. Når jeg går til fanen Administrasjon, er det slik jeg kan kjøre Discovery. Og Discovery vil i utgangspunktet gå ut og løpe inn i nettverket ditt og finne all SQL Server i miljøet.
Her har jeg dette presise domenet som er et domene av vårt, og jeg har satt det opp for å si, du vet, på dette bestemte domenet bruker du denne spesielle Windows-brukerkontoen til å oppdage, og jeg vil at du skal gjøre en fullstendig skanning. Jeg kan også velge å spesifisere "Bare skann dette bestemte underdomenet" eller "Bare skann overordnede." Men i dette tilfellet her har jeg sagt kjørt fullstendig skanning. Her er de forskjellige skannetyper jeg kan bruke, og hvis jeg lagrer det, og i utgangspunktet er det en jobb jeg kan angi. Akkurat nå er det av, noe som betyr at jeg måtte kjøre disse skannene manuelt. Men hvis jeg ville, kunne jeg stille det hver dag, vet du, kjøre jobben daglig. Eller hvis jeg velger å ikke kjøre den hver dag - det er for mye - kan jeg si at du løper jobben ukentlig på en bestemt dato og tid.
Og så automatisk registrering her, hvis dette er slått på, hva det vil gjøre er at hver gang den finner en ny server, vil den automatisk registrere den i Inventory Manager slik at jeg kan begynne å overvåke den. Hvis det er en slags utgave som jeg vil ekskludere, som for eksempel, jeg bryr meg ikke om Express- eller Developer-utgaven, fordi de er utviklingsmiljø, så vil jeg bare klikke på de her, og hva det vil gjøre, er det bare sier hver Når jeg finner noe nytt, vil jeg bare legge det til i Inventory Manager, slik at du kan overvåke det så lenge det ikke er en Developer- eller Express-utgave.
Og her kan jeg stille inn kodene, så hvis jeg for eksempel har produksjonsservere, kan jeg gå hit og merke disse serverne. Jeg kunne merke verken databasen eller serveren med en spesifikk blå tagg, så jeg kunne for eksempel si at denne AO_NODE skulle ha en produksjons-kode. Og på denne måten hvis jeg trengte å komme lett til serveren, kan jeg gå ut her og klikke på Produksjons-taggen, så tar den meg med en gang til de to serverne. Dette er Explorer-visningen vår, og dette vises av eier, men jeg kan si ved Instance tag, også av databaser, og jeg kan utvide dette for å se hva de er.
En annen nyttig funksjon som vi har bygget som folk virkelig liker her, er muligheten til å se på hva du styrer gjennom Inventory Manager og se hvilket patch-nivå de er på. I utgangspunktet forteller det meg her om de seks serverne jeg har administrert i verktøyene mine, om det er en oppdatering tilgjengelig for Microsoft eller ikke, om versjonen jeg er på, om den støttes eller ikke, og støtten status. Hvis jeg ville finne ut mer om denne bestemte hurtigreparasjonen, kan jeg klikke på den, og den vil koble meg opp til artikkelen fra Microsoft når det gjelder hva den hurtigreparasjonen handler om og om jeg skal adressere dem. Du kan eksportere denne listen hvis du vil, så på den måten kan du si: "Hei, jeg trenger å lappe tre av disse serverne i helgen og de tre andre på et senere tidspunkt."
Byggelisten - så det er en liste som den sjekker mot for å se at versjonen din er oppdatert. Du kan gå ut og laste ned denne listen for å sikre at den er oppdatert, og at du har den siste listen du kan sammenligne den med. En annen ryddig lagerfunksjon som folk liker er muligheten til å legge til, ikke bare koder, men muligheten til å legge til tilpassede lagerfelt. Hvis du ønsket å legge til et felt her for å merke en database for eksempel, la oss si at jeg vil merke det på databasenivå. Avdeling, denne avdelingen og denne databasen, jeg kunne gjøre det til en annen type: åpen slutt, sann / usann eller plukliste.
Og jeg kan si, du vet, dette er HR, markedsføring, FoU, økonomi. Og hva dette gjør her er i utgangspunktet, når du først har tagget disse tingene, kan du få noen data herfra som sier hvor mye kapasitet hver database bruker, og så kan du begynne å forme, vokser den og gir det mening å lade tilbake disse avdelingene?
En annen ting er, du vet, hvis du må kjøre vedlikehold, ved å vite hvem som er i den databasen, kan du vite hvem du skal kontakte for å gi dem beskjed, "Hei, jeg må kjøre vedlikehold i helgen, databasene dine vil være offline, " og så videre. En annen nyttig funksjon er søkeboksen her oppe folk liker. Mange ganger blir DBAs spurt om en database eller et program eller en server, avhengig av hvem som snakker med dem, er det litt vanskelig å finne ut nøyaktig hvor det er. Hva du kan gjøre her er at du kanskje ikke vet hvor databasen bor, men du kan bare skrive den inn. Jeg kan bare skrive inn IDERA Dashboard og det kommer til å trekke opp et par databaser og hvor de sitter slik at du enkelt kan få tak i til de. Og så henter den ytterligere informasjon om dem: deres størrelse, en loggstørrelse, om den noen gang har hatt en sikkerhetskopi, hvilken gjenopprettingsmodus den er i, hvis jeg ville legge til noen koder om den. Det er mange forskjellige funksjoner i dette verktøyet, du vet, det er et inventarverktøy, men det er et inventarverktøy som er veldig spesifikt for SQL Server og for DBAer.
Fordi det er, antar jeg, flere ting DBA ønsker å ha tilgang til eller for å få et godt inntrykk av hvordan miljøet og landskapet deres ser ut for databasene deres. Du kan også abonnere, konfigurere SMTP-serveren og sette opp abonnement for å varsle for deg selv eller for noen brukere her. Jeg kommer til å stoppe dette og gå tilbake til presentasjonen. Og dette siste lysbildet her er bare et enkelt syn på arkitekturen. Det er en nettkonsoll som kjører på en innebygd Tomcat Web Services.
Vi har noen samlingstjenester og administrasjonstjenester som vi setter inn i et depot, og administrasjonstjenestene går ut og kjører Discovery på dine forskjellige SQL Server-forekomster. Det er ingenting installert på skjermserverne. Vi har jobber som kjøres med jevne mellomrom som bare samler inn data om det, så i utgangspunktet om det er opp eller ned, hvor mye data som brukes, hva folks andre versjoner er. Vel, det er alt.
Eric Kavanagh: Ja, la meg spørre deg - jeg skal stille et par spørsmål, og så er jeg sikker på at Robin og Dez har noen også - bare av nysgjerrighet, når noen kommer inn for å gjøre en revisjon, la oss si at Microsoft, er bruker de dette verktøyet, eller antar jeg at de har noen proprietære verktøy som de bruker?
Binh Chau: Ja, jeg tror de bruker proprietære verktøy. Saken er at dette verktøyet er et inventarverktøy, så det holder seg oppdatert når det gjelder, for du vet det, fordi det har jobben å gå ut og kontinuerlig samle informasjon om serverne dine, den kommer til å løpe der ute og når som helst. har du oppdatert informasjon, faktisk, om hvordan ting endres versus, du vet, engangsrapporter som du kan få fra Microsoft for å si at dette er antall servere du har, dette er versjonene du har .
Eric Kavanagh: Ja, jeg er nysgjerrig på Discovery. Så når noen kjøper dette verktøyet og begynner å bruke det, hvordan skjer egentlig funnet? Dette var liksom det jeg antydet tidligere, med andre ord, tapper du på nettverket for å se hvilke signaler som flyr ut der som ser ut til å være database-forekomster, og så katalogiserer du det og så når du har merket en databaseinstans som overvåker du? Jeg antar at den har en slags ping som den gjør så ofte og hvis den for eksempel går ned, er det slik du vet at den er nede. Er det sånn hvordan ting fungerer?
Binh Chau: Ja. Jeg mener, når du først har slått på Discovery, går den ut til nettverket ditt, og vi har flere forskjellige skanninger å gå ut der, men det vet du, nettleserskanning og registerskanning. Den gjør forskjellige skanninger for å se hvilken datamaskin som er der ute, og så kontrollerer den: har du SQL-servere der ute eller BI-tjenester der ute? Og så bringer den det tilbake og drar det inn i verktøyet og viser det til deg: "Hei, her er alle tingene som jeg oppdaget."
Og hvis du sa: "Jeg vil overvåke å bruke dette verktøyet, " så kommer det til å holde oversikt over det, og det kommer til å pinge det. Det har jobber for å pinge det så ofte for å si: "OK, sjekk dette nå om denne tingen, " - du vet, databaseadgangen - sjekk den nå om databaseshistorien, sjekk databasesiden. Det kjører en serie jobber for å sjekke databasen du overvåker.
Eric Kavanagh: Ja, det er bra. Og vi har et spørsmål fra et publikummedlem. Jeg vet at dere har verktøy som fungerer med en rekke databaseteknologier, men dette du spesielt viser i dag, er dette bare for SQL Server, eller dekker dette andre databasetyper også?
Binh Chau: Akkurat nå dekker dette spesielle verktøyet SQL Server.
Eric Kavanagh: Ok, det går bra. La meg vende det til Robin, jeg er sikker på at han har et par spørsmål, og kanskje tilbake til Dez. Robin?
Dr. Robin Bloor: Ja, helt sikkert. Microsoft ganske nylig - en gang i 2006 - kunngjorde SQL Server på Linux, men jeg tror ikke den har levert den ennå. Jeg bare lurte på om du fikk kommentarer til det. Er du klar over det? Leker du med det?
Binh Chau: Ja, det er vi. Vi planlegger å inkludere det. Jeg mener, det fine med dette verktøyet er at jeg har snakket med mange kunder som har bygget sine egne hjemmevokste verktøy for å gjøre det samme, men de må følge med på de nye utgavene og versjonene som Microsoft kommer ut med, men vi har nye versjoner og utgaver, vi kommer inn på det tidlig for å sikre at verktøyet vil kunne slags overvåke og administrere de nye utgavene. Så SQL på Linux er noe vi planlegger å legge til og gjøre tilgjengelig når det er tilgjengelig - tror jeg senere i år.
Dr. Robin Bloor: Ja, det er interessant. Forventer du at mange av kundene dine faktisk skal gjøre det? Jeg mener, SQL Server er en veldig sofistikert database, etter min erfaring. Jeg mener, det er lenge i tannen, det er nok tingen å si. Jeg mener, du vet, den opprinnelige Sybase som den kom fra var faktisk ganske forenklet i mange ting den gjorde. Men Microsoft har lagt til flere og flere ting gjennom årene. Kommer alt dette til å være tilgjengelig på Linux? Jeg mener, vil du gi kundene råd om hvorvidt de skal flytte migrasjonen?
Binh Chau: Jeg beklager, er spørsmålet at vi ser at folk ber om det?
Dr. Robin Bloor: Vel, gitt at du har rotet med det, er det så sofistikert på Linux som det er på Windows?
Binh Chau: Jeg har ikke lekt med det selv, men det jeg har hørt fra en kollega er at det faktisk er veldig på nivå. Men jeg har personlig ikke spilt med den nye versjonen av SQL på Linux.
Dr. Robin Bloor: OK. Har jeg rett i å tenke at du ganske enkelt har lagt agenter på hver SQL Server du finner? Er det slik dette verktøyet fungerer?
Binh Chau: Nei, vi har ikke agenter. For dette spesielle verktøyet, inventarstykket, legger vi ikke agenter på det. Vi går bare ut og ringer og sjekker statuser for det. En fin ting med dette verktøyet er at det er agentfritt.
Dr. Robin Bloor: Så har du andre SQL Server-verktøy, kan du på en måte minne meg om hvilke andre produkter du har i denne suiten som omhandler SQL Server?
Binh Chau: Ja. Vi har SQL Diagnostic Manager. Det er et overvåknings- og ytelsesverktøy. Den gjør mer dyptgående analyser eller diagnostiske og ytelses- og helsekontroller for deg enn Inventory Manager. Inventory Manager er den lette versjonen av den helsesjekk. Vi har også Compliance Manager og Secure, som er en del av sikkerhetspakken vår. Den vil i utgangspunktet fortelle deg hvem som har tilgang til dataene dine, hvilke data de får tilgang til, hvorfor, og det hjelper deg med overholdelse og andre rapporteringsretningslinjer. Vi har SQL Safe, som er vårt backup-verktøy - det gjør sikkerhetskopi og gjenoppretting, og det er hyggelig.
Vi har også vår Enterprise Job Manager, som bare overvåker jobben din. Og så har vi Toolbox-verktøyet, som er Admin-verktøy, og også Sammenligningsverktøyer, så vel som SQL Doctor. Administratorverktøysett og sammenligningsverktøysett, det er det jeg tenker på som en sveitsisk hærkniv. De har flere verktøy der for å på en måte hjelpe DBA med å gjøre forskjellige ting som du vet, sjekke lapper eller flytte eller klone en database. Men det er 24 slike verktøy i den verktøykassen.
Dr. Robin Bloor: Så er de menneskene som går for Inventory Management, er de vanligvis allerede brukere av de andre verktøyene dine? Eller er denne typen inngangspunkt? Jeg kan forestille meg - jeg mener, du kan fortelle meg om du har noen krigshistorier - men jeg kan forestille meg at hvis du aldri faktisk har ført et inventar i et ganske betydelig datasenter, kan opplevelsen være ganske nøktern. Er det det du finner?
Binh Chau: Ja. Jeg mener, vi har kunder som blir introdusert for verktøyet fra andre verktøysett, men vi har kunder som kommer etter et verktøy som dette på grunn av prosjekter de har. Et eksempel jeg var der, var et selskap som fusjonerte med et annet selskap og kjøpte en serie selskaper og trengte å konsolidere SQL Server-fotavtrykket for å redusere kostnadene. Og så lette de etter et verktøy for å gå ut og oppdage alt de hadde, slik at de kan starte prosessen med hvordan vi konsoliderer dette.
Dr. Robin Bloor: Jeg forstår. Jeg antar at det er ganske vanlig med fusjoner når du tenker på det. OK, jeg vil gi videre til Dez, jeg vil ikke ta meg hele tiden. Se hvilke spørsmål vi har fra Australia.
Dez Blanchfield: Takk, ja, spørsmålene er alltid opp ned her. Noe av det som kommer opp i tankene, og jeg får til dette ganske mye, vet du, selskaper er ikke helt sikre på hvor de skal trekke streken når de skal begynne å investere. Når bør en organisasjon - i din erfaring gitt at du er i den kalde fasen - når er riktig tidspunkt å begynne å investere i verktøy som dette for å sikre at du ikke får problemer? Gjør du det fra første dag når du begynner å bygge databaseinfrastrukturen til den nye organisasjonen, eller som du nettopp skisserte, når du gjør et oppkjøp / fusjon?
Eller er det en bestemt skala du virkelig trenger å være på? Trenger du 10 eller 100 eller 1000 databaser? Hva er din erfaring så langt som markedet du har hatt med så lenge, når er det rette tidspunktet å komme inn i dette rommet og sannsynligvis hvor du skal begynne? Hvordan ser det ut når du kommer i gang?
Binh Chau: Jeg mener, kanskje jeg kanskje ikke har behov for dette verktøyet, med en DBA eller et par DBA, hvis det er en veldig liten organisasjon. Når du begynner å få en gruppe på, jeg vet ikke, tre eller fire DBA-er og kanskje 50 til 100 servere, kan det være lurt å begynne å gjøre noe som dette. Etter hvert som organisasjonen din blir større og bare forretningsfolk som er teknisk kyndige som vil, vet du, som det eksempelet du ga, de vil installere applikasjonene og databasene på egenhånd, men det er da du vil ha denne typen verktøy fordi du på den måten kan se hva som er der ute.
Men selv i en mindre organisasjon er det hyggelig å ha denne typen verktøy for å holde rede på hva du har. Hvis du deler den opp slik at du kan si: "Å ja, jeg kjøpte SQL 2012 for denne boksen, men den har SQL 2008 for øyeblikket fordi jeg har et program som fortsatt trenger den gamle versjonen." Det hjelper å ha det inventarverktøyet bare å på en måte komme bort fra å administrere flere regneark som kan bli foreldet.
Dez Blanchfield: Det andre spørsmålet jeg bare fulgte om det: hvilke typer ferdigheter eller ressurser bør organisasjoner planlegge å ha når de kommer til den skalaen? Er det slik at det er et bestemt ferdighetssett du virkelig trenger, eller en type opplevelse eller bakgrunn eller den typen person som er best egnet til denne typen utfordringer? Eller er det noe gjennomsnittlig DBA eller sys admin eller nettverksadministrator type ferdighetssett kan kaste dette på? Trenger du en skarp, spiss endet hjerne, eller kan du plukke opp dette ganske raskt?
Binh Chau: Beklager, så du snakket om ferdighetssettet til personen?
Dez Blanchfield: Ja, så når du tenker på en databaseadministrator, er det et spesielt sett med ferdigheter du trenger. Så når du skal ansette en DBA, per se, for den spesifikke rollen, når du tenker på hvilke typer utfordringer du snakket om her der du bruker et verktøy som dette for å holde deg oppdatert på kartlegging og sporing av databaser, gjør du oppdagelsesstykket, og driver dette spesielle verktøyet, er det noe unikt med bruken av verktøyet og tilnærmingen til denne type utfordringer, eller er det noe som den gjennomsnittlige DBA kan plukke opp ganske raskt?
Binh Chau: Jeg tror, den gjennomsnittlige DBA-en din kan plukke opp dette raskt. Jeg tror det er nyttig å ha denne typen verktøy fordi du også kan snu det fordi det er nettbasert. Du kan gi den til andre brukere i organisasjonen. Du kan gi den til apputvikler som kan sjekke på sin spesifikke database eller server. Det tar bort noen av de administrative tingene som en DBA må gjøre. Tidligere vil noen ringe DBA og si: "Åh, hvorfor er serveren min opp eller ned?" Nå kan de slags få tilgang og se om serverne deres er oppe eller nede.
Dez Blanchfield: Og hva slags miljø vil en gjennomsnittlig organisasjon trenge for å distribuere dette? Trenger den en dedikert fysisk server, eller kan det gjøres på en virtuell maskin? Kan de distribuere det i skymiljøet? Hva er det generelle fotavtrykket for distribusjonen av verktøyet og bare den generelle driften av det? Hvor mye tungt jern trenger det potensielt å løpe parallelt med de andre miljøene det er kartlagt?
Binh Chau: Ja, det kan kjøres på en VM eller en datamaskin eller en server. Det trenger ikke nødvendigvis å være en dedikert server, det avhenger bare av hvor mange servere du overvåker. Hvis du har et større miljø, kan det hjelpe å ha en større server fordi den samler inn mye data om SQL Server som du overvåker.
Dez Blanchfield: Rett. Er det den slags ting du komfortabelt kan kjøre i skyforekomsten og opprette en VPN tilbake til miljøet ditt, eller er mengden data den samler sannsynligvis litt tung for den type bruk?
Binh Chau: Vi har ikke satt det opp for å kjøre det på skyen, for å kjøre dette i skyen ennå. Det bør antagelig kjøres på prem.
Dez Blanchfield: Og det siste spørsmålet, om jeg kan: mange verktøy som jeg har sett på dette rommet, spesielt der du nevnte det for ett scenario der noen kjøpte selskap eller det var en fusjon eller noe i den retning, eller til og med Hvis det var en organisasjon som bare fusjonerer forretningsenheter, er det et fornuftig brukssaksscenario der noen distribuerer det på en bærbar datamaskin og tar det med inn i et miljø for å kartlegge en verden som en gang, eller er det et usannsynlig brukssaksscenario? Er det mer slags sånn at det kommer til å være der inne og bare permanent igjen å løpe?
Binh Chau: Dette spesifikke verktøyet er mer en slags installasjon på en server, og det blir liggende der for å kjøre. På den måten kan du samle inn informasjonen du trenger for den og beholde, antar jeg, en løpende beholdning av det du har. Det er i motsetning til kartverktøyet fordi kartverktøyet er slags en-til-en, hopp til porten du trenger, gjør det du trenger å gjøre med det i dag. Denne er slags - den fine delen med det er det faktum at du kan merke den, gi folk tilgang til den til å sjekke tilstanden til den aktuelle serveren deres, de som de er interessert i.
Dez Blanchfield: Ok. Sannsynligvis det siste spørsmålet for meg, og så vil jeg levere tilbake til Eric for spørsmål som kommer gjennom spørsmål og svar-vinduet med de fremmøtte, fordi vi har hatt en god valgdeltagelse i dag, en av favorittene mine. Bare for å pakke sammen dette, hva er prosessen for å få hendene på dette? Jeg vet at mange verktøyene dine er tilgjengelige for å prøve ting før du kjøper. Hvor skal folk gå for å lære mer om dette på nettet, hvor på nettstedet skal de lete etter nedlastningene og hvordan ser reisen ut, slags gjøre et bevis på et konsept eller en prøve og få hendene på det og bli kjent med det for så å komme i kontakt og kjøpe den?
Binh Chau: Ja. Du kan gå til IDERA.com-nettstedet, og du kan laste ned en to ukers prøveperiode gratis. Og hvis du liker det, og du vil nå oss, kan vi også planlegge en demo med en av våre ingeniører for å gjøre et dypt dykk i verktøyet.
Dez Blanchfield: Fantastisk. Vel, tusen takk for det. Jeg setter pris på tiden til å chatte med deg om det, og basert på min personlige erfaring og jeg er sikker på at jeg snakker for Robin om dette på hans livslange opplevelse, tror jeg det er gitt at noe slikt er et krav i dag. Vi kan ikke gjøre dette manuelt nå uansett hvor hardt vi prøver; skalaen er bare for stor og ting beveger seg for raskt.
Jeg anbefaler folk å gjøre akkurat det, hoppe på IDERAs nettsted og få en kopi å leke med. Fordi den potensielle risikoen for min egen erfaring med anekdotene jeg delte akkurat i dag, har vært, kan det gå fra veldig dårlig til veldig bra raskt, hvis du har de riktige verktøyene, men det kan også gå den andre veien hvis du ikke t. Eric, tilbake til deg.
Eric Kavanagh: Ja, bare kom med et siste spørsmål til deg, et interessant spørsmål. Jeg er bare nysgjerrig på å vite hva du ser der ute, du vet, skyen er tydeligvis stadig viktigere i disse dager - Amazon Web Services, men de er ikke de eneste, Microsoft har hele Azure-tilbudet det ser ut til å ta fart. Jeg er nysgjerrig på å vite, en av de fremmøtte skriver at Dr. Bloor gjorde et interessant poeng om at DBA-er er dyre og at ledelsesproblemer forårsaket av enten en useriøs DBA eller noen som ikke gjør det de burde gjøre, kan det løses ved å migrere til skyen. Jeg er egentlig bare nysgjerrig på å vite, hvor mye aktivitet ser du? Ser du at migrering til skyen blir en større sak for bedrifter, eller hva tar du for deg som en trend?
Binh Chau: Jeg føler at det bare kommer an på hva slags problem du er i. Jeg føler at noen bransjer sier: "Nei, vi migrerer ikke." De migrerer kanskje ikke til en offentlig sky; de kan se på å migrere eller migrere tingene sine til en privat sky. Men så ser jeg noen organisasjoner som du er interessert i, virkelig kommer inn på rask vei og slags går mot en Amazon eller Microsoft Azure. Og så er det noen mennesker som sier: "Nei, vi migrerer ikke dataene våre" eller "Det er bare visse data vi vil migrere, men ikke kritiske." Jeg tror det er slags tre leirer.
Eric Kavanagh: Ja, det ville være fornuftig. Jeg mener, vi ser det mer og mer, og jeg tror det kommer til å komme i passform og starter ganske lenge. Og det er en motreaksjon mot skyen også. Folk kommer inn på Amazon Web Services - vi har hørt dette mer enn noen få ganger - og til å begynne med er kostnadene håndterbare og deretter over tid kryper det bare opp og så sitter du litt fast der. På mange måter er skyen bare et annet datasenter, men det blir mildt sagt en interessant reise fremover.
Vel, folk arkiverer alle disse webcastene. Hop online til techopedia.com for å sjekke ut en komplett liste over alle tingene vi gjør. Og selvfølgelig insideanalysis.com for alt det siste. Og med det kommer vi til å ta farvel. Og tusen takk igjen for din tid og oppmerksomhet. Takk for alle vennene våre på IDERA, og vi snakker med deg i morgen, forhåpentligvis for vår Philosophy of Data som kulminerer webcast. Det stemmer, Philosophy of Data er i morgen klokken fire øst. Håper på å se deg der. Ta vare folkens, farvel.
