Installer SQL Server R Services (i databasen). Opprett en ODBC-datakilde for en forekomst i datavitenskapsklienten

Jeg har aldri hørt om noen i oppveksten som drømte om å bli databaseadministrator når de ble store. Livet fører oss rett og slett til dette yrket, selv om mange virkelig liker det. Dykk ned i administrasjon SQL Server skjer sjelden med en produktmanual, oftere enn ikke må vi lære hemmelighetene til håndverket på egen hånd. Det var akkurat slik jeg startet, og jeg gjorde mange feil under studiene. Derfor utarbeidet jeg en serie artikler som allerede dekket temaene Reserver eksemplar og bedring. Nå er det på tide å snakke om hovedkonfigurasjonsverktøyet SQL-parametere Server - SQL Server Settings Manager.

SQL Server Settings Manager er en interaktiv applikasjon for å administrere alle tjenester på SQL basert Server, nettverksprotokoller, lytteporter og lage serveraliaser. SQL Server Configuration Manager (SSCM) er tilgjengelig i Start\Microsoft SQL Server 20xx\Configuration Tools\SQL Server Configuration Manager-menyelementhierarkiet i Microsoft-versjoner Windows tidligere Windows-utgivelse 8 og Windows Server 2012. I nyeste versjoner oppført operativsystem bare søk etter SQL Server og velg SQL Server Settings Manager fra listen over applikasjoner. Første gang du får tilgang til SSCM, ser programmet omtrent ut som figur 1 viser (denne artikkelen bruker SQL Server 2014 som et eksempel).

Skjerm 1: SQL Server Settings Manager

Innstillinger

La oss ta en nærmere titt mulige handlinger, tillatt i SSCM. Hvert element i venstre rute representerer én eller flere oppgaver som du kan utføre i SSCM. I noen tilfeller er det både et 64-biters og et 32-biters alternativ. I denne artikkelen vil vi fokusere på 32-bitsversjonen. I dag er Microsoft SQL Server kun vert på 32-biters servere hvis:

a) du er eieren gammel versjon SQL Server;

b) Du frarøver sannsynligvis din SQL Server-instans for verdifulle minneressurser.

La oss liste opp handlingene som er tilgjengelige i SSCM-manageren (se figur 2).

Skjerm 2: Handlinger tilgjengelig i SSCM

• SQL Server-tjenester. Denne handlingen Lar deg starte, stoppe og starte alle Microsoft SQL Server-relaterte tjenester på nytt. I tillegg kan du endre Kontoer tjenester, oppstartsatferd og tilleggsfunksjoner og oppstartsalternativer avhengig av tjenesten.
• SQL Server-nettverksinnstillinger. Denne handlingen lar deg aktivere eller deaktivere spesifikke nettverksprotokoller: Delt minne, navngitte rør og TCP/IP, samt konfigurere Ekstra alternativer for hver av dem.
• SQL Server Native Client-innstillinger (nåværende versjon 11.0). Denne handlingen lar deg angi rekkefølgen som klienter skal bruke spesialaktiverte protokoller for å koble til en tilpasset forekomst av SQL Server. Du kan bruke den til å lage aliaser for SQL Server-forekomsten din ulike applikasjoner sluttbrukere kan koble til servere med navn som er forskjellige fra det faktiske servernavnet. Dette gjøres i tilfelle du ikke kan endre tilkoblingsstrenger når du migrerer applikasjonsdatabaser, men likevel ønsker å sikre kontinuitet eller skjule det virkelige servernavnet for sluttbrukere. La oss se på hver av disse handlingene mer detaljert.

SQL Server-tjenester

SQL Server-kombinerte tjenester kan (og bør) administreres og konfigureres fra SSCM i stedet for services.msc API. Som nevnt ovenfor kan vi kontrollere ikke bare oppstartsatferden og tjenestekontoen, men også tilleggsinnstillinger for hver tjeneste (se figur 3).

• SQL Server-integrasjonstjenester. Det er ingen ekstra konfigurerbare alternativer.
• SQL Server Analysetjenester. Det er ingen ekstra konfigurerbare alternativer.
• SQL Server Service:

1. FILESTRØM. Denne innstillingen lar deg aktivere eller deaktivere T-SQL-tilgang, tilgang fil I/O, Tilgang til ekstern klient og angi navnet delt ressurs FILESTREAM.

2. Høy level Alltid på tilgjengelighet. Denne innstillingen gir deg muligheten til å aktivere eller deaktivere AlwaysOn Availability Groups og konfigurere Windows Failover Cluster (WFCS) som tilgjengelighetsgruppen er bygget på.

3. Startalternativer. SSCM lar deg tilordne spesielle oppstartsalternativer som trer i kraft for en forekomst. Du vil alltid ha til din disposisjon i det minste Tre oppstartsalternativer for enhver forekomst av SQL Server for å sikre at Microsoft SQL Server starter riktig:

• -d. Angir plasseringen av hoveddatabasedatafilen (.mdf).
• -l. Angir plasseringen av transaksjonsloggfilen (.ldf) for hoveddatabasen.
• -e. Angir plasseringen av forekomstfeilloggfilen.

