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

Jeg har aldrig hørt om nogen, der voksede op, som drømte om at blive databaseadministrator, når de blev store. Livet fører os simpelthen til dette erhverv, selvom mange mennesker virkelig kan lide det. Dyk ned i administration SQL Server Det sker sjældent med en produktmanual, oftere end ikke skal vi lære håndværkets hemmeligheder på egen hånd. Det var præcis sådan, jeg startede, og jeg lavede mange fejl under studiet. Derfor udarbejdede jeg en række artikler, der allerede dækkede emnerne Reserve eksemplar og bedring. Nu er det tid til at tale om det vigtigste konfigurationsværktøj SQL parametre Server - SQL Server Settings Manager.

SQL Server Settings Manager er en interaktiv applikation til at administrere alle tjenester på SQL baseret Server, netværksprotokoller, lytteporte og oprettelse af serveraliaser. SQL Server Configuration Manager (SSCM) er tilgængelig i menupunkthierarkiet Start\Microsoft SQL Server 20xx\Configuration Tools\SQL Server Configuration Manager Microsoft versioner Windows tidligere Windows udgivelse 8 og Windows Server 2012. I nyeste versioner anført operativ system bare søg efter SQL Server og vælg SQL Server Settings Manager fra listen over applikationer. Første gang du får adgang til SSCM, ser programmet noget ud som figur 1 viser (denne artikel bruger SQL Server 2014 som eksempel).

Skærm 1: SQL Server Settings Manager

Indstillinger

Lad os se nærmere mulige handlinger, tilladt i SSCM. Hvert element i venstre rude repræsenterer en eller flere opgaver, som du kan udføre i SSCM. I nogle tilfælde er der både en 64-bit og en 32-bit mulighed. I denne artikel vil vi fokusere på 32-bit versionen. I dag hostes Microsoft SQL Server kun på 32-bit servere, hvis:

a) du er ejeren gammel version SQL Server;

b) Du berøver sandsynligvis din SQL Server-instans for værdifulde hukommelsesressourcer.

Lad os liste de tilgængelige handlinger i SSCM-manageren (se figur 2).

Skærm 2: Handlinger tilgængelige i SSCM

• SQL Server Services. Denne handling Giver dig mulighed for at starte, stoppe og genstarte alle Microsoft SQL Server-relaterede tjenester. Derudover kan du ændre Regnskaber tjenester, opstartsadfærd og ekstra funktioner og opstartsmuligheder afhængigt af tjenesten.
• SQL Server netværksindstillinger. Denne handling giver dig mulighed for at aktivere eller deaktivere specifikke netværksprotokoller: Delt hukommelse, navngivne rør og TCP/IP samt konfigurere Ekstra muligheder for hver af dem.
• SQL Server Native Client-indstillinger (aktuelt version 11.0). Denne handling giver dig mulighed for at indstille den rækkefølge, som klienter vil bruge specielt aktiverede protokoller til at oprette forbindelse til en tilpasset forekomst af SQL Server i. Du kan bruge den til at oprette aliaser til din SQL Server-instans til forskellige applikationer slutbrugere kunne oprette forbindelse til servere med andre navne end det faktiske servernavn. Dette gøres i tilfælde af, at du ikke kan ændre forbindelsesstrenge, når du migrerer applikationsdatabaser, men stadig ønsker at sikre kontinuitet eller skjule det rigtige servernavn for slutbrugere. Lad os se på hver af disse handlinger mere detaljeret.

SQL Server Services

SQL Server bundtede tjenester kan (og bør) administreres og konfigureres fra SSCM i stedet for services.msc API. Som nævnt ovenfor kan vi kontrollere ikke kun opstartsadfærden og servicekontoen, men også yderligere indstillinger for hver tjeneste (se figur 3).

• SQL Server Integration Services. Der er ingen yderligere konfigurerbare muligheder.
• SQL Server Analyse Services. Der er ingen yderligere konfigurerbare muligheder.
• SQL Server Service:

1. FILESTRØM. Denne indstilling giver dig mulighed for at aktivere eller deaktivere T-SQL-adgang fil I/O, Adgang til fjernklient og indstil navnet delt ressource FILESTREAM.

2. Højt niveau Altid på tilgængelighed. Denne indstilling giver dig mulighed for at aktivere eller deaktivere AlwaysOn Availability Groups og konfigurere Windows Failover Cluster (WFCS), som tilgængelighedsgruppen er bygget på.

3. Startindstillinger. SSCM giver dig mulighed for at tildele specielle opstartsindstillinger, der træder i kraft for en instans. Du vil altid have til din rådighed i det mindste Tre opstartsmuligheder for enhver forekomst af SQL Server for at sikre, at Microsoft SQL Server starter korrekt:

• -d. Angiver placeringen af ​​masterdatabasens datafil (.mdf).
• -l. Angiver placeringen af ​​transaktionslogfilen (.ldf) for masterdatabasen.
• -e. Angiver placeringen af ​​forekomstens fejllogfil.

