Af Techopedia Staff, 26. maj 2016
Takeaway: Værten Eric Kavanagh diskuterer databasestyring og forekomstopdagelse med Robin Bloor, Dez Blanchfield og Bullett Manale i den seneste episode af Hot Technologies.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay damer og herrer. Velkommen tilbage igen. Jeg hedder Eric Kavanagh. Tingene er varme. Tingene varmer op her. Jeg ved ikke, hvad der sker. Åh det er rigtigt, det er tid for Hot Technologies. Ja, ja, jeg hedder endnu en gang Eric Kavanagh. Du kan finde mig på Twitter @eric_kavanagh. Dette er showet, der er designet til at tale om, hvad der er varmt på markedet. Titlen i dag, "Keys to the Kingdom: Managing SQL Server with Dynamic Discovery." Gode ting. Der er din virkelig. Okay, det billede var fra for et par år siden. Jeg vil ikke lyve, jeg ser lidt ældre ud nu, men det er okay.
Så vi taler om, hvordan teknologier og SQL Server er virkelig, virkelig, virkelig, virkelig hot. Vi har en hel masse indhold i dag, så jeg overleverer det med det samme. Stå ved, her går vi. Der er vores højttalere. Og Robin Bloor går først.
Robin Bloor: Ja. Præsentationen kommer til at gå i dybden i databasestyring, så jeg tænkte bare, at jeg ville køre gennem databasestyring eller, du ved, databasens labyrint, for at få folk til dets ånd. Jeg plejede at være en DBA, jeg formoder, at du kunne sige, at jeg plejede at være en databasekonsulent for ca. 20 år siden, og det, der faktisk overrasker mig ved databaser, er, at ikke meget har ændret sig. En masse ting har ændret sig med hensyn til hastighed, med hensyn til mængderne af data og lignende, men meget af det forbliver faktisk meget ligner det, der plejede at ske.
En database er efter min mening en organiseret udvidelig samling af data, der kan optimeres til specifikke arbejdsmængder og levere datastyringsfunktioner. Det kom primært til, fordi hvis du ville administrere data i filer, var det et forfærdeligt vanskeligt job. Og ideen om at sammensætte et stykke software, der ville gøre stort set alt, hvad du havde brug for det, gjorde næsten øjeblikkeligt med det samme, så snart vi havde tilfældig adgang til IBM-mainframes tilbage i 1970'erne.
Den relationelle database blev opfundet i 70'erne og kom til i form af prototyper i 80'erne og slags fik sin trækkraft på markedet fra begyndelsen af 90'erne og fremover. Og relationelle databaser er stadig yderst dominerende i popularitet. Hvis du læser pressen, vil du høre en masse ting, der er sagt om disse - SQL-databaser, og for nylig er der meget frygtelig støj omkring grafdatabaser. Og det er interessant, hvis du vil, men faktisk stadig i de seneste salgstal, har relationelle databaser 95% af markedet. Og Microsoft SQL Server, som vi skal diskutere i en dybde i dag, er den næstmest populære for Oracle.
Det ved relationelle databaser, der gør dem usædvanlige med hensyn til de motorer, de er, er, at de kan arbejde på både OLTP og forespørgsel. Du er nødt til at indstille dem anderledes, hvis du gør det, men de er faktisk i stand til begge typer arbejdsbelastning. Den ene er korte tilfældige transaktioner, og den anden er lange forespørgsler, der spænder over en masse data. Alternativet, NoSQL-databasen og grafdatabasen er hovedsageligt beregnet til analyse, og de er steget ret for nylig. NoSQL kom først, og grafen er begyndt at få en smule trækkraft i nyere tid. NoSQL kan bruges til transaktionsaktiviteter, men grafer bruges næsten aldrig til transaktionsaktiviteter. Årsagen til, at jeg stødte på en stat, som jeg faktisk er mindst ti år gammel, der siger, at de fleste virksomheder har mindst tre, faktisk var tallet 3, 5, forskellige mærker af databaser, hvis man ser på deres opgørelse af software.
Men virkeligheden er, at de fleste virksomheder standardiserer på en bestemt database. Og de fleste virksomheder har standardiseret enten på SQL Server og Oracle som de to mest populære til, hvis du vil, standarddatabaser. Og de bruger kun alternativerne under ekstraordinære omstændigheder, hvor de for eksempel får en softwarepakke, der har brug for en anden database, eller hvis de følger nogle af de store dataanalysemål, der er kommet til.
Vi har også, hvis du vil, indblanding fra Hadoop. Hadoop på en eller anden måde er blevet mere end et filsystem, men endnu ikke en database. Men det har SQL, der sidder over toppen af det. Men beviset der er, at det ikke rigtig erstatter eller hvor som helst i nærheden af at erstatte de relationelle databaser, der tjente verdens hjerter og sind. Og grunden til det er virkelig, at de relationelle databaser tog tyve år, faktisk længere end tyve år, for at blive så gode som de er. Og du bygger ikke bare en forespørgselsmotor eller SQL-motor, der virkelig er performant på meget lidt tid. Det sker bare ikke.
Og derfor er konklusionen af dette lysbillede, at databaser er strategiske, og de udvikler sig, de bliver bedre. Og det er bestemt tilfældet med Oracle og Microsoft SQL Server. Du husker sandsynligvis kun få af jer tilbage til de dage, hvor databaser først opstod, men det gjorde jeg, jeg var da en dreng. Den oprindelige idé var, at der ville være en enkelt database, og det var en konceptuel idé, der absolut aldrig slog rod. Der var et forsøg fra IBM med AS / 400 til faktisk at have et databasebaseret filsystem, men det dominerede heller ikke. Du har tilbage med det faktum, at databaser naturligt fragmenterer. Du har faktisk naturligvis flere tilfælde. Der er problemer med skalerbarhed. Databasen skaleres kun til en bestemt størrelse, ganske vist er størrelsen steget med årene, men de havde grænser.
Og der var problemer med arbejdsmængde, hvor det største problem med arbejdsbyrden var, at OLTP-arbejdsbelastninger og store forespørgsel-arbejdsbelastninger simpelthen ikke er kompatible med hinanden. Og det var umuligt at bygge en motor, der ville gøre det. Hvad vi støder på, hvilket er slags interessant, jeg stødte på et websted for nylig, der havde over tusind forskellige forekomster af Oracle. Jeg kan ikke huske nøjagtigt, hvor mange DBA'er de havde, men hvis du faktisk talte med dem om hvor mange af disse databaser, der faktisk blev overvåget af en DBA, var det noget i retning af ti. De brugte dybest set databasen som et skab og kaste bare data ind i den, fordi du i det mindste havde et skema, og det var mere organiseret, end et filsystem nogensinde ville være, men ingen gjorde noget andet end at give det en standardkonfiguration og indstille det løs.
Jeg er ikke sikker på, om det var en god ide. Det lyder bizart for mig, for at være ærlig, fordi jeg efter min mening, hver gang jeg arbejdede med databaser, brugte databaser, og du var nødt til på en eller anden måde at vide nøjagtigt, hvad der foregik derude. Og meget af systemafhængighed betyder, at visse former for serviceniveau absolut skal overholdes, ellers får du problemer.
Der var for nylig tale, jeg har stødt på forskellige databaser, der hævder at være selvstemt. Dem, der er kolonnebutikker, der er indstillet til forespørgselstrafik, er stort set selvindstilling, fordi der er meget to valg, du skal tage med hensyn til indekserne. Men bortset fra det særlige område skal databaserne indstilles. Og de er nødt til at være indstillet, visse relationelle databaser, hovedsageligt fordi en forfærdelig masse transaktioner involverer sammenføjninger. Samlinger er dyre aktiviteter. Hvis du ikke sætter de rigtige indekser på det rigtige sted, skal du sammen med tage overdrevne mængder tid, når de ikke har brug for det.
Selve indstillingsdatabaserne i øjeblikket, det findes kun i disse områder, hvor arbejdsmængderne er velkendte. Og min erfaring er, at de fleste virksomheder har meget få DBA'er, og det er fordi de er dyre. Og derfor er det bedre, hvis du kan skifte, hvad DBA gør. Dette er en DBA's aktiviteter, som jeg forstår dem. De udfører installation, konfiguration og opgradering af databaser. Opgradering er for øvrig ikke nødvendigvis en triviel aktivitet. Årsagen til, at du opgraderer en database, mener jeg, reglen, som jeg altid har arbejdet med, er ikke at røre ved den, hvis den fungerer, og hvis du vil opgradere en database til en bestemt ny version, gør du det i testtilstand først og derefter opgraderer du alt. Du har stadig altid at gøre med den samme version. Men i virkeligheden er der mange websteder, jeg er stødt på, det er ikke, hvad der sker. Der er, lad os sige, en rimelig grad af entropi. Licensstyring er et problem, afhænger af, hvilken licens du har. ETL og datareplikering.
Et af tricksene med databasen er, hvis du har en forespørgselsbelastning, der skal opdeles, du kan oprette to forekomster og replikere, og det gøres ofte, hvor folk bruger replikaen som en hot backup om nødvendigt. Derefter lagring og kapacitetsplanlægning, det er en del af en DBAs aktivitet, fordi data naturligvis vokser, og du er nødt til at spore det. Og så skal du planlægge forskellige hardwareopgraderinger eller hardwareudvidelser. Der er fejlfinding, som er en smertefuld aktivitet for de fleste DBA'er. Hvor noget går galt, og sikkerhedskopien ikke fungerer nøjagtigt perfekt, og så er de nødt til at rulle ærmerne op og komme ned og prøve at gendanne ting fra logfiler. Det sker måske oftere, end jeg tror, ja, jeg kan huske, at det sker, men jeg har været ude af spillet i mindst ti år, men jeg kan huske, at det sker måde oftere, end du nogensinde ville have forventet. Performance monitoring og tuning er bare slags det bankende hjerte for et DBA-job. Men der er også sikkerhed med hensyn til adgangshåndtering, sikkerhedskopiering og gendannelse, hvilket skaber softwaretestsystemer, der med rimelighed parallelt med et live system vil gøre. Og hele dataets livscyklus ting. Så det er efter min mening DBA's liste over job bortset fra alt andet, som de måtte blive bedt om at gøre. Operationel dynamik. I sidste ende er DBA's hovedansvar for dataintegritet og serviceniveauledelse. Og normalt er de kritiske. Og det er alt, hvad jeg har at sige. Jeg overleverer til Dez.
Dez Blanchfield: Mange tak. Jeg tager os med på en lidt sjov, anekdotisk rejse rundt, hvorfor hele emnet, som i dag handler om, og er mere kritisk end nogensinde. For ikke så længe siden var jeg involveret i et projekt, hvor vi migrerede en statsregeringsplatform, der blev brugt til licensregistrering og køretøjsregistrering og en hel række ting omkring det emne, fra en Fujitsu mainframe platform, der kørte en ting kaldet A + Addition, som er et Solaris-operativsystem, eller med andre ord, Unix, kører Oracle og gør et meget godt stykke arbejde for det. Og synspunktet var, at denne ting blev ældre, og det var på tide at flytte den til noget andet. Vi havde det meget sjovt at køre Unix på mainframe, og det var meget stabilt og meget sikkert og underligt nok SDL-platformen, og det var bare absolut lynet hurtigt. Men visdom var det på tide at gå af hovedrammen og flytte.
Denne betydelige udfordring ved at kortlægge alle systemer og forretningslogik og SQL-miljøet for databaserne nedenunder og se på, hvordan vi skulle arkitekt og konstruere et nyt hjem til det. Og vi endte med at tage det til en af disse ting, som er et par år gammel nu, men en af den øverste ende af Sun-rack-systemet Starfire-servere. Og dette er sandsynligvis noget af det største tin, du kan købe på planeten, som alle lever i en stor kasse og en symmetrisk multiprocesseringsserver. Det var et mellemklasse-system i vores verden. Det kørte Unix, og det kørte Oracle indfødte, og udsigten var: "Hvad kunne muligvis gå galt?" Det viser sig, meget.
For eksempel på det tidspunkt, og vi taler ikke for længe siden, var vi nødt til at gennemgå en meget manuel proces for at finde ud af, hvad der var på mainframe-platformen og bringe det igennem. Især det faktiske databasemiljø og SQL-logikken. Så visningen var, at det skulle være et ret ligetil Oracle-to-Oracle-bevægelse, database-til-database-bevægelse; al forretningslogik ville komme på tværs, det meste af forretningslogikken var skrevet i indlejrede forespørgsler og triggere, og hvor hårdt kunne det være? Men noget, der skulle tage måneder, endte med at det ikke tog et helt år. For bare fysisk og manuelt at gennemgå alle dele af Unix på mainframe-miljøet, opdage, hvor alle databaser var, og hvor mange forekomster der kørte, og hvad der kørte på disse tilfælde, og det var en ikke-triviel øvelse, og vi endte med at gøre det tre gange bare for at sikre os, at vi havde fanget alt. Fordi hver gang vi troede, at vi havde gravet så dybt, som vi havde brug for, under overfladen viste det sig, at der var mere der.
Den anden udfordring, vi havde, var, hvilke tilfælde der kører, og i hvilken tilstand? Er dette et udviklingsmiljø? Er det et testmiljø? Er det en del af integrationsprocessen? Er det systemintegration? Er det UAT, test af brugeraccept? Er det produktion? Er det et DR-miljø? Fordi det store ved mainframes er, at du kan opbygge disse små virtuelle miljøer, som vi alle tager for givet nu og flytte tingene rundt. Og du er nødt til at træne, er denne person, der udfører produktionskvalitet og tester, eller laver de produktionsproduktion, er der faktiske brugere på dette? Husk, at denne ting udfører realtid udstedelse af kørekort og bilregistrering og ting, der virkelig betyder noget for folks liv.
Og det tog lang tid at køre sikkerhedskopier til denne ting, så vi ikke rigtig havde et vindue med vedligeholdelse til at tage tinget offline og se, hvad der skete. Der var ikke noget, der omdirigerede det. Vi havde også udfordringen med ikke bare at finde, hvilke forekomster der kørte, og hvor og hvem til, men så måtte vi finde ud af, hvilke versioner af hvilke forekomster der kørte. Og det er her, jeg næsten mistede mit plot. Da jeg begyndte at indse, at vi havde to eller tre versioner af produktionsmiljøet gennem forskellige testniveauer, og der var meget lidt i vejen for værktøjer og systematiske tilgange til dette. Vi var bogstaveligt talt nødt til at gå i dybden i koden og i det kørende eksempel og i nogle tilfælde tage risikoen for at tage noget offline et lille stykke tid. Vi kom til bunden af det hele, vi kortlagde det, og det var en meget manuel proces som sagt. Og endelig lavede vi hele ETL-skiftet, dumpede det fra et sted og flyttede det til et andet, og i det store og hele fungerede det. Og vi var som, okay det er funktionelt, vi er meget tilfredse med det.
Men så løb vi ind i en række meget alvorlige solide murvægge. Vi fandt især præstationsproblemer. Og den fornuftige tænkning af dagen var, ja, det er gået til en større, bedre, hurtigere, hårdere hardware, der er ingen grund til, at det skulle fungere dårligt i applikationen på databaseniveau, så lad os begynde at se andre steder. Så vi genopbyggede netværket to gange. Hver router, hver switch, hvert kabel, vi gik fra Ethernet til fiber i nogle tilfælde, vi opgraderede software, vi lappet, du får udsigten. Vi genopbyggede i det væsentlige netværket to gange og troede, at det var ydelsesproblemer der. Og det så ud og føltes som om det var. Vi gik gennem forskellige sikkerhedssystemer, forskellige firewalls. Vi lappede operativsystemet. Vi flyttede ting fra det ene datablad til det andet. Og vi brugte en betydelig mængde tid på at se på infrastrukturen.
Og så indså vi, at da vi koblede serverne fra og kørte nogle andre applikationer på det, at netværket kørte helt fint. Så vi begyndte at trække operativsystemet fra hinanden. Samme problem. Men interessant, netværksniveauet og operativsystemniveauet, værktøjerne var der, det var faktisk relativt ligetil for os at benchmark og teste og bevise, at hver af disse brikker fungerede. Men selv da, på Solaris i mellemklassen på SPARC-hardwareplatform, var værktøjerne bare ikke der for os for at begynde at diagnosticere databasemiljøet. Du ved, kortlægger, om vi havde bragt alle tilfælde hen. Og så måtte vi faktisk bygge vores egne værktøjer og skrive nogle og sætte os ned, og hvad enten det var inden for selve databaseværktøjerne på de oprindelige scripting-sprog, eller om det var en række shell-scripts eller i nogle tilfælde en masse C-programmer.
Vi delte endelig ind i nogle meget interessante problemer, hvor logikken under SQL-laget, de faktiske databasemotorer i sig selv, det viste sig, at når noget blev bygget en bestemt måde for noget, der kørte på mainframe-versionen af Oracle, blev migreret til Solaris på SPARC version Oracle det transponerede ikke umiddelbart den samme ydelse. Så dette var en meget smertefuld rejse for os i første omgang, bare ved at gøre det og finde det hele, men nu var vi nødt til at diagnosticere det på det nye produktionssystem, og igen sprængte denne ting en måneds værdi af migration til næsten et år. Og det kom ganske enkelt ned på det faktum, at vi ikke havde værktøjerne rundt. Løb rundt og gør ting som at prøve at kortlægge metadata.
På et tidspunkt besluttede vi næsten, at vi havde brug for et Ouija-bord, fordi det ville være lettere på den måde bare tilfældigt at pege og pirke. Enkle ting som at finde ud af, hvem der havde adgang til de gamle systemer, og hvorfor de havde denne adgang. Og hvem havde brug for adgangen til den nye og bekræftet, få nogen til at logge af og bekræfte det og kortlægge det. Selv noget så simpelt som størrelsen på databasen var ikke ensartet på tværs af de to platforme. Vi var nødt til at bygge et værktøj til at gøre det og foretage en sammenligning mellem hvor stor databasen er i tonnage, i rå megabyte eller terabyte på System A versus System B. Og dykke mere detaljeret omkring ydeevne og det performante miljø. Igen, måtte bygge nye værktøjer. Der var bare ikke noget off-hylde for os.
Og du får hele denne meddelelse ud af dette, da vi kom til slutningen af at få tingene til at køre, og vi fik det stabilt, hvert eneste stykke af det var en meget manuel proces, den eneste måde, vi kunne automatisere noget på, var, hvis vi bygger en nyt værktøj eller nyt script. Og hvis vi havde de værktøjer, der er tilgængelige i dag, ville livet have været så meget lettere og så meget bedre. Og vi ville have sparet millioner på dette projekt. Men jeg tror, at det, vi skal tale om i dag, er, at værktøjerne er tilgængelige nu, og at de gør livet så meget lettere. Der er stadig mange faldgruber. Opdagelse af de databaser, der er derude, og hvilke tilfælde, der kører hvad. Hvilken tilstand de er i. Hvor mange kører? Hvorfor de kører. Uanset om de kører godt. Sikkerhedskopieres de?
Dette er alle ting, som vi på mange måder kan tage for givet nu med de rigtige værktøjer. Men der var en periode i denne særlige anekdote, som jeg sagde, hvor det var noget, som mange af os mistede meget hår om, vi sandsynligvis tog femten år af vores liv, og beklagede det faktum, at værktøjerne ikke var der nu . Og jeg ser frem til at høre meget mere om det fra vores gæst i dag, Bullett. Så med det, Bullett, vil jeg videregive til dig, og jeg ser frem til at høre, hvordan du har løst dette problem.
Bullett Manale: Okay. Lyder godt. Eric, lad mig overtage her med diasene og tale lidt om, virkelig hurtigt, Idera, virksomheden, inden vi kommer ind i selve produktet. Ligesom en FYI er dette en slags portefølje af forskellige produkter, som vi har til rådighed.
Eric Kavanagh: Din lyd er lidt varm, så hvis du bruger et headset, skal du bare trække det lidt op.
Bullett Manale: Intet problem. Er det bedre?
Eric Kavanagh: Det er meget bedre. Tage det væk.
Bullett Manale: Okay. Så i dag vil vi fokusere på Inventory Manager, som åbenlyst er tilpasset mange af disse emner, som vi diskuterer. Jeg vil bare give dig en lille smule forståelse af, hvordan dette produkt fik det, hvor det er. Vi begyndte med at se dagligt på vores produktlinje, vi har et værktøj til overvågning af præstationer kaldet Diagnostic Manager. Vi har et Compliance Manager-værktøj. Så mange forskellige værktøjer omkring SQL Server og uundgåeligt stiller vi altid spørgsmålet til licensformål: "Hvad er antallet af tilfælde, som du i øjeblikket administrerer i din organisation?" Og det interessante var, at vi aldrig var i stand til virkelig at få et fast svar på det. Det gjorde ikke noget, hvem du talte med. Det var altid slags, "Nå, vi tror, det er omkring dette nummer." Disse slags ting kom altid ind, og så skulle vi gennemgå denne proces med at finde ud af, hvad det var, de havde, som de ønskede at licensere med hensyn til de tilfælde, vi administrerer.
Vi regnede tydeligvis virkelig hurtigt ud, at der ser ud til at være nogle smerter, der er forbundet med det med mange af DBA'erne. Som en DBA er det naturligvis en af de ting, de er ansvarlige for, at vide det, fordi en af de ting, de skal gøre, er at bekymre sig om deres licensaftaler, i vores tilfælde med Microsoft og SQL Server. Det er klart, at de har en masse andre forskellige områder, som de er ansvarlige for, men det er en af dem, der er slags en stor billetpost i form af som DBA, hvad dit generelle ansvar er. Med det, hvad vi slags kom til konklusionen om, er vi brug for et værktøj, der gør det let for en DBA at være i stand til virkelig at forstå dette nummer. Fordi du har SQL-spredning, hvis du vil kalde det sådan, og det sker af en række forskellige årsager. Der er måske ikke så meget kontrol omkring, hvem der installerer softwaren og den slags ting.
Og det værste, der kan ske, er, at nogen får fat i en kopi af SQL Server, installerer den, begynder at arbejde med den uden nogen viden til nogle af de andre organisationer eller afdelinger i virksomheden, og så er den næste ting, du ved, måske dataene sikkerhedskopieres ikke, og den slags ting der kan ske. Hvor du nu har et andet problem, hvor du har situationer, hvor du faktisk mister kritiske data, fordi du ikke ved, at forekomsten endda findes i første omgang.
En af de ting, vi var nødt til at gøre, var at sige, lad os finde ud af opdagelsesstykket. Og så oven på det, være i stand til at organisere og styre de oplysninger, som vi indsamler på en logisk måde, der giver mening ud fra, hvad virksomheden laver. Og så åbenbart derfra være i stand til at tage beslutninger omkring denne information og være i stand til at gøre den slags ting. Det er slags, hvor værktøjet startede, og hvor det kom fra. Jeg kan fortælle jer, at når vi taler med DBA'er regelmæssigt, er det, vi virkelig har, problemet med ikke at vide, hvor mange tilfælde de har.
Og det er sjovt, fordi udtrykket, du kan ikke styre det, du ikke kan måle, altid kom med præstationsværktøjer, som vi har, ligesom SQL Diagnostic Manager, men du kan virkelig ikke styre noget, hvis du ikke ved det “Det”, selv der i første omgang. Så det er også en slags stor del af dette værktøj, bare ved at være i stand til at vide, at det er der.
Nu på den note, at tale med nogle af de større organisationer eller firmabutikker med SQL Server, var det interessante, som vi fandt med mange fyre, som vi talte med, at de faktisk havde sat en tid op i løbet af deres år, hvor de gik faktisk fysisk fra et sted til et andet for at prøve at bestemme, hvordan antallet ser ud. Du kan forestille dig som en DBA, at du får en ganske god penge til at fysisk gå fra en maskine til en anden i nogle tilfælde, hvilket overraskende nok var hvad vi ville høre fra nogle ret store virksomheder, som jeg ikke vil navngive. Men bare et slags interessant punkt, som to uger af et år måske bruges på at udføre denne slags øvelser bare for at finde ud af, om deres licensoptællinger er korrekte.
Dette er alt sammen relateret til dette værktøj, og hvordan det hjælper, men den måde, vi adresserede det på, var gennem evnen til at opdage baseret på en række egenskaber ved SQL Server. Og så er det første spørgsmål, hvad peger du på, eller hvad prøver du først at se på? Den måde, vi gjorde det på, var at sige, lad os gøre det efter IP-rækkevidde, eller vi kan gøre det ved medlemskab af selve domænet med hensyn til de computere, der er medlemmer af domænet. Det er sådan, hvordan vi adresserede den del, bare for at kunne sige, at dette er det område, vi vil fokusere på med hensyn til opdagelse.
Og så er den anden del af dette baseret på disse egenskaber, porte og andre ting, WMI-registernøgler og den slags ting, vi kan samle og konstatere, at SQL sandsynligvis kører og installeres i den instans eller det pågældende miljø. Det er tydeligvis en meget bedre metode end sneaker-metoden eller sneaker express-metoden. Nu er det fede, at alle de oplysninger, vi samler om forekomsten, opbevares i et oplagringssted, og de kan ændre sig, efterhånden som miljøet ændres. Det handler ikke kun om, "Hej, der er et eksempel, her er en liste, vi har fundet, " men det er som DBA, eller den person, der administrerer forekomsterne, der er i stand til at bestemme, om de vil gøre den del af opgørelsen, og derefter hvornår det er ikke en del af opgørelsen, at være i stand til at nedlægge den forekomst. Og så har de livscyklussen for hele processen i SQL Server-instansen, der virkelig kan forstås i værktøjet.
Når vi har opdaget forekomsterne, hvad skal vi gøre efter det? Den anden ting er meget af informationen om forekomsten, jeg vil ikke være nødt til at gå manuelt til at hente den og lægge den i et regneark eller den slags ting. Og det er en anden ting, der var lidt interessant ved at tale med DBA om lagerprocessen og licensen, er at du ville blive overrasket over hvor mange DBA'er jeg talte med, når du spørger dem, "Hvordan opretholder du dine varebeholdninger?" Og vi taler med DBA'er, som er den virkelig ironiske del af det, at de holder det og sporer det i et statisk regneark for alle ting. Som jeg sagde, det er meget ironisk, når du tænker på det i et øjeblik. Men det var i mange tilfælde, og det er stadig tilfældet med mange organisationer, hvordan de styrer det. Hvordan de holder det. Det er en masterkopi af et Excel-regneark, der flyder rundt og skal opdateres regelmæssigt.
Det er de ting, der var en udfordring, og så ved at registrere denne instans og gøre det til en del af opgørelsen, kan du gøre det og hente oplysningerne. Du kan få det til at automatisere, om det bliver en del af opgørelsen, versionen, udgaven, de andre ting, du kan gøre med det, er du manuelt kan tilføje den liste eller Excel-regneark, du har. Du kan importere det til dette værktøj kaldet SQL Inventory Manager. Hvis du allerede har et udgangspunkt for forekomster, som du føler, at du er temmelig sikker på, kan du importere disse forekomster i og derefter udgøre den del af din administrerede beholdning i produktet. Når vi først har fået forekomsten, og når vi først ved, at den er der, bliver den, okay, vi har en masse information, som vi kan udnytte ved at vide, at denne instans er der, ved at gå ud og indsamle disse oplysninger.
Og meget af informationen bliver brug for mere end kun licensformål. Meget af det kan bruges til åbenbart bare at vide, hvor tingene er, for at kunne søge gennem disse oplysninger, efter at de er opnået. Men de vigtigste ting er serveren, selve hardwaren. At være i stand til at forstå, hvilken slags maskine det er, måske modellen eller producenten, hukommelse, mængden af hukommelse, hvad enten det er en fysisk eller virtuel maskine og især antallet af fysiske stikkontakter eller kerner og CPU'er og de slags ting.
Med hensyn til antallet af kerner, især med SQL Server, at det at kende den måde, de laver deres licens på, er per-core beregninger nu i de nyere versioner af SQL, der bliver en virkelig vigtig del af det, og det er ikke noget, du har at gå ud og faktisk grave efter. Når forekomsten er identificeret, kan vi give disse oplysninger og få dem ud og lade dig se dem og forstå dem og naturligvis kunne drage fordel af dem.
Det næste lag nede er i det tilfælde, som du tydeligvis har meget forskellige af SQL Server-forekomsten, hvad enten det er standard eller virksomhed eller endda ekspress for den sags skyld eller den gratis version af SQL Server. At være i stand til også at forstå, hvilke applikationer der er knyttet til denne instans, og dette kan gøres automatisk. At være i stand til at forstå konfigurationsindstillingerne og den slags ting samt andre oplysninger, der er relateret til forekomsten af selve SQL Server.
Derefter kommer du ned til den faktiske database og ser konfigurationsindstillingerne, mængden af plads bundet til disse data, hvor de er placeret, alle disse ting bliver automatisk udfyldt, og så det er en enorm tidsbesparelse. Og igen, fordi det dynamisk går ud og til daglig at identificere nye tilfælde, er det en levende ting, du har med hensyn til din beholdning. Det er slags formålet med produktet er at gøre det på den måde, er at gøre det til noget, der dynamisk ændrer sig.
Når alle disse oplysninger bliver tilgængelige for os, og vi kan trække alle disse data ind, er det virkelig fornuftigt at begynde at oprette dine egne metadata, der er knyttet til disse tilfælde, og at metadata kan oprettes på en sådan måde tilpasser sig den måde, du gør forretning på.
Så hvis du har dine forekomster grupperet efter geografisk placering, eller af applikationsejere eller af DBA-ejere eller hvad, kan det være i form af, hvordan du vil gruppere disse forekomster, hvordan du logisk vil give mening om disse tilfælde, så er der venlig af to områder inden i værktøjet, der giver dig denne mulighed.
Den første er muligheden for at oprette et eksempel på et eksempel eller et tag. Hvilket væsentligt er at oprette en tilknytning til enten serveren, instansen eller databasen, så du kan oprette visninger og besvare spørgsmål, der kan komme op på en daglig basis, der virkelig hjælper dig med at få et greb om det, du har, hvad du administrerer, og hvordan du vil komme videre med disse oplysninger.
Den anden ting, vi har, er noget, der hedder lagerfelter eller brugerdefinerede lagerfelter, og disse er mere specifikke til slags sprit af information, som du kan bore ind i, f.eks. Det databaselag, jeg måske beslutter at tilføje en rulleliste, der har alle DBA'er og jeg kan sætte, hvem der er ansvarlig for denne database, afhængigt af den type situation eller hvad der er, uanset hvilken database det er med den, der er ansvarlig for det, være i stand til at vælge det, så jeg ved, at det er dem, der er ansvarlige og meget let bare ved at grave i lageret.
Så disse informationsstykker bliver meget værdifulde, især hvis du har et stort miljø, fordi det bare hjælper dig med at give mening om disse oplysninger og vide, hvad du har, og hvordan du gør det.
Så lad mig gå videre og skifte til det næste lysbillede her. Det, jeg viser dig nu, er, at alle disse oplysninger, vi indsamler, alle disse oplysninger og data, som vi indsamler og anvender metadata på, giver dig muligheden for at derefter tage en meget lettere og hurtigere beslutning, når det kommer til skru op for dine licenser hos Microsoft i virksomhedsvolumenlicenser eller softwareforsikring hos Microsoft.
Det gør det virkelig nemt for dig at gøre dette snarere end at skulle være nødt til at gå og lave en masse manuel indsamling af data, en masse manuel indsamling af disse oplysninger, som virkelig bare samlet set gør det meget bedre af en proces. Så det er slags et af produktets mandater, engang for at gøre det lettere for DBA'erne at træffe disse beslutninger omkring licens.
Nu er den anden ting, vi som snak med DBA'er, opdaget og lært virkelig hurtigt, det - og det er slags at gå tilbage til det, der blev diskuteret tidligere - du har måske 300 tilfælde i dit miljø af SQL Server, men der er virkelig kun måske en undergruppe af dem, der virkelig overvåges og styres fra en traditionel værktøj til overvågning af ydeevne.
Så hvis du går, og du faktisk sidder ned med DBA, og du siger, ”Se, vi ved, at du har disse 20 tilfælde eller 10 tilfælde af de 300, der overvåges med dette værktøj, der er designet til at overvåge det og overholde dine SOAs og få advarsler og alle disse slags gode ting, ”hvad vi også fandt er, at hvis du spurgte, ” Hvad skal du så med disse andre 280 tilfælde, du har? Er det ligeglad med dem? ”Og det gør de, de bryder sig om dem, men de vil bare ikke nødvendigvis foretage en investering for at overvåge dem på det dybdeniveau, der kan gøres med disse tilfælde versus disse 10 eller 20, virkelig kritiske produktforekomster.
Så den anden del af ligningen med dette værktøj er, at det også hjælper med at være i stand til at sikre dig, at du på et basisniveau er dækket med hensyn til instansens sundhed. Nu vil det ikke fortælle dig, om du har en dødvande, eller hvem offeret for dødvandet er. Det er ikke at komme til det niveau af selve sessionerne og detaljerne i forespørgslerne. Men på samme tid vil det stadig fortælle dig, hej, serveren er nede, eller hej lydstyrken udfylder, eller du er nødt til at lave sikkerhedskopier af databasen, det er en slags vigtig del af at være en DBA.
Så den slags ting er bestemt stadig vigtig, og så med dette værktøj gjorde det det til en måde for dig at få en alt for dine virkelig kritiske tilfælde, der har en masse, meget værd at være bundet til dem, hvis de går nede skal du vide det med det samme. De kan have det højere niveau af overvågning og være i stand til at udføre den slags ting, mens det med dette vil være i stand til at hente eventuelle nye tilfælde, der føjes til miljøet, og sørge for, at de er redegjort for og også lave at de grundlæggende niveauer af sundhedskontroller dannes.
Så det er lidt i et nøddeskal, hvad Inventory SQL Import Manager handler om. Nu skal jeg vise dig en demonstration af det. Før vi gør det, bare hurtigt viser jeg dig en slags, dette er arkitekturdia her og bare for at vise dette, forekomsterne af SQL, som vi administrerer, vi kan opdage alt fra SQL 2000 helt op til det nye versioner af SQL.
Så vi kan gøre det uden nogensinde at skulle indsætte agenter til selve instanserne. Vi gør det gennem en indsamlingstjeneste, og det vil gå ud og indsamle disse oplysninger og lægge dem i et arkiv og derefter fra en Tomcat-webservices front-end-konsol, hvor vi derefter kan interagere med disse data og se dem. Så det er temmelig ligetil arkitektur.
Jeg går videre og skifter over og faktisk bringer os ind i selve produktet, så du kan få en fornemmelse af det, en forståelse af, hvordan det fungerer. Så den bedste måde at gøre dette på er at første slags introducere dig til selve grænsefladen på dette er en slags instrumentbræt, som vi ser på her.
Jeg kan se antallet af tilfælde lige nu, som jeg har under ledelse, ikke er så mange. Men jeg har heller ikke et helt datacenter i min baglomme. Så jeg har cirka seks tilfælde, som vi ser her. Når det er sagt, er jeg, hvad jeg skal gøre, er at gå gennem opdagelsesprocessen og vise, hvordan det ville fungere.
Nu er den første ting, du ville gøre, i administrationsafsnittet, du kan specificere, hvordan du vil finde dine forekomster. Du vil være i stand til at placere disse oplysninger her og endnu en gang, der kan gøres gennem en række IP-adresser. Du kan pege på et domæne eller et underdomæne og kun være i stand til på de maskiner, der er medlemmer af dette domæne, at være i stand til at udføre de kontroller, du ville være i stand til at vælge et antal forskellige slags egenskaber for, når SQL kører for at se efter.
Når du først har gjort det, og du kan få det automatiseret til at køre dagligt for at samle disse data. Du vil også være i stand til at gøre det på ad hoc-basis om nødvendigt. Men når du først har startet det, er denne proces med opdagelse, hvad du vil begynde at se, når du går over til oversigten over tilfælde her. Du har en fane Opdag, og fanen Opdag viser os de tilfælde, der for nylig er blevet opdaget. Så i vores tilfælde har vi et nummer her. Hvad jeg vil gå foran og gøre er at gå foran og tilføje den, som vi vil bruge som eksempel. Så dette er et Chicago-eksempel i dette tilfælde, ikke? Jeg vil gå videre og tilføje denne instans til min beholdning.
Okay, og det kommer til at lede mig gennem et par ting her. Jeg vil bare gå videre, og du kan se, at vi kan indstille legitimationsoplysninger. Mine legitimationsoplysninger skulle være gode der. Jeg vil gå videre, og du vil bemærke, at jeg kan tildele ejerskab til dette, hvis jeg vil. Jeg kan også angive en placering. Nu kan selve lokationen også tilføjes, og det vil huske, at næste gang, åbenbart.
Endnu en gang kan jeg også knytte tags til dette med hensyn til metadataene, og hvordan vi ønsker at placere disse forekomster af SQL, især denne, i hvilke spande vi vil lægge det i. Så vi har nogle aktuelle tags, populære tags, så vi kan se på en masse forskellige tags, som jeg måske allerede har inkluderet. Jeg vil bare vælge nogle af disse tilfældigt, og vi kan anvende det.
Så nu når jeg går videre og tilføjer dette til opgørelsen. Nu, hvor det er tilføjet, vil vi nu se det vises under denne administrerede visning, og så kan du se det nævnt her. Så du ved, at det er det første skridt, og hvad jeg lige viste dig, var den måde, du hovedsageligt ville tilføje de tilfælde, når du går igennem på den daglige basis. I nogle tilfælde kan du sige, at du ved, hvad hvis det er en virksomhedsudgave af SQL-server, jeg automatisk vil tilføje det til min beholdning? Jeg behøver ikke manuelt gå og vælge at gøre det.
Jocelyn: Jeg vil afbryde dig virkelig hurtigt. Vi kan ikke se din demo.
Bullett Manale: Du er ikke?
Jocelyn: Nej.
Bullett Manale: Det er ikke godt, lad os se.
Eric Kavanagh: Hvis du går til øverste venstre hjørne, skal du klikke på start, klikke på det.
Bullett Manale: Ah, okay.
Eric Kavanagh: Og del nu skærmen.
Bullett Manale: Undskyld det. Jep.
Eric Kavanagh: Det er okay. God fangst der, producent Jocelyn.
Bullett Manale: Okay, er det bedre? Ser du det nu?
Robin Bloor: Ja.
Bullett Manale: Okay, så lad os bare køre dig igennem, hvor vi var virkelige hurtigt. Vi har fået de opdagede tilfælde, som vi har haft tidligere. Jeg har lige tilføjet Chicago-eksemplet, og det, du ser nu, er, at det nu er opført her. Bemærk, at det allerede har trukket en masse yderligere oplysninger. Hvis jeg klikker på selve forekomsten, vil du begynde at se alle slags oplysninger, vi allerede har samlet om den forekomst. Her er en oversigt over alle de databaser, der er der. Vi kan se en opdeling af databaserne efter størrelse og aktivitet, når det gælder hvilke, der har mest af en størrelse og aktivitet.
Igen kan vi også fortælle dig lige fra flagermus, hvilke applikationer, vi ser, der kører på denne instans baseret på den arbejdsbyrde, som vi ser, der kører på instansen. Så det er lidt rart at kunne gøre det automatisk. Jeg behøver ikke at gå ind og binde ansøgningen til forekomsten. Baseret på hvad vi ser, kan vi udfylde det. Hvis du nu vil tilføje et program manuelt, kan du absolut gøre det. Men det er bare en dejlig måde at være i stand til at vise foreningens tilknytning til databasen eller, undskyld, applikationen.
Du vil også bemærke, at på højre side af skærmen har vi en øjeblikkelig oversigt og nedenunder, at vi har en serveroversigt. Så vi taler om ved de vigtigste oplysninger om eksemplerne her, kender versionen og ikke bare, du ved, SQL Server 2012 men det faktiske versionnummer, der inkluderer og fortæller os, hvilke hotfixes der er knyttet til den, hvilke servicepakker er bundet til det, kan det være meget vigtigt at vide. Naturligvis er hukommelseskravet vigtigt. Alt lignende, uanset om det er samlet, alle disse oplysninger, behøver jeg ikke at indsætte dem - den er allerede samlet og samlet, og når vi først identificerer, at det er et opdaget eksempel, vil det være en del af vores lager.
Den anden ting, du vil se her - og det vil vise dig - er under denne forekomstvisning. Vi har disse attributter, som jeg har talt om tidligere, de tilpassede attributter, der kan tilføjes. Så vi kan tilføje åbne slags tekstfeltfelter, vi kan gøre ja / nej med hensyn til, du ved, en milliard slags valg. Vi kan endda lave rullelister. Du kan gøre det ved forekomsten af databasen eller på serverniveau.
Så hvis vi ruller ned lidt længere, kan vi se alle de relaterede oplysninger til selve serveren. Så du ved, at alle disse slags ting er åbenlyst virkelig, virkelig nyttigt, fordi det hele er samlet og samlet, og det er der for os snart vi tager den beslutning om at gøre det til en del af vores lager. Her kan vi vise nogle af forskellene med hensyn til CPU'er, antallet af logiske kontra fysiske, hvor meget hukommelse. Så du får virkelig et rigtig godt informationsmateriale uden at skulle arbejde meget.
Nu den anden del af dette, er som sagt, at vi indsamler disse data på serverniveauet. Hvis vi endda går ned til databasen, kan vi også se, at en masse af disse ting er fordelt for os. Så hvis jeg går til mit overholdelseslager, i dette tilfælde kunne jeg sige, vel, du ved, at dette har at gøre med en, dette er en overholdelsesdatabase, hvor niveauet for overholdelse eller lovkrav er det knyttet til, og det kan være, lad os sige, SOX-overholdelse eller PCI-overholdelse. Så jeg kan vælge, hvilke databaser der har, hvilken overholdelse der er knyttet til dem, som jeg skal udfylde, eller sørge for, at jeg opretholder hvad angår dette lovkrav.
Så denne type ting har vist sig at være meget nyttigt for DBA'er, fordi der er et sted, de kan centralt gå for at holde alle disse tilknyttede metadata i deres miljø let, og de kan få det til, som sagt, at overholde deres forretning, som de har ' gør det, som den måde, de gør forretninger på. Så hvis vi ser på alle de ting, indtil videre, hvad vi har set, har du tydeligvis en temmelig god oversigt over forekomsten, hvis jeg driller ind i det.
Jeg kan også søge så jeg sagde, lad os kigge efter den overholdelsesdatabase på tværs af min beholdning. Så hvad du vil se her er, at jeg kan søge efter disse ting og være i stand til at identificere dem. Jeg siger det - jeg er ikke sikker på hvad, min go-knap fungerer ikke der. Okay. Lad os se, lad os prøve det igen. Sådan der. Så vi vil så være i stand til at se en oversigt over, hvor vi ser noget med vores overholdelse, og jeg kan bore ned i det og se det også ud fra det synspunkt. Så du har en rigtig hurtig og nem måde at slags grave ind i disse data.
Som vi nævnte før, har du mange forskellige måder at oprette metadata på for eksempel serveren og databasen. Den anden del af det er at være i stand til at drage fordel af det på den måde, du har grupperet det, og på den måde, du har tilknyttet det. Vi går til opdagelsesrejseren, vi kan gøre netop det. Vi kan sige, at jeg vil foretage en databaseoptælling efter placeringer. Så antallet af databaser på hvert sted i miljøerne, som jeg understøtter. Eller måske er det baseret på ejeren, der ejer de forekomster, som jeg har derude med hensyn til måske forekomst. Så vi kan se det. Så du får en rigtig god, nem måde at slags male disse billeder til dig baseret på det spørgsmål, det er, som du prøver at svare på det tidspunkt.
Så hvad du har den slags information skabte den måde, du ville have, vi kan eksportere den ud til PDF eller forskellige formater for at kunne udnytte den og sende til vores kolleger eller gøre hvad vi har brug for der. Så du ved, at du ville være i stand til at gøre den slags ting. Lad os gå tilbage til - mistede jeg det? Sådan der. Okay, så forhåbentlig er det fornuftigt med hensyn til det, jeg har talt om indtil videre. Nu hvor de data, vi har indsamlet, er alt dette naturligvis meget vigtigt af flere årsager - licens og hvad ikke.
Den sidste slags ting bare at nævne er, at vi går over til denne administrationsafdeling her. Det er her du også kan konfigurere din e-mail og din alarmering og være i stand til at sikre dig, at du også kan indstille disse ting for de ting, du virkelig vil vide om. Så vi kan indstille e-mail-advarsler, vi kan indstille muligheden for at tænde for visse ting og slukke for visse ting og derefter være i stand til derefter at bestemme, hvem der vil modtage disse e-mails, og abonnere på de alarmer, vi kan knytte sammen, hvem vi ønsker at være, hvem vil gerne vide om den slags ting.
Men som jeg sagde tidligere, dette er en rigtig dejlig måde at gøre, i det mindste have generel ro i sindet ved at vide for hele din virksomheds SQL-forekomster - hvad det er, du har, og også sørge for, at det kører optimalt, selvom du ikke gør det ' t, har ikke taget beslutningen om at foretage en investering til et kraftigt ramt værktøj til overvågning af ydeevne til at styre det tilfælde. Dette vil dække dig, fordi det er en meget overkommelig måde at gå ud på, og i mange tilfælde være i stand til at udføre disse varebeholdninger og være i stand til at udføre en slags en meget bred slags generel overvågningsniveau for at sikre dig, at du fik den ro i sindet og ved hvad der foregår.
Så forhåbentlig giver det mening i den måde, vi har beskrevet det og viste det for dig. Jeg gætte ud fra det synspunkt, at jeg kan gå foran og videregive det, og vi kan tale lidt mere.
Eric Kavanagh: Det lyder godt. Så Robin? Dez? Nogen spørgsmål?
Robin Bloor: Jeg har spørgsmål. Det er meget interessant at faktisk, jeg mener, at jeg bare ville kommentere, at stort set overalt jeg har været, ikke kun blandt DBA'erne, men blandt netværkets fyre, blandt de opbevarings fyre, blandt de virtuelle maskinstyrings fyre, de ' re alle arbejder off regneark.
Eric Kavanagh: Det er rigtigt.
Dez Blanchfield: Du ved det, det er, du ved, at det er okay, indtil tallene begynder at bevæge sig. Når numrene begynder at bevæge sig, ved du, at de kommer i problemer. Så spørgsmålet nu er jeg lidt interesseret i, og jeg ved, det vil være svært for dig at besvare, men hvad, hvis du går ind på et sted, hvor de ikke har noget lignende derinde til at arbejde med regneark, så lad os antage DBA'erne er meget smarte fyre, og så videre og så videre, hvilken slags ROI tror du, du ville få ved at implementere noget som dette? Har du tal for det på eller nogen retningslinjer for det?
Bullett Manale: Det er svært at sige, hvad ROI er, fordi miljøet bliver lidt anderledes. Det er klart, at jo større virksomheden er, jo større er miljøet, naturligvis desto mere vil ROI sandsynligvis være, hvis de bruger, du ved, manuelle metoder nu.
Jeg ved, at jeg har talt med en række - når jeg siger store organisationer i de tusinder og tusinder af ansatte og også sandsynligvis de tusinder af tilfælde - hvor jeg har folk, hvor jeg viser det for dem, og de siger, at dette vil tage to uger af min tid tilbage. Det har jeg sagt til mig mere end én gang. Så det er svært at sige, hvad angår det faktiske dollarbeløb fra et køb, men det er betydeligt, når du har miljøerne.
Som jeg sagde, det er temmelig konsistent, det er de mennesker, jeg, de fleste af de mennesker, jeg snakker med, opbevarer dette i et regneark. Så det er bare det er en meget, meget subjektiv ting, fordi ethvert miljø, det er lidt anderledes med hensyn til, hvordan de udfører deres licens, og hvordan de gør deres licens hos Microsoft, er en anden del af det, der er en faktor. Men hvis de er nødt til at gøre sande ups hvert år eller hvert tredje år, tror jeg, at tre år maksimalt for Microsoft, at de vil, vil de have, at du skal indtaste mindst hvert tredje år.
Så ved du, det er betydeligt, og det, du ved, det er bare noget, der gør meget lettere. Fordi det er en dynamisk ting, der altid ændrer sig, giver den også lidt mere gyldighed med hensyn til hvad det er, du ser på vers, og vi har ikke rigtig opdateret regnearket på seks måneder eller et år. Så hvor ofte opdaterer du regnearket er et andet spørgsmål til slags forståelse for, at svaret på ROI.
Dez Blanchfield: Ja, jeg mener, SQL-licens, licensering af dette er bare et jævligt mareridt, men det er især et mareridt, fordi licensen ikke er den samme mellem Microsoft og Oracle og alle andre der er derude, der gør database ting. Hvis du faktisk holder ting i regneark, der har tendens til at være, hvad der faktisk sker, ved du, at licenstid kommer rundt, før du faktisk indser det, og du har faktisk ikke dataene, hvis du ved, hvad jeg mener, for let at komme til disse oplysninger.
I det mindste, som du påpeger, er det dynamisk, og jeg har ingen idé personlig, fordi jeg faktisk aldrig har været nødt til at forhandle med Microsoft, så jeg har ingen idé, men formodentlig er der databaser, som folk ganske ofte tager ned testdataene, tester miljøer, og jeg vil gætte, at det er en torn i din side, hvis du laver licens. Er det dig-?
Bullett Manale: Ja, ja. Det er tilfældet, fordi mange gange det er glemt, og så begynder vi at finde ud af, okay, okay okay, vi har en kernelicens, som vi er nødt til at finde ud af antallet af kerner i hvert af disse tilfælde, og jeg don ved ikke, hvad angår standarderne for, hvad du køber hardware klogt, kan du lige så godt købe temmelig god hardware, så hvis du ikke bruger den hardware, som den skal bruges, betaler du for meget, fordi du betaler for kernepriser, når disse kerner ikke udnyttes, så det bliver et problem.
Så hver version af SQL har en anden måde, hvorpå licens anvendes, hvilket endda gør det lidt forvirrende. Så du har nogle udfordringer omkring det, og så det er en stor del af, hvorfor disse oplysninger er meget nyttige, fordi vi kan fortælle dig, hvilken version det er, vi kan fortælle dig åbenlyst antallet af kerner, du har, hvis det er ældre versioner af SQL det var prissætning pr. socket, vi kan stadig tydeligt vise det også. Så det bare, det gør det meget enklere for en rutine, som du er nødt til at gennemgå, når det kommer tid til at indse det.
Dez Blanchfield: En ting der kommer til at tænke for mig, åh ked af det -
Robin Bloor: Det er okay, du går i Dez, jeg ville stille et muligvis irrelevant spørgsmål.
Dez Blanchfield: Bare noget virkelig hurtigt, mens du er i det emne, du er i nu - vi ser meget mere vedtagelse af skymiljøer, og hvis vi kører dette i vores eget vores datacenter, i vores eget miljø, de kravler rundt og finder, at opdage ting er relativt ligetil.
Hvordan skal vi, hvordan håndterer vi scenariet, hvor vi måske har tre datasæt, to skyer, og synligheden på tværs af disse miljøer er firewalled, og der er ofte et datasæt i slutningen af et rør eller en VPN. Er der væk at opdage fra frontend, eller er vi nødt til, for at starte åbning af havne, så vi kan scanne over bestemte miljøer mellem en slags sky og fra lokaler, hvor denne platform kører?
Bullett Manale: Ja, det ville der være, ville der være en vis overvejelse med hensyn til havne. Så det er, desværre skulle jeg ønske, at jeg kunne sige, at det vil bryde igennem alle disse miljøer, men der er nogle forskellige muligheder, du kan gøre med dette. Naturligvis, hvis du laver noget i retning af Amazon EC2, er alt hvad du har brug for virkelig adgangen til det miljø gennem din forbindelse, under forudsætning af at dine porte er åbne og derefter er i stand til at specificere dine IP-adresser eller dit domæne, der er knyttet til det, og det kan starte indsamlingen og start opdagelsen.
Så det er, i de typer miljøer er det virkelig ikke et problem; det er de mere specifikke typer miljøer som RDS, og hvor du lige får selve databasen, hvor det vil være lidt mere udfordrende at se og opdage den type information.
Dez Blanchfield: Så efter at der var der, er der databaser og databaser. Så for eksempel de gode gamle dage med bare at have en meget, en meget stor databasemotor som den anekdote, som jeg delte foran, hvor det bare er en massiv platform, og alt hvad det gør er at levere database. I disse dage er databaser indlejret i alt, faktisk er der som to eller tre af dem, der bare kører i min telefon bag apps.
Hvilke slags udfordringer ser du med scenarier, hvor du har miljøer, der kommer fra Lotus Notes, med apps bag dem, SharePoint med databasen på forskellige internet osv.? Alt i alt drives af databasen i bagenden. Hvilken slags ting ser du derude, og hvilken slags udfordringer ser du, at folk står overfor bare prøver at kortlægge den slags verdener, og hvad dit værktøj gør for dem?
Bullett Manale: Nå, jeg mener, at sagen ved det er, at det, du sagde - alt har brug for en database nu, så der er mange gange sandsynligvis en masse databaser, der introduceres i det miljø, som DBA selv gøres ikke engang opmærksomme på, fordi det ikke er meget svært at få en SQL-server installeret i miljøet, generelt set.
Dette værktøj identificerer også ting som ekspressdatabaser, så de gratis versioner af SQL Server. Sjovt nok, når du igen snakker med DBA'erne, får du ikke et konsekvent svar med hensyn til, om de holder af de gratis databaser, der er derude. Mange af disse applikationer, som du taler om, bruger den gratis version af databasen. Men organisationerne selv vil have en anden holdning med hensyn til, hvem der er ansvarlig for den database, afhængigt af hvem du snakker med.
Nogle DBA'er, som jeg taler med, kan jeg tænke på, sidste gang jeg var på SQL Server PASS, som er i Seattle, du stiller spørgsmålet “Gør du interesseret i dine ekspressdatabaser?” Og det var omkring halvtredshalvtreds. Nogle af de mennesker, de ønskede at vide om dem som en DBA, fordi de følte at de er en del af deres ansvar, selv de udtrykte databaser, de stadig kunne indeholde kritiske oplysninger; de er stadig nødt til at gennemgå processen med at blive sikkerhedskopieret og stadig nødt til at sikre sig, at alle ting fungerer ud fra et sundhedsmæssigt perspektiv på dem. Men bare det at vide, at de findes, er lige så vigtigt, hvis ikke mere vigtigt.
Mens den anden halvdel af folkene er: ”Hej, vi er ikke, vi er ikke ansvarlige for disse databaser, og alt, hvad de lægger på dem, er på pas med den person, der installerede dem.” Men jeg vil sige, at det overordnede, hvad du sagt, alt temmelig meget i dag har en applikation bundet til den, som bare bidrager mere til kompleksiteten og forvirringen ved at skulle inventarere disse oplysninger.
Dez Blanchfield: Ja, jeg har set nogle, regeringswebsteder er sandsynligvis min favorit, men jeg ser ofte i virksomhedsmiljøer, hvor er det, som du sagde, at folk glemmer jeg endda, når de installerer noget som SharePoint eller som selvudveksling, så du ved, at de kommer med en gratis version, der lige er indbygget, fordi de vil, du ved, installere den hurtigt og ikke bekymre dig om at skulle gå og købe licens.
Så bliver det stort, og så begynder nogen at klage over ydeevne, og de er som "Det er bare din gamle server, dit lager, dit netværk, hvad som helst, " og så bliver DBA kaldet, og de er ligesom, "Nå, du ' Vi har lige lagt alt i denne gratis version af databasen, hvilket ikke er det, du har brug for for at udføre denne store. ”
Især når du fik scenarier som Project Manager og Office kører hundreder, hvis ikke tusinder af projekter på tværs af en stor virksomhed eller en virksomhed, og de bruger SharePoint med Microsoft Project Server, og de dumper alle deres PMO-ting i denne database. Men i forreste ende er de ligesom, det er bare en webgrænseflade. Men der er virkelig databaser og databaser.
Bullett Manale: Ja.
Dez Blanchfield: Så hvad er de, en af de slags første trin, som folk her antager, at der er et par spørgsmål, som vi måske ønsker at bringe ind fra publikum. Et af de første spørgsmål er, hvor folk starter? Hvad er det første naturlige skridt for dem at gå, "Okay, vi er nødt til at gøre den Anonyme Alkoholikerversion?"
Vi har flere databaser, end vi ved, hvad vi skal gøre med. Hvordan ser en naturlig slags trin ud af dem at gå, ”Okay, vi er nødt til at få denne ting og begynde at løbe?” Gør de bare koldt kalkun, eller senere har de virkelig brug for at starte i det små og bare få lidt erfaring med at kortlægge deres miljø ?
Bullett Manale: Nå, jeg tror det sagt, at de er nødt til at kortlægge miljøet. Nu tilbyder Microsoft et gratis værktøj til at gøre det, Microsoft Assessment Planning Tool, det er et gratis værktøj, men det er statisk. Du gør opdagelsen, og det er det. Du får en liste over de ting, der er derude. Vi tog det og sagde se, lad os tage et skridt videre lad os gøre opdagelsen, lad os finde ud af hvad der er derude og lad os lægge det i depotet og lad os gøre det så det er dynamisk og vi kan tilføje det, fjerne det.
Men samlet set er det største første skridt, jeg tror bare for at finde ud af det, gøre opdagelsen. Uanset om det betyder at downloade vores produkt i prøveperiode, kan du downloade dette og prøve det i 14 dage, og du kan pege på dit miljø og udføre samlingen.
Nu, hvis du allerede har et regneark med en masse af de oplysninger derinde, at du er lidt overbevist om, at disse oplysninger er korrekte, har du også muligheden for at kunne lide importen til CSV, det regneark med alle disse oplysninger, og gøre den del af det, du har allerede. Men med hensyn til at finde ud af, hvad du ikke ved, er den eneste måde at gøre det manuelt at gå ud, gøre det eller have et værktøj, der ser efter den type ting som denne. Det er den beslutning, du på et tidspunkt bliver nødt til at tage, er: "Forsøger jeg at automatisere denne opdagelse eller i det mindste få et godt grundlag af, hvad derude først er, og så måske bekymre dig om nogle af undtagelserne?" Men for det meste har du sandsynligvis brug for et værktøj.
Dez Blanchfield: Så bare hurtigt. Hvor går folk for at komme i gang med dette? De rammer dit websted? Hvordan når de ud og kommer hurtigt i gang med dette?
Bullett Manale: Hvis du går til Idera, IDERA.com, vil du se, og jeg kan faktisk bare virkelig hurtigt vise det virkelig hurtigt. Over på Idera-webstedet går du til produkter, går til lagerbehandling. Du kan se, at der er et downloadlink lige her. Du bestemmer bare, hvilken bygning vil du installere på en 64 eller 32 bit, og det får dig i gang, og du kan starte din opdagelse derfra.
Robin Bloor: Fantastisk og god, god præsentation, meget tak.
Bullett Manale: Tak.
Eric Kavanagh: Vi har et par spørgsmål fra publikum, og vi e-mailer dem til dig, fordi vi er hårdt nødt til at stoppe os selv i dag, men Bullett, igen, godt stykke arbejde på demoen, stort job af vores producent, der fanger, at det ikke var ' t viser.
Bullett Manale: Undskyld det.
Eric Kavanagh: Nej, dette er gode ting, du giver synlighed ind i forretningens kerne, ikke? Fordi virksomheden kører data, og du giver synlighed helt ned til kernen. Så ikke mere bølgede ting; nu kan du faktisk pege på tingene og få det løst. Så godt for dig.
Bullett Manale: Tak.
Robin Bloor: Men det var dejligt at se det leve forresten, godt klaret.
Eric Kavanagh: Ja, vi arkiverer denne webcast til senere visning, og så vil vi forhåbentlig have den op inden for cirka en time eller to, det oprindelige arkiv går nogle gange op, det er lidt længere end det, men vi vil sørge for at lade folk ved godt. Med det vil vi give dig fri, folkens. Tak igen for at have deltaget i Briefing Room, vi er faktisk Hot Technologies. Vi henter dig næste gang. Pas på, farvel.