Hvorfor disse tre parameterne? Fordi master fungerer som den utadvendte "hjernen" til SQL-forekomsten, og jobber sammen med den skjulte ressursdatabasen, og gir alle nødvendige metadata som trengs for å kjøre SQL Server-forekomsten. Du må bruke en feillogg for å registrere hvert trinn i oppstartsprosessen.

Ytterligere alternativer kan konfigureres, spesielt for å kjøre serveren i enkeltbrukermodus for feilsøkingsformål (-m); starte en instans fra minimumssett innstillinger (-f) i tilfeller der det er nødvendig å omgå en mislykket parameter som kan føre til forverring av instansens respons; sette sporingsflagg som endrer den grunnleggende oppførselen til Microsoft SQL Server (-T). Jeg måtte bruke -f for å omgå mislykkede innstillinger da jeg prøvde å demonstrere problemer med minnegrense og innstillinger maksimal verdi Serverens minne var så lite at den ikke kunne kjøre SQL Server. Selvfølgelig setter de fleste DBA-er flere sporingsflagg under deres profesjonell aktivitet på hver av SQL-serverne via -T-parameteren, men jeg vil snakke mer om dette i en annen artikkel.

En fullstendig liste over oppstartsalternativer finner du i den offisielle Microsoft-dokumentasjonen (https://msdn.

microsoft.com/en-us/library/ms190

4. Avansert ("Avansert"). Avansert-fanen for SQL Server-tjenesten (figur 4) gir muligheten til å endre dumpkatalogen for forekomsten, samt konfigurere mekanismen for å sende tilbakemelding til Microsoft-selskap Til videre arbeid over produktet. I tillegg får du muligheten til å lese (men ikke endre) tilleggsparametrene som er oppført nedenfor.

• SQL Server Reporting Services. Vi kan administrere noen grunnleggende tjenesteinnstillinger for SQL Server Reporting Services (SSRS), men det er et eget grensesnitt for denne tjenesten. Jeg anbefaler ikke å bruke SSCM for alle aspekter av SSRS-konfigurasjon, selv om noen er tilgjengelige.
• SQL Server-nettleser. Foruten oppstartsadferd og tjenestekonto, er det flere tilleggsinnstillinger av denne tjenesten som kan administreres bortsett fra dumpkatalogen og feilloggen. Det anbefales at du deaktiverer denne tjenesten med mindre du har flere forekomster av SQL Server på samme node.
• SQL Server Agent Service I likhet med mange andre tjenester kan du bare konfigurere dumpkatalogen, feillogging og tilbakemeldingsrapportering, sammen med oppstartsatferd og tjenestekonto.

SQL Server-nettverksinnstillinger

Handlinger til nettverksoppsett SQL Server lar deg aktivere hvilken som helst eller alle tre nettverksprotokoll, tilgjengelig i Microsoft SQL Server: Delt minne, Named Pipes og TCP/IP.

Delt minne og navngitte rør gir tilgang nettverksdatamaskin til SQL Server, og TCP/IP definerer kommunikasjonsmetodene nettverksenheter med en forekomst av SQL Server. Ja, Named Pipes kan brukes i Windows-miljø, men du mister alle fordelene ved å omgå nettverksstabel ved bruk av navngitte rør mellom eksterne servere. Innstillinger for delt minne begynner og slutter med aktiveringsstatus. Navngitte rør lar deg, i tillegg til aktivert/deaktivert status, spesifisere et rørnavn for SQL Server. Til slutt lar TCP/IP deg aktivere eller deaktivere denne protokollen, sammen med å endre porten som SQL Server lytter etter forespørsler på.

Sette opp SQL Server Native Client

Dette settet med handlinger lar deg angi rekkefølgen som spørringene behandles i i SQL Server. I tillegg vil du kunne deaktivere navngitte protokoller for klienten, samt tildele et kanalnavn og portnummer.

SQL Server Settings Manager-grensesnitt - essensiell komponent konfigurere hvordan forekomster fungerer og hvordan SQL Server samhandler med datamaskiner og klienter som sender spørringer til databaser som er vert for forekomsten. Det bestemmer hvordan forekomsten startes og sikkerheten til selve forekomsten. grunnleggende nivå gjennom å administrere tjenestekontoer som eier ulike komponenter Microsoft SQL Server. Dette er SQL Servers første forsvarslinje, og både nye og erfarne DBAer må bruke SSCM riktig og være klar over tilpasningsmulighetene den gir.

23/09/2015

Typiske feil ved oppsett av vedlikeholdsplaner for MS SQL Server DBMS for 1C

God ettermiddag, kolleger.

I dagens artikkel vil vi gjerne vurdere en ganske populær og populært emne, som å sette opp MS SQL Server-vedlikeholdsplaner. I s som et resultat av våre revisjoner, vigjenværende vanlig (mer enn 60 % av tilfellene)Vi oppdager unøyaktigheter i konfigurasjonen av MS SQL Server DBMS som brukes til å jobbe med 1C-produkter. Praksis viser at denne DBMS er den vanligste, så i denne artikkelen vil vi vurdere hovednyansene ved å jobbe med den.

Så hvor begynner du å sette opp en vedlikeholdsplan? Fra en backup, selvfølgelig! Den første regelen for DBA er: "Ikke begynn å gjøre noe uten en sikkerhetskopi." Vel, det vil vi heller ikke. La oss se på to hovedalternativer for å lage sikkerhetskopier, eller snarere to sikkerhetskopieringsmodeller, eller gjenopprettingsmodeller ( https://msdn.microsoft.com/ru-ru/library/ms189275(v=sql.120).aspx )

Gjenoppretting ved hjelp av den enkle modellen

Databasen din er i ENKEL gjenopprettingsmodus. Hva betyr dette? Dette betyr at det bare er fulle sikkerhetskopier, det er ikke nødvendig å sikkerhetskopiere transaksjonslogger, ytelsen i denne forstand er maksimal, men du kan bare gjenopprette til sikkerhetskopipunktet. Å gjenopprette databasen "til et spesifisert tidspunkt" er umulig.
Derfor må vi hver natt (eller oftere, avhengig av behovet) ta en ny kopi av databasen vår og legge den på et trygt sted, og definitivt ikke på samme sted som vår hoveddatabase
Generelt er bruken av SIMPLE-modellen for ekte arbeidsbaser kun berettiget i tilfeller der høy belastning og ubetydeligheten av datatap-hendelsen siden siste sikkerhetskopiering.

I tillegg vil jeg umiddelbart berøre spørsmålet om arbeid med transaksjonsloggen. Siden transaksjonsloggen ikke er veldig nyttig for oss i denne gjenopprettingsmodusen, er det ikke nødvendig å sikkerhetskopiere den - all informasjon fra loggen er allerede overført til sikkerhetskopien. Vanligvis vil logger i denne gjenopprettingsmodellen ikke vokse mye, men noen ganger er det nyttig å avkorte den. For eksempel, etter en massiv dataendring, kan denne operasjonen være ekstremt fordelaktig med tanke på transaksjonsloggplass. Hvis disken med loggen blir full, vil du garantert få problemer med funksjonen til databasen.

Dataavkorting kan utføres enten ved hjelp av standard serviceplanoppsettveiviser eller ved å bruke et enkelt T-SQL-skript:

DBCC SHRINKFILE(Databasenavn, 1);
GÅ

Dette skriptet vil redusere størrelsen på databaseloggfilen til den opprinnelige størrelsen (som standard vil dette oftest være 1 MB). Du bør imidlertid ikke utføre denne operasjonen konstant. Ideelt sett bør ikke filene dine endres i størrelse under systematisk arbeid, men vi vil snakke om dette en annen gang.

Gjenoppretting ved hjelp av hele modellen

La oss se på de grunnleggende prinsippene for å sette opp sikkerhetskopiering og administrere størrelsen på transaksjonsloggen fra synspunktet til det mest utbredte alternativet - den fullstendige databasegjenopprettingsmodellen.

Den fullstendige gjenopprettingsmodellen skiller seg fra den enkle ved at vi under hele driften av databasen kan (eller, mer presist, MÅ!) ta sikkerhetskopier av transaksjonsloggen, og gir derved muligheten til å gjenopprette databasen mellom punktene i hovedenheten. sikkerhetskopiering eller tilbakeføring i bestemte perioder av databasens drift, og også sikre at det frigjøres plass i loggfilen (trunkering). Hvis dette ikke gjøres, vil det vokse kontinuerlig til det en dag fyller all tilgjengelig plass (enten på disken eller opp til grensen satt i DBMS). Konsekvensene virker åpenbare, og ikke de mest behagelige.

Når det gjelder tilgjengelighet fullstendige sikkerhetskopier– selvfølgelig er minimumsgrensen vanligvis den samme en dag. Differensielle databasesikkerhetskopier er muligheten til å lagre kun endringer som har skjedd siden siste sikkerhetskopiering. Dette lar deg raskt og effektivt sikkerhetskopiere databasen, samtidig som du bruker nok rask bedring DB til ønsket tilstand.
Sikkerhetskopiering av transaksjonslogger kan utføres så ofte du trenger i løpet av dagen, mer spesifikt enn sikkerhetskopiering av differensielle databaser. Vi anbefaler vanligvis å velge et kopidetaljnivå på omtrent ¼ av tiden det tar å lage differensielle databasekopier.

Som nevnt ovenfor, når du utfører en sikkerhetskopi av databasetransaksjonslogg i en full modell, vil den bli avkortet automatisk (bare ikke forveksle trunkering med komprimering!).

Omberegning av statistikk og arbeid med indekser

Dagens praksis med å jobbe med indekser og statistikk blant våre kunder er ganske feil. Svært ofte står vi overfor et fullstendig fravær av disse prosedyrene i databasevedlikeholdsplaner. De gjøres ofte i feil rekkefølge. Ofte er det rett og slett ikke optimalt (for eksempel samtidig!).

Den riktige rekkefølgen av handlinger ser slik ut:

Bestemme graden av indeksfragmentering

Hvis indeksen er liten eller litt fragmentert, starter vi prosedyren for omorganisering av indeksen og omberegning av statistikk.

Ellers starter vi prosedyren for gjenoppbygging av indeksen. Indeksgjenoppbyggingsprosedyren vil faktisk oppdatere statistikken, så det er ikke nødvendig å beregne statistikken på nytt etter en fullstendig indeksombygging.

1. Vi regner om all annen statistikk der det er nødvendig.

Hvis vi vurderer et miniskript for å beregne statistikk på nytt og gjenoppbygge indekser (vi later ikke til å være superfullstendig og universell), vil det se omtrent slik ut (med indekser sortert gjennom en markør):

ERKLÆR @SQL NVARCHAR(MAX)

DECLARE @MIN_IND_SIZE heltall = 128

DECLARE @MIN_FRAGMENTATION_LEVEL heltall = 10

DECLARE @CRITICAL_FRAGMENTATION_LEVEL heltall = 30

ERKLÆR gjeldende indeks CURSOR LOCAL READ_ONLY FORWARD_ONLY FOR

VELG "ENDRE INDEKS [" + ind.navn + N"] PÅ [" +

SCHEMA_NAME(obj.) + "].[" + obj.name + "] " +

CASE WHEN stat.avg_fragmentation_in_percent > @CRITICAL_FRAGMENTATION_LEVEL

SÅ "GJENBYG MED (SORT_IN_TEMPDB = PÅ, ONLINE = PÅ)"

ELLER "REORGANISERE"

END + ";"

FRA(

SELECT stat., stat.index_id,

avg_fragmentation_in_percent = MAX(stat.avg_fragmentation_in_percent)

FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, "DETAILED") stat

WHERE stat.page_count > @MIN_IND_SIZE OG stat.index_id > 0

OG stat.avg_fragmentation_in_percent > @MIN_FRAGMENTATION_LEVEL

GROUP BY stat., stat.index_id

) stat

JOIN sys.indexes ind MED(NOLOCK) ON stat. = ind.

OG stat.index_id = ind.index_id

JOIN sys.objects obj MED(NOLOCK) ON obj. =stat.

ÅPNE gjeldende indeks

HENT NESTE FRA aktuell indeks TIL @SQL

WHILE @@FETCH_STATUS = 0 BEGIN

skriv ut @sql

EXEC sys.sp_executesql @SQL

FETCH NEXT FROM cur INTO @SQL

LUKK gjeldende indeks

DEALLOCATE currentIndex

Vær oppmerksom på bruken av tempdb, samt å holde indeksen tilgjengelig under gjenoppbyggingen - avhengig av utgaven av DBMS-en din, kan det hende at sistnevnte funksjon ikke er tilgjengelig.

Varsler

I tillegg til alle de tekniske aspektene er det veldig riktig å sette opp vedlikeholdsplaner som, dersom de utføres feil, likevel vil varsle deg om et problem som har oppstått. Og dette vil være det korteste avsnittet i artikkelen min. :)