Hvorfor disse tre parametre? Fordi master fungerer som den udadvendte "hjerne" af SQL-forekomsten, der arbejder sammen med den skjulte ressourcedatabase og leverer alle de nødvendige metadata, der er nødvendige for at køre SQL Server-forekomsten. Du skal bruge en fejllog til at registrere hvert trin i opstartsprocessen.

Yderligere muligheder kan konfigureres, især til at køre serveren i enkeltbrugertilstand til fejlfindingsformål (-m); starte en instans fra minimum sæt indstillinger (-f) i tilfælde, hvor det er nødvendigt at omgå en mislykket parameter, der kan føre til forringelse af instansens respons; indstilling af sporingsflag, der ændrer den grundlæggende adfærd for Microsoft SQL Server (-T). Jeg var nødt til at bruge -f for at omgå mislykkede indstillinger, da jeg forsøgte at demonstrere problemer med hukommelsesgrænse og indstilling maksimal værdi Serverens hukommelse var så lille, at den ikke kunne køre SQL Server. Selvfølgelig sætter de fleste DBA'er flere sporingsflag under deres faglig aktivitet på hver af SQL-serverne via parameteren -T, men jeg vil fortælle mere om dette i en anden artikel.

En komplet liste over opstartsmuligheder kan findes i den officielle Microsoft-dokumentation (https://msdn.

microsoft.com/en-us/library/ms190

4. Avanceret ("Avanceret"). Fanen Avanceret for SQL Server-tjenesten (figur 4) giver mulighed for at ændre dumpbiblioteket for forekomsten samt konfigurere mekanismen til at sende feedback til Microsoft selskab Til videre arbejde over produktet. Derudover får du mulighed for at læse (men ikke ændre) de yderligere parametre, der er anført nedenfor.

• SQL Server Reporting Services. Vi kan administrere nogle grundlæggende serviceindstillinger for SQL Server Reporting Services (SSRS), men der er en separat grænseflade til denne service. Jeg anbefaler ikke at bruge SSCM til alle aspekter af SSRS-konfiguration, selvom nogle er tilgængelige.
• SQL Server browser. Udover opstartsadfærd og servicekonto er der flere yderligere indstillinger af denne service, der kan administreres med undtagelse af dumpbiblioteket og fejlloggen. Det anbefales, at du deaktiverer denne tjeneste, medmindre du har flere forekomster af SQL Server på den samme node.
• SQL Server Agent Service I lighed med mange andre tjenester kan du kun konfigurere dumpkataloget, fejllogning og feedbackrapportering sammen med opstartsadfærd og servicekonto.

SQL Server netværksindstillinger

Handlinger til netværksopsætning SQL Server giver dig mulighed for at aktivere enhver eller alle tre netværksprotokol, tilgængelig i Microsoft SQL Server: Shared Memory, Named Pipes og TCP/IP.

Shared Memory og Named Pipes giver adgang netværkscomputer til SQL Server, og TCP/IP definerer kommunikationsmetoderne netværksenheder med en forekomst af SQL Server. Ja, Named Pipes kan bruges i Windows miljø, men du mister alle fordelene ved at omgå netværksstak ved brug af navngivne rør mellem fjernservere. Indstillinger for delt hukommelse begynder og slutter med aktiveringsstatus. Navngivne rør giver dig ud over statussen aktiveret/deaktiveret mulighed for at angive et rørnavn til SQL Server. Endelig giver TCP/IP dig mulighed for at aktivere eller deaktivere denne protokol, sammen med at ændre den port, som SQL Server lytter efter anmodninger på.

Opsætning af SQL Server Native Client

Dette sæt handlinger giver dig mulighed for at indstille rækkefølgen, som forespørgsler behandles i i SQL Server. Derudover vil du være i stand til at deaktivere navngivne protokoller for klienten, samt tildele et kanalnavn og portnummer.

SQL Server Settings Manager Interface - væsentlig komponent konfigurere, hvordan instanser fungerer, og hvordan SQL Server interagerer med computere og klienter, der sender forespørgsler til databaser, der er hostet på instansen. Det bestemmer, hvordan instansen lanceres og sikkerheden for selve instansen. basis niveau gennem administration af servicekonti, der ejer forskellige komponenter Microsoft SQL Server. Dette er SQL Servers første forsvarslinje, og både nye og erfarne DBA'er skal bruge SSCM korrekt og være opmærksomme på de tilpasningsmuligheder, det giver.

23/09/2015

Typiske fejl ved opsætning af vedligeholdelsesplaner for MS SQL Server DBMS for 1C

God eftermiddag, kolleger.

I dagens artikel vil vi gerne overveje en ret populær og populært emne, som at opsætte MS SQL Server-vedligeholdelsesplaner. I s som et resultat af vores revisioner, viresterende almindelig (mere end 60 % af tilfældene)Vi opdager unøjagtigheder i konfigurationen af ​​MS SQL Server DBMS, der bruges til at arbejde med 1C-produkter. Praksis viser, at dette DBMS er det mest almindelige, så i denne artikel vil vi overveje de vigtigste nuancer ved at arbejde med det.

Så hvor begynder du at opsætte en vedligeholdelsesplan? Fra en backup, selvfølgelig! Den første regel i DBA er: "Begynd ikke at gøre noget uden en backup." Nå, det gør vi heller ikke. Lad os se på to hovedmuligheder for at oprette sikkerhedskopier, eller rettere to sikkerhedskopieringsmodeller eller gendannelsesmodeller ( https://msdn.microsoft.com/ru-ru/library/ms189275(v=sql.120).aspx )

Gendannelse ved hjælp af den simple model

Din database er i SIMPLE gendannelsestilstand. Hvad betyder det? Det betyder, at der kun er fuld backup, der er ingen grund til at sikkerhedskopiere transaktionslogfiler, ydeevnen i denne forstand er maksimal, men du kan kun gendanne til backuppunktet. Gendannelse af databasen "til et bestemt tidspunkt" er umuligt.
Derfor skal vi hver aften (eller oftere, afhængigt af behovet) tage en frisk kopi af vores database og lægge den et sikkert sted, og bestemt ikke på samme sted som vores hoveddatabase
Generelt er brugen af ​​SIMPLE-modellen til rigtige arbejdsbaser kun berettiget i tilfælde, hvor høj belastning og ubetydeligheden af ​​datatabshændelsen siden sidste sikkerhedskopiering.

Derudover vil jeg straks berøre spørgsmålet om arbejdet med transaktionsloggen. Da transaktionsloggen ikke er særlig nyttig for os i denne gendannelsestilstand, er der ingen grund til at sikkerhedskopiere den - alle oplysningerne fra loggen er allerede blevet overført til sikkerhedskopien. Typisk vil logfiler i denne gendannelsesmodel ikke vokse meget, men nogle gange er det nyttigt at afkorte det. For eksempel, efter en massiv dataændring, kan denne operation være yderst fordelagtig med hensyn til transaktionslogplads. Hvis disken med loggen bliver fuld, vil du med garanti få problemer med databasens funktion.

Datatrunkering kan udføres enten ved hjælp af standardserviceplanopsætningsguiden eller ved hjælp af et simpelt T-SQL-script:

DBCC SHRINKFILE(Databasenavn, 1);
GÅ

Dette script vil reducere størrelsen af ​​databasens logfil til den oprindelige størrelse (som standard vil dette oftest være 1 MB). Du bør dog ikke udføre denne operation konstant. Ideelt set bør dine filer ikke ændre sig i størrelse under systematisk arbejde, men vi vil tale om dette en anden gang.

Gendannelse ved hjælp af den fulde model

Lad os se på de grundlæggende principper for opsætning af backup og styring af størrelsen af ​​transaktionsloggen fra synspunktet om den mest udbredte mulighed - den fulde databasegendannelsesmodel.

Den fulde gendannelsesmodel adskiller sig fra den simple ved, at vi under hele driften af ​​databasen kan (eller mere præcist SKAL!) lave sikkerhedskopier af transaktionsloggen og derved give mulighed for at gendanne databasen mellem hovedpunkterne sikkerhedskopier eller rollbacks i bestemte perioder af databasens drift, og også sikre, at der frigøres plads i logfilen (trunkering). Hvis dette ikke gøres, vil det vokse kontinuerligt, indtil det en dag fylder al den ledige plads (enten på disken eller op til den grænse, der er sat i DBMS). Konsekvenserne synes indlysende, og ikke de mest behagelige.

Med hensyn til tilgængelighed fuld backup- selvfølgelig er minimumsgrænsen normalt den samme en dag. Differentielle database backups er muligheden for kun at gemme ændringer, der er sket siden sidste backup. Dette giver dig mulighed for hurtigt og effektivt at tage backup af databasen, mens du bruger nok hurtig bedring DB til den ønskede tilstand.
Sikkerhedskopiering af transaktionslog kan udføres så ofte, som du har brug for i løbet af dagen, mere specifikt end differentielle database-backups. Vi anbefaler normalt at vælge et kopidetaljeniveau på ca. ¼ af den tid, det tager at oprette differentielle databasekopier.

Som nævnt ovenfor, når du udfører en backup af en databasetransaktionslog i en fuld model, vil den automatisk blive trunkeret (du skal bare ikke forveksle trunkering med komprimering!).

Genberegning af statistik og arbejde med indekser

Den nuværende praksis med at arbejde med indeks og statistik blandt vores kunder er ret fejlagtig. Meget ofte står vi over for et fuldstændigt fravær af disse procedurer i databasevedligeholdelsesplaner. De udføres ofte i den forkerte rækkefølge. Ofte er det simpelthen ikke optimalt (f.eks. samtidig!).

Den korrekte rækkefølge af handlinger ser sådan ud:

Bestemmelse af graden af ​​indeksfragmentering

Hvis indekset er lille eller lidt fragmenteret, iværksætter vi proceduren for omorganisering af indekset og genberegning af statistik.

Ellers starter vi indeksgenopbygningsproceduren. Indeksgenopbygningsproceduren vil faktisk opdatere statistikken, så der er ingen grund til at genberegne statistikken efter en komplet indeksgenopbygning.

1. Vi genberegner al anden statistik, hvor det er nødvendigt.

Hvis vi overvejer et mini-script til genberegning af statistikker og genopbygning af indekser (vi foregiver ikke at være super komplet og universel), så vil det se sådan ud (med indekser sorteret gennem en markør):

ERKLÆR @SQL NVARCHAR(MAX)

DECLARE @MIN_IND_SIZE heltal = 128

DECLARE @MIN_FRAGMENTATION_LEVEL heltal = 10

DECLARE @CRITICAL_FRAGMENTATION_LEVEL heltal = 30

ERKLÆR aktuelt indeks CURSOR LOKAL LÆS_KUN FORWARD_ONLY FOR

VÆLG "ALTER INDEX [" + ind.navn + N"] TIL [" +

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

CASE WHEN stat.avg_fragmentation_in_percent > @CRITICAL_FRAGMENTATION_LEVEL

SÅ "GENBYG MED (SORT_IN_TEMPDB = TIL, ONLINE = TIL)"

ANDET "REORGANISER"

END + ";"

FRA (

VÆLG stat., stat.indeks_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.indeks_id = ind.indeks_id

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

ÅBN currentIndex

FETCH NEXT FRA currentIndex INTO @SQL

WHILE @@FETCH_STATUS = 0 BEGIN

udskriv @sql

EXEC sys.sp_executesql @SQL

FETCH NEXT FROM cur INTO @SQL

LUK nuværende indeks

DEALLOCATE currentIndex

Bemærk brugen af ​​tempdb, samt at holde indekset tilgængeligt under genopbygningen - afhængigt af udgaven af ​​dit DBMS, er sidstnævnte funktion muligvis ikke tilgængelig.

Meddelelser

Ud over alle de tekniske aspekter er det meget korrekt at opsætte vedligeholdelsesplaner, der, hvis de udføres forkert, stadig vil give dig besked om et problem, der er opstået. Og dette vil være det korteste afsnit i min artikel. :)

Hvis alt virkede for kompliceret for dig, eller du ikke er sikker på, at du selv kan foretage sådanne indstillinger, så tøv ikke med at kontakte os - vi hjælper!

Så for at fortsætte emnet om servicering af 1C-databaser, lad os se nærmere på kontrolsystemet relationelle databaser Microsoft data SQL Server. Dette produkt giver os fantastiske muligheder for behandling, lagring, sikkerhedskopiering og gendannelse af databaser. Jeg vil starte en kort serie af artikler om dette emne. Alt, hvad der er skrevet nedenfor, er en personlig mening om dette spørgsmål og er genstand for kritik.

Denne artikel diskuterer processen med at oprette basisvedligeholdelsesplaner. Vi vil overveje at underrette operatøren, samt et eksempel på gendannelse af databasen, i de følgende artikler.

I testlaboratoriet har vi følgende:

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

Som sædvanlig stiller vi os selv opgaven:

Udfør basisvedligeholdelse mellem 00:30 og 01:00, og vedligeholdelse bør ikke være mærkbar (eller knap mærkbar) for basebrugere.

Lad os starte med vigtige punkter. MS SQL-database kan have en af ​​tre typer gendannelsesmodeller:

• Enkel.
• Fuld.
• Med ufuldstændig logning.

Når vi sikkerhedskopierer, får vi også tre kopieringsmuligheder at vælge imellem:

• Komplet.
• Forskel.
• Kopiering af transaktionsloggen (logfiler).

På fulde version kopiering gemmer mdf-databasen og transaktionsloggen. En differentiel sikkerhedskopi (også kendt som differentiel) kopierer data, der er ændret siden den sidste fulde sikkerhedskopi blev oprettet. Kopiering af en transaktionslog gemmer derfor kun selve transaktionsloggen.

Hvis du vælger den simple model, kan du gendanne databasen fra den sidste differentielle eller fulde backup. Når vi vælger den fulde gendannelsesmodel, kan vi gendanne databasen op til minuttet ved at oprette en fuld backup, for eksempel om natten, og lave kopier af transaktionsloggen i løbet af dagen. Nedenfor vil vi se, hvor dette punkt kommer op. Jeg vil også gerne citere nogle uddrag fra MSDN: "Den bulk-loggede gendannelsesmodel er udelukkende beregnet som en tilføjelse til modellen fuld bedring. Generelt ligner den bulk-loggede gendannelsesmodel den fuld-log-gendannelsesmodellen, bortset fra at de fleste bulk-handlinger er minimalt logget."

Du kan se gendannelsesmodellen for din database ved for eksempel at gå til databaseegenskaberne Buh Firma og gå til linjen - Parametre.

I MSSQL 2008 er standardgendannelsesmodellen i oprettede databaser Fuld.

Hvordan vælger man en genopretningsmodel? Vi skal bare besvare spørgsmålet: er tabet af information fatalt i den tid, der er gået efter en fuld backup? Hvis svaret er ja, så vælg den fulde gendannelsesmodel; hvis ikke, vælg den simple. Masselogningsmodellen bør kun bruges under massive databaseoperationer.

Altså, hvis du vælger simpel model, så vil du kun være i stand til at gendanne data på tidspunktet for fuld eller differentiel kopiering om natten, og derefter vil brugerne gendanne alle oplysninger manuelt. Når du vælger Full-modellen, skal du tage backup af transaktionsloggen, ellers vil loggene vokse betydeligt. Med enhver gendannelsesmodel bør du altid have en fuld sikkerhedskopi.

Først vil vi oprette en natlig basisvedligeholdelsesplan, som vil omfatte rækkefølgen af ​​følgende handlinger:

• Kontrol af databasens integritet
• Genopbygning af indekset
• Opdater statistik
• Rydning af DBMS proceduremæssige cache
• Database backup
• Rengøring efter service
• Rydning af loggen

For at gøre dette skal du oprette forbindelse til MSSQL-serveren ved hjælp af miljøet Microsoft SQLServer Management Studio. Du kan starte miljøet ved at gå til Start - Alle programmer - Microsoft SQL Server 2008.

Lad os oprette forbindelse til SQL-serveren og gå til Ledelse - Serviceplaner. Lad os klikke Højreklik efter serviceplaner og vælg Opret en serviceplan. Lad os give ham et navn: SRV1CTEST.

Foran os er vinduet SRV1CTEST, hvor vi vil oprette sekvensen af ​​handlinger angivet tidligere. Vi ser det straks dukke op Indlejret_Plan1. Til højre for navnet på den indlejrede plan vil du se et skiltformet ikon. Klik på den og kom ind i egenskaberne for opgaveplanen. Her kan du ændre navnet på den indlejrede plan, indstille gentagelsesfrekvensen til Daglige og indstil tiden. Så nu er det tilbage at fylde vores plan med opgaver. For at gøre dette skal du trække opgaver fra værktøjslinjen, som er placeret i højre side.

Lad os starte med Databaseintegritetstjek.

Når du har trukket opgaven, skal du dobbeltklikke på den. Et vindue åbnes, hvori vi i databaselinjen vælger vores oprettede database Buh Firma. Tilføj derefter opgaver på samme måde Genopbygning af indekset Og Opdater statistik, og glem ikke at vælge dem det nødvendige grundlag data.

Procedure Genopbygning af indekset genskaber indekset med en ny fyldfaktor. På grund af dette øger vi udførelsen af ​​arbejdet i databasen.

Opgave Opdater statistik Opdaterer tabeldataoplysninger for MS SQL. Hvilket også forbedrer produktiviteten. Men efter denne operation er det nødvendigt at rydde cachen.

Lad os stoppe for nu og tale om at oprette forbindelser mellem opgaver. Forbindelserne afspejler rækkefølgen af ​​udførelsen. For at lave en forbindelse mellem opgaverne skal du klikke én gang på opgaven, og du vil se en pil vises. Hun skal trækkes til næste opgave. Forbindelsen kan have 3 farver: blå, grøn og rød, som hver betyder tre typer overgangsskydning: ved simpel afslutning af den foregående opgave - Færdiggørelse, i tilfælde af vellykket gennemførelse - Succes, og hvis der opstår en fejl under udførelse af den forrige opgave - Fejl. Du kan se alle disse parametre ved at højreklikke på pilen tegnet mellem opgaverne. Altså hvis vi har brug for det Genopbygning af indekset først afskediget efter vellykket afslutning af opgaven Kontrol af databaseintegritet, vi skal forbinde dem med en pil. Ved at højreklikke på pilen, skift dens tilstand til Succesfuldt, som vi ser, er dens farve ændret til grøn.

På dette øjeblik vi har 3 oprettede opgaver i vores indlejrede plan. Som du måske har bemærket, er opgaven Rydning af DBMS proceduremæssige cache ikke i værktøjslinjen. Vi vil bruge problemet Ydeevne T-SQL-udsagn . Lad os trække det ind i planen og dobbeltklikke på det. Vi ser et vindue, hvor vi indtaster følgende:

DBCC GRATIS PROCCACHE

Ofte fungerer basen under "normale" forhold. Hvad betyder det:

• SQL-serveren er godt “fodret”, dvs. mængden af ​​RAM forudsat SQL arbejde servere bør vælges med en hastighed på 70 % af størrelsen af ​​alle mdf filer databaser.
• Processoren belastes ikke mere end 50 % i 90 % af tiden.
• Der er tilstrækkelig diskplads (især bruges temp.db-databasen til sortering; 1C bruger den til alle sine livsaktiviteter, så det er værd at tage sig af diskpladsen med denne database på forhånd).
• Databasegendannelsestilstand er "Simpel". (Det er empirisk fundet, at en stor ldf-fil sænker farten 1c, og muligheden for at gendanne fra en logfil er meget tvivlsom).

Det er også værd at overveje flere nuancer:

• Ved brug af Standard-udgaven af ​​SQL, med en komplet ombygning af indekset, vil alle brugere blive afbrudt fra databasen, så det er værd at tage højde for dette, når der skal besluttes om en Ugentlig vedligeholdelsesplan (planen vil blive beskrevet nedenfor).
• Det er værd at overveje, at 1C-serveren også bruger hukommelse, især hvis der bruges tynde klienter eller webtjenester.
• Det er bedre for SQL selv at begrænse den maksimale mængde RAM i serverparametrene, så når den kritiske masse er nået, begynder den at rydde unødvendige data fra RAM på forhånd. Og så det, efterhånden som det vokser, ikke driver hele serveren til en sløvhed.

Under normale forhold er det rationelt at bruge 2 serviceplaner Ugentlig(en gang om ugen) og Daglige(på de resterende 6 dage i ugen).

Ugentlig

Generel form

Efter serviceplanelementer:

1. Genopbygning af indekset. Pointen med opgaven er at slette alle eksisterende indekser og installere nye. (groft sagt inventar og sætte alt i stand).
   Som parametre:
   • Valg af en målbase (dette vil ske i næsten alle opgaver, så jeg vil ikke være opmærksom på denne parameter yderligere i denne artikel).
   • Objekt, hvori vi vælger "Tabeller og visninger".
   • Muligheder Fri plads– til små mængder harddisk Du kan vælge "standard", men jeg anbefaler at bruge "Skift procentdelen af ​​ledig plads på siden", den anbefalede værdi er 20%. Dette giver dig mulighed for at forlade en reserve gratis sider, og giver dig mulighed for at beholde indekser længere nuværende tilstand. ADVARSEL: Forøger størrelsen af ​​databasen.
   • Sorter resultater i tempdb. Jeg tror, ​​der er ingen grund til at forklare, men jeg vil gerne advare dig om, at på dette tidspunkt vil tempdb vokse meget, selvom sortering i det er designet til at fremskynde processen, vær forsigtig, hav lidt plads tilbage.
   • At gemme indekset online er en funktion tilgængelig for virksomhedsversionen af ​​SQL. Giver dig mulighed for at genindeksere uden at afbryde klienter.

   !!! OPMÆRKSOMHED!!! I standardversionen afbrydes klienter fra databasen under genindeksering, så længe dette trin varer.

   Eksempelindstillinger

   
   

2. Statistik opdatering. Opgaven med at indsamle information om tilstanden af ​​indekser i databasen. (Generelt har det ringe relevans efter genindeksering, men jeg gør det stadig).
   Muligheder:
   • Et objekt. Alle de samme tabeller og visninger som til genopbygning af indekset.
   • Opdatering. Her opdaterer vi al statistik.
   • Visningstype – Fuld visning.

   På den måde opdaterer vi statistik på tværs af hele databasen.

   Eksempelindstillinger

   
   

3. Udførelse af en T-SQL-sætning. Dette er udførelsen af ​​en vilkårlig kommando på SQL sprog, vi er især interesserede i dbcc proccache

   Som navnet antyder, rydder cachen.

   Eksempel

   
   

4. Kontrol af databasens integritet. Det virker unødvendigt at forklare her – vi sørger for, at intet går i stykker. I parametrene "inkluder indekser" i checken var det ikke forgæves, at de blev genopbygget.

   Eksempelindstillinger

   
   

5. Database backup. Vi er nødt til at tale mere her, på grund af mange funktioner. Bedre studie denne vare separat i andre vejledninger giver formatet af denne artikel ikke mulighed for en dybdegående undersøgelse af backup.
   Men jeg vil gerne advare dig om et par nuancer:
   • SQL ved ikke, hvordan man renser sin beholder, så hvis du tilføjer sikkerhedskopier til en fil (det kaldes også en "Backup-enhed"), ender du med at fylde al den ledige plads op.
   • SQL husker det sikkerhedskopier, derfor, efter at have lavet en engangssikkerhedskopi manuelt (for eksempel for at tage databasen til et andet sted eller for at implementere den til en anden database fra sikkerhedskopien til test), vil den næste "forskel" blive talt fra den. For at forhindre dette skal du markere afkrydsningsfeltet "Kun sikkerhedskopiering". Der er ikke noget sådant element i backup-opgaven. Generelt i en ugeplan anbefaler jeg stadig at bruge den fulde type backup.
   • Og det ville være godt at tjekke kopien, så du kan sove bedre.
   • Kompression kan generelt bruges, men vær forsigtig, så skal differensværdier også komprimeres.

   Eksempelindstillinger

   

6. Rydning af loggen.
   • Sikkerhedskopiering og gendannelseslog.
   • SQL Server Agent joblog.
   • Vedligeholdelsesplan log.

   Jeg renser alt. Som navnet antyder, renser den hændelser i SQL-loggen. Jeg tror, ​​at begivenheder, der er ældre end 4 uger, sandsynligvis ikke vil interessere mig, for hvis der er et problem, så meld det inden for en måned.

   Eksempelindstillinger

   
   

7. Operatørmeddelelse. Peg igen for selvstudie. Men som navnet antyder, er det til at rapportere problemer under udførelsen af ​​planen.

Daglige

Generel form

Det giver ingen mening at tale separat. Næsten alt er det samme som Weekly.
Forskellen ligger i den første opgave - "Indeksreorganisering". Opgaverne adskiller sig ved, at omorganiseringen forsøger at rette op på de eksisterende indekser, frem for at gøre alt med ren tavle. Jo større fragmentering, jo oftere koster det at lancere. Men under normale forhold er en gang om dagen nok til at holde indekset opdateret indtil næste genopbygning.

Muligheder

Du kan også bruge differentiel backup.

Det er alt. Jeg gentager, jeg så ikke noget dogme på dette tidspunkt; denne mulighed blev udviklet og testet af mig. Relevant for databaser i størrelser fra 6 til 100 GB.

Jeg ønsker dig hurtigt og pålideligt arbejde.
P.S. På grund af at jeg ikke er en fuldgyldig DBA, måske mine kommentarer er meget overfladiske, vil jeg med glæde læse kommentarerne i kommentarerne og i PM.

I SQL Server 2016 og nyere versioner kan du installere alle R Services (i-database) relaterede komponenter ved hjælp af en guide SQL installationer Server.

Efter installationen er fuldført, skal du muligvis yderligere handlinger at aktivere R-tjenester, konfigurere konti og give brugere tilladelse til at få adgang til specifikke databaser.

Hvis du har problemer med at få adgang til databaserne efter installationen er fuldført, eller hvis du skal fjerne tidligere versioner, se afsnit.

Åben SQL miljø Server Management Studio. Hvis den ikke allerede er installeret, kan du køre SQL Server Setup Wizard igen for at downloade den fra linket og installere den.

Opret forbindelse til den instans, hvor R Services er installeret (i databasen), og kør følgende kommando for eksplicit at aktivere R Services-komponenten. Ellers vil du ikke være i stand til at kalde R-scripts, selvom komponenten blev installeret af installationsprogrammet.

Exec sp_configure "eksterne scripts aktiveret", 1 Genkonfigurer med tilsidesættelse

Genstart SQL Server-tjenesten for SQL Server-forekomsten. Relateret service SQL Server Trusted Launchpad genstarter også automatisk. Du kan genstarte tjenesten ved at bruge panelet Tjenester i Kontrolpanel eller ved at bruge SQL Server Configuration Manager.

Når SQL Server-tjenesten er tilgængelig, skal du kontrollere, om R er aktiveret ved at køre følgende kommando og kontrollere, om egenskaben er run_value værdi 1:

Exec sp_configure "eksterne scripts aktiveret"

Du kan også åbne panelet Tjenester og kontroller, om launchpad-tjenesten kører for din instans. Hvert eksemplar har egen service affyringsrampe.

Du skulle nu kunne køre i SQL Server Management Studio simple scripts 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

Hej
1

Installationsprocessen opretter 20 Windows-brugerkonti til at udføre opgaver med SQL Server Trusted Launchpad-tjenestesikkerhedstokenet. Når en bruger indsender et R-script fra en ekstern klient, aktiverer SQL Server en tilgængelig arbejdskonto, matcher den med den kaldende brugers identitet og udfører R-scriptet på brugerens vegne. Dette er en ny Database Engine-tjeneste, der giver sikker udførelse af eksterne scripts ved hjælp af en mekanisme kaldet implicit autentificering.

Konti kan ses i gruppen Windows-brugere SQLRUserGroup. Hvis du har brug for at køre R-scripts fra en ekstern datavidenskabsklient, og du bruger Windows-godkendelse, skal disse arbejdskonti have tilladelse til at logge på SQL Server-instansen på dine vegne.

1. Udvid i SQL Server Management Studio i Object Explorer Sikkerhed, Højreklik Log ind og vælg Opret login.
2. I dialogboksen Oprettelse af et login klik på knappen Søg.
3. Klik Objekttyper og vælg Grupper. Fravælg alle andre muligheder.
4. Indtast i feltet "Indtast objektnavn". SQLRUserGroup og klik Tjek navne.
5. Navnet på den lokale gruppe, der er knyttet til forekomstens launchpad-tjeneste, skal løses til instansnavn\SQLRUserGroup. Klik på knappen Okay.
6. Som standard er loginnavnet tildelt offentligt tilgængelig roller og har tilladelse til at oprette forbindelse til DBMS-kernen.
7. Klik på knappen Okay.

Hvis du selv har installeret SQL Server og kører R-scripts i din egen instans, gør du det typisk med administrative rettigheder og har derfor eksplicit tilladelse til at udføre forskellige operationer og få adgang til alle data i databasen, samt mulighed for at installere nye R-pakker pr. efter behov.

Men i et virksomhedsscenarie har de fleste brugere, inklusive dem, der får adgang til databasen ved hjælp af SQL-logins, ikke sådanne forhøjede rettigheder. Derfor skal hver bruger, der skal udføre eksterne scripts, have tilladelse til at udføre R-scripts på hver database, hvori R vil blive brugt.

BRUG GÅ TILDELING UDFØR ENHVER EKSTERNT SCRIPT TIL

Dette afsnit beskriver yderligere ændringer, du kan foretage til instanskonfigurationen, eller, hvis du bruger en datavidenskabsklient, ændringer for at aktivere R-scripts til at køre.

Skift antallet af arbejdskonti, der bruges af SQL Server Trusted Launchpad

Hvis du forventer at bruge R-miljøet meget eller har mange brugere, der kører scripts på samme tid, kan du øge antallet af arbejdskonti, der er tildelt Launchpad-tjenesten. For mere information, se.

Giv R-brugere eller login de nødvendige læse-, skrive- eller DDL-tilladelser på yderligere databaser

Når du kører R-scripts, skal en brugerkonto muligvis læse data fra andre databaser, oprette tabeller for at gemme resultaterne og skrive data til tabeller.

Hver brugerkonto, der kører R-scripts, skal have tilladelser db_datalæser, db_datawriter eller db_ddladmin for en bestemt database.

For eksempel giver følgende Transact-SQL-sætning SQL-login MySQLLogin rettigheder til at udføre T-SQL-forespørgsler på databasen RSampler. For at fuldføre denne sætning skal SQL-logonet allerede eksistere i serverens sikkerhedskontekst.

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

For mere information om de tilladelser, der er inkluderet i hver rolle, se .

Opret en ODBC-datakilde for en forekomst i datavidenskabsklienten

Hvis du bygger en R-løsning på en datavidenskabsklientmaskine, og du skal oprette forbindelse til SQL Server-maskinen, der tjener som beregningskontekst, kan du bruge SQL-login eller integreret Windows-godkendelse.

Når du bruger et SQL-login, skal det have passende tilladelser til databasen, hvorfra dataene skal læses. For at gøre dette kan du tilføje tilladelser Forbinde til Og VÆLG eller tilføje login til rollen db_datalæser. Hvis du har brug for at oprette objekter, skal du have tilladelser DDL_admin. For at gemme data i tabeller skal du tilføje et login til rollen db_datawriter.

Hvis du bruger Windows-godkendelse, skal du konfigurere ODBC-datakilden i datavidenskabsklienten med instansnavnet og andre forbindelsesoplysninger.

For mere information, se.

Serveroptimering til R

Standardindstillingerne for SQL Server Setup er designet til at optimere udførelsen af ​​forskellige tjenester, der understøttes af databasemotoren på serveren, herunder udtræks-, transformations- og indlæsningsprocesser, rapportering, revision og applikationer, der forbruger SQL Server-data. Derfor, når du bruger standardindstillinger, kan ressourcer til R-operationer være begrænsede eller formindsket, især for hukommelsesintensive operationer.

For at sikre, at R-opgaver tildeles de rette prioriteter og allokeres de nødvendige ressourcer, anbefaler vi at bruge værktøjet Resource Governor til at konfigurere en ekstern ressourcepulje til R-operationer. Du kan også ændre mængden af ​​hukommelse, der er allokeret til SQL Server Database Engine eller øge antallet af konti i Trusted Launchpad-tjenesten SQL Server.

Kompatibel med RC2 version: download arkiv rre-gpl-src.8.0.2.tar.gz

Kompatibel med RC3 version: download arkiv rre-gpl-src.8.0.3.tar.gz

Kompatibel med RTM-version: download arkiv rre-gpl-src.8.0.3.tar.gz

Har du problemer? Gennemgå listen over almindelige problemer, når du installerer forhåndsvisningsversioner af R Services (i databasen).