Av Techopedia Staff, 26. mai 2016
Takeaway: Vert Eric Kavanagh diskuterer databestyring og forekomstfunn med Robin Bloor, Dez Blanchfield og Bullett Manale i den siste episoden av Hot Technologies.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: OK damer og herrer. Velkommen tilbake igjen. Jeg heter Eric Kavanagh. Ting er varmt. Ting varmes opp her inne. Jeg vet ikke hva som skjer. Å det stemmer, det er på tide med Hot Technologies. Ja, navnet mitt er nok en gang Eric Kavanagh. Du finner meg på Twitter @eric_kavanagh. Dette er showet som er designet for å snakke om det som er varmt på markedsplassen. Tittelen i dag, “Keys to the Kingdom: Managing SQL Server with Dynamic Discovery.” Gode greier. Det er ditt virkelig. OK, det bildet var fra for noen år siden. Jeg skal ikke lyve, jeg ser litt eldre ut nå, men det er greit.
Så vi snakker om hvordan teknologier og SQL Server er virkelig, virkelig, virkelig, veldig varmt. Vi har en hel haug med innhold i dag, så jeg kommer til å overlate det med en gang. Stå ved, her går vi. Det er våre høyttalere. Og Robin Bloor går først.
Robin Bloor: Ja. Presentasjonen kommer til å gå i dybden i databasestyring, så jeg trodde bare at jeg ville løpe gjennom databasestyring eller, du vet, databaser labyrinten, for å få folk til ånden i den. Jeg pleide å være en DBA, jeg antar at du kan si at jeg pleide å være en databankonsulent for omtrent 20 år siden, og det som faktisk overrasker meg om databaser er at ikke mye har endret seg. Mange ting har endret seg med tanke på hastighet, med tanke på datamengdene og sånt, men mye av det forblir faktisk veldig likt det som pleide å skje.
En database er, etter min mening, en organisert utvidbar samling av data som kan optimaliseres for spesifikke arbeidsmengder og levere datastyringsfunksjoner. Det kom først og fremst fordi hvis du ønsket å administrere data i filer, var det en fryktelig vanskelig jobb. Og ideen om å sette sammen et stykke programvare som ville gjøre stort sett alt du trengte for å gjøre, tok nesten umiddelbart av, så snart vi hadde tilfeldig tilgang på IBMs hovedrammer tilbake på 1970-tallet.
Den relasjonsdatabase ble oppfunnet på 70-tallet og kom til i form av prototyper på 80-tallet, og slags fikk sin trekkraft på markedet fra begynnelsen av 90-tallet og fremover. Og relasjonsdatabaser er fremdeles helt dominerende i popularitet. Hvis du leser pressen, vil du høre utrolig mange ting sagt om disse - SQL-databaser, og i det siste er det utrolig mye støy rundt grafdatabaser. Og de er interessante, hvis du vil, men faktisk fremdeles i de siste salgstallene, har relasjonsdatabaser 95% av markedet. Og Microsoft SQL Server som vi skal diskutere i noen dybder i dag er den nest mest populære for Oracle.
Saken med relasjonsdatabaser som gjør dem uvanlige når det gjelder motorene som de er, er at de kan jobbe med både OLTP og spørsmålsbelastning. Du må stille dem annerledes hvis du skal gjøre det, men de er faktisk i stand til begge typer arbeidsmengde. Den ene er korte tilfeldige transaksjoner, og den andre er lange spørsmål som spenner over mye data. Alternativet, NoSQL-databasen og grafdatabasen er hovedsakelig for analyse, og de har steget opp ganske nylig. NoSQL kom først, og graf har begynt å bli litt trekkraft i nyere tid. NoSQL kan brukes til transaksjonsaktiviteter, men grafer brukes nesten aldri til transaksjonsaktiviteter. Grunnen til at jeg kom over en statistikk som faktisk jeg tror er minst ti år gammel som sier at de fleste selskaper har minst tre, faktisk var tallet 3, 5, forskjellige merker av databaser, hvis du ser på deres lager av programvare.
Men realiteten er at de fleste selskaper standardiserer på en spesifikk database. Og de fleste selskaper har standardisert enten på SQL Server og Oracle som de to mest populære for, hvis du vil, standard databaser. Og de bruker alternativene bare under eksepsjonelle omstendigheter der de for eksempel får en programvarepakke som trenger en annen database, eller hvis de følger noen av de store dataanalysemålene som har kommet til.
Hvis du vil, har vi også innblandingen fra Hadoop. Hadoop har på en eller annen måte blitt mer enn et filsystem, men ennå ikke en database. Imidlertid har den SQL som sitter over toppen av den. Men beviset der er at det ikke egentlig erstatter eller hvor som helst i nærheten av å erstatte de relasjonsdatabaser som tjente verdens hjerter og sinn. Og grunnen til det er virkelig at de relasjonsdatabasene tok tjue år, faktisk lenger enn tjue år, for å bli så gode som de er. Og du bygger ikke bare en spørsmotor eller SQL-motor som virkelig er utøvende på veldig liten tid. Det skjer bare ikke.
Og så konklusjonen av dette lysbildet er at databaser er strategiske og at de utvikler seg, de blir bedre. Og det er absolutt tilfelle med Oracle og Microsoft SQL Server. Du husker nok, få av dere tilbake til dagene da databaser først dukket opp, men det gjorde jeg, jeg var en gutt da. Den opprinnelige ideen var at det ville være en enkelt database, og det var en konseptuell ide som absolutt aldri slo rot. Det ble gjort et forsøk fra IBM med AS / 400 til å faktisk ha et databasebasert filsystem, men det dominerte heller ikke. Du sitter igjen med det faktum at databaser naturlig fragmenterer. Du har naturlig nok flere forekomster. Det er problemer med skalerbarhet. Databasen skaleres bare til en viss størrelse, riktignok har størrelsen økt med årene, men de hadde grenser.
Og det var problemer med arbeidsmengden, det viktigste problemet med arbeidsmengden var at OLTP-arbeidsmengder og store spørsmål om arbeidsmengder ganske enkelt ikke er kompatible med hverandre. Og det var umulig å bygge en motor som ville gjøre det. Hva vi støter på, som er slags interessant, kom jeg over et nettsted som nylig hadde over tusen forskjellige forekomster av Oracle. Jeg kan ikke huske nøyaktig hvor mange DBA-er de hadde, men hvis du faktisk snakket med dem om hvor mange av disse databasene som faktisk ble overvåket av en DBA, var det noe som ti. De brukte i utgangspunktet databasen som skap og bare kastet data i den fordi du i det minste hadde et opplegg og det var mer organisert enn et filsystem noensinne ville være, men ingen gjorde noe annet enn å gi den en standardkonfigurasjon og sette den løs.
Jeg er ikke sikker på om det var en god idé. Det høres bisart ut for meg, for å være ærlig, etter min mening, hver gang jeg jobbet med databaser, databaser trengte oppmøte, og du trengte å på en eller annen måte vite nøyaktig hva som foregikk der ute. Og veldig mange systemavhengigheter gjør at visse slags servicenivåer absolutt må oppfylles, ellers får du problemer.
Det var snakk om nylig, jeg har kommet over forskjellige databaser som hevder å være selvstemte. De som er kolonnebutikker som er satt opp for spørretrafikk, er i stor grad selvstemming fordi det er veldig to valg du må ta når det gjelder indeksene. Men bortsett fra det aktuelle området, må databaser være innstilt. Og de trenger å være innstilt, visse relasjonsdatabaser, hovedsakelig fordi det er utrolig mange transaksjoner som inkluderer. Skjøter er dyre aktiviteter. Hvis du ikke plasserer de riktige indeksene på rett sted, må du ta overdreven mengder tid når de ikke trenger det.
Selve innstillingsdatabasene for tiden, vel, de finnes bare i disse områdene hvor arbeidsmengdene er godt kjent. Og min erfaring er at de fleste selskaper har veldig få DBA-er, og det er fordi de er dyre. Og derfor er det bedre hvis du kan bytte ut hva DBA gjør. Dette er en DBAs aktiviteter slik jeg forstår dem. De gjør installasjon, konfigurasjon og oppgradering av databaser. Oppgradering er forresten ikke nødvendigvis en bagatellmessig aktivitet. Grunnen til at du oppgraderer en database, mener jeg, regelen som jeg alltid har jobbet med er ikke å røre den hvis den fungerer, og hvis du skal oppgradere en database til en bestemt ny versjon, gjør du det i testmodus først og etter det oppgraderer du alt. Du har fremdeles alltid å gjøre med den samme versjonen. Men faktisk mange nettsteder jeg har kommet over, det er ikke det som skjer. Det er, la oss si, en god grad av entropi. Lisensstyring er et problem, avhenger av hvilken lisens du har. ETL og datareplikering.
Et av triksene med databasen er at hvis du har en arbeidsmengde som må deles, kan du opprette to forekomster og kopiere, og det gjøres ofte der folk bruker kopien som en varm sikkerhetskopi om nødvendig. Deretter lagring og kapasitetsplanlegging, det er en del av en DBAs aktivitet fordi naturligvis data vokser og du må spore det. Og så må du planlegge for forskjellige maskinvareoppgraderinger eller maskinvareforstørrelser. Det er feilsøking som er en smertefull aktivitet for de fleste DBA-er. Der noe går galt og sikkerhetskopien ikke fungerer helt perfekt, og da må de rulle opp ermene og komme seg ned og prøve å gjenopprette ting fra loggfiler. Det skjer oftere enn jeg tror, vel, jeg husker at det skjedde, men jeg har vært ute av spillet i minst ti år, men jeg husker at det skjedde oftere enn du noen gang hadde forventet. Ytelsesovervåkning og tuning er bare slags bankende hjerte for en DBA-jobb. Men det er også sikkerhet når det gjelder tilgangsstyring, sikkerhetskopiering og gjenoppretting, og lager programvare-testsystemer som rimelig parallelt med et live-system vil gjøre. Og hele dataets livssyklus-ting. Så det er etter min mening DBAs liste over jobber bortsett fra alt annet de måtte bli bedt om å gjøre. Operasjonsdynamikk. Til syvende og sist er DBA hovedansvaret for dataintegritet og styring på tjenestenivå. Og normalt sett er de kritiske. Og det er alt jeg har å si. Jeg skal overlate til Dez.
Dez Blanchfield: tusen takk. Jeg kommer til å ta oss med på en litt morsom, anekdotisk reise rundt hvorfor hele emnet som i dag handler om og er mer kritisk enn noen gang. For ikke så lenge siden var jeg involvert i et prosjekt der vi migrerte en statlig regjeringsplattform som ble brukt til lisensregistrering og kjøretøyregistrering og en hel rekke ting rundt det emnet, fra en Fujitsu mainframe-plattform som kjørte en ting som heter A + Addition, som er et Solaris-operativsystem, eller med andre ord, Unix, kjører Oracle og gjør en veldig god jobb med det. Og synet var at denne tingen ble gammel og det var på tide å flytte den til noe annet. Vi hadde det veldig moro med å kjøre Unix på mainframe, og det var veldig stabilt og veldig sikkert og merkelig nok SDL-plattformen, og det var bare helt lynrask. Men visdom var det på tide å gå av hovedrammen og bevege seg.
Denne betydningsfulle utfordringen med å kartlegge alle systemer og forretningslogikk og SQL-miljøet for databasene under og se på hvordan vi skulle arkitekt og konstruere et nytt hjem for det. Og vi endte opp med å ta den med til en av disse tingene som er et par år gammel nå, men en av øverste ende av Sun-rack-systemet Starfire-servere. Og dette er sannsynligvis noe av det største tinnet du kan kjøpe på planeten som alle lever i en stor boks og en symmetrisk flerbehandlingsserver. Det var et mellomtonesystem i vår verden. Den kjørte Unix og den løp Oracle innfødt og utsikten var: “Hva kan muligens gå galt?” Det viser seg, mye.
For eksempel den gangen, og vi ikke snakker om for lenge siden, måtte vi gå gjennom en veldig manuell prosess for å finne ut hva som var på mainframe-plattformen og komme over. Spesielt det faktiske databasemiljøet og SQL-logikken. Så utsikten var at det skulle bli et ganske greit Oracle-to-Oracle-trekk, database-til-database-trekk; all forretningslogikk ville komme over, det meste av forretningslogikken hadde blitt skrevet i innebygde spørringer og triggere, og hvor vanskelig kunne det være? Men noe som skulle ta måneder, endte opp med å ta ikke et helt år. For bare fysisk og manuelt å gå gjennom alle deler av Unix på stormaskinmiljøet, oppdage hvor alle databasene var og hvor mange forekomster som kjørte og hva som kjørte på disse instansene, og det var en ikke-triviell øvelse, og vi endte opp med å gjøre det tre ganger bare for å sikre at vi hadde fanget alt. For hver gang vi trodde vi hadde gravd så dypt som vi trengte, under overflaten viste det seg at det var mer der.
Den andre utfordringen vi hadde var hvilke forekomster som kjører, og i hvilken tilstand? Er dette et utviklingsmiljø? Er det et testmiljø? Er det en del av integrasjonsprosessen? Er det systemintegrasjon? Er det UAT, brukertakstesting? Er det produksjon? Er det et DR-miljø? Fordi det flotte med mainframes er at du kan bygge disse små virtuelle miljøene som vi alle tar for gitt nå og flytte ting rundt. Og du må trene, er denne personen som driver med utvikling og testing av produksjonskvalitet, eller gjør de produksjonsproduksjon, er det faktiske brukere på dette? Husker at denne tingen utfører sanntid utstedelse av førerkort og bilregistrering og ting som virkelig betyr noe for folks liv.
Og det tok lang tid å kjøre sikkerhetskopier for denne tingen, så vi hadde egentlig ikke et vindu med vedlikehold for å ta tingen offline og se hva som skjedde. Det var ikke noe slikt som å omdirigere det. Vi hadde også utfordringen med å ikke bare finne hvilke forekomster som kjørte og hvor og hvem for, men da måtte vi finne ut hvilke versjoner av hvilke forekomster som kjørte. Og det er her jeg nesten mistet tomten min. Da jeg begynte å innse at vi hadde to eller tre versjoner av produksjonsmiljøet gjennom forskjellige testnivåer, og det var veldig lite i veien for verktøy og systematiske tilnærminger til dette. Vi måtte bokstavelig talt fordype oss i koden og i den kjørende forekomsten og i noen tilfeller ta risikoen for å ta noe offline en liten stund. Vi kom til bunns i hele denne saken, vi kartla den, og det var en veldig manuell prosess som sagt. Og endelig gjorde vi hele ETL-skiftet, dumpet det fra ett sted og flyttet det til et annet og i det hele tatt fungerte det. Og vi var som, ok, det er funksjonelt, vi er veldig glade for det.
Men så løp vi inn i en rekke veldig alvorlige solide teglsteinsvegger. Spesielt fant vi ytelsesproblemer. Og den fornuftige tanken om dagen var, vel, det har gått til en større, bedre, raskere, hardere maskinvare, det er ingen grunn til at den skal fungere dårlig på applikasjonen på databasenivå, så la oss begynne å lete andre steder. Så vi konstruerte nettverket fullstendig to ganger. Hver ruter, hver bryter, hver kabel, vi gikk fra Ethernet til fiber i noen tilfeller, vi oppgraderte programvare, lappet vi, får du utsikten. Vi bygde nettopp om nettverket to ganger og tenkte at det var ytelsesproblemer der. Og det så ut og føltes som det var. Vi gikk gjennom forskjellige sikkerhetssystemer, forskjellige brannmurer. Vi lappet operativsystemet. Vi flyttet ting fra ett datablad til et annet. Og vi brukte betydelig tid på å se på infrastrukturstykket.
Og da innså vi at da vi koblet ut serverne og kjørte noen andre applikasjoner på det, så fungerte nettverket helt fint. Så vi begynte å trekke operativsystemet fra hverandre. Samme sak. Men interessant, nettverksnivået og operativsystemnivået, verktøyene var der, det var faktisk relativt greit for oss å benchmark og teste og bevise at hver av disse brikkene fungerte. Men selv da, på Solaris på mellomtonen på SPARC maskinvareplattform, var ikke verktøyene der for å begynne å diagnostisere databasemiljøet. Du vet, kartlegger om vi hadde brakt alle forekomster over. Og så måtte vi faktisk bygge våre egne verktøy og skrive noen og sette oss ned, og enten det var i selve databaseverktøyene på de originale skriptspråkene, eller om det var en serie med shell-skript eller i noen tilfeller en haug med C-programmer.
Vi delte til slutt inn noen veldig interessante problemer der logikken under SQL-laget, de faktiske databasemotorene selv, viste seg at når noe ble bygget en bestemt måte for noe som kjørte på mainframe-versjonen av Oracle, ble migrert til Solaris på SPARC versjon Oracle det transponerte ikke den samme ytelsen umiddelbart. Så dette var en ganske smertefull reise for oss i utgangspunktet, bare å gjøre det og finne alt, men nå måtte vi diagnostisere det på det nye produksjonssystemet, og igjen blåste denne tingen en måneds migrasjon verdt til nesten et år. Og det kom ganske enkelt ned på at vi ikke hadde verktøyene rundt. Løper rundt og gjør ting som å prøve å kartlegge metadata.
På et tidspunkt bestemte vi oss nesten for at vi trengte et Ouija-brett fordi det skulle bli lettere på den måten å bare peke og pirke tilfeldig. Enkle ting som å finne ut hvem som hadde tilgang til de gamle systemene, og hvorfor de hadde den tilgangen. Og som trengte tilgangen til den nye og bekrefte, få noen til å melde seg av og bekrefte det og kartlegge det. Selv noe så enkelt som størrelsen på databasen var ikke konsistent på tvers av de to plattformene. Vi måtte bygge et verktøy for å gjøre det og gjøre en sammenligning mellom hvor stor databasen er i tonnasje, i rå megabyte eller terabyte på System A versus System B. Og dykke mer detaljert rundt ytelse og det performante miljøet. Igjen, måtte bygge nye verktøy. Det var bare ikke noe hylle for oss.
Og du får hele meldingen ut av dette, da vi kom til slutten av å få tingen til å løpe og vi fikk den stabile, hvert eneste stykke av det var en veldig manuell prosess, den eneste måten vi kunne automatisere noe på var hvis vi bygger en nytt verktøy eller nytt skript. Og hvis vi hadde verktøyene som er tilgjengelige i dag, ville livet vært så mye enklere og så mye bedre. Og vi ville ha spart millioner på dette prosjektet. Men jeg tror at det vi skal snakke om i dag, er det faktum at verktøyene er tilgjengelige nå, og at de gjør livet så mye enklere. Det gjenstår fortsatt mange fallgruver. Oppdagelse av databasene som er der ute og hvilke tilfeller som kjører hva. Hvilken tilstand de er i. Hvor mange kjører? Hvorfor de løper. Enten de kjører bra. Sikkerhetskopieres de?
Dette er alle ting som vi på mange måter kan ta for gitt nå med de riktige verktøyene. Men det var en periode i denne spesielle anekdoten som sagt, der det var noe som mange av oss mistet mye hår om, vi sannsynligvis tok femten år av livene våre, og beklager det faktum at verktøyene ikke var der nå . Og jeg gleder meg til å høre mye mer om det fra gjesten vår i dag, Bullett. Så med det, Bullett, vil jeg gi deg videre, og jeg ser frem til å høre hvordan du har løst dette problemet.
Bullett Manale: OK. Høres bra ut. Eric, la meg ta over her med lysbildene og snakke litt om, virkelig raskt, Idera, selskapet, før vi kommer inn i selve produktet. Akkurat som en FYI, er dette en slags portefølje av forskjellige produkter som vi har tilgjengelig.
Eric Kavanagh: Lyden din er veldig varm, så hvis du bruker et headset, bare dra det litt opp.
Bullett Manale: Ikke noe problem. Er det bedre?
Eric Kavanagh: Det er mye bedre. Ta den bort.
Bullett Manale: OK. Så i dag skal vi fokusere på Inventory Manager, som åpenbart er tilpasset mange av disse temaene som vi diskuterer. Jeg vil bare gi deg en liten forståelse av hvordan dette produktet ble der det er. Vi begynte å se på en daglig basis med vår produktlinje, vi har et ytelsesovervåkningsverktøy kalt Diagnostic Manager. Vi har et Compliance Manager-verktøy. Så mange forskjellige verktøy rundt SQL Server, og uunngåelig stiller vi alltid spørsmålet for lisensformål, "Hva er antall forekomster som du for øyeblikket administrerer i organisasjonen din?" Og det interessante var at vi aldri har klart å få et fast svar på det. Det gjorde egentlig ingen rolle hvem du snakket med. Det var alltid slags, "Vel, vi tror det er rundt dette tallet." De slags ting kom alltid inn, og da måtte vi gå gjennom denne prosessen med å finne ut nøyaktig hva det var som de hadde som de ønsket å lisensiere i forhold til de tilfeller vi administrerer.
Vi har tydeligvis funnet ut veldig raskt at det ser ut til å være litt smerte forbundet med det med mange av DBA-ene. Som en DBA er det klart at en av tingene de er ansvarlig for er å vite at fordi en av tingene de må gjøre er å bekymre seg for lisensavtalene deres, i vårt tilfelle med Microsoft og SQL Server. Det er klart de har mange andre forskjellige områder som de er ansvarlige for, men det er en av dem som er en slags stor billettvare når det gjelder DBA hva dine generelle ansvarsområder er. Med det vi slags kom til konklusjonen er at vi trenger et verktøy som gjør det enkelt for en DBA å virkelig kunne forstå det tallet. Fordi du har SQL-spredning hvis du vil kalle det slik, og det skjer av flere forskjellige grunner. Det er ikke så mye kontroll rundt hvem som installerer programvaren og den slags ting.
Og det verste som kan skje er at noen får hendene på en kopi av SQL Server, installerer den, begynner å jobbe med den uten kunnskap til noen av de andre organisasjonene eller avdelingene i selskapet, og så er det neste du vet, kanskje dataene blir ikke sikkerhetskopiert, og den slags ting som kan skje. Hvor nå har du et annet problem, der du har situasjoner hvor du faktisk mister kritiske data fordi du ikke vet at forekomsten til og med eksisterer i utgangspunktet.
Noe av det vi måtte gjøre var å la oss finne ut av funnstykket. Og så på toppen av det kunne organisere og administrere den informasjonen vi samler inn på en logisk måte som er fornuftig basert på hva virksomheten driver med. Og da åpenbart fra det å kunne ta beslutninger rundt den informasjonen og kunne gjøre den slags ting. Det er slags hvor verktøyet startet og hvor det kom fra. Jeg kan fortelle deg at når vi snakker med DBA-er med jevne mellomrom, det vi virkelig har, er problemet med å ikke vite hvor mange tilfeller de har.
Og det er morsomt fordi begrepet, du ikke klarer det du ikke kan måle, alltid kom med ytelsesverktøy som vi har, som SQL Diagnostic Manager, men du virkelig ikke klarer noe hvis du ikke vet det “Det” selv der i utgangspunktet. Så det er litt av en stor del av dette verktøyet, å kunne bare være i stand til å vite at det er der.
Når vi snakket med noen av de større organisasjonene eller foretaksbutikkene med SQL Server, var det interessante som vi fant med mange gutter som vi snakket med, at de faktisk hadde satt opp en tid i løpet av året de gikk faktisk fysisk fra et sted til et annet for å prøve å finne ut hvordan den tellingen ser ut. Du kan forestille deg som en DBA at du får betalt en ganske god sum for å fysisk gå fra en maskin til en annen i noen tilfeller, noe som overraskende nok var hva vi ville høre fra noen ganske store selskaper som jeg ikke vil navngi. Men bare et interessant poeng at to uker i året kan brukes på å gjøre denne typen øvelser bare for å finne ut om lisensantellingene deres er riktige.
Dette er alt relatert til dette verktøyet og hvordan det hjelper, men måten vi adresserte det på, var gjennom muligheten til å oppdage basert på en rekke egenskaper ved SQL Server. Og så er det første spørsmålet, hva peker du på eller hva prøver du å se på først? Måten vi gjorde det på var å si at la oss gjøre det etter IP-rekkevidde, eller vi kan gjøre det ved medlemskap i selve domenet når det gjelder datamaskiner som er medlemmer av domenet. Det er sånn vi adresserte den delen, bare for å kunne si at dette er området vi ønsker å fokusere på når det gjelder funn.
Og så er den andre delen av dette basert på disse egenskapene, portene og andre ting, WMI-registernøkler og den slags ting, vi kan samle og konstatere at SQL sannsynligvis kjører og installeres i den forekomsten eller det aktuelle miljøet. Det er tydeligvis en mye bedre metode enn sneaker-metoden eller sneaker express-metoden. Nå er det kule ting at all den informasjonen vi samler om forekomsten blir oppbevart i et depot, og at den kan endres etter hvert som miljøet endres. Det handler ikke bare om, "Hei, det er en forekomst, her er en liste vi har funnet, " men det er som DBA, eller personen som administrerer forekomstene, å kunne bestemme om de vil gjøre den delen av inventaret, og deretter når det er ikke en del av inventaret, for å kunne ta av den forekomsten. Og slik at de har livssyklusen til hele prosessen med SQL Server-forekomsten som virkelig skal forstås i verktøyet.
Når vi har oppdaget tilfellene, hva gjør vi etter det? Den andre tingen er mye informasjon om forekomsten, jeg vil ikke måtte gå manuelt og skaffe den i et regneark eller den slags ting. Og det er en annen ting som var ganske interessant når jeg snakket med DBA om lagerbehandlingen og lisensiering, er at du vil bli overrasket over hvor mange DBA-er jeg snakket med, når du spør dem: "Hvordan opprettholder du varebeholdningene dine?" Og vi snakker med DBAer som er den virkelig ironiske delen av det, at de holder det og sporer det i et statisk regneark med alle ting. Som sagt, det er veldig ironisk når du tenker på det i et øyeblikk. Men det var i mange tilfeller, og det er fremdeles tilfelle for mange organisasjoner hvordan de styrer det. Hvordan de holder det. Det er en mesterkopi av et Excel-regneark som flyter rundt og det må oppdateres regelmessig.
Det er de tingene som var en utfordring, og så ved å registrere den instansen og gjøre den til en del av inventaret, kan du gjøre det og hente informasjonen. Du kan få det til å automatisere hvorvidt det blir en del av inventaret, versjonen, utgaven, de andre tingene du kan gjøre med det, du kan legge til kanskje den listen eller Excel-regnearket du har. Du kan importere det til dette verktøyet som heter SQL Inventory Manager. Hvis du allerede har et utgangspunkt for forekomster som du føler at du er ganske trygg på, kan du importere disse forekomstene i og deretter gjøre den delen av det administrerte lageret ditt i produktet. Når vi først har forekomsten og når vi vet at den er der, blir den, ok, vi har mye informasjon som vi kan utnytte ved å vite at den forekomsten er der, ved å gå ut og samle den informasjonen.
Og mye av informasjonen vil trengs for mer enn bare lisensformål. Mye av det kan brukes til å åpenbart bare vite hvor ting er, for å kunne søke gjennom denne informasjonen etter at den er innhentet. Men de viktigste tingene er serveren, selve maskinvaren. Å kunne forstå hva slags maskin det er, kanskje modellen eller produsenten, minne, mengden minne, enten det er en fysisk eller virtuell maskin og spesielt antall fysiske stikkontakter eller kjerner og prosessorer og de slags ting.
Når det gjelder antall kjerner, spesielt med SQL Server, å vite måten de gjør på lisensiering på er kjerneberegninger nå i de nyere versjonene av SQL, som blir en veldig viktig del av det, og det er ikke noe du har å gå ut og faktisk grave etter. Når forekomsten er identifisert, kan vi gi den informasjonen og få den ut og la deg se den og forstå den, og selvfølgelig kan dra nytte av den.
Det neste laget ned er i det tilfellet, som tydeligvis du har mye forskjellig fra SQL Server-forekomsten, enten det er standard eller enterprise eller til og med ekspress for den saks skyld, eller gratisversjonen av SQL Server. Å kunne forstå også hvilke applikasjoner som er knyttet til den forekomsten, og dette kan gjøres automatisk. Å kunne forstå konfigurasjonsinnstillingene og den slags ting samt annen informasjon som er relatert til forekomsten av selve SQL Server.
Så kommer du ned til den faktiske databasen og ser konfigurasjonsinnstillingene, hvor mye plass som er bundet til disse dataene, hvor den ligger, alt dette blir automatisk befolket og det er en enorm tidsbesparelse. Og nok en gang, fordi det dynamisk går ut og til daglig å identifisere nye tilfeller, er det en levende ting du har når det gjelder varebeholdningen. Det er slags mål med produktet er å gjøre det på den måten, er å gjøre det til noe som endres dynamisk.
Når all denne informasjonen blir tilgjengelig for oss, og vi kan hente inn alle disse dataene, er det virkelig fornuftig å begynne å lage dine egne metadata knyttet til disse tilfellene, og at metadata kan opprettes på en slik måte samsvarer med måten du gjør forretninger på.
Så hvis du har forekomstene gruppert etter geografisk beliggenhet, eller av applikasjonseiere eller av DBA-eiere eller hva som helst, kan det være når det gjelder hvordan du vil gruppere disse instansene, hvordan du logisk vil gi mening om disse tilfellene, så er det snilt av to områder i verktøyet som vil gi deg den muligheten.
Den første er muligheten til å opprette en forekomsttag, eller en tag. Noe som egentlig er å opprette en tilknytning til enten serveren, forekomsten eller databasen slik at du kan lage visninger og svare på spørsmål som kan komme opp hver dag, som virkelig hjelper deg å få tak i det du har, hva du styrer og hvordan du vil komme deg videre med den informasjonen.
Den andre tingen vi har er noe som heter lagerfelt eller egendefinerte lagerfelt, og disse er mer spesifikke for slags småting av informasjon som du kan bore i, for eksempel databaselaget jeg kanskje bestemmer meg for å legge til en rullegardinliste som har alle DBA-ene og jeg kan sette hvem som er ansvarlig for den databasen avhengig av den type situasjoner eller hva som helst, uansett hvilken database det er med hvem som er ansvarlig for den, kunne velge det slik at jeg vet at det er de som er ansvarlige og veldig enkelt bare ved å grave i varelageret.
Så disse informasjonsstykkene blir veldig verdifulle, spesielt hvis du har et stort miljø, fordi det bare hjelper deg å være klar over informasjonen og vite hva du har og hvordan du gjør det.
Så la meg gå videre og bytte til neste lysbilde her. Det jeg viser deg nå, er at all denne informasjonen vi samler inn, all denne informasjonen og dataene som vi samler inn og bruker metadata på, gir deg muligheten til å ta enklere og raskere avgjørelser når det gjelder skru opp lisenser hos Microsoft i enterprise volumlisenser eller programvareforsikring hos Microsoft.
Det gjør det veldig enkelt for deg å gjøre dette i stedet for å måtte, måtte gå og gjøre mye manuell innsamling av data, mye manuell innsamling av den informasjonen som egentlig bare generelt gjør det mye bedre av en prosess. Så det er slags et av mandatene til produktet, en gang for å gjøre det lettere for DBAene å ta de beslutningene rundt lisensiering.
Nå er det andre vi snakker med DBA-er, oppdaget og lært virkelig raskt, det - og det er litt tilbake til det som ble diskutert tidligere - du har kanskje 300 forekomster i ditt miljø av SQL Server, men det er egentlig bare en undergruppe av de som virkelig overvåkes og styres fra en tradisjonell ytelsesovervåkningstype.
Så hvis du går, og du faktisk setter deg ned med DBA og du sier: “Se, vi vet at du har disse 20 forekomstene eller 10 forekomster av de 300 som overvåkes med dette verktøyet som er designet for å overvåke det og samsvare med SOAs og få varsler og alle de slags gode ting, ”det vi også fant, er at hvis du spurte:“ Så hva med disse andre 280 tilfellene du har? Bryr du deg om dem? Og de gjør det, de bryr seg om dem, men de ønsker ikke nødvendigvis å investere for å overvåke de på dybdenivået som kan gjøres med disse tilfellene kontra de 10 eller 20 virkelig, virkelig kritiske produktforekomster.
Så den andre delen av ligningen med dette verktøyet er at det også hjelper når det gjelder å være i stand til å sikre at du på et basenivå er dekket med tanke på instansens helse. Nå kommer det ikke til å fortelle deg om du har en dødvakt eller hvem offeret for dødvollen er. Det er ikke for å komme til det nivået på selve øktene og detaljene i spørsmålene. Men på samme tid vil det fortsatt gi deg beskjed om at hei, serveren er nede eller hei volumet fyller eller du trenger å gjøre sikkerhetskopier av databasen, det er en slags viktig del av å være en DBA.
Så de slags ting er definitivt fortsatt viktige, og med dette verktøyet har de gjort det til en måte for deg å ha en fange for de virkelig kritiske tilfellene som har mye, mye verdt knyttet til dem, hvis de går nede må du vite det med en gang. De kan ha et høyere nivå av overvåking og være i stand til å gjøre slike ting, mens det med dette vil være i stand til å plukke opp nye tilfeller som blir lagt til miljøet og sørge for at de blir redegjort for og også lage at de grunnleggende nivåene av helsekontroller blir dannet.
Så det er litt i et nøtteskall hva Inventory SQL Import Manager handler om. Nå skal jeg vise deg en demonstrasjon av det. Før vi gjør det, bare raskt viser jeg deg at dette er arkitektur-lysbildet her, og bare for å vise dette, forekomstene av SQL som vi administrerer, vi kan oppdage alt fra SQL 2000 helt opp til det nye versjoner av SQL.
Så vi kan gjøre det uten å måtte distribuere agenter til selve instansene. Vi gjør det gjennom en samlingstjeneste, og den kommer til å samle informasjonen og putte den i et arkiv, og deretter fra en Tomcat-webtjeneste front-end-konsoll vil vi kunne interagere med disse dataene og se dem. Så det er ganske grei arkitektur.
Jeg kommer til å gå over og faktisk ta oss inn i selve produktet slik at du kan få en følelse av det, en forståelse av hvordan det fungerer. Så den beste måten å gjøre dette på er å første typen introdusere deg for grensesnittet i dette, er et slags dashbord som vi ser på her.
Jeg kan se antall tilfeller akkurat nå som jeg har under ledelse, ikke er så mange. Men jeg har ikke et helt datasenter i baklommen heller. Så jeg har omtrent seks tilfeller som vi ser her. Når det er sagt, er jeg det jeg skal gjøre er å gå gjennom oppdagelsesprosessen og vise hvordan det ville fungere.
Nå er det første du vil gjøre i administrasjonsdelen du kan spesifisere hvordan du ønsker å oppdage forekomstene dine. Du vil kunne legge den informasjonen inn her og igjen som kan gjøres gjennom en rekke IP-adresser. Du kan peke på et domene eller et underdomen og bare være i stand til på maskinene som er medlemmer av det domenet å kunne utføre de kontrollene du ville være i stand til å velge en rekke forskjellige typer egenskaper når SQL kjører for å se etter.
Så når du har gjort det, og du kan få det automatisert til å kjøre på daglig basis for å samle dataene. Du vil også kunne gjøre det på ad hoc-basis om nødvendig. Men når du først har startet den, oppdagelsesprosessen, er det du vil se når du går over til forekomstevisningen her. Du har en Oppdag-fane, og Oppdag-fanen skal vise oss de tilfeller som nylig er oppdaget. Så i vårt tilfelle har vi et nummer her. Det jeg skal gå foran og gjøre er å gå foran og legge til den vi skal bruke som eksempel. Så dette er en Chicago-instans i dette tilfellet, ikke sant? Jeg kommer til å legge til den forekomsten i varelageret mitt.
OK, og det kommer til å lede meg gjennom et par ting her. Jeg vil bare gå foran, og du vil se at vi kan angi legitimasjon. Min legitimasjon skulle være god der. Jeg kommer til å fortsette, og du vil merke at jeg kan tildele eierskap til dette hvis jeg vil. Jeg kan også spesifisere et sted. Nå kan selve plasseringen legges til, og den vil huske at neste gang, åpenbart.
Nok en gang kan jeg også knytte tagger til dette med tanke på metadataene og hvordan vi ønsker å plassere disse forekomstene av SQL, spesielt denne, i hvilke bøtter vi vil legge dem i. Så vi har noen aktuelle koder, populære koder, så vi kan se på en haug med forskjellige tagger som jeg kanskje allerede har inkludert. Jeg skal bare velge noen av disse tilfeldig, og vi kan bruke det.
Så nå når jeg går videre og legger dette til varelageret. Nå som den er lagt til, vil vi nå se den vises under denne administrerte visningen, og slik at du kan se den oppført her. Så du vet at det er det første trinnet, og det jeg nettopp viste deg, var måten du hovedsakelig vil legge til disse tilfellene når du går gjennom på en daglig basis. I noen tilfeller kan du si at du vet hva hvis det er en bedriftsutgave av SQL-server, jeg automatisk vil legge det til i mitt lager? Jeg trenger ikke å gå manuelt og velge å gjøre det.
Jocelyn: Jeg kommer til å avbryte deg veldig raskt. Vi ser ikke demoen din.
Bullett Manale: Du er ikke?
Jocelyn: Nei.
Bullett Manale: Vel, det er ikke bra, la oss se.
Eric Kavanagh: Hvis du går til øvre venstre hjørne, klikker du på start, klikker på det.
Bullett Manale: Ah, ok.
Eric Kavanagh: Og del nå skjermen.
Bullett Manale: Beklager det. Jepp.
Eric Kavanagh: Det er OK. Bra fangst der, produsent Jocelyn.
Bullett Manale: OK, er det bedre? Ser du det nå?
Robin Bloor: Ja.
Bullett Manale: OK, så la oss bare snakke deg gjennom der vi var virkelig raskt. Vi har fått de oppdagede tilfeller vi har hatt tidligere. Jeg har nettopp lagt til Chicago-forekomsten, og det du ser nå er at det nå er oppført her. Legg merke til at det allerede har trukket mye tilleggsinformasjon. Hvis jeg klikker på selve forekomsten, vil du begynne å se all slags informasjon som vi allerede har samlet om den forekomsten. Her er en liste over alle databasene som er der. Vi kan se en oversikt over databasene etter størrelse og aktivitet, i forhold til hvilke som har mest mulig størrelse og aktivitet.
Nok en gang kan vi også fortelle deg rett fra flaggermus hvilke applikasjoner vi ser kjører på den forekomsten basert på arbeidsmengden som vi ser kjører på forekomsten. Så det er litt hyggelig å kunne gjøre det automatisk. Jeg trenger ikke å gå inn og knytte søknaden til forekomsten. Basert på hva vi ser kan vi befolke det. Hvis du nå vil legge til et program manuelt, kan du absolutt gjøre det. Men det er bare en fin måte å kunne vise foreningens tilknytning til databasen eller, beklager, til applikasjonen.
Du vil også legge merke til at på høyre side av skjermen har vi et øyeblikkelig sammendrag og under at vi har en serveroppsummering. Så vi snakker om for eksempel viktige opplysninger her, å vite versjonen og ikke bare SQL Server 2012, men selve versjonsnummeret som inkluderer og forteller oss hvilke hurtigreparasjoner som er knyttet til den, hvilke servicepakker er knyttet til det, kan det være veldig viktig å vite. Det er klart minnekravet er viktig. Alt sånt, uansett om det er gruppert, all denne informasjonen, trenger jeg ikke å legge den inn - den er allerede samlet og samlet, og når vi først identifiserer at det er et oppdaget eksempel, vil det være en del av varelageret vårt.
Det andre du ser her - og det vil vise deg - er under denne forekomstvisningen. Vi har disse attributtene som jeg snakket om tidligere, de tilpassede attributtene som kan legges til. Så vi kan legge til åpne slags tekstfeltfelt, vi kan gjøre ja / nei i form av, du vet, en milliard typer valg. Vi kan til og med lage nedtrekkslister. Du kan gjøre det ved forekomsten av databasen eller på servernivå.
Så hvis vi blar litt lenger ned, kan vi se all relatert informasjon til selve serveren. Så du vet at alle disse slags ting er tydeligvis veldig, veldig hjelpsomme fordi det hele er samlet og samlet, og det er der for oss snart vi tar den beslutningen om å gjøre det til en del av varelageret vårt. Her kan vi vise noen av forskjellene når det gjelder prosessorene, antall logiske kontra fysiske, hvor mye minne. Så du får virkelig mye informasjon og trenger ikke å gjøre mye arbeid.
Den andre delen av dette, er som sagt at vi samler inn disse dataene på forekomst av servernivå. Hvis vi til og med går ned til databasen, kan vi se at mye av dette er ødelagt for oss også. Så hvis jeg går til samsvarslageret mitt, kan jeg i dette tilfellet si, vel, du vet at dette har å gjøre med en, dette er en samsvarsdatabase der nivået for samsvar eller forskriftskrav er knyttet til, og det kan være, la oss si, SOX-samsvar eller PCI-samsvar. Så jeg kan velge hvilke databaser som har samsvar knyttet til dem som jeg må fylle, eller sørge for at jeg opprettholder i henhold til det lovkravet.
Så denne typen ting har vist seg å være veldig nyttig for DBA-er fordi det er et sted de sentralt kan gå for å holde alle disse tilknyttede metadataene i omgivelsene sine lett, og de kan gjøre at de, som sagt, samsvarer med virksomheten deres som de har. ' gjør det, slik de gjør forretninger. Så hvis vi ser på alle tingene så langt det vi har sett, har du tydeligvis en ganske god oversikt over forekomsten, hvis jeg driller inn i det.
Jeg kan også søke i tillegg, så jeg sa la oss se etter det samsvarslageret i hele mitt inventar. Så det du vil se her er at jeg kan søke etter disse tingene og være i stand til å identifisere dem. Jeg sier det - jeg er ikke sikker på hva, go-knappen min fungerer ikke der. Greit. La oss se, la oss prøve det igjen. Der går vi. Så vi vil da kunne se en oversikt over hvor vi ser noe som vi overholder, og jeg kan bore ned i det og se det også fra det synspunktet. Så du har en veldig rask og enkel måte å grave i disse dataene på.
Nå som vi nevnte før, har du mange forskjellige måter å lage metadata mot forekomstserveren og databasen. Den andre delen av det er å kunne dra nytte av det på den måten du har gruppert det og på den måten du har assosiert med det. Vi går til utforskerutsikten, vi kan gjøre akkurat det. Vi kan si at jeg vil gjøre en databaseopptelling etter lokasjoner. Så antall databaser på hvert sted i miljøene som jeg støtter. Eller kanskje er det basert på eieren som eier forekomstene jeg har der ute i form av forekomstall. Så vi vil kunne se det. Så du får en veldig god og enkel måte å male disse bildene på for deg basert på hvilket spørsmål det er du prøver å svare på den gangen.
Så hva du har den informasjonen som er laget slik du ville, kan vi eksportere den ut til PDF eller forskjellige formater for å kunne utnytte den og sende til kollegene eller gjøre hva vi trenger der. Så du vet at du ville være i stand til å gjøre den slags ting. La oss gå tilbake til - mistet jeg det? Der går vi. OK så forhåpentligvis er dette fornuftig med tanke på det jeg har snakket om så langt. Nå som dataene vi har samlet inn, er alt dette åpenbart veldig viktig av flere årsaker - lisensiering og hva ikke.
Den siste typen ting bare å nevne er at vi går over til denne administrasjonsdelen her. Det er her du også kan konfigurere e-postmeldingen og varslingen din og være i stand til å sørge for at du kan konfigurere disse tingene for tingene du virkelig vil vite om. Så vi kan sette opp e-postvarsler, vi kan sette opp muligheten til å slå på visse ting og slå av visse ting og deretter kunne bestemme hvem som skal motta disse e-postene, og abonnere på varslene vi kan knytte til hvem vi ønsker å være, som vil vite om den slags ting.
Men som jeg sa tidligere, dette er en veldig fin måte å gjøre, i det minste ha den generelle tryggheten av å vite for hele enterprise SQL-forekomster - hva det er du har, og også sørge for at den kjører optimalt selv om du ikke har det. t, har ikke tatt beslutningen om å investere i et tungt slående ytelsesovervåkningsverktøy for å administrere den forekomsten. Dette kommer til å dekke deg fordi det er en veldig rimelig måte å gå ut på, og i mange tilfeller være i stand til å gjøre disse varelager og være i stand til å gjøre en slags veldig bred type generell overvåkningsnivå for å sikre at du har den tryggheten og vet hva som skjer.
Så forhåpentligvis er det fornuftig på den måten vi har beskrevet det og vist det for deg. Jeg antar at fra det ståstedet kan jeg gå videre og gi det tilbake, og vi kan snakke litt mer.
Eric Kavanagh: Det høres bra ut. Så Robin? Dez? Noen spørsmål?
Robin Bloor: Jeg har spørsmål. Det er veldig interessant å faktisk, jeg mener at jeg bare ønsket å komme med kommentaren som stort sett overalt jeg har vært, ikke bare blant DBA-ene, men blant nettverksgutta, blant lagringsgutta, blant de virtuelle maskinstyringsgutta, de ' alle arbeider av regneark.
Eric Kavanagh: Det stemmer.
Dez Blanchfield: Du vet litt at det er, du vet at det er greit til tallene begynner å bevege seg. Når tallene begynner å bevege seg, vet du at de kommer til å komme i trøbbel. Så spørsmålet nå er jeg interessert i, og jeg vet at det vil være vanskelig for deg å svare, men hva, hvis du går til et sted hvor de ikke har noe sånt der inne for bruk av regneark, så la oss anta DBAene er veldig smarte karer og så videre og så videre, hva slags ROI tror du at du ville fått fra å implementere noe som dette? Har du noen tall på det eller noen retningslinjer for det?
Bullett Manale: Det er vanskelig å si hva avkastningen er fordi miljøet blir litt annerledes. Det er klart at jo større virksomhet, desto større miljø er, selvfølgelig mer ROI vil sannsynligvis være hvis de bruker manuelle metoder nå.
Jeg vet at jeg har snakket med en rekke - når jeg sier store organisasjoner i tusenvis av ansatte og sannsynligvis også tusenvis av tilfeller - der jeg har folk der jeg viser dette til dem, og de sier at dette vil ta to uker av tiden tilbake. Det har jeg sagt til meg mer enn en gang. Så det er vanskelig å si når det gjelder det faktiske dollarbeløpet fra et kjøp, men det er betydelig når du har miljøene.
Som sagt, det er ganske konsistent, det er menneskene jeg, de fleste jeg snakker med, holder tingene i et regneark. Så det er bare en veldig, veldig subjektiv ting, fordi alle omgivelser er litt forskjellige i forhold til hvordan de gjør lisensiering og hvordan de gjør lisenser hos Microsoft er en annen del av det som er en faktor. Men hvis de må gjøre ekte oppslag hvert år eller hvert tredje år, tror jeg at det er tre år for maksimalt for Microsoft at de vil, vil de at du skal oppfylle minst hvert tredje år.
Da vet du at det er betydelig og det, du vet at det bare er noe som gjør mye enklere. Fordi det er en dynamisk ting som alltid endrer seg, gir den litt mer gyldighet også når det gjelder hva det er du ser på versene, vel, vi har ikke oppdatert regnearket på seks måneder eller et år. Så hvor ofte oppdaterer du regnearket er et annet spørsmål for å forstå at svaret på avkastningen.
Dez Blanchfield: Ja, jeg mener, SQL-lisensiering, lisensiering av dette er bare et jævla mareritt, men det er spesielt et mareritt fordi lisensieringen ikke er den samme mellom Microsoft og Oracle og alle andre som er der ute og gjør databaseting. Hvis du faktisk holder ting i regneark som har en tendens til å være det som faktisk skjer, vet du at lisensieringstid kommer før du faktisk innser det, og du har ikke dataene, hvis du vet hva jeg mener, for å enkelt få den informasjonen.
Uansett, som du påpeker, er det dynamisk, og jeg har ingen anelse om personlig fordi jeg faktisk aldri har hatt til å forhandle med Microsoft, så jeg har ingen anelse, men antagelig er det databaser som folk ganske ofte tar ned testdataene, tester miljøer, og jeg vil gjette at det er en torn i din side hvis du driver med lisenser. Er det deg-?
Bullett Manale: Ja, ja. Det er tilfelle fordi mange ganger ting blir glemt og så begynner vi å prøve å finne ut, ok, ok, vi har kjernelisenser som vi må finne ut antall kjerner for hvert av disse tilfellene, og jeg Jeg vet at når det gjelder standardene for hva du kjøper maskinvaremessig, kan du like godt kjøpe ganske god maskinvare, så hvis du ikke bruker den maskinvaren slik den skal brukes, betaler du for mye fordi du betaler for kjerneprising når disse kjernene ikke blir utnyttet, så det blir et problem.
Så hver versjon av SQL har en annen måte lisenser blir brukt på, noe som til og med gjør det litt forvirrende. Så du har noen utfordringer rundt det, og det er en stor del av hvorfor denne informasjonen er veldig nyttig fordi vi kan fortelle deg hvilken versjon det er, vi kan fortelle deg tydelig hvor mange kjerner du har, hvis det er eldre versjoner av SQL det var prissetting per socket, vi kan fremdeles vise tydelig det også. Så det bare, det gjør det mye enklere for en rutine du må gjennomgå når det kommer tid til å gjøre opp for de tingene.
Dez Blanchfield: En ting som kommer til tankene for meg, oh sorry go-
Robin Bloor: Det er OK, du går i Dez, jeg hadde tenkt å stille et mulig irrelevant spørsmål.
Dez Blanchfield: Bare noe veldig raskt mens du er i emnet du er nå - vi ser mye mer adopsjon av skymiljøer, og hvis vi kjører dette i vårt eget datasenter, i vårt eget miljø, de kryper rundt og finner, å oppdage ting er relativt greit.
Hvordan klarer vi, hvordan takler vi scenariet der vi kan ha tre datasett, to skyer og synlighet på tvers av disse miljøene er brannmur og det er ofte et datasett på slutten av et rør eller en VPN. Er det borte å oppdage fra frontend, eller må vi, for å starte åpning av porter, slik at vi kan skanne over bestemte miljøer mellom en slags sky og utenfor lokaler der denne plattformen kjører?
Bullett Manale: Ja, det ville det vært noe betraktning når det gjelder havnene. Så det er, dessverre, jeg skulle ønske jeg kunne si at det kommer til å bryte gjennom alle disse miljøene, men det er noen forskjellige alternativer du kan gjøre med dette. Selvfølgelig, hvis du gjør noe som Amazon EC2, alt du trenger trenger er tilgangen til det miljøet gjennom tilkoblingen din, forutsatt at portene dine er åpne og deretter kan spesifisere IP-adressene dine eller domenet ditt tilknyttet det, og det kan starte samlingen og start oppdagelsen.
Så det er, i de typer miljøer er det virkelig ikke noe problem; det er de mer spesifikke miljøtypene som RDS, og hvor du bare skaffer databasen i seg selv, der det blir litt mer utfordrende å se og oppdage den typen informasjon.
Dez Blanchfield: Så etter at det var der, er det databaser og databaser. Så for eksempel de gode gamle dagene med bare å ha en veldig, veldig stor databasemotor som anekdoten som jeg delte foran, hvor det bare er en massiv plattform, og alt det gjør er å tilby database. I disse dager er databaser innebygd i alt, faktisk er det som at to eller tre av dem bare kjører i telefonen min bak apper.
Hva slags utfordringer ser du med scenarier der du har miljøer fra Lotus Notes, med apper bak seg, SharePoint med databasen på de forskjellige internett og så videre? I hovedsak drives alt av database på baksiden. Hva slags ting ser du der ute, og hva slags utfordringer ser du at folk står overfor bare prøver å kartlegge den slags verdener, og hva verktøyet ditt gjør for dem?
Bullett Manale: Vel, jeg mener at tingen med det er at det du sa - alt trenger en database nå, så mange ganger er det sannsynligvis mye, det er mange databaser som blir introdusert i miljøet som DBA selv blir ikke en gang gjort oppmerksom på fordi det ikke er veldig vanskelig å få en SQL-server installert i miljøet, generelt sett.
Dette verktøyet identifiserer også ting som ekspressdatabaser, så gratis versjoner av SQL Server. Morsomt nok, når du igjen snakker med DBA-ene, får du ikke et konsistent svar med tanke på om de bryr seg om de gratis databasene som er der ute. Mange av disse applikasjonene som du snakker om, vil bruke den gratis versjonen av databasen. Men organisasjonene selv vil ha en annen holdning når det gjelder hvem som er ansvarlig for den databasen, avhengig av hvem du snakker med.
Noen DBA-er som jeg snakker med, kan jeg tenke på forrige gang jeg var på SQL Server PASS, som er i Seattle, spør du spørsmålet “Bryr du deg om ekspressdatabasene dine?”, Og det var omtrent femti-femti. Noen av menneskene ønsket å vite om dem som en DBA fordi de følte at de er en del av sitt ansvar, selv de uttrykte databasene de fremdeles kunne inneholde kritisk informasjon; de trenger fortsatt å gå gjennom prosessen med å bli sikkerhetskopiert og fortsatt må sørge for at alle ting fungerer fra et helseperspektiv på dem. Men bare det å vite at de eksisterer er like viktig om ikke viktigere.
Mens den andre halvparten av folkene er: "Hei, vi er ikke vi ikke ansvarlige for databasene, og alt som de har lagt på dem, er på pasning fra personen som installerte dem." Men jeg vil si at det generelt er det du sagt, alt ganske mye i dag har en applikasjon knyttet til den som bare bidrar mer til kompleksiteten og forvirringen ved å måtte inventar denne informasjonen.
Dez Blanchfield: Ja, jeg har sett noen, regjeringsnettsteder er sannsynligvis min favoritt, men oftere ser jeg ikke i bedriftsmiljøer, hvor er det, som du sa, at folk glemmer jeg til og med, når de installerer noe som SharePoint eller som selvutveksling, slik at du vet at de kommer med en gratis versjon som nettopp er innebygd fordi de vil, vet du, installere den raskt og ikke bekymre deg for å måtte gå og kjøpe lisenser.
Så blir det stort, og så begynner noen å klage på ytelse, og de er som: "Det er bare den gamle serveren din, lagringsplassen din, nettverket ditt, hva som helst, " og så blir DBA oppringt og de er som "Vel, du ' Vi har nettopp tappet alt i denne gratis versjonen av databasen, og det er ikke det du trenger for å utføre denne store. "
Spesielt når du fikk scenarier som Project Manager og Office kjører hundrevis om ikke tusenvis av prosjekter på tvers av et stort foretak eller et selskap, og de bruker SharePoint med Microsoft Project Server, og de dumper alle PMO-tingene deres i denne databasen. Men i fronten er de like, vel, det er bare et webgrensesnitt. Men det er egentlig databaser og databaser.
Bullett Manale: Ja.
Dez Blanchfield: Så hva er det, et av de første trinnene som folk her antar jeg at det er et par spørsmål som vi kanskje ønsker å få inn fra publikum. Et av de første spørsmålene er hvor folk begynner? Hva er det første naturlige steget for dem å gå, "OK, vi trenger å gjøre den anonyme versjonen av Alkoholikere?"
Vi har flere databaser enn vi vet hva vi skal gjøre med. Hvordan er et naturlig trinnvis utseende av dem å gå, “OK, vi trenger å få tak i denne tingen og begynne å løpe?” Går de bare kald kalkun, eller senere trenger de virkelig å begynne i det små og bare få litt erfaring med å kartlegge miljøet ?
Bullett Manale: Jeg tror vel det sagt at de må kartlegge miljøet. Nå tilbyr Microsoft et gratis verktøy for å gjøre det, Microsoft Assessment Planning Tool, det er et gratis verktøy, men det er statisk. Du gjør oppdagelsen, og det er det. Du får en liste over tingene som er der ute. Vi tok det og sa la oss ta et skritt videre la oss gjøre oppdagelsen, la oss finne det som er der ute og la oss legge det i depotet og la oss gjøre det slik at det er dynamisk og vi kan legge til det, fjerne det.
Men totalt sett er det største første trinnet jeg tror bare for å finne ut det, gjøre oppdagelsen. Enten det betyr å laste ned produktet vårt i prøveperiode, kan du laste ned dette og prøve det i 14 dager, og du kan peke på miljøet ditt og gjøre samlingen.
Hvis du allerede har et regneark med en haug med den informasjonen der inne, og at du er litt sikker på at den informasjonen er riktig, har du også muligheten til å like importen til CSV som regnearket med all den informasjonen og gjøre den delen av det du har allerede. Men når det gjelder å finne ut hva du ikke vet, er den eneste måten å gjøre det på manuelt å gå ut, gjøre det eller ha et verktøy som ser etter den typen ting som denne. Det er avgjørelsen du på et tidspunkt vil måtte ta, er: "Prøver jeg å automatisere oppdagelsen eller i det minste få et godt grunnlag av hva som er der først, og kanskje kanskje bekymre meg for noen av unntakene?" det meste trenger du sannsynligvis et verktøy.
Dez Blanchfield: Så bare raskt. Hvor går folk for å komme i gang med dette? De treffer nettstedet ditt? Hvordan når de ut og kommer raskt i gang med dette?
Bullett Manale : Hvis du går til Idera, IDERA.com, vil du se, og jeg kan faktisk bare virkelig raskt vise det virkelig raskt. Over på Idera nettstedet vil du gå til produkter, gå til varebehandler. Du ser at det er en nedlastingslink her. Du bestemmer bare hvilken bygg du vil installere på en 64 eller 32 bit, og det får deg i gang, og du kan starte oppdagelsen derfra.
Robin Bloor: Fantastisk og flott, flott presentasjon, tusen takk.
Bullett Manale: Takk.
Eric Kavanagh: Vi har et par spørsmål fra publikum, og vi e-post dem til deg fordi vi må vanskelig stoppe oss selv i dag, men Bullett, igjen, god jobb med demoen, god jobb av produsenten vår som fanger at det ikke var ' t viser.
Bullett Manale: Beklager det.
Eric Kavanagh: Nei, dette er gode ting, du gir synlighet i kjernen av virksomheten, ikke sant? Fordi virksomheten kjører data og du gir synlighet helt ned til kjernen. Så ikke flere bølgete ting; nå kan du faktisk peke på ting og få det løst. Så bra for deg.
Bullett Manale: Takk.
Robin Bloor: Men det var flott å se det leve forresten, godt gjort.
Eric Kavanagh: Ja, vi arkiverer denne webcasten for senere visning, og så får vi den forhåpentligvis i løpet av en time eller to. Det første arkivet går opp noen ganger er det litt lenger enn det, men vi vil sørge for å la folk vet. Med det skal vi gi deg fri, folkens. Takk igjen for at du deltok på Briefing Room, vi er faktisk Hot Technologies. Vi henter deg neste gang. Ta vare, farvel.