Hvis alt virket for komplisert for deg, eller du ikke er sikker på at du kan gjøre slike innstillinger selv, ikke nøl med å kontakte oss - vi hjelper deg!

Så, fortsetter temaet om å betjene 1C-databaser, la oss se nærmere på kontrollsystemet relasjonsdatabaser Microsoft data SQL Server. Dette produktet gir oss gode muligheter for behandling, lagring, sikkerhetskopiering og gjenoppretting av databaser. Jeg vil starte en kort serie med artikler viet til dette emnet. Alt som er skrevet nedenfor er en personlig mening om dette problemet og er gjenstand for kritikk.

Denne artikkelen diskuterer prosessen med å lage grunnleggende vedlikeholdsplaner. Vi vil vurdere å varsle operatøren, samt et eksempel på gjenoppretting av databasen, i de følgende artiklene.

I testlaboratoriet har vi følgende:

• Windows Server 2008 Enterprise: SRV-1C-TEST.
• Microsoft SQL Server 2008: SRV-1C-TEST.
• Testbase Buh Firma.

Som vanlig satte vi oss oppgaven:

Utfør basevedlikehold mellom 00:30 og 01:00, og vedlikehold skal ikke være merkbart (eller knapt merkbart) for basebrukere.

La oss begynne med viktige poeng. MS SQL-databasen kan ha en av tre typer gjenopprettingsmodeller:

• Enkel.
• Full.
• Med ufullstendig logging.

Når vi sikkerhetskopierer, får vi også tre kopialternativer å velge mellom:

• Fullstendig.
• Forskjell.
• Kopiering av transaksjonsloggen (logger).

På fullversjon kopiering lagrer mdf-databasen og transaksjonsloggen. En differensiell sikkerhetskopi (også kjent som differensiell) kopierer data som har endret seg siden den siste fullstendige sikkerhetskopien ble opprettet. Kopiering av en transaksjonslogg lagrer derfor bare selve transaksjonsloggen.

Hvis du velger den enkle modellen, kan du gjenopprette databasen fra siste differensielle eller full sikkerhetskopi. Når vi velger full gjenopprettingsmodell, kan vi gjenopprette databasen opptil ett minutt ved å lage en full sikkerhetskopi, for eksempel om natten, og lage kopier av transaksjonsloggen på dagtid. Nedenfor skal vi se hvor dette punktet kommer opp. Jeg vil også sitere noen utdrag fra MSDN: "Den bulkloggede gjenopprettingsmodellen er utelukkende ment som et tillegg til modellen full bedring. Generelt er den bulkloggede gjenopprettingsmodellen lik modellen for full logggjenoppretting, bortsett fra at de fleste bulkoperasjoner er minimalt logget."

