Af Techopedia Staff, 22. februar 2017
Takeaway: Værten Eric Kavanagh diskuterer databasestyring med Dr. Robin Bloor, Dez Blanchfield og IDERAs Binh Chau.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay, mine damer og herrer. Hej og velkommen igen. Det er en onsdag, klokken er østlig klokka fire, og i de sidste par år betyder det, at det er tid for Hot Technologies. Det er rigtigt, dette er vores show med vores venner Techopedia - Techopedia.com. Tjek dem ud online. De får monstertrafik, 1, 5 millioner unikke besøgende om måneden. Det er en masse webtrafik. Emnet i dag, "DBA's drøm: Opdagelse og ledelse overalt i miljøet." Ja, det er et stort emne, især for større organisationer. Der er et lysbillede om dit virkelig, og nok om mig, slå mig op på Twitter @eric_kavanagh, jeg prøver altid at følge tilbage og engagere sig i en samtale derude.
Igen, vi taler om databaseteknologier i dag og virkelig være i stand til at forstå, hvad der foregår i et bredt landskab af databasesituationer. Som mange af jer ved, når du først begynder at vokse din organisation, får du mange flere af disse forekomster derude, og det kan være en smule interessant udfordring at holde et greb om det. Faktisk husker jeg for flere år siden, jeg havde en god samtale med en fyr, der var direktør for datastyring for CIO's kontor ved forsvarsdepartementet. Og jeg fortalte ham alle disse interessante ting, vi havde denne store samtale, og jeg fortalte ham min baggrundshistorie om lobbyvirksomhed for gennemsigtighed i føderale udgifter, og han lo og han sagde: ”Åh, så det er dit hus, hvor jeg skulle sende det næste rovdyr drone strejke. ”Han sagde, “ Gennemsigtighed i føderale udgifter? Jeg ved ikke engang, hvor mange Oracle-licenser jeg har her. ”Da jeg hørte det, kunne jeg virkelig sætte pris på omfanget af den udfordring, som nogle organisationer står overfor.
Nu i disse dage er der masser af interessante værktøjer - vi hører om et i dag - til at forstå, hvad der flyver derude, men selv for 20 år siden var det en virkelig alvorlig udfordring. Når det kommer til organisationer på størrelse med DOD, kan du bare forestille dig, at at få et greb om det vil spare en masse penge, det vil spare en masse tid, det vil løse nogle styringsproblemer; du ender med at løse flere udfordringer på én gang, hvis du gør denne slags ting korrekt. Vi lærer om det i dag.
Vi har vores egen Dr. Robin Bloor på, chefanalytiker for The Bloor Group. Vi har Dez Blanchfield, vores datavidenskabsmand, der kalder ind fra under, Sydney, Australien. Og Binh Chau, senior produktchef for IDERA, er også på banen.
Vi gør #HOTTECH som hashtaggen - velkommen til at tweet væk under showet. Og vi stoler på jer for gode spørgsmål, så vær ikke venlig: still spørgsmål til enhver tid ved hjælp af Q & A-komponenten i din webcast-konsol eller det chatvindue, uanset hvad. Og med det overleverer jeg det til Dr. Robin Bloor. Lad mig give ham nøglerne til WebEx. Der går den, og tag den væk.
Dr. Robin Bloor: Okay. Nå, her går vi, lad os gå videre til det første lysbillede. I Italien kalder de dem Stanlio og Olio, Laurel og Hardy. Tilbage i 1990'erne, da alle var bekymrede for år 2000, blev jeg involveret i et antal år 2000-projekter. Og jeg gik til - lad os kalde dem et stort forsikringsselskab - og de opdagede, at de havde over 500 applikationer, som de ikke vidste, at der eksisterede på mainframe. De tog en fortegnelse over mainframe. I disse dage var mainframe-miljøer langt bedre ivaretaget end noget, der kom senere, jeg mener, der er bare ikke noget spørgsmål om det.
Jeg var virkelig bedøvet, og jeg talte med folk i organisationen, og de sagde, at der ikke var noget, der ikke var noget centralt omfattende … der var ingen person, der var ansvarlig for at kende den information, du ved, dybest set. De tog aldrig varebeholdninger over deres aktiver. Og en database er et aktiv på ingen usikre vilkår, fordi den indeholder data og data er værdifulde. Hvor mange tilfælde er spørgsmålet, og hvor er de egentlig? Dette er bare ”Hvad er en database?”, Og grunden til, at jeg tænker sådan, en database er et skab, som man kaster data i. Og jeg talte for nylig med et websted, der havde tusinder af forekomster af Oracle. Nå, Oracle er en database, som, hvis du bruger den på en sofistikeret måde, kræver en DBA.
Jeg spurgte lidt om det, og de sagde, de tror, det drejer sig om syv eller otte DBA'er i hele organisationen. Og jeg sagde, du ved, ”Hvem passer på de andre tusinder af tilfælde?” Og de sagde, ”Nå, hvad der virkelig skete der, er, at folk bare bruger det som et filsystem. Vi har en række databaser, der findes i store klynger, hvor ydelsen virkelig betyder noget, og de har DBA'er, der står over dem hele tiden. Og så har vi tusinder af andre databaser, som ingen overhovedet tager sig af. ”Og jeg spurgte dem nøjagtigt, hvor mange databaser, og de kom på, ” Nå, sidste gang Oracle reviderede det. ”De foretog ikke revisioner selv, ved du, hvilket er en slags interessant ting.
Men, du ved, der er grunde til at bruge en database. En database implementerer en datamodel. Det er der for at dele data: kan administrere flere samtidige anmodninger om data, implementere en sikkerhedsmodel, er ACID-kompatibel, er elastisk eller kan indstilles til at være elastisk, ved du. Det er grunden til, at vi har databaser. Men, du ved, det er ikke usædvanligt at støde på websteder med tusinder af forekomster af SQL Server eller Oracle, og de fleste af dem bruges kun som filsystemer, dybest set. Og hvorfor skulle du egentlig oprette en ny instans?
Jeg kender til udviklerteam, at hvis de bygger en ny applikation, bygger de den i en silo, så enhver given ny applikation ville have en separat database. De ville ikke nødvendigvis forsøge at gøre et datalag ud af tingene - jeg synes ikke, det er god praksis. Men der igen, ved du, hvis du har et meget kompliceret miljø, bliver det meget, meget vanskeligt at prøve at sammensætte alle de databaser, der er relateret til hinanden i form af at have data i dem, hvor der er relationer. Forekomster oprettes til kopier.
Du ved, du kan have hot standbys eller replikker til tilgængelighedsformål, men du har også kopier eller semi-replikker i datamarkeder. Og når datalagerverdenen blev introduceret, spørgsmålet om, du ved, hvor mange datamarkter der var derude, og folk brugte dem bare som klonefiler, tog data ud af datalageret og var ikke særlig opmærksomme på dets ydeevne i fornemme, at de bare ville gøre sig som standardydelse. De fleste af disse mennesker vidste sandsynligvis ikke engang, at du rent faktisk kunne indstille databaser. Jeg har set designs, der har skåret data i karakteristiske dynger med henblik på distribution.
Du ved, du får ofte denne replikationssituation, hvor du har flere depoter inden for en organisation, og de har hver især databaser, og hver er en beskæring af en central database. Du får forekomster fra spaltning. Dårlige designbeslutninger - Jeg har set nogle virkelig bisarre designs finde sted med hensyn til databaser, hvor folk har oprettet separate databaser uden god grund. Og som jeg har bemærket, databaser er filsystemer.
Og så er der test- og udviklingsmiljøerne, der skal stilles op og falde ned, men de regnes alle som databaserede forekomster, og alle af dem har forresten brug for sikkerhed og alt det andet, som databasen forhåbentlig giver. Overvejelser ved forekomster - en databasearbejdsbyrde kan kun optimeres til en bestemt instans. Hvis du virkelig er interesseret i at have absolut den bedste ydelse, er det ikke nødvendigvis nødvendigt at give dig den slags optimering, hvis data afskærmes i en masse databaser.
Der er en grund til ikke at oprette falske forekomster af data. Blandede arbejdsmængder på den samme database som kontrapunktet kan føre til dårlig ydeevne - især bemærkelsesværdigt af OLTP og stor forespørgselstrafik blandes simpelthen ikke, har aldrig blandet og sandsynligvis aldrig vil blandes. Det er normalt bedst at konsolidere en database på serverniveau i stedet for at have flere VM'er. Men VM'er giver isolering; hos nogle mennesker er det en designbeslutning at isolere data fra andre data, så du ved, hvis denne applikation mislykkes, eller hvis denne database mislykkes, ikke bringer min applikation ned.
Problemet med det er naturligvis, at du ender med at løbe ind i det næste punkt, som er databaselicensgebyrer. Disse varierer, men jeg har set databaselicensafgifter blive et designkriterium, fordi nogen ikke ønskede at sprænge et bestemt antal, og derfor mennesker, der designer systemer dårligt blot på grund af den måde, databaselicensen fungerer på. Og der er den anden ting: hvis du begynder at konsolidere alle dine databaser, er det værd at bemærke, at DBA'er er dyre. Det er ikke så let at gøre.
Et simpelt billede af verden - og dette er det sidste lysbillede - der er et datalag, der er et transportlag og der er et behandlingslag. Og al hardware sidder under det. Det er ikke virkelig muligt at optimere datalaget uden at vide nøjagtigt, hvad der er i det, og hvorfor.
Når det er sagt, skal jeg videregive til min ven nedenunder, Dez Blanchfield.
Dez Blanchfield: Tak, Robin. Lad mig bare få min mus sorteret her. Så jeg vil give os et par anekdoter i dag, fordi dette er et kæmpe emne, og jeg kunne tilbringe to uger med en tavlemarkør og have det sjovt, fordi jeg har haft næsten tre årtier med op og nedture i dette rum .
Men først et mentalt visuelt billede. Når jeg tænker på den udfordring, vi taler om i dag - og i det væsentlige taler vi om databasevækst, replikation og spredning og alle de udfordringer, der følger med det - ville jeg bare sætte dette billede af en gigantisk eg i vores sind. Dette er berømte smukke træer, de begynder som en lille agern, men de vokser til disse behemoths. Og når de gør det, er de meget store og rodede. Og som du kan se fra dette billede, som en visuel metafor, hvis du vil, du ved, grene, der går overalt og derefter kviste, der kommer fra disse og forlader i slutningen af disse, og de er i alle tilfældige, kaotiske former, og det er bare den bit, vi kan se over jorden.
Jeg tænker slags på dem som data inde i databasen, og nedenfor er der en struktur med rødder, og de tapper ind i alle slags retninger. Men det virker meget rent og fornuftigt på overfladen af jorden, hvor det er pænt og fladt, men virkeligheden er, at den er lige så skør under jorden, som den er over jorden; vi ser det bare ikke. Og jeg bruger ofte denne slags, når jeg begynder at tænke på, hvordan jeg beskriver den udfordring, vi taler om i dag, til organisationer fra bestyrelsesrummet ned til teknologierne for at få dem til at visualisere, hvad der faktisk sker i deres organisationer. Fordi det er så let at se på en computerskærm og se disse smukke felter med rækker og søjler og tænke, "Vi har fået det sorteret, det er ikke nogen stor ting." Men det er slet ikke tilfældet. Og det er på det tidspunkt, jeg normalt rammer denne ene linje og siger, at databaser i mit sind er som agern, ved du, de begynder i det små og vokser, men inden du ved det, har du en skov af kæmpe egetræer, og dermed det visuelle.
Så to anekdoter bare for at dele et scenarie, der voksede ud af kontrol og bare ikke kunne rettes, og så en anden, der gjorde en lignende ting, men som var i stand til at blive rettet, og jeg vil fremhæve det centrale punkt i dagens diskussion omkring hvordan vi kom til det.
Det første var et scenarie, hvor en CIO med de største intentioner over tid uforvarende forårsagede en af de mest uventede og uønskede sprawls, der bare voksede uden for kontrol. Det var et scenarie, hvor en regeringsorganisation med tusinder af ansatte, meget teknisk kyndige medarbejdere, krævede adgang til dets systemer og værktøjer, som de kunne begynde at samarbejde med og automatisere en masse af deres processer. De ønskede at slippe væk fra papirformularer, og de ønskede at oprette onlinesystemer, de ønskede at fange data og spore dem og overvåge dem og rapportere dem tilbage og præsentere dem tilbage til deres kolleger.
Og der er alle slags ting, der er ting fra folk, der dukker op til deres kontorer og holder ind og logger ind til sikkerhedsmæssige formål hele vejen igennem, til hvem der bestilte hvad der var på cafeteriet ved frokosttid. Og så besluttede en velment CIO, at Lotus Notes var en god idé, fordi han havde været på en række seminarer, og IBM havde gjort et godt stykke arbejde med at slå det, og i det rigtige scenarie ville det have været en god beslutning, havde det er gjort under kontrol. Men hvad der skete var i stedet for at overdrage Lotus Notes til et team af tekniske mennesker til at sortere redskab i et miljø og derefter stå op fornuftige værktøjer og så videre og give en vis kontrol og styring omkring det, hvad der faktisk skete, var det, der blev anvendt til standarden driftsmiljø, SOE, så hvert skrivebord blev effektivt en server.
Og så leverede de træning og praktiske noter og dokumentation til hele denne proces, og pludselig blev folk klar over, ”Ja, jeg har Lotus Notes på mit skrivebord!” Hvad betyder det, tror du? Nå, det betød, at tusinder af meget teknisk dygtige medarbejdere lærte, hvordan man manuskripter og skriver apps, effektivt i Lotus Notes skabte små databaser, der i det væsentlige lignede regneark, rækker og kolonner og felter, og præsenterede denne lille webgrænseflade gennem Domino.
Hvis jeg ønskede at fange oplysninger om noget, kunne jeg bare oprette en lille form og i en regneark-type interface, sætte den i en fil, oprette en lille Lotus Notes-database bag det og præsentere den som en webapp og begynde at indsamle information. Og det lød godt, indtil det havde kørt i årevis, og pludselig indså de, nogen vågnede op og sagde: ”Hold det godt, hvorfor vises der 10.000 nye databasedrevne apps på LAN, og især i de sidste 12 måneder? Hvad sker der? ”Det, der skete, var, at du faktisk gav folk en pistol, og den blev indlæst, og sikkerheden var slukket, og selvfølgelig skød de sig selv i foden.
Og der er dette fantastiske billede her, som jeg normalt trylle frem i mit sind om en italiensk kunstner, der gør denne underlige ting, hvor han får en lastbil hø og halm og dumpes midt i et kunststudie og derefter får en kurator for kunststudiet at tilfældigt skyve en nål ind i midten af den. Og så tilbringer han dage på levende foder, på kamera, går gennem halmen på udkig efter nålen i høstakken, som den var. Indtil han til sidst efter timer og dage finder det og springer op og ned og bliver ophidset. Og alligevel, italiensk kunstner, hvad kan du gøre? Men det er ret humoristisk, og hvis du nogensinde har set det online, eller hvis du ser det online, finder du det meget katartisk.
Her er et mareridt-scenarie, hvor en velmenende teknisk person gav forretningsfolk - meget teknisk kyndige forretningsfolk - et værktøj, der skulle gøre deres liv lettere. Men inden længe havde vi spørgsmål som, hvem der bakker dem op, hvem der overvåger og støtter dem, hvor er disse data, hvilken struktur er dataene i, hvem der politiserer skemaerne, hvad hvis jeg vil oprette en anden version, hvilke data er der i disse versioner, kan jeg lave en dev testintegrationsrejse på disse ting?
Du ved, du kan drage dine egne konklusioner om, hvordan det gik, men det gik ikke godt, og du kan forestille dig, at bare hundreder af terabyte med data og ikke er sikkerhedskopieret, siddende på, effektivt, pc'er eller laptops på skriveborde, nogle systemer, der ikke engang var tilgængelige, fordi folk ikke vidste, når de lukkede den bærbare computer kl. 05:30 og tog den med hjem for at udføre arbejde, som ingen på LAN kunne komme til den applikation. Det sluttede ikke godt. Og en masse data måtte renses og manuelt manipuleres og bringes tilbage til et fornuftigt system; størstedelen af det blev bare udslettet og fjernet, fordi det bare ikke kunne få lov til at sprede sig yderligere.
Så min anden anekdote med ting på en meget anden rejse. Forestil dig et scenarie, du har dev, test, integrationer, systemintegrationer, test af brugeraccept, produktion, gendannelse af katastrofer, sikkerhedskopier og sikkerhedskopi en til 99 og derover, du har opgraderinger, programrettelser og derefter demonstrationsmiljøer fra en til 99 og mere. Og pludselig sidder du der og siger: ”Vent, hvad er der, hængende, hvem bruger hvad?” Du ved, dette er et mareridt, der potentielt venter på at ske.
Men i dette scenarie, hvad der skete, var jeg lejlighed til at gå ind i en organisation, der ønskede at udtrække en velstandsstyring-forretningsenhed fra deres grundlæggende bankplatform og stå det op som en separat organisation i det væsentlige en opstart i en virksomhed. Udfordringen var at tage vores forretningsenhed med formuestyring og alle mennesker og teknologi og data omkring det i de offentlige tjenester, oprette en opstart i vores eget firma og skære den ud, så den kan køre på sit eget brand.
Dette er en global førende inden for bankvirksomhed, som jeg ikke vil navngive. Vi var nødt til at udpakke selve formuestyringsenheden og alle tingene deromkring. Så alt i sin helhed, alt personale, den fysiske infrastruktur og flytte det ind i et nyt kontor. Alle forretningssystemer, al software, alle data, al licens, navngiv det. Du kan godt forestille dig, at det lignede lidt af et mareridt at starte med.
Og for at sætte en vis kontekst omkring det, taler vi om 78 systemer i den originale bankplatform, der understøtter omkring 14 kerneprodukter, hvilket kan være omkring tusind forskellige tilbud. Hundredvis og hundreder af levende databaser i brug, og når jeg siger i brug, måtte vi flytte dem på stedet, så på en fredag eftermiddag ville de være i et miljø, på mandag forventes de at være et andet sted og på lørdag og søndag måtte de have denne krydsning, hvor transaktioner gik fra et system til venstre, lad os sige, for at visualisere det, til et andet system til højre.
Cirka 15.000 kunder med utallige poster hver og et ETL-mareridt, fordi ingen af de 78 systemer på den ene side blev matchet af systemer på den anden side. Vi havde en helt ny bankplatform, nye systemer, ny software, nye databaser og nyt skema. Så metadata, felter, rækker, kolonner, poster, tabeller, du navngive det, intet matchede. Der er 14 forskellige aktive udviklingshold, et for hvert produkt. Og da vi byggede dette miljø, fandt vi ud af, at vi på det tidspunkt havde udvikletest, integration, systemintegration, test af brugeraccept, produktion, gendannelse af katastrofer, demonstrationskopier, sikkerhedskopier, opgraderinger, opdatering - jeg savnede endda en der - træning, f.eks. og uddannelse, var der 23 versioner af hvert af disse miljøer for hvert udviklingshold.
Nu sidder du der, og pludselig begynder dit blod at kramme, og din hud bliver kold, og dit hår står - det kan aldrig ende godt. Det viser sig, det endte meget godt, fordi den allerførste ting, vi gjorde, før vi selv begyndte teknologidistributionen, var at vi gik og fik de rigtige værktøjer. Og vi brugte værktøjer, og ikke nødvendigvis mennesker, men folk, der kørte værktøjer. Vi brugte værktøjer til at kortlægge dataene, vi brugte værktøjer til at kortlægge databaserne, de boede i, kortlagde alle metadata, skemaer og helt ned til rækker, kolonner, post og felter.
Vi vidste, hvad vi kom fra, og så korrelerede vi det med kortet over, hvad vi satte på plads, så langt som den uafhængige bankplatform så ud, og vi havde en en-til-en-korrelation. Og alt, hvad der faldt ned i midten, skabte vi et datarum, hvor vi ville gå igennem og manuelt kortlægge dem. Men inden vi udførte en installation og opsætning af disse miljøer i den nye verden, sørgede vi for, at hver enkelt post, hver enkelt tabel, hvert felt, hver række, hver kolonne, hver database og alle metadata omkring det, alle tilladelser og kontroller blev kortlagt fra en til en. Og vi flyttede ikke en eneste ting, før den korrelation blev skabt.
Og så gik ETL-stykket fra at være et mareridt til en temmelig smertefri proces med bare validering af kontrollerne og processerne, der blev fulgt. Og vi kunne gøre dette regelmæssigt næsten hver time. Vi lavede overgang fra produktion til den gamle verden til nye miljøer med dev, test, integration osv. I den nye verden. Og den dag, vi gik live, efter en fem-måneders proces for at gå live efter en måned med testen, og derefter om seks måneder var det online og aktivt, vi havde kun et problem, og problemet var, at nogen glemte deres adgangskode og det måtte nulstilles. Det var det eneste, der var, og skabte grundlæggende omkring en times stress af mennesker, der troede, at noget var gået galt - det viste sig, at et kodeord udløb, og de glemte, hvad det var, og måtte nulstille det.
Du kan forestille dig det scenarie sammenlignet med Lotus Notes-miljøet, hvor nogen havde store intentioner, men ikke tænkte igennem udfordringen, og næste ting vi var nødt til at gå og prøve at kortlægge alle disse data, og hovedparten af dem måtte afskrives og det var bare et stort tab af tid og kræfter og ressource og moral. Til et scenarie, hvor vi, når det er korrekt planlagt og korrekt udført og leveret korrekt med de rigtige værktøjer, fik et fantastisk resultat.
Og så det punkt bringer mig til denne ene linje - før jeg overleverer til vores medarbejder for at tale om, hvad IDERA har til at løse netop denne udfordring - er, at det i nutidens verden, hvor stigende systemer drives af databaser, ikke bare er et pænt, men for mig er det en kendsgerning, det er en nødvendighed, at smarte værktøjer efter min erfaring er den eneste måde at styre dataopdagelse, datastyring i skalaen og den hastighed, vi bevæger os på.
Og hvis det gøres rigtigt, som den anden anekdote, som jeg netop delte forhåbentlig illustreret, kan det være en meget smertefri og meget problemfri proces. Ikke kun i nye projekter, men at få dine arme rundt i et aktuelt miljø og sikre, at du når som helst hver dag kan spore og spore, hvad der sker i din organisation, hvilken database der er, hvilke versioner af databasen kører du, og hvem bruger hvad.
Og med det formål overleverer jeg vores medarbejder fra IDERA, og jeg ser frem til at høre, hvad de har at tilbyde på bordet, og hvordan de løser netop denne udfordring.
Binh Chau: Fantastisk, tak, Dez. Kan I høre mig okay? Okay, tak. Hej alle sammen, jeg er Binh Chau med IDERA. I dag skal jeg tale lidt om produkter, som vi har kaldt SQL Inventory Manager, og det taler om opdagelsen og muligheden for at inventar dine SQL Server-forekomster og databaser derude og om at få et greb om, hvad du har i miljøet og snak om nogle andre ting, som Dez og Robin talte om med hensyn til databasespredning og behovet for data i disse dage.
Med det er her nogle overvejelser, som du har hørt, tror jeg, anekdotisk gennem de to historier, som Dez beskrev. Men dybest set i dag er der så meget behov for data og forretningsgrupper derude og forretningsgrupper derude slags spinding af deres egne applikationer og servere, især med SQL Server, ikke? Fordi du nemt kan spinde op en SQL Express-version eller BI-tjenester, at der bare er SQL-sprawl, der foregår hos mange organisationer, du ved, fra den lille til den store.
Mange gange er DBA'er ikke klar over, at nogen har besluttet at starte, ved du, oprette en instans i stedet for blot at sætte en database på en eksisterende instans. De er ikke opmærksomme på disse ting, før der potentielt er et problem, og nogen ringer til DBA: ”Åh nej, min ansøgning er stoppet med at fungere, den er ikke i stand til at oprette forbindelse til en database, hvad sker der?” Og du ved, når DBA spørger nogle spørgsmål, de opdager, "Hej, denne var ikke på vores radar, vi var ikke opmærksomme på det."
En anden er licensomkostninger, ikke? Microsoft SQL Server-licens: Den måde, det fungerer, er, at du ikke har nogen specifik nøgle til det antal tilfælde, du har. Du kan implementere, og derefter foretager de en revision. De ved, de foretager en revision senere og opdager slags, hvor mange licenser du faktisk har brug for. Og så, hvis de foretager en revision, og du ikke er opmærksom på de ukendte servere, kan det resultere i en slags kostbar revision. Og det er en god ting at have værktøjet eller have en fortegnelse over tid for at vide, hvad din licens koster, og at være i stand til ikke kun at vide, men også styre det.
Og så, hvad jeg lige har talt om, hvis du ikke er opmærksom på en server mange gange, hvis ting løber fint, er alt fint, men den eneste gang, du bliver opmærksom på noget, er, når der er et problem. Og så kunne det føre til produktionsafbrydelser eller måske blev serveren ikke vedligeholdt, og du fik ikke en patch på denne server, og det skaber et problem.
Nogle af de spørgsmål, som en DBA-type skal stille dag til dag, er, at de står overfor, ved du, de kunne være administrative eller strategiske, men nogle ting som, Microsoft har lige udgivet en kritisk system patch, hvor mange systemer derude har brug for dette nye lappe? Hvem vil blive påvirket af nedetid, hvis jeg bliver nødt til at tage systemet ned for at lave det op? Hvordan kan jeg nemt komme til disse oplysninger? Skal jeg gå ind i et regneark? Skal jeg gå ind i flere systemer for at finde det? Skal jeg nå ud til de forskellige forretningsgrupper for at få listen? Det er virkelig svært at samle det.
En anden god er dybest set, nogen kommer med, og de siger, jeg har brug for en ny database. Det kræver X-størrelse, og det skal have så meget kapacitet, og så vil de vide, hvor kan jeg sætte det. Uden at vide, hvad der er i dit landskab, er det svært at fortælle dem, okay, vi kan sætte det her, her eller her. Du er nødt til at gå og lave dine manuelle kontroller, der er nødvendige for at få det gjort. Og vi talte om revisionen og også den useriøse server.
Hvis du har en useriøs server derude, ved du ikke, i hvilken tilstand den er i, om den er sikkerhedskopieret, om den har alle dens programrettelser. Nogle gange bliver du muligvis ikke opmærksom på disse ting, før der er problemer, hvilket ville være dårligt.
Det er slags alle udfordringer, spørgsmålene, DBA-ansigtet en dag til dag, hvad der bliver kastet på dem. Så jeg ønskede at introducere dig SQL Inventory Manager, som er et produkt, som vi har derude. Det gør et par ting. Det gør opdagelse, som dybest set er en slags gå ud i dit miljø for at se, hvilke SQL Server der er derude i dit miljø. Og så kan den også automatisk opdage, så dybest set, når du først har kørt en opdagelse, kan du indstille den til at gå derude dagligt eller ugentligt - uanset hvilken tidsramme du vil - til at opdage nye tilfælde derude.
Og så kan du også få det til automatisk at registrere disse tilfælde, så du kan begynde at overvåge dem og tjekke om deres helbredstilstand, og så kan du starte katalogisering og opgørelse af disse tilfælde, så du kan få et godt overblik over dit SQL Server-landskab. Hvad er derude, hvad er produktion, hvad er udvikling, hvad der er gendannelse af katastrofer, hvad der er mindre kritisk, og du ved, hvilke applikationer der kører på dem. Og du kan også få advarsler om, hvornår ting, når sundhedscheck mislykkes, så dybest set, hvis serveren går ned eller såvel som et antal yderligere ting, kan du værktøjet selv.
Eric Kavanagh: Du bliver lidt blød, bare så du ved det.
Binh Chau: Beklager, er det bedre? Hvad jeg vil gøre var at tage jer gennem en demo, vise jer hvad det gør. Hold et øjeblik, lad mig først dele min skærm. Ser I fyre webgrænsefladen? Dette er SQL Inventory Manager-interface. Skærmen, som jeg viser dig her, det er en webbaseret interface. Skærmen, som jeg viser dig her, er vores database-forekomstvisning. På tværs af toppen kan du se, at vi har forskellige. Så "opdaget" er dybest set alle de tilfælde, det opdages på netværket. Og hvad det vil vise mig er dybest set.
Eric Kavanagh: Du begynder bare at bryde lidt op der. Det kan være nødvendigt at lægge telefonen ned og sætte den på højttaleren. Fortsæt.
Binh Chau: Denne skærm til opdagelse viser dig alt, hvad Inventory Manager har opdaget på dit netværk. Her opdages det som 1.003 servere derude. Og det fortæller dig versionen, udgaven, hvis den kan finde den, hvornår den blev opdaget og hvordan den blev opdaget. Lad os sige, for eksempel at jeg vælger at ignorere nogle af disse, hvilket betyder, ved du, måske vil jeg ignorere Developer Edition, fordi de ikke er så vigtige for mig, fordi de bare er Developer Edition; Jeg kan vælge at ignorere disse, og det vil sætte dem på fanen Ignorer, så næste gang jeg kører Discovery, vil den ikke vise mig det igen. Nu kan jeg udfylde for at udføre automatisk registrering eller jeg kan registrere manuelt.
Og her har jeg valgt at overvåge seks tilfælde. Og her er det logget ind, og det vil køre periodiske kontroller af disse, og så er der flere kontroller, alt her fra, du ved, det kontrolleres hvert 30. sekund for at se, om serveren er op eller ned, og det giver dig en slags oversigt over hvad den tilstand er. Grundlæggende her fortæller det mig, at jeg har en server, der er nede, og disse fem der er ope. Det fortæller mig også hvilke serverudgaver, antallet af databaser, status for databaserne, eventuel yderligere opgørelse eller metadata omkring den server. Jeg kan også komme til licensvisningen herfra. Her giver det mig nogle af de Microsoft licensinformationer, som jeg har brug for, hvis jeg ville komme i forvejen for at få en total eller et resumé før en Microsoft-revision.
Her er antallet af kerner, antallet af stikkontakter, den mulige kernelicens, som Microsoft havde introduceret fra 2012. Det var vores syn på Forekomst. Vores oversigtsside, det er den slags side, du vil åbne op til. Dette viser dig de sundhedscheck eller anbefalinger, den har, ligesom lige nu fortæller det mig, at jeg har ni databaser, der ikke har den aktuelle sikkerhedskopi. Jeg kan klikke derind for at gå til detaljerne om, hvilke databaser der er, og jeg kan gå ind og tage en handling på dem, hvis jeg skulle. Det fortæller mig alle de øverste databaser efter størrelse, de øverste databaser efter aktivitet. Jeg kan klikke på den bestemte server og få flere detaljer om den.
Eric Kavanagh: Mens det ruller, hvad du viser os her, er evnen til at se virkelig alt, hvad der er forbundet med netværket, er det ikke?
Binh Chau: Okay. Dette viser alt, hvad jeg har valgt at overvåge ved hjælp af Inventory Manager. Dette er en SQL Server, det viser mig her alle de applikationer, der er tilsluttet serveren. Igen kan jeg hente alle de databaser, der er tilknyttet denne server. Over her kunne jeg mærke ting. Jeg kan oprette et tag til netop denne server, hvad enten det er et præcist domæne eller ej. Vi har kunder, der bruger det til, som de gerne vil mærke deres produktionsservere eller deres gældsservere, og så kan de slags få en fuldstændig rapport om, hvordan tingene er. Når jeg går over til fanen Administration, er det sådan, jeg kan køre Discovery. Og Discovery vil dybest set gå ud og løbe ind i dit netværk og finde alle SQL Server i dit miljø.
Her har jeg dette præcise domæne, som er et domæne af vores, og jeg har oprettet det til at sige, du ved, på dette særlige domæne skal du bruge denne særlige Windows-brugerkonto til at finde opdagelse, og jeg vil have dig til at gøre en komplet scanning. Jeg kan også vælge at specificere "Kun scanne dette bestemte underdomæne" eller "Kun scanne overordnede." Men i dette tilfælde her har jeg sagt køre den komplette scanning. Her er de forskellige scannetyper, jeg kan bruge, og hvis jeg gemmer det, og så er det grundlæggende et job, som jeg kan indstille. Lige nu er det slukket, hvilket betyder, at jeg skulle manuelt køre disse scanninger. Men hvis jeg ville, kunne jeg stille det dagligt, ved du, køre jobbet dagligt. Eller hvis jeg vælger ikke at køre det dagligt - det er for meget - kan jeg sige, at køre jobbet ugentligt på en bestemt dato og tid.
Og så automatisk registrering her, hvis dette er tændt, hvad det ville gøre, er, at hver gang den finder en ny server, vil den automatisk registrere den i Inventory Manager, så jeg kan begynde at overvåge den. Hvis der er en slags udgave, som jeg vil udelukke, som for eksempel, jeg er ligeglad med Express- eller Developer-udgave, fordi det er udviklingsmiljø, så ville jeg bare klikke på dem her, og hvad det vil gøre, er det bare siger hver Når jeg finder noget nyt, vil jeg bare tilføje det til Inventory Manager, så du kan overvåge det, så længe det ikke er en Developer- eller Express-udgave.
Og her kan jeg indstille tags, så hvis jeg f.eks. Har produktionsservere, kunne jeg gå her og mærke disse servere. Jeg kunne mærke enten database eller server med et specifikt blå tag, så jeg kunne for eksempel sige, at denne AO_NODE skulle have et produktionsmærke. Og på denne måde, hvis jeg havde brug for let at komme til serveren, kan jeg gå ud her og klikke på produktionsmærket, og det vil tage mig med det samme til de to servere. Dette er vores Explorer-visning, og dette vises af Ejer, men jeg kunne sige ved Instance-tag, også af databaser, og jeg kan udvide dette for at se, hvad de er.
En anden nyttig funktion, som vi har bygget, som folk virkelig kan lide her, er evnen til at se på, hvad du administrerer gennem Inventory Manager og se, hvilket patch-niveau de er på. Grundlæggende fortæller det her de seks servere, jeg har administreret i mine værktøjer, hvorvidt der er en opdatering tilgængelig for Microsoft, og om den version, jeg er på, om den understøttes eller ej, og supporten status. Hvis jeg ville finde ud af mere om netop denne hotfix, kan jeg klikke på den, og den vil linke mig op til artiklen fra Microsoft med hensyn til, hvad hotfixen handler om, og om jeg skal adressere dem. Du kan eksportere denne liste, hvis du ville, så på den måde kan du sige: "Hej, jeg er nødt til at lappe måske tre af disse servere i denne weekend og de andre tre på et senere tidspunkt."
Byggelisten - så der er en liste, som den kontrollerer imod at se, at din version er opdateret. Du kan gå ud og downloade denne liste for at sikre dig, at den er opdateret, og at du har den seneste liste, du kan sammenligne den med. En anden pæn opgavefunktion, som folk kan lide, er muligheden for at tilføje, ikke kun tags, men muligheden for at tilføje brugerdefinerede lagerfelter. Du ved, hvis du ønskede at tilføje et felt her for at tagge en database for eksempel, lad os sige, at jeg vil mærke det på databaseniveau. Afdeling, denne afdeling og denne database, jeg kunne gøre det til en anden type: open ending, true / false eller picklist.
Og jeg kunne sige, du ved, dette er en HR, marketing, F & U, finans. Og hvad dette gør her er dybest set, når du først har tagget disse ting, kan du få nogle data herfra, der siger, hvor meget kapacitet hver database bruger, og så kan du begynde at forme det, vokser det og giver det mening at opkræve disse afdelinger?
En anden ting er, ved du, hvis du er nødt til at køre vedligeholdelse, ved at vide, hvem der er i den database, kan du vide, hvem du skal kontakte for at fortælle dem, "Hej, jeg er nødt til at køre vedligeholdelse denne weekend, dine databaser vil være offline, " og så videre og så videre. En anden nyttig funktion er søgefeltet her oppe, som folk kan lide. Mange gange bliver DBA'er spurgt om en database eller en applikation eller en server, afhængigt af hvem der snakker med dem, er det slags svært at finde ud af nøjagtigt, hvor det er. Hvad du kunne gøre her er, du ved måske ikke, hvor databasen bor, men du kan bare skrive den i. Jeg kunne bare indtaste IDERA Dashboard, og det vil trække et par databaser op, og hvor de sidder, så du nemt kan få til dem. Og så henter det yderligere oplysninger om dem: deres størrelse, en logstørrelse, uanset om det nogensinde har haft en sikkerhedskopi, hvilken gendannelsestilstand den er i, hvis jeg ville tilføje nogen tags om det. Der er mange forskellige funktioner i dette værktøj, ved du, det er et inventarværktøj, men det er et inventarværktøj, der er meget specifikt for SQL Server og for DBA'er.
Fordi der er, antager jeg, yderligere ting, som DBA gerne vil have adgang til eller til en slags få et godt overblik over, hvordan miljøet og deres landskab ser ud for deres databaser. Du kan også abonnere, konfigurere SMTP-serveren og konfigurere abonnement til at advare for dig selv eller for nogen brugere her. Jeg vil stoppe dette og vende tilbage til præsentationen. Og dette sidste lysbillede her er bare et simpelt billede af arkitekturen. Det er en webkonsol, der kører på en indlejret Tomcat Web Services.
Vi har nogle indsamlingstjenester og managementtjenester, som vi lægger i et lager, og administrationstjenesterne går ud og kører Discovery på dine forskellige SQL Server-instanser. Der er intet installeret på dine monitor-servere. Vi har job, der kører med jævne mellemrum, som bare indsamler data om det, så dybest set, uanset om det er op eller ned, hvor meget data der bruges, hvad folks andre versioner er. Det er alt sammen.
Eric Kavanagh: Ja, lad mig spørge dig - jeg vil stille et par spørgsmål, og så er jeg sikker på, at Robin og Dez også har nogle - bare af nysgerrighed, når nogen kommer ind for at foretage en revision, lad os sige Microsoft, er de bruger dette værktøj, eller jeg formoder, at de har nogle proprietære værktøjer, som de bruger?
Binh Chau: Ja, jeg tror, de bruger proprietære værktøjer. Sagen er, at dette værktøj er et inventarværktøj, så det holder sig ajour med hensyn til, ved du, fordi det har jobbet at gå ud og kontinuerligt indsamle oplysninger om dine servere, det kommer til at løbe derude og på ethvert tidspunkt har du ajourførte oplysninger. Faktisk om, hvordan ting ændrer sig i forhold til, ved du, engangsrapporter, som du muligvis får fra Microsoft for at sige, at dette er det antal servere, du har. Dette er de versioner, du har .
Eric Kavanagh: Ja, jeg er nysgerrig efter Discovery. Så når nogen køber dette værktøj og begynder at bruge det, hvordan sker der egentlig opdagelsen? Dette var slags, hvad jeg henviste til tidligere, med andre ord, tapper du på netværket for at se, hvilke signaler der flyver derude, der ser ud til at være databaseforekomster, og så katalogiserer du det, og når du først har tagget et databaseeksempel, overvåger du? Jeg gætter på, at den har en slags ping, som den gør så ofte, og hvis den for eksempel går ned, er det sådan, du ved, at den er nede. Er det sådan, hvordan tingene fungerer?
Binh Chau: Ja. Jeg mener, når du først har tændt for Discovery, går den ud til dit netværk, og vi har flere forskellige scanninger til at gå derude, men det ved, du ved, en browserskanning og registreringsdatabase scanning. Det gør forskellige scanninger for at se, hvilken computer der er derude, og derefter kontrollerer den: har du SQL-servere derude eller BI-tjenester derude? Og så bringer det det tilbage og trækker det ind i værktøjet og viser det til dig, "Hej, her er alle de ting, som jeg opdagede."
Og hvis du så skulle sige, "Jeg vil overvåge ved hjælp af dette værktøj, " så vil det holde styr på det, og det vil pinge det. Det har job til at pinge det så ofte for at sige, ”Okay, kontroller dette nu om denne ting, ” - du ved, databaseadgangen - kontroller det nu om databasens historie, kontroller databasesiden. Det kører en række job for at kontrollere den database, du overvåger.
Eric Kavanagh: Ja, det er godt. Og vi har et spørgsmål fra et publikummedlem. Jeg ved, at I fyre har værktøjer, der fungerer med en række databaseteknologier, men især denne, du viser i dag, er dette kun for SQL Server, eller dækker dette også andre databasetyper?
Binh Chau: Lige nu dækker dette særlige værktøj SQL Server.
Eric Kavanagh: Okay, det er fint. Lad mig vende det til Robin, jeg er sikker på, at han har et par spørgsmål, så måske tilbage til Dez. Robin?
Dr. Robin Bloor: Ja, bestemt. Microsoft har for nylig - engang i 2006 - annonceret SQL Server på Linux, men jeg tror ikke, den har leveret den endnu. Jeg spekulerede bare på, om du fik kommentarer til det. Er du klar over det? Leger du med det?
Binh Chau: Ja, det er vi også. Vi planlægger at medtage det. Jeg mener, det dejlige ved dette værktøj er, at jeg har talt med en masse kunder, der har bygget deres egne hjemmevoksede værktøjer for at slags gøre det samme, men de skal følge med i de nye udgaver og versioner, som Microsoft kommer ud, men vi har nye versioner og udgaver, vi begynder tidligt på det for at sikre, at værktøjet kan forme en slags overvågning og styre de nye udgaver. Så SQL på Linux er noget, vi planlægger at tilføje og stille til rådighed, når det er tilgængeligt - jeg tror senere på året.
Dr. Robin Bloor: Ja, det er interessant. Forventer du, at mange af dine kunder rent faktisk vil gøre det? Jeg mener, SQL Server er en meget sofistikeret database i min erfaring. Jeg mener, du ved, det er længe i tanden, det er sandsynligvis den ting at sige. Jeg mener, du ved, den originale Sybase, som den kom fra, var faktisk ret forenklet i mange ting, den gjorde. Men Microsoft har tilføjet flere og flere ting gennem årene. Skal alt dette være tilgængeligt på Linux? Jeg mener, vil du rådgive dine kunder om, hvorvidt de skal foretage migreringen?
Binh Chau: Beklager, er det spørgsmål, vi ser folk bede om det?
Dr. Robin Bloor: Er det vel så avanceret i Linux, som det er på Windows, når du har rodet med det?
Binh Chau: Jeg har ikke spillet med det selv, men hvad jeg har hørt fra en kollega er, at det faktisk er meget på niveau. Men jeg har personligt ikke spillet med den nye version af SQL på Linux.
Dr. Robin Bloor: Okay. Har jeg ret i at tænke på, at du simpelthen har lagt agenter på enhver SQL Server, du finder? Er det sådan dette værktøj fungerer?
Binh Chau: Nej, vi lægger faktisk ikke agenter. For dette særlige værktøj, inventarstykket, lægger vi ikke agenter der. Vi går bare lidt ud og ringer og kontrollerer status på det. En dejlig ting ved dette værktøj er, at det er agentfrit.
Dr. Robin Bloor: Så du har andre SQL Server-værktøjer, kan du på en måde minde mig om, hvilke andre produkter, du har i denne pakke, der beskæftiger sig med SQL Server?
Binh Chau: Ja. Vi har SQL Diagnostic Manager. Det er et overvågnings- og ydelsesværktøj. Det gør en mere dybdegående analyse eller diagnosticering og ydeevne og sundhedskontrol for dig end Inventory Manager. Inventory Manager er den lette version af sundhedscheck. Vi har også Compliance Manager og Secure, som er en del af vores sikkerhedssuite. Det fortæller dig dybest set, hvem der har adgang til dine data, hvilke data de får adgang til, hvorfor, og det hjælper dig med overholdelse og andre rapporteringsretningslinjer. Vi har SQL Safe, som er vores backup-værktøj - det gør sikkerhedskopiering og gendannelse, og det er en dejlig en.
Vi har også vores Enterprise Job Manager, som bare overvåger dit job. Og så har vi værktøjskasseværktøjet, der er værktøjsadministratorer og også sammenligningsværktøjssæt såvel som SQL Doctor. Administrationsværktøjssæt og sammenligningsværktøjssæt, det er hvad jeg tænker på som en schweizisk hærkniv. De har flere værktøjer derinde for at hjælpe DBA med at gøre forskellige ting, f.eks. Ved du, kontrollere programrettelser eller flytte eller klone en database. Men der er 24 sådanne værktøjer i den værktøjskasse.
Dr. Robin Bloor: Så er de mennesker, der går til Inventory Management, er de normalt allerede brugere af dine andre værktøjer? Eller er denne form for et indgangspunkt? Jeg kan forestille mig - jeg mener, du kan fortælle mig, hvis du har nogen krigshistorier - men jeg kan forestille mig, at hvis du aldrig rent faktisk har kørt en opgørelse i et temmelig stort datacenter, kan oplevelsen være ganske nøgtern. Er det hvad du finder?
Binh Chau: Ja. Jeg mener, vi har kunder, der introduceres til værktøjet fra andre værktøjssæt, men vi har kunder, der kommer på udkig efter et værktøj som dette på grund af projekter, de har. Et eksempel på, at der var et firma, der fusionerede med et andet firma og købte en række virksomheder og havde brug for at konsolidere deres SQL Server-fodaftryk for at reducere deres omkostninger. Og så de ledte efter et værktøj til slags at gå ud og opdage alt det, de havde, så de kan starte processen med, hvordan konsoliderer vi dette.
Dr. Robin Bloor: Rigtigt, jeg forstår. Det er vel almindeligt med fusioner, når du tænker over det. Okay, jeg overleverer til Dez, jeg vil ikke tage det hele tiden. Se hvilke spørgsmål, vi har fra Australien.
Dez Blanchfield: Tak, ja, spørgsmålene er altid på hovedet her. En af de ting, der kommer til at tænke på, og jeg får dette ret meget, ved du, virksomheder er ikke helt sikre på, hvor de skal trække på, hvornår de skal begynde at investere. Hvornår skal en organisation - i din oplevelse i betragtning af at du er i den kolde fase - hvornår er det rigtige tidspunkt at begynde at investere i værktøjer som dette for at sikre, at du ikke får problemer? Gør du det fra første dag, når du begynder at opbygge din databaseinfrastruktur for den nye organisation eller, som du lige har skitseret, når du foretager en overtagelse / fusion?
Eller er der en bestemt skala, du virkelig har brug for at være på? Har du brug for 10 eller 100 eller 1.000 databaser? Hvad er din oplevelse så langt som det marked, du har haft at gøre med så længe, hvornår er det rigtige tidspunkt at komme ind i dette rum og sandsynligvis, hvor du skal starte? Hvordan ser det ud, når du kommer i gang?
Binh Chau: Jeg mener, måske hvis det er en meget lille organisation, har du muligvis ikke behov for dette værktøj, ligesom med en DBA eller et par DBA'er. Når du begynder at få en gruppe af, jeg ved ikke, tre eller fire DBA'er og måske 50 til 100 servere, kan du eventuelt begynde at gøre sådan noget. Efterhånden som din organisation bliver større i størrelse og bare forretningsfolk, der er teknisk kyndige, og som du ved, ligesom det eksempel, du gav, de vil installere applikationer og databaser på egen hånd, men det er når du vil have denne slags værktøj, fordi du på den måde kan se, hvad der er derude.
Men selv i en mindre organisation er det rart at have denne type værktøj til at holde styr på, hvad du har. Hvis du deler det op, så du kan sige, ”Åh ja, jeg købte SQL 2012 til dette felt, men kører i øjeblikket SQL 2008, fordi jeg har et program, der stadig har brug for den ældre version.” Det hjælper med at have dette inventarværktøj bare for at slippe af med at administrere flere regneark, der kan blive uaktuelle.
Dez Blanchfield: Det andet spørgsmål, jeg lige har fulgt, om det: Hvilke typer færdigheder eller ressourcer skal organisationer planlægge at have, når de kommer til den skala? Er det tilfældet, at der er et bestemt kvalifikationssæt, som du virkelig har brug for, eller en type oplevelse eller baggrund eller den type person, der er bedst egnet til denne form for udfordring? Eller er det noget, som den gennemsnitlige DBA- eller sys-administrator eller netværksadministrator-type færdigheds sæt kan kaste dette på? Har du virkelig brug for en skarp, spidsen hjerne, eller kan du afhente dette temmelig hurtigt?
Binh Chau: Beklager, så du talte om personens færdighedssæt?
Dez Blanchfield: Ja, så når du tænker på en databaseadministrator, er der et bestemt sæt færdigheder, som du har brug for. Så når du går ud for at ansætte en DBA i sig selv til den specifikke rolle, når du tænker på de typer udfordringer, som du talte om her, hvor du bruger et værktøj som dette til at holde styr på kortlægning og sporing af databaser, udfører opdagelsesstykket og driver dette særlige værktøj, er der noget unikt ved brugen af værktøjet og tilgang til denne type udfordringer, eller er det noget, som den gennemsnitlige DBA kan opsamle temmelig hurtigt?
Binh Chau: Jeg mener, at din gennemsnitlige DBA hurtigt kan afhente dette. Jeg synes, det er nyttigt at have denne type værktøj, fordi du også kan have vendt det, fordi det er webbaseret. Du kan give det til andre brugere i din organisation. Du kan give det til appudvikler, der kan tjekke på sin specifikke database eller server. Det fjerner nogle af de administrative ting, som en DBA skal gøre. Tidligere vil nogen ringe til DBA og sige, ”Åh, hvorfor er min server op eller ned?” Nu kan de slags få adgang og se, om deres servere er op eller ned.
Dez Blanchfield: Og hvad slags miljø ville en gennemsnitlig organisation have brug for for at implementere dette? Har den brug for en dedikeret fysisk server, eller kan det gøres på en virtuel maskine? Kan de implementere det i skymiljøet? Hvad er det generelle fodaftryk for installationen af værktøjet og bare den generelle drift af det? Hvor meget tungt jern har det potentielt brug for at køre parallelt med de andre miljøer, det kortlægger?
Binh Chau: Ja, det kan køres på en VM eller en computer eller en server. Det behøver ikke nødvendigvis at være en dedikeret server, det afhænger bare af, hvor mange servere du overvåger. Hvis du har et større miljø, kan det hjælpe med at have en større server, fordi den indsamler en masse data om den SQL Server, du overvåger.
Dez Blanchfield: Right. Er det den slags ting, du komfortabelt kan køre i skyinstansen og skabe en VPN tilbage til dit miljø, eller er mængden af data, den indsamler, sandsynligvis en smule tung til den type brug?
Binh Chau: Vi har ikke indstillet det til at køre det på skyen, for at køre dette i skyen endnu. Det skal sandsynligvis køres på prem.
Dez Blanchfield: Og sidste spørgsmål, hvis jeg kan: en masse af de værktøjer, som jeg har set i dette rum, især hvor du nævnte det for et scenarie, hvor nogen erhvervede virksomhed eller der var en fusion eller noget i den retning, eller endda Hvis det var en organisation, der bare fusionerede forretningsenheder, er det et fornuftigt brugssagsscenarie, hvor nogen deplobler det på en bærbar computer og tager det ind i et miljø for at kortlægge en verden som en gang, eller er det et usandsynligt brugsscenarie? Er det mere slags, at det vil være derinde og bare permanent tilbage til at køre?
Binh Chau: Dette specifikke værktøj er mere en slags, installerer det på en server, og det er tilbage der for at køre. På den måde kan du indsamle de oplysninger, du har brug for, og beholde, antager jeg, en løbende fortegnelse over, hvad du har. Det er i modsætning til kortværktøjet, fordi kortværktøjet er en slags en-til-en, spring til den port, du har brug for, gør det, du skal gøre med det i dag. Denne er slags - den gode del ved det er det faktum, at du slags kan tagge det, give folk adgang til det til en slags kontrol af tilstanden på deres bestemte server, dem, de er interesseret i.
Dez Blanchfield: Okay. Sandsynligvis det sidste spørgsmål til mig, og så giver jeg tilbage til Eric for spørgsmål, der kommer gennem Q & A-vinduet med de deltagende, fordi vi har haft en god valgdeltagelse i dag, en af mine favoritter. Bare for at pakke dette op, hvad er processen for at få dine hænder på dette? Jeg ved, at mange af dine værktøjer er tilgængelige til ting, du kan prøve før du køber. Hvor skal folk gå for at lære mere om dette online, hvor på webstedet skulle de kigge efter downloadene, og hvordan ser rejsen ud, slags gør et bevis på et koncept eller en prøve og får dine hænder på det og bliver fortrolig med det for så at komme i kontakt og købe det?
Binh Chau: Ja. Du kan gå til IDERA.com-webstedet, og du kan downloade en prøve på to uger gratis. Og hvis du kan lide det, og du ønsker at nå ud til os, kan vi også planlægge en demo med en af vores ingeniører for på en slags dybt at dykke ned i værktøjet.
Dez Blanchfield: Fantastisk. Nå, meget tak for det. Jeg sætter pris på tiden til at chatte med dig om det, og baseret på min personlige erfaring, og jeg er sikker på, at jeg taler for Robin om dette på hans livslange oplevelse, synes jeg det er en given, at noget som dette er et krav i dag. Vi kan ikke gøre dette manuelt nu, uanset hvor hårdt vi prøver; skalaen er bare for stor, og tingene bevæger sig for hurtigt.
Jeg kan varmt anbefale folk at gøre nøjagtigt det, hoppe på IDERAs websted og få en kopi at lege med. Fordi den potentielle risiko for min egen oplevelse med de anekdoter, jeg delte lige i dag, har været, kan det hurtigt gå fra meget dårlig til meget god, hvis du har de rigtige værktøjer, men det kan også gå den anden vej, hvis du ikke gør det. ' t. Eric, tilbage til dig.
Eric Kavanagh: Ja, bare pop til et sidste spørgsmål til dig, et interessant spørgsmål. Jeg er bare nysgerrig efter at vide, hvad du ser derude, ved du, skyen er tydeligvis stadig vigtigere i disse dage - Amazon Web Services, men de er ikke de eneste, Microsoft har hele Azure-tilbudet det ser ud til at vinde damp. Jeg er nysgerrig efter at vide, en af de fremmødte skriver, at Dr. Bloor gjorde et interessant punkt om, at DBA'er er dyre, og at ledelsesproblemer forårsaget af enten en useriøs DBA eller nogen, der ikke gør, hvad de skal gøre, kan det løses ved at migrere til skyen. Jeg er virkelig bare nysgerrig efter at vide, hvor meget aktivitet ser du? Ser du, at migrering til skyen bliver et større problem for virksomheder, eller hvad tager du det lige som en tendens?
Binh Chau: Jeg har lyst til, det afhænger bare af, hvilken slags emne du er i. Jeg har lyst til nogle industrier, de siger: ”Nej, vi migrerer ikke.” De migrerer muligvis ikke til en offentlig sky; de ser muligvis på migrering eller migrering af deres ting til en privat sky. Men så ser jeg nogle organisationer, som du er interesseret i, virkelig kommer ind på det hurtige spor og slags går mod en Amazon eller Microsoft Azure. Og så er der nogle mennesker, der siger: ”Nej, vi migrerer ikke vores data” eller ”Der er kun visse data, vi ville migrere, men ikke vores kritiske.” Jeg tror, der er slags tre lejre.
Eric Kavanagh: Ja, det ville give mening. Jeg mener, vi ser det mere og mere, og jeg tror, det vil bevæge sig i pas og begynder i ganske lang tid. Og der er også et tilbageslag til skyen. Folk kommer op på Amazon Web Services - vi har hørt dette mere end et par gange - og til at begynde med er omkostningerne håndterbare og derefter med tiden kryber det bare op og så sidder du lidt fast der. På mange måder er skyen blot et andet datacenter, men det bliver mildt sagt en interessant rejse fremover.
Nå, folk arkiverer alle disse webcasts. Hop online til techopedia.com for at tjekke en komplet liste over alle de ting, vi gør. Og selvfølgelig insideanalysis.com for alt det nyeste. Og med det vil vi byde dig farvel. Og tak så endnu en gang for din tid og opmærksomhed. Tak for alle vores venner på IDERA, og vi taler med dig i morgen forhåbentlig for vores datafilosofi, der kulminerer med webcast. Det er rigtigt, Philosophy of Data er i morgen klokken fire østlige. Håber at se dig der. Pas på folk, farvel.