Du kan se gjenopprettingsmodellen til databasen din ved å gå til databaseegenskapene, for eksempel Buh Firma og gå til linjen - Parametere.

I MSSQL 2008 er standardgjenopprettingsmodellen i opprettede databaser Full.

Hvordan velge en gjenopprettingsmodell? Vi trenger bare å svare på spørsmålet: er tapet av informasjon dødelig i løpet av tiden som har gått etter en fullstendig sikkerhetskopi? Hvis svaret er ja, velg den fullstendige gjenopprettingsmodellen hvis ikke, velg den enkle. Masseloggingsmodellen skal bare brukes under massive databaseoperasjoner.

Så hvis du velger enkel modell, så vil du kunne gjenopprette data bare på tidspunktet for nattlig full eller differensiell kopiering, og etter det vil brukerne gjenopprette all informasjon manuelt. Når du velger Full-modellen, må du sikkerhetskopiere transaksjonsloggen, ellers vil loggene vokse betydelig. Med enhver gjenopprettingsmodell bør du alltid ha en fullstendig sikkerhetskopi.

Først vil vi lage en nattlig basevedlikeholdsplan, som vil inkludere sekvensen av følgende handlinger:

• Sjekker databaseintegritet
• Gjenoppbygging av indeksen
• Oppdater statistikk
• Tømmer DBMS prosedyrebuffer
• Database backup
• Rengjøring etter service
• Tømmer loggen

For å gjøre dette, koble til MSSQL-serveren ved hjelp av miljøet Microsoft SQLServer Management Studio. Du kan starte miljøet ved å gå til Start - Alle programmer - Microsoft SQL Server 2008.

La oss koble til SQL-serveren og gå til Ledelse - Serviceplaner. La oss klikke Høyreklikk etter serviceplaner og velg Lag en serviceplan. La oss gi ham et navn: SRV1CTEST.

Foran oss er SRV1CTEST-vinduet, der vi vil lage sekvensen av handlinger som er angitt tidligere. Vi ser det umiddelbart dukke opp Nested_Plan1. Til høyre for navnet på den nestede planen vil du se et skiltformet ikon. Klikk på den og gå inn i egenskapene til oppgaveplanen. Her kan du endre navnet på den nestede planen, sette repetisjonsfrekvensen til Daglig og still inn tiden. Så nå gjenstår det å fylle planen vår med oppgaver. For å gjøre dette, dra oppgaver fra verktøylinjen, som er plassert på høyre side.

La oss begynne med Databaseintegritetssjekker.

Etter at du har dratt oppgaven, dobbeltklikker du på den. Et vindu åpnes der vi på Database-linjen velger vår opprettede database Buh Firma. Deretter legger du til oppgaver på samme måte Gjenoppbygging av indeksen Og Oppdater statistikk, ikke glem å velge dem det nødvendige grunnlaget data.

Fremgangsmåte Gjenoppbygging av indeksen gjenskaper indeksen med en ny fyllfaktor. På grunn av dette øker vi ytelsen til arbeidet i databasen.

Oppgave Oppdater statistikk Oppdaterer tabelldatainformasjon for MS SQL. Noe som også forbedrer produktiviteten. Men etter denne operasjonen er det nødvendig å tømme hurtigbufferen.

La oss stoppe for nå og snakke om å sette opp forbindelser mellom oppgaver. Forbindelsene gjenspeiler rekkefølgen av utførelse. For å lage en forbindelse mellom oppgaver, må du klikke én gang på oppgaven og du vil se en pil vises. Hun må dras til neste oppgave. Forbindelsen kan ha 3 farger: blå, grønn og rød, som hver betyr tre typer overgangsskyting: ved enkel fullføring av forrige oppgave - Fullføring, i tilfelle vellykket gjennomføring - Suksess, og hvis det oppstår en feil under utføring av forrige oppgave - Feil. Du kan se alle disse parameterne ved å høyreklikke på pilen som er tegnet mellom oppgavene. Altså, hvis vi trenger det Gjenoppbygging av indeksen avfyrt først etter vellykket fullføring av oppgaven Sjekke databaseintegritet, må vi koble dem med en pil. Ved å høyreklikke på pilen, endre modusen til Vellykket, som vi ser, har fargen endret seg til grønn.

På dette øyeblikket vi har 3 opprettede oppgaver i vår nestede plan. Som du kanskje har lagt merke til, er ikke oppgaven Tømme DBMS prosedyrebuffer i verktøylinjen. Vi vil bruke problemet Opptreden T-SQL-utsagn . La oss dra den inn i planen og dobbeltklikke på den. Vi ser et vindu der vi skriver inn følgende:

DBCC GRATIS PROCCACHE

Ofte opererer basen under "normale" forhold. Hva betyr dette:

• SQL-serveren er godt "matet", dvs. mengde RAM forutsatt SQL-arbeid servere bør velges med en hastighet på 70 % av størrelsen på alle mdf-filer databaser.
• Prosessoren er ikke lastet mer enn 50 % i 90 % av tiden.
• Det er nok diskplass (spesielt brukes temp.db-databasen til sortering; 1C bruker den til alle sine livsaktiviteter, så det er verdt å ta vare på diskplassen med denne databasen på forhånd).
• Databasegjenopprettingsmodus er "Enkel". (Det er empirisk funnet at en stor ldf-fil bremser 1c, og muligheten for å gjenopprette fra en loggfil er svært tvilsom).

Det er også verdt å vurdere flere nyanser:

• Ved bruk av standardutgaven av SQL, med en fullstendig ombygging av indeksen, vil alle brukere bli koblet fra databasen, så det er verdt å ta hensyn til dette når man bestemmer seg for en ukentlig vedlikeholdsplan (planen vil bli beskrevet nedenfor).
• Det er verdt å tenke på at 1C-serveren også bruker minne, spesielt hvis tynnklienter eller webtjenester brukes.
• Det er bedre for SQL selv å begrense den maksimale mengden RAM i serverparametrene, slik at når kritisk masse er nådd, begynner den å fjerne unødvendige data fra RAM på forhånd. Og slik at etter hvert som den vokser, driver den ikke hele serveren til en stupor.

Under normale forhold er det rasjonelt å bruke 2 serviceplaner Ukentlig(en gang i uken) og Daglig(på de resterende 6 dagene i uken).

Ukentlig

Generell form

Etter serviceplanelementer:

1. Gjenoppbygging av indeksen. Poenget med oppgaven er å slette alle eksisterende indekser og installere nye. (grovt sett, inventar og ordne alt).
   Som parametere:
   • Velge en målbase (dette vil skje i nesten alle oppgaver, så jeg vil ikke ta hensyn til denne parameteren videre i denne artikkelen).
   • Objekt der vi velger "Tables and Views".
   • Alternativer ledig plass– for små volumer harddisk Du kan velge alternativet "standard", men jeg anbefaler å bruke "Endre prosentandelen av ledig plass på siden", den anbefalte verdien er 20%. Dette vil tillate deg å forlate en reserve gratis sider, og lar deg beholde indeksene lenger nåværende situasjon. ADVARSEL: Øker størrelsen på databasen.
   • Sorter resultatene i tempdb. Jeg tror det ikke er nødvendig å forklare, men jeg vil advare deg om at på dette tidspunktet vil tempdb vokse veldig mye, selv om sortering i den er designet for å fremskynde prosessen, vær forsiktig, ha litt plass igjen.
   • Lagring av indeksen på nettet er en funksjon som er tilgjengelig for bedriftsversjonen av SQL. Lar deg indeksere på nytt uten å koble fra klienter.

   !!! MERK FØLGENDE!!! I standardversjonen, ved reindeksering, kobles klienter fra databasen så lenge dette trinnet varer.

   Eksempelinnstillinger

   
   

2. Statistikkoppdatering. Oppgaven med å samle informasjon om tilstanden til indekser i databasen. (Generelt sett er det lite relevant etter re-indeksering, men jeg gjør det fortsatt).
   Alternativer:
   • En gjenstand. Alle de samme tabellene og visningene som for å gjenoppbygge indeksen.
   • Oppdater. Her oppdaterer vi all statistikk.
   • Visningstype – Full visning.

   På denne måten oppdaterer vi statistikk på tvers av hele databasen.

   Eksempelinnstillinger

   
   

3. Utføre en T-SQL-setning. Dette er utførelse av en vilkårlig kommando på SQL-språk, spesielt er vi interessert i dbcc proccache

   Som navnet antyder, tømme bufferen.

   Eksempel

   
   

4. Kontrollere integriteten til databasen. Det virker unødvendig å forklare her – vi sørger for at ingenting er ødelagt. I parametrene "inkluder indekser" i sjekken, var det ikke forgjeves at de ble gjenoppbygd.

   Eksempelinnstillinger

   
   

5. Database backup. Vi må snakke mer her, på grunn av mange funksjoner. Bedre studie denne gjenstanden separat i andre veiledninger, gir ikke formatet til denne artikkelen en grundig studie av sikkerhetskopiering.
   Men jeg vil advare deg om et par nyanser:
   • SQL vet ikke hvordan den skal rengjøre beholderen, så hvis du legger til sikkerhetskopier til en fil (den kalles også en "Sikkerhetskopieringsenhet"), vil du ende opp med å fylle opp all ledig plass.
   • SQL husker det sikkerhetskopier, derfor, etter å ha laget en engangssikkerhetskopi manuelt (for eksempel for å ta databasen til et annet sted, eller for å distribuere den til en annen database fra sikkerhetskopien for testing), vil den neste "forskjellen" telles fra den. For å forhindre dette, må du merke av for "Bare sikkerhetskopiering". Det er ikke noe slikt element i sikkerhetskopieringsoppgaven. Generelt, i en ukeplan, anbefaler jeg fortsatt å bruke hele typen sikkerhetskopiering.
   • Og det ville være greit å sjekke kopien, slik at du kan sove lettere.
   • Komprimering kan generelt brukes, men vær forsiktig, da må differanseverdier også komprimeres.

   Eksempelinnstillinger

   

6. Tømmer loggen.
   • Sikkerhetskopierings- og gjenopprettingslogg.
   • SQL Server Agent jobblogg.
   • Vedlikeholdsplanlogg.

   Jeg renser alt. Som navnet antyder, renser den hendelser i SQL-loggen. Jeg tror at hendelser eldre enn 4 uker er usannsynlig å interessere meg, fordi hvis det er et problem, rapporter det innen en måned.

   Eksempelinnstillinger

   
   

7. Operatørvarsling. Pek igjen for selvstudium. Men som navnet tilsier, er det for å rapportere problemer under gjennomføringen av planen.

Daglig

Generell form

Det gir ingen mening å snakke separat. Nesten alt er det samme som Weekly.
Forskjellen ligger i den første oppgaven - "Indeksreorganisering". Oppgavene er forskjellige ved at omorganiseringen forsøker å rette opp de eksisterende indeksene, i stedet for å gjøre alt med blanke ark. Jo mer fragmentering, jo oftere koster det å lansere. Men under normale forhold er en gang om dagen nok til å holde indeksen oppdatert frem til neste ombygging.

Alternativer

Du kan også bruke differensiell backup.

Det er alt. Jeg gjentar, jeg så ikke noe dogme på dette tidspunktet dette alternativet ble utviklet og testet av meg. Relevant for databaser som varierer i størrelse fra 6 til 100 GB.

Jeg ønsker deg raskt og pålitelig arbeid.
P.S. På grunn av det faktum at jeg ikke er en fullverdig DBA, kanskje kommentarene mine er veldig overfladiske, vil jeg gjerne lese kommentarene i kommentarfeltet og i PM.

I SQL Server 2016 og nyere versjoner kan du installere alle R Services (i databasen) relaterte komponenter ved hjelp av en veiviser SQL installasjoner Server.

Etter at installasjonen er fullført, kan det hende du trenger ytterligere handlinger for å aktivere R-tjenester, konfigurere kontoer og gi brukere tillatelser til å få tilgang til bestemte databaser.

Hvis du har problemer med å få tilgang til databasene etter at installasjonen er fullført, eller hvis du må fjerne tidligere versjoner, se avsnitt.

Åpen SQL miljø Server Management Studio. Hvis den ikke allerede er installert, kan du kjøre SQL Server Setup Wizard på nytt for å laste den ned fra koblingen og installere den.

Koble til forekomsten der R Services er installert (i databasen) og kjør følgende kommando for å eksplisitt aktivere R Services-komponenten. Ellers vil du ikke kunne kalle R-skript, selv om komponenten ble installert av installasjonsprogrammet.

Exec sp_configure "eksterne skript aktivert" , 1 Rekonfigurer med overstyring

Start SQL Server-tjenesten på nytt for SQL Server-forekomsten. Relatert tjeneste SQL Server Trusted Launchpad vil også starte på nytt automatisk. Du kan starte tjenesten på nytt ved å bruke Tjenester-panelet i Kontrollpanel eller ved å bruke SQL Server Configuration Manager.

Når SQL Server-tjenesten er tilgjengelig, sjekk om R er aktivert ved å kjøre følgende kommando og sjekke om egenskapen er run_value verdi 1:

Exec sp_configure "eksterne skript aktivert"

Du kan også åpne panelet Tjenester og sjekk om launchpad-tjenesten kjører for din forekomst. Hvert eksemplar har egen tjeneste startrampe.

Du skal nå kunne kjøre i SQL Server Management Studio enkle skript R, som følgende:

Exec sp_execute_external_script @language =N"R", @script=N"OutputDataSet<-InputDataSet ", @input_data_1 =N"select 1 as hello" with result sets (( int not null)); go

resultater

Hallo
1

Installasjonsprosessen oppretter 20 Windows-brukerkontoer for å utføre oppgaver med SQL Server Trusted Launchpad-tjenestesikkerhetstoken. Når en bruker sender inn et R-skript fra en ekstern klient, aktiverer SQL Server en tilgjengelig arbeidskonto, matcher den til den anropende brukerens identitet og kjører R-skriptet på brukerens vegne. Dette er en ny Database Engine-tjeneste som gir sikker utførelse av eksterne skript ved hjelp av en mekanisme kalt implisitt autentisering.

Kontoer kan vises i gruppen Windows-brukere SQLRUserGroup. Hvis du trenger å kjøre R-skript fra en ekstern datavitenskapsklient og du bruker Windows-autentisering, må disse arbeidskontoene gis tillatelse til å logge på SQL Server-forekomsten på dine vegne.

1. Utvid i SQL Server Management Studio i Object Explorer Sikkerhet, Høyreklikk Pålogginger og velg Opprett pålogging.
2. I dialogboksen Opprette en pålogging klikk på knappen Søk.
3. Klikk Objekttyper og velg Grupper. Fjern markeringen av alle andre alternativer.
4. Skriv inn i feltet "Skriv inn objektnavn". SQLRUserGroup og klikk Sjekk navn.
5. Navnet på den lokale gruppen som er knyttet til forekomstens launchpad-tjeneste må løses til forekomstnavn\SQLRUserGroup. Klikk på knappen OK.
6. Som standard er påloggingsnavnet tildelt offentlig tilgjengelig roller og har tillatelse til å koble til DBMS-kjernen.
7. Klikk på knappen OK.

Hvis du installerte SQL Server selv og kjører R-skript i din egen instans, gjør du det vanligvis med administrative rettigheter og har derfor eksplisitt tillatelse til å utføre ulike operasjoner og få tilgang til alle data i databasen, samt muligheten til å installere nye R-pakker ved å som nødvendig.

Men i et bedriftsscenario har de fleste brukere, inkludert de som får tilgang til databasen ved hjelp av SQL-pålogginger, ikke slike forhøyede rettigheter. Derfor må hver bruker som skal kjøre eksterne skript gis tillatelse til å kjøre R-skript på hver database der R skal brukes.

BRUK GÅ GJENNE UTFØR EVENTUELLE EKSTERNE SCRIPT TIL

Denne delen beskriver ytterligere endringer du kan gjøre i forekomstkonfigurasjonen, eller, hvis du bruker en datavitenskapsklient, endringer for å aktivere R-skript å kjøre.

Endre antall jobbkontoer som brukes av SQL Server Trusted Launchpad

Hvis du forventer å bruke R-miljøet mye eller har mange brukere som kjører skript samtidig, kan det være lurt å øke antallet arbeidskontoer som er tilordnet Launchpad-tjenesten. For mer informasjon, se.

Gi R-brukere eller logger på nødvendige lese-, skrive- eller DDL-tillatelser på flere databaser

Når du kjører R-skript, kan det hende en brukerkonto må lese data fra andre databaser, lage tabeller for å lagre resultatene og skrive data til tabeller.

Hver brukerkonto som kjører R-skript må ha tillatelser db_datareader, db_datawriter eller db_ddladmin for en bestemt database.

For eksempel gir følgende Transact-SQL-setning SQL-påloggingen MySQLLlogging rettigheter til å utføre T-SQL-spørringer på databasen RSampler. For å fullføre denne setningen må SQL-påloggingen allerede eksistere i serverens sikkerhetskontekst.

BRUK RSamples GO EXEC sp_addrolemember "db_datareader", "MySQLLogin"

For mer informasjon om tillatelsene som er inkludert i hver rolle, se .

Opprett en ODBC-datakilde for en forekomst i datavitenskapsklienten

Hvis du bygger en R-løsning på en datavitenskapsklientmaskin og du må koble til SQL Server-maskinen som fungerer som beregningskontekst, kan du bruke SQL-pålogging eller integrert Windows-autentisering.

Når du bruker en SQL-pålogging, må den ha passende tillatelser til databasen som dataene skal leses fra. For å gjøre dette kan du legge til tillatelser Koble til Og PLUKKE UT eller legg til pålogging til rollen db_datareader. Hvis du trenger å lage objekter, trenger du tillatelser DDL_admin. For å lagre data i tabeller, legg til en pålogging til rollen db_datawriter.

Hvis du bruker Windows-autentisering, må du konfigurere ODBC-datakilden i datavitenskapsklienten med forekomstnavnet og annen tilkoblingsinformasjon.

For mer informasjon, se.

Serveroptimalisering for R

Standardinnstillingene for SQL Server Setup er utformet for å optimalisere utførelsen av ulike tjenester som støttes av databasemotoren på serveren, inkludert utvinning, transformasjon og lasteprosesser, rapportering, revisjon og applikasjoner som bruker SQL Server-data. Derfor, når du bruker standardinnstillinger, kan ressursene for R-operasjoner være begrenset eller begrenset, spesielt for minnekrevende operasjoner.

For å sikre at R-oppgaver blir tildelt de riktige prioriteringene og tildelt de nødvendige ressursene, anbefaler vi at du bruker ressursstyringsverktøyet til å konfigurere en ekstern ressurspool for R-operasjoner. Du kan også endre mengden minne som er allokert til SQL Server-databasemotoren antall kontoer i Trusted Launchpad-tjenesten SQL Server.

Kompatibel med RC2-versjon: last ned arkiv rre-gpl-src.8.0.2.tar.gz

Kompatibel med RC3-versjon: last ned arkiv rre-gpl-src.8.0.3.tar.gz

Kompatibel med RTM-versjon: last ned arkiv rre-gpl-src.8.0.3.tar.gz

Har du problemer? Se gjennom listen over vanlige problemer når du installerer forhåndsvisningsversjoner av R Services (i databasen).