Võtke ette Accessi ekskursioon läbi SQL Serveri

Draivi jätkusuutlikkus

Accessi lahenduse puhul soovite, et selle töötamise jooksul esineks võimalikult vähe katkestusi, kuid Accessi tagaandmebaasi võimalused on piiratud. Andmete kaitsmiseks on oluline Accessi andmebaasi varundada, kuid selleks on vaja viia kasutajad võrgust välja. Esineb ka planeerimata seisakuaeg, mida põhjustavad riistvara/tarkvara hooldustäiendused, võrgu- või elektrikatkestused, riistvaratõrked, turbemurded või isegi küberrünnakud. Selleks et minimeerida seisakuaega ja selle mõju teie ärile, saate SQL Serveri andmebaasi selle kasutamise ajal varundada. Lisaks pakub SQL Server ka suure kättesaadavuse (HA) ja avariijärgse taaste (DR) strateegiaid. Neid kahte kombineeritud tehnoloogiat nimetatakse HADR-iks. Lisateavet leiate artiklitest Jätkusuutlikkus ja andmebaasitaaste ning Draivi jätkusuutlikkus koos SQL Serveriga (e-raamat).

Varundamine kasutamise ajal

SQL Server kasutab võrgus varundamise protsessi, mis võib esineda andmebaasi töötamise ajal. Saate teha täieliku varukoopia, osalise varukoopia või faili varukoopia. Selleks et tagada täielik taastetoiming, teeb varundamine koopiad andmetest ja tehingulogidest. Kohapealse lahenduse puhul tuleb eriti silmas pidada erinevusi lihtsate ja täielike taastesuvandite vahel ning kuidas need mõjutavad tehingulogi kasvu. Lisateavet leiate artiklistVarundamise mudelid.

Enamik varundustoiminguid toimub kohe, v.a failihalduse ja andmebaasi kahandamise toimingud. Kui proovite andmebaasifaili luua või kustutada varundustoimingu ajal, siis toiming nurjub. Lisateavet leiate artiklist Varundamise ülevaade.

HADR

Kaks levinumat meetodit suure kättesaadavuse ja jätkusuutlikkuse saavutamiseks on peegeldamine ja klasterdamine. SQL Server integreerib peegeldamise ja klasterdamise tehnoloogiat funktsioonidega „Always On Failover Cluster Instances“ ja „Always On Availability Groups“.

Peegeldamine on andmebaasitasemel järjepidevuslahendus, mis toetab kohe rikkeümberlülitust, säilitades ooteandmebaasi, täielikku koopiat või aktiivset peegelandmebaasi eraldi riistvaral. See võib toimida sünkroonrežiimis (väga turvalises), kus sissetulev tehing on pühendunud samal ajal kõigile serveritele, või asünkroonrežiimis (suure jõudlusega), kus sissetulev tehing on pühendunud aktiivsele andmebaasile ning seejärel kopeeritakse see varem kindlaks määratud hetkel peegelandmebaasi. Peegeldamine on andmebaasitasemel lahendus ja see töötab ainult andmebaasides, mis kasutavad täielikku taastemudelit.

Klasterdamine on serveritasemel lahendus, mis ühendab servereid ühte andmete salvestusruumi, mis näib kasutajale üksikeksemplarina. Kasutajad saavad luua ühenduse eksemplariga ega pea teadma, milline server on selles eksemplaris parajasti aktiivne. Kui ühes serveris esineb tõrge või peab sellega hoolduse eesmärgil ühenduse katkestama, ei muutu kasutuskogemus. Igat klastris olevat serverit jälgib talitlusimpulssi kasutades klastrihaldur, mis avastab, millal klastris oleva aktiivse serveriga ühendus katkeb, ja üritab sujuvalt vahetada järgmisele klastris olevale serverile. Vahetuse ajal esineb viivitus.

Lisateavet leiate artiklitest Always On Failover Cluster Instances ja Saadavusrühmad Always On: suure kättesaadavuse ja avariijärgse taaste lahendus.

Lehe algusse

SQL Serveri turve

Ehkki Accessi andmebaasi on võimalik kaitsta usalduskeskuse abil ja andmebaasi krüptimisega, on SQL Serveris rohkem täiustatud turvafunktsioone. Allpool on toodud kolm võimalust, mis on Accessi kasutajale olulised. Lisateavet leiate artiklist SQL Serveri turvamine.

Andmebaasi autentimine

SQL Serveris on neli andmebaasi autentimise meetodit. Igat neist saab täpsustada ODBC-ühenduse stringis. Lisateavet leiate artiklist Azure’i SQL Serveri andmebaasist andmete importimine või nendega linkimine. Igal meetodil on oma eelised.

Integreeritud Windowsi autentimine    Kasutage kasutaja kinnitamiseks, turberollideks ning kasutajate juurdepääsu piiramiseks funktsioonidele ja andmetele Windowsi identimisteavet. Saate kasutada ära domeeni identimisteavet ja hõlpsasti hallata oma rakenduses kasutaja õigusi. Soovi korral saatel valida teenusesubjekti nimesid (SPN-id). Lisateavet leiate artiklist Autentimisrežiimi valimine.

SQL Serveri autentimine    Kasutajad peavad ühenduse looma andmebaasis häälestatud identimisteabe abil, sisestades seansi ajal esimest korda andmebaasi sisenedes sisselogimise ID ja salasõna. Lisateavet leiate artiklist Autentimisrežiimi valimine.

Azure Active Directory integreeritud autentimine    Saate Azure SQL Serveri andmebaasiga ühenduse luua Azure Active Directory kaudu. Kui olete konfigureerinud Azure Active Directory autentimise, ei pea te enam täiendavalt sisse logima ega parooli kasutama. Lisateavet leiate artiklist SQL-andmebaasiga ühenduse loomine Azure Active Directory autentimise kaudu.

Active Directory parooli autentimine    Saate ühenduse luua Azure Active Directorys häälestatud identimisteabe abil, sisestades sisselogimisnime ja parooli. Lisateavet leiate artiklist SQL-andmebaasiga ühenduse loomine Azure Active Directory autentimise kaudu.

Näpunäide    Selleks et saada teatisi anomaalse andmebaasi tegevuse kohta, mis viitab potentsiaalsetele Azure’i SQL Serveri turbeohtudele, kasutage ohuavastust. Lisateavet leiate artiklist SQL-andmebaasi ohuavastus.

Rakenduse turve

SQL Serveris on kaks rakendusetasemel turbefunktsiooni, mida saab Accessis kasutada.

Andmete dünaamiline maskimine    Peitke delikaatset infot, maskides seda kasutajate eest, kellel pole õigusi. Näiteks saate maskida nii osaliselt kui ka täielikult sotsiaalkindlustuse numbrit.

Andmete osaline maskimine

Andmete täielik maskimine

Andmete maski määratlemiseks on mitu võimalust ja neid saab rakendada ka eri andmetüüpide puhul. Andmete maskimine on kindlaks määratud kasutajatele tabeli- ja veerutasemel poliitikapõhine ning seda kohaldatakse päringule reaalajas. Lisateavet leiate artiklist Andmete dünaamiline maskimine.

Reatasemel turve    Selleks et kontrollida juurdepääsu kindlatele andmebaasi ridadele, kus on delikaatset informatsiooni, saate kasutaja tunnustel põhinedes kasutada reatasemel turvet. Andmebaasisüsteem rakendab juurdepääsupiiranguid, mis muudavad turbesüsteemi usaldusväärsemaks ja töökindlamaks.

Turbepredikaate on kaks:

• Filtripredikaat filtreerib ridasid päringust. Filter on läbipaistev ja lõppkasutaja pole ühestki filtreerimisest teadlik.

• Blokipredikaat takistab volitamata toiminguid ja kui toimingut ei saa sooritada, annab erandi.

Lisateavet leiate artiklist Reatasemel turve.

Andmete kaitsmine krüptimise abil

Andmeid saab jõudeolekus, edastamisel ja kasutamise ajal kaitsta ilma andmebaasi jõudlust mõjutamata. Lisateavet leiate artiklist SQL Serveri krüptimine.

Krüptimine jõudeolekus    Selleks et kaitsta isikuandmeid ühenduseta andmekandja rünnakute eest füüsilise salvestusruumi kihil, kasutage krüptimist jõudeolekus, mida nimetatakse ka läbipaistvaks andmekrüptimiseks (Transparent Data Encryption, TDE). See tähendab, et andmed on kaitstud isegi siis, kui füüsiline andmekandja varastatakse või see likviteeritakse valesti. TDE krüptib ja dekrüptib reaalajas andmebaase, varukoopiaid ja tehingulogisid, ilma et rakenduses oleks vaja teha muudatusi.

Krüptimine edastamisel    Selleks et kaitsta oma andmeid nuhkimis- ja vahendusründe eest, saate krüptida üle võrgu edastatavaid andmeid. Pakkumaks väga turvalist suhtlust, toetab SQL Server transpordikihi turvet (Transport Layer Security, TLS) 1.2. Ebausaldusväärsetes võrkudes suhtluse kaitsmiseks kasutatakse ka tabelina esitatud andmevoo (Tabular Data Stream, TDS) protokolli.

Krüptimine kasutamise ajal kliendis    Kui tahate kaitsta isikuandmeid kasutamise ajal, siis kasutage funktsiooni Always Encrypted (alati krüptitud). Draiver krüptib ja dekrüptib klientarvutis isikuandmeid, kuid ei avalda andmebaasimootorile krüptimisvõtmeid. Seetõttu on näevad krüptitud andmeid vaid inimesed, kes vastutavad andmete haldamise eest. Teised suurte õigustega kasutajad, kellel pole andmetele juurdepääsu, neid ei näe. Olenevalt valitud krüptimistüübist võib funktsioon Always Encrypted mõnda andmebaasifunktsiooni, nt otsimine, rühmitamine ja krüptitud veergude indekseerimine, piirata.

Lehe algusse

Privaatsusega seotud probleemide lahendamine

Privaatsusega seotud probleemid on nii levinud, et Euroopa Liit on määratlenud isikuandmete kaitse üldmääruse (GDPR) kaudu õiguslikud nõuded. Õnneks vastab SQL Serveri tagasüsteem neile nõuetele. Isikuandmete kaitse üldmäärust rakendatakse kolme sammu abil.

1. samm: Nõuetele vastavuse riski hindamine ja haldamine

Isikuandmete kaitse üldmäärus nõuab, et tuvastaksite ja inventeeriksite tabelites ja failides olevaid isikuandmeid. Need andmed võivad olla näiteks nimi, foto, meiliaadress, pangaandmed, postitused sotsiaalmeedias, terviseandmed ja isegi IP-aadress.

Uus SQL Server Management Studiosse integreeritud tööriist SQL-andmete tuvastamine ja klassifikatsioon aitab tuvastada, klassifitseerida, sildistada ja raporteerida delikaatseid andmeid, rakendades veergudele kahte metaandmete atribuuti:

• Sildid    Andmete tundlikkuse määratlemiseks.

• Teabetüübid    Pakkumaks lisagranulaarsust veerus salvestatud andmetüüpide kohta.

Võite kasutada ka täistekstiotsingut, mis sisaldab funktsioonide CONTAINS ja FREETEXT predikaatide kasutamist ning selliseid reakomplektipõhiseid funktsioone nagu CONTAINSTABLE ja FREETEXTTABLE, mida saab kasutada lausega SELECT. Täistekstiotsingu abil saate otsida tabelitest sõnu, sõnakombinatsioone või sõnavariatsioone, nagu näiteks sünonüümid ja muutelõppudega vormid. Lisateavet leiate artiklist Täistekstiotsing.

2. samm: Isikuandmete kaitsmine

Isikuandmete kaitse üldmäärus nõuab, et kaitseksite isikuandmeid ja piiraksite juurdepääsu nendele. Peale tavaliste sammude, mida kasutate oma võrgule ja ressurssidele juurdepääsu haldamiseks (nt tulemüüri sätted), saate andmetele ligipääsu juhtimiseks kasutada ka järgmisi SQL Serveri turbefunktsioone:

• SQL Serveri autentimine, mis aitab hallata kasutaja identiteeti ja ennetada volitamata juurdepääsu.

• Reatasemel turve, mis aitab piirata juurdepääsu tabeli ridadele. See põhineb kasutaja ja andmete vahelisel seosel.

• Andmete dünaamiline maskimine, mis aitab piirata isikuandmete avaldamist, maskides need õigusteta kasutajate eest.

• Krüptimine, mis tagab, et isikuandmed on ülekande ja salvestamise ajal kaitstud ning kaitstud ka turvarikke (sh serveripoolse) eest.

Lisateavet leiate artiklist SQL Serveri turve.

3. samm: Päringutele tõhusalt reageerimine

Isikuandmete kaitse üldmäärus nõuab, et säilitaksite isikuandmete töötlemise kirjed ning teeksite kirjed järelevalveasutuse nõude korral neile ligipääsetavaks. Kui tekib tõrkeid, nt juhuslik andmete avaldamine, võimaldavad kaitsekontrollid kiirelt reageerida. Aruande edastamiseks peavad andmed olema kiiresti saadaval. Näiteks nõuab isikuandmete kaitse üldmäärus, et isikuandmete turbemurdest antakse järelevalveasutusele teada „mitte hiljem kui 72 tunni jooksul pärast sellest teadasaamist“.

SQL Server 2017 aitab teid teatamise juures mitmel eri viisil:

• SQL Server Audit aitab tagada, et saadaval on andmebaasipääsu ja andmebaasi töötlemise toimingute püsikirjed. See sooritab täpselt määratletud auditi, mis jälgib andmebaasitoiminguid ning aitab mõista ja määratleda potentsiaalseid ohte, kuritarvituse kahtlusi või turberikkumisi. Saate hõlpsasti sooritada andmeekspertiisi.

• SQL Serveri ajalised tabelid on süsteemi versioonitud kasutajatabelid, mille eesmärk on talletada kogu andmete muutmiste ajalugu. Saate neid kasutada lihtsaks aruandluseks ja ajapunktipõhiseks analüüsiks.

• SQL Vulnerability Assessment aitab tuvastada turbe- ja õiguseprobleeme. Kui tuvastatakse probleem, saate minna süvitsi andmebaasiskanni aruannetesse, et leida selle lahendamiseks võimalusi.

Lisateavet leiate järgmistest allikatest: Looge usaldusplatvorm (e-raamat) ja Isikuandmete kaitse üldmääruse täitmise teekond.

Lehe algusse

Andmebaasi hetktõmmiste loomine

Andmebaasi hetktõmmis on SQL Serveri andmebaasi kirjutuskaitstud staatiline vaade mingil kindlal ajahetkel. Kuigi andmebaasi hetktõmmise loomiseks on võimalik Accessi andmebaasifaili kopeerida, pole Accessil sellist integreeritud metoodikat nagu SQL Serveril. Andmebaasi hetktõmmist saab kasutada selleks, et kirjutada aruannet, mis põhineb andmebaasi hetktõmmise loomise ajal esinenud andmetel. Samuti saate andmebaasi hetktõmmist kasutada selleks, et säilitada ajaloolisi andmeid, näiteks iga finantskvartali jaoks ühte, mida kasutatakse perioodilõpu aruannete kokkuvõtteks. Soovitame järgmisi parimaid tavasid:

• Hetktõmmise nimi    Iga andmebaasi hetktõmmise jaoks on vaja kordumatut andmebaasi nime. Hõlpsamaks tuvastamiseks lisage nimele eesmärk ja ajavahemik. Näiteks, kui soovite teha AdventureWorksi andmebaasist hetktõmmist kolm korda päevas vahemikus kella 6.00–18.00 iga kuue tunni järel, pange neile nimeks AdventureWorks_snapshot_0600, AdventureWorks_snapshot_1200 ja AdventureWorks_snapshot_1800.

• Hetktõmmiste arvu piiramine    Iga andmebaasi hetktõmmis püsib seni, kuni sellest selgelt loobutakse. Kuna iga hetktõmmis kasvab edasi, võib juhtuda, et soovite kettaruumi säästa, kustutades vanema hetktõmmise pärast uue hetktõmmise loomist. Näiteks kui teete aruandeid iga päev, hoidke andmebaasi hetktõmmist alles 24 tundi ning seejärel loobuge sellest ja asendage hetktõmmis uuega.

• Ühenduse loomine õige hetktõmmisega    Selleks et kasutada andmebaasi hetktõmmist, peab Accessi eesserver teadma selle õiget asukohta. Kui asendate olemasoleva hetktõmmise uuega, peate Accessi ümber suunama uue hetktõmmise juurde. Kui soovite veenduda, et loote ühenduse õige andmebaasi hetktõmmisega, lisage Accessi tagaserverisse loogikat.

Andmebaasi hetktõmmise loomine:

CREATE DATABASE AdventureWorks_dbss1800 ON  
( NAME = AdventureWorks_Data, FILENAME =   
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\AdventureWorks_snapshot_0600' )  
AS SNAPSHOT OF AdventureWorks;  

Lisateavet leiate artiklist Andmebaasi hetktõmmised (SQL Server).

Lehe algusse

Samaaegsuse juhtimine

Kui mitu inimest proovib andmebaasis andmeid samal ajal muuta, on vaja kontrollisüsteemi, mis tagab, et ühe inimese tehtud muudatused ei mõjuta teise inimese muudatusi ebasoodsalt. Seda nimetatakse samaaegsuse juhtimiseks, mille puhul esineb kaks peamist lukustamise strateegiat: optimistlik ja pessimistlik. Lukustamise abil saab takistada kasutajaid muutmast andmeid nii, et see mõjutaks teisi kasutajaid. Peale selle aitab lukustamine tagada andmebaasi tervikluse, eriti nende päringute puhul, mis võivad muidu anda ootamatuid tulemeid. Selles, kuidas Access ja SQL Server samaaegsuse juhtimise strateegiaid rakendavad, on olulisi erinevusi.

Accessis on lukustamise strateegia vaikimisi optimistlik ja annab esimesele inimesele, kes proovib kirjesse kirjutada, lukustamise omandiõiguse. Access kuvab järgmisele inimesele, kes proovib samal ajal samasse kirjesse kirjutada, dialoogiboksi Write Conflict (Kirjutuskonflikt). Konflikti lahendamiseks võib teine inimene kirje salvestada, kopeerida selle lõikelauale või muudatustest loobuda.

Samaaegsuse juhtimise strateegiate muutmiseks saab kasutada ka atribuutiRecordLocks. See atribuut mõjutab vorme, aruandeid ja päringuid ning sellel on kolm sätet:

• No Locks (Lukke pole)    Vormi korral saavad kasutajad proovida sama kirjet ühel ajal redigeerida, kuid ilmuda võib dialoogiboks Write Conflict (Kirjutuskonflikt). Aruannetes olevaid kirjeid aruande eelvaate või printimise ajaks ei lukustata. Päringu kirjeid ei lukustata päringu käitamise ajaks. See on Accessi viis rakendada optimistlikku lukustamist.

• All Records (Kõik kirjed)    Kõik aluseks oleva tabeli või päringu kirjed lukustatakse aruande eelvaate ja printimise või päringu sooritamise ajaks, kui vorm on avatud vormi- või andmelehevaates. Kasutajad saavad lukustamise ajal andmeid lugeda.

• Edited Record (Redigeeritud kirje)    Vormide ja päringute puhul lukustatakse kirjetega leht kohe, kui mõni kasutaja alustab kirje suvalise välja redigeerimist, ning hoitakse lukus, kuni kasutaja siirdub mõne muu kirje juurde. Seega saab kirjet redigeerida korraga ainult üks kasutaja. See on Accessi moodus rakendada pessimistlikku lukustamist.

Lisateavet leiate artiklitest Dialoogiboks Write Conflict (Kirjutuskonflikt) ja Atribuut RecordLocks.

SQL Serveris töötab samaaegsuse juhtimine järgmiselt:

• Pessimistlik    Pärast seda, kui kasutaja on sooritanud toimingu, mis põhjustab lukustamise, ei saa teised kasutajad sooritada toiminguid, mis lähevad lukustusega konflikti, kuni omanik luku vabastab. Sellist samaaegsuse juhtimist kasutatakse peamiselt keskkondades, kus on suur andmekonfliktide arv.

• Optimistlik    Optimistliku samaaegsuse juhtimise puhul ei lukusta kasutajad andmeid nende lugemise ajal. Kui kasutaja andmeid värskendab, siis süsteem kontrollib, kas teine kasutaja on pärast andmete lugemist neid muutnud. Kui teine kasutaja on andmeid värskendanud, tekib tõrge. Tavaliselt pöörab tõrke saanud kasutaja tehingu tagasi ja alustab uuesti. Sellist samaaegsuse juhtimist kasutatakse peamiselt keskkondades, kus on väike andmekonfliktide arv.

Saate määrata samaaegsuse juhtimise tüübi, valides mitu tehingu isoleerimistaset, mis kehtestavad tehingu kaitsetaseme. Selle määravad teiste tehingute tehtud muudatused, kasutades lauset SET TRANSACTION:

 SET TRANSACTION ISOLATION LEVEL
 { READ UNCOMMITTED
    | READ COMMITTED
    | REPEATABLE READ  
    | SNAPSHOT
    | SERIALIZABLE
 }

Lisateavet leiate artiklist Tehingu lukustamise ja rea versioonimise juhend.

Lehe algusse

Päringu jõudluse parandamine

Pärast seda, kui teie Accessi läbiv päring on hakanud tööle, kasutage ära SQL Serveri keerukamaid võimalusi, mis parandavad efektiivsust.

Erinevalt Accessi andmebaasist pakub SQL Server paralleelpäringuid, mis aitavad arvutite puhul, millel on rohkem kui üks mikroprotsessor (CPU), optimeerida päringute täitmis- ja indekseerimistoiminguid. Kuna SQL Server saab mitut süsteemi töölõime kasutades sooritada päringu- või indekseerimistoiminguid paralleelselt, on võimalik toiming lõpetada kiirelt ja efektiivselt.

Päringud on olulised komponendid, mis aitavad parandada andmebaasilahenduse üldist jõudlust. Halvad päringud käitavad lõputult, aeguvad ning kasutavad ära ressursid, nagu näiteks protsessorid, mälu ja Network BANDIT-i. See takistab omakorda olulise äriteabe kättesaadavust. Isegi ainult üks halb päring võib andmebaasile tekitada tõsiseid jõudlusprobleeme.

Lisateavet leiate artiklist Kiiremad päringud koos SQL Serveriga (e-raamat).

Päringu optimeerimine

Päringu jõudluse analüüsimiseks ja parandamiseks kasutatakse korraga mitut tööriista: päringuoptimeerijat, käivitamisplaane ja päringusalve.

Päringuoptimeerija

Päringuoptimeerija on SQL Serveri üks kõige olulisemaid komponente. Päringuoptimeerija abil saab päringut analüüsida ja määrata kindlaks kõige efektiivsem viis vajalikele andmetele ligipääsemiseks. Päringuoptimeerija sisend koosneb päringust, andmebaasi skeemist (tabeli- ja indeksimääratlus) ning andmebaasi statistikast. Päringuoptimeerija väljund on käivitamisplaan.

Lisateavet leiate artiklist SQL Serveri päringuoptimeerija.

Käivitamisplaan

Käivitamisplaan on määratlus, mis järjestab lähtetabelid, kuhu peab juurde pääsema, ning meetodid, mida kasutati igast tabelist andmete ekstraktimiseks. Optimeerimine on protsess, mille käigus valitakse mitme võimaliku plaani hulgast üks käivitamisplaan. Igal võimalikul käivitamisplaanil on seostatud kulu, mis oleneb kasutatud arvutusressurside hulgast, ning päringuoptimeerija valib selle, millel on kõige väiksem eeldatav kulu.

SQL Server peab ka dünaamiliselt kohanema andmebaasis olevate tingimuste muutmise järgi. Päringu käivitamisplaanis esinevad regressioonid võivad jõudlust tugevalt mõjutada. Olenevalt andmebaasi uuest olekust võivad andmebaasi teatud muudatused põhjustada seda, et käivitamisplaan muutub ebaefektiivseks või kehtetuks. SQL Server tuvastab muudatused, mis muudavad käivitamisplaani kehtetuks, ning märgib plaani kehtetuks.

Seejärel peab järgmise ühenduse tarvis, mis päringu käivitab, uuesti kompileerima uue plaani. Tingimused, mis muudavad plaani kehtetuks, on:

• Päringu viidatud muudatused, mis on tehtud tabelile või vaatele (ALTER TABLE ja ALTER VIEW).

• Muudatused indeksites, mida kasutab käivitamisplaan.

• Värskendused statistikas, mida kasutab käivitamisplaan. Need on loodud kas selgelt lausest, näiteks UPDATE STATISTICS, või automaatselt.

Lisateavet leiate artiklist Käivitamisplaanid.

Päringusalv

Päringusalv annab ülevaate käivitamisplaani valikust ja jõudlusest. See lihtsustab jõudluse tõrkeotsingut, aidates kiiresti tuvastada jõudluserinevusi, mida põhjustavad käivitamisplaani muudatused. Päringusalv kogub telemeetriaandmeid, näiteks päringute ajalugu, plaane, käitusajastatistikat ja ooteajastatistikat. Päringusalve rakendamiseks kasutage lauset ALTER DATABASE:

ALTER DATABASE AdventureWorks2012 SET QUERY_STORE = ON;

Lisateavet leiate artiklist Jõudluse jälgimine päringusalve kasutades.

ALTER DATABASE [YourDatabaseName] SET COMPATIBILITY_LEVEL = 140;

Päringuviisid

SQL Serveris saab päringuid teha mitmel viisil ja neil kõigil on oma eelised. Neid on kasulik teada, sest siis saate teha oma Accessi lahenduse jaoks õige valiku. Kõige parem viis luua TSQL-i päringuid on neid interaktiivselt redigeerida ja testida, kasutades SQL Server Management Studio (SSMS) Transact-SQL-i redaktorit, mille funktsioon IntelliSense aitab valida õigeid võtmesõnu ja kontrollida süntaksivigu.

Vaated

SQL Serveris on vaade nagu virtuaaltabel, kus vaate andmed pärinevad ühest või mitmest tabelist või muudest vaadetest. Sellegipoolest viidatakse vaadetele päringutes samamoodi nagu tabelitele. Vaated võivad peita päringute keerukust ja kaitsta andmeid, piirates ridade ja veergude kogumit. Siin on näide lihtsast vaatest:

CREATE VIEW HumanResources.EmployeeHireDate AS  
SELECT p.FirstName, p.LastName, e.HireDate  
FROM HumanResources.Employee AS e JOIN Person.Person AS p  
ON e.BusinessEntityID = p.BusinessEntityID;

Optimaalse jõudluse tagamiseks ja vaate tulemite redigeerimiseks looge indekseeritud vaade, mis püsib andmebaasis nagu tabel, millele on eraldatud salvestusruum ja mida saab päringusse kaasata nagu mis tahes tabelit. Kui soovite seda Accessis kasutada, siis linkige sellele samamoodi nagu lingite tabelile. Siin on näide indekseeritud vaatest:

CREATE VIEW Sales.vOrders  
WITH SCHEMABINDING  
AS  
    SELECT SUM(UnitPrice*OrderQty*(1.00-UnitPriceDiscount)) AS Revenue,  
        OrderDate, ProductID, COUNT_BIG(*) AS COUNT  
    FROM Sales.SalesOrderDetail AS od, Sales.SalesOrderHeader AS o  
    WHERE od.SalesOrderID = o.SalesOrderID  
    GROUP BY OrderDate, ProductID;  

CREATE UNIQUE CLUSTERED INDEX IDX_V1   
    ON Sales.vOrders (OrderDate, ProductID);  

Siiski on olemas teatud piirangud. Te ei saa andmeid värskendada, kui mõjutatud on rohkem kui üks alustabel või kui vaade sisaldab kokkuvõttefunktsiooni või DISTINCT-klauslit. Kui SQL Server annab tõrketeate, mis ütleb, et ei tea, millist kirjet kustutada, siis võib juhtuda, et peate vaatesse lisama kustutuspäästiku. Samuti ei saa te kasutada ORDER BY-klauslit nagu Accessi päringu puhul.

Lisateavet leiate artiklitest Vaated ja Indekseeritud vaadete loomine.

Salvestatud protseduurid

Salvestatud protseduur on rühm ühest või mitmest TSQL-i lausest, mis võtavad sisendparameetreid, tagastavad väljundparameetreid ja näitavad oleku väärtust kasutades edu või nurjumist. Need toimivad vahekihina Accessi eesserveri ja SQL Serveri tagaserveri vahel. Salvestatud protseduurid võivad olla sama lihtsad kui SELECT-lause või sama keerukad kui mis tahes programm. Üks näide on toodud siin:

CREATE PROCEDURE HumanResources.uspGetEmployees   
    @LastName nvarchar(50),   
    @FirstName nvarchar(50)   
AS   
    SET NOCOUNT ON;  
    SELECT FirstName, LastName, Department  
    FROM HumanResources.vEmployeeDepartmentHistory  
    WHERE FirstName = @FirstName AND LastName = @LastName  
    AND EndDate IS NULL;  

Kui kasutate salvestatud protseduuri Accessis, siis tagastatakse tavaliselt tulem, mis on vormile või aruandele tagasi seatud. Siiski võib see sooritada muid toiminguid, mis ei tagasta tulemeid (nt DDL- või DML-laused). Läbiva päringu kasutamisel veenduge, et määrate atribuudi Returns Records (Tagastab kirjed) sobivalt.

Lisateavet leiate artiklist Salvestatud protseduurid.

Levinud tabeliavaldised

Levinud tabeliavaldised (Common Table Expressions, CTE) on justkui ajutine tabel, mis loob nimega tulemite kogumi. See on olemas ainult ühe päringu või DML-lause täitmiseks. CTE on integreeritud samale koodireale kui SELECT-lause või DML-lause, mis seda kasutab, samas kui ajutise tabeli või vaate loomine ja kasutamine on tavaliselt kaheetapiline protsess. Üks näide on toodud siin:

-- Define the CTE expression name and column list.  
WITH Sales_CTE (SalesPersonID, SalesOrderID, SalesYear)  
AS  
-- Define the CTE query.  
(  
    SELECT SalesPersonID, SalesOrderID, YEAR(OrderDate) AS SalesYear  
    FROM Sales.SalesOrderHeader  
    WHERE SalesPersonID IS NOT NULL  
)  
-- Define the outer query referencing the CTE name.  
SELECT SalesPersonID, COUNT(SalesOrderID) AS TotalSales, SalesYear  
FROM Sales_CTE  
GROUP BY SalesYear, SalesPersonID  
ORDER BY SalesPersonID, SalesYear;

CTE-l on mitu eelist, sealhulgas:

• Kuna CTE-d on ajutised, siis pole vaja neid luua kui püsivaid andmebaasiobjekte, näiteks nagu vaateid.

• Samale CTE-le on võimalik päringus või DML-lauses viidata rohkem kui üks kord, mistõttu on kood lihtsamini hallatav.

• Kursori määratlemiseks saab kasutada päringuid, mis viitavad CTE-le.

Lisateavet leiate artiklist WITH common_table_expression.

Kasutaja määratletud funktsioonid (UDF)

Kasutaja määratletud funktsioon (user-defined function, UDF) saab teha päringuid ja arvutusi ning tagastada kas skalaarväärtusi või andmetulemite kogumeid. Need on samasugused nagu funktsioonid programmeerimiskeeltes, mis aktsepteerivad parameetreid, sooritavad selliseid toiminguid nagu keerukad kalkulatsioonid ja tagastavad selle toimingu tulemi väärtusena. Üks näide on toodud siin:

CREATE FUNCTION dbo.ISOweek (@DATE datetime)  
RETURNS int WITH SCHEMABINDING -- Helps improve performance
WITH EXECUTE AS CALLER  
AS  
BEGIN  
     DECLARE @ISOweek int;  
     SET @ISOweek= DATEPART(wk,@DATE)+1  
          -DATEPART(wk,CAST(DATEPART(yy,@DATE) as CHAR(4))+'0104');  
-- Special cases: Jan 1-3 may belong to the previous year  
     IF (@ISOweek=0)   
          SET @ISOweek=dbo.ISOweek(CAST(DATEPART(yy,@DATE)-1   
               AS CHAR(4))+'12'+ CAST(24+DATEPART(DAY,@DATE) AS CHAR(2)))+1;  
-- Special case: Dec 29-31 may belong to the next year  
     IF ((DATEPART(mm,@DATE)=12) AND   
          ((DATEPART(dd,@DATE)-DATEPART(dw,@DATE))>= 28))  
          SET @ISOweek=1;  
     RETURN(@ISOweek);  
END;  
GO  
SET DATEFIRST 1;  
SELECT dbo.ISOweek(CONVERT(DATETIME,'12/26/2004',101)) AS 'ISO Week';  

UDF-il on teatud piirangud. Näiteks ei saa nad kasutada teatud mittedeterministlikke süsteemifunktsioone, rakendada DML- või DDL-lauseid ega teha dünaamilisi SQL-päringuid.

Lisateavet leiate artiklist Kasutaja määratletud funktsioonid.

Lehe algusse

Võtmete ja indeksite lisamine

Olenemata sellest, millist andmebaasisüsteemi kasutatakse, käivad võtmed ja indeksid käsikäes.

Võtmed

SQL Serveris tuleb veenduda, et iga tabeli jaoks luuakse primaarvõtmed ja iga seotud tabeli jaoks välisvõtmed. SQL Serveris on Accessi automaatnumbri andmetüübiga samaväärne funktsioon atribuut IDENTITY, mille abil saab luua võtmeväärtusi. Kui rakendate seda atribuuti mis tahes arvuveerule, muutub see kirjutuskaitstuks ja seda hakkab haldama andmebaasisüsteem. Kui lisate kirje tabelisse, mis sisaldab IDENTITY-veergu, suurendab süsteem IDENTITY-veeru väärtust automaatselt 1 võrra ja alates 1-st, kuid neid väärtusi on võimalik argumentidega reguleerida.

Lisateavet leiate artiklist CREATE TABLE, IDENTITY (atribuut).

Indeksid

Nagu tavaliselt on indeksivalik tasakaalustav toiming päringukiiruse ja värskenduskulu vahel. Accessis on ühte tüüpi indeks, kuid SQL Serveris on neid tüüpe kaksteist. Õnneks saab kasutada päringuoptimeerijat, mis aitab usaldusväärselt valida kõige tõhusama indeksi. Azure’i SQL-is on võimalik kasutada automaatset indeksihaldust, automaathäälestuse funktsiooni, mis soovitab, milliseid indekseid lisada või kustutada. Erinevalt Accessist tuleb SQL Serveris välisvõtmetele luua oma indeksid. Selleks et päringu jõudlust parandada, saab luua indekseid ka indekseeritud vaates. Indekseeritud vaate miinuseks on see, et vaate alustabelis andmete muutmise korral suurenevad üldkulud, kuna ka vaadet tuleb värskendada. Lisateavet leiate artiklitest SQL Serveri indeksiarhitektuuri ja disaini juhend ning Indeksid.

Lehe algusse

Tehingute sooritamine

Veebipõhiste tehingute protsessi (Online Transaction Process, OLTP) sooritamine on Accessi kasutades keeruline, kuid SQL Serveris suhteliselt lihtne. Tehing on üks tööüksus, mis teeb õnnestumise puhul kõik andmemuudatused, kuid mis ebaõnnestumise korral pöörab muudatused tagasi. Tehingul peab olema neli atribuuti, mida tihti nimetatakse ACID-iks:

• Atomaarsus (Atomicity)    Tehing peab olema atomaarne tööüksus; kõik andmete muudatused sooritatakse või ei tehta neist ühtegi.

• Konsistentsus (Consistency)    Pärast tehingu lõppu peavad kõik andmed olema kooskõlalises olekus. See tähendab, et kohaldatakse kõiki andmete tervikluse reegleid.

• Isoleeritus (Isolation)    Samaaegsete tehingute tehtud muudatused on isoleeritud praegusest tehingust.

• Püsivus (Durability)    Pärast tehingu lõpetamist on muudatused püsivad isegi süsteemi tõrke korral.

Tehingut kasutatakse selleks, et tagada garanteeritud andmete terviklus, näiteks pangaautomaadist raha väljavõtmise või palga automaatse deposiidi korral. Võimalik on teha otseseid, kaudseid ja partiipõhiseid tehinguid. Järgnevalt on toodud kaks TSQL-i näidet:

-- Using an explicit transaction

BEGIN TRANSACTION;  
DELETE FROM HumanResources.JobCandidate  
    WHERE JobCandidateID = 13;  
COMMIT;  

-- the ROLLBACK statement rolls back the INSERT statement, but the created table still exists.

CREATE TABLE ValueTable (id int);  
BEGIN TRANSACTION;  
       INSERT INTO ValueTable VALUES(1);  
       INSERT INTO ValueTable VALUES(2);  
ROLLBACK;

Lisateavet leiate artiklist Tehingud.

Lehe algusse

Piirangute ja päästikprotsesside kasutamine

Kõigil andmebaasidel on võimalused andmete tervikluse säilitamiseks.

Piirangud

Accessis saate rakendada tabeliseostes viitamisterviklust, kasutades välisvõtme ja primaarvõtme sidumist, värskenduste ja kustutamiste virnastamist ning valideerimisreegleid. Lisateavet leiate artiklitest Tabeliseoste juhend ja Andmesisestuse piiramine valideerimisreeglite abil.

SQL Serveris kasutatakse piiranguid UNIQUE ja CHECK, andmebaasiobjekte, mis rakendavad SQL Serveri tabelites andmete terviklust. Selleks et kontrollida, kas väärtus kehtib ka teises tabelis, kasutatakse välisvõtme piirangut. Kontrollimaks seda, kas veerus olev väärtus on konkreetses vahemikus, saab kasutada piirangut CHECK. Need objektid on teie esimene kaitseliin ja on loodud tõhusalt töötama. Lisateavet leiate artiklist Piirangud UNIQUE ja CHECK.

Päästikprotsessid

Accessis pole andmebaasipäästikuid. SQL Serveris saab kasutada päästikprotsesse selleks, et rakendada kompleksandmete terviklusreegleid ja käitada seda äriloogikat serveris. Andmebaasipäästik on salvestatud protseduur, mis töötab, kui andmebaasis esinevad teatud toimingud. Päästik on sündmus, näiteks tabelis kirje lisamine või kustutamine, mis vallandab ja seejärel täidab salvestatud protseduuri. Kuigi Accessi andmebaas tagab viitamistervikluse siis, kui kasutaja proovib andmeid värskendada või kustutada, on SQL Serveril arenenum päästikprotsesside kogum. Näiteks on võimalik programmeerida päästikut nii, et see kustutaks kirjeid suurtes kogustes ja tagaks andmete tervikluse. Päästikuid on võimalik lisada isegi tabelitele ja vaadetele.

Lisateavet leiate artiklitest DML-i päästikud, DDL-i päästikud ja T-SQL-i päästiku kujundamine.

Lehe algusse

Arvutatud veergude kasutamine

Accessis saab luua arvutatud veergu (calculated column), lisades selle päringule ja koostades avaldist, näiteks:

Extended Price: [Quantity] * [Unit Price]

SQL Serveris on samaväärne funktsioon computed column (arvutatud veerg), mis on virtuaalne veerg, mida tabelis füüsiliselt ei salvestata, v.a juhul kui veerg on märgitud kui PERSISTED (püsiveerg). Mõlemad arvutatud veerud (calculated ja computed) kasutavad andmeid, mis on pärit avaldise teistest veergudest. Arvutatud (computed) veeru loomiseks lisage see tabelisse. Näiteks:

CREATE TABLE dbo.Products   
(  
    ProductID int IDENTITY (1,1) NOT NULL  
  , QtyAvailable smallint  
  , UnitPrice money  
  , InventoryValue AS QtyAvailable * UnitPrice  
);  

Lisateavet leiate artiklist Tabelis arvutatud veergude määratlemine.

Lehe algusse

Andmetele ajatempli lisamine

Andmesisestuse logimiseks lisatakse mõnikord tabeliväli, mis salvestab kirje loomise ajatempli. Accessis saab lihtsalt luua kuupäevaveeru, mille vaikeväärtus on =Now(). Selleks et salvestada kuupäeva või kellaaega SQL Serveris, saab kasutada andmetüüpi datetime2, mille vaikeväärtus on SYSDATETIME().

Märkus    Andmetesse ajatempli lisamine võib segadusse ajada rowversioni, nii et proovige seda vältida. Keyword timestamp on SQL Serveris rowversioni sünonüüm, kuid kasutama peaks keyword rowversionit. SQL Serveris on rowversion andmetüüp, mis paljastab andmebaasis olevad automaatselt loodud kordumatud kahendnumbrid, ja seda kasutatakse tavaliselt mehhanismina, mis varustab tabeliveerge versioonitempliga. Siiski on andmetüüp rowversion vaid suurenev arv, see ei salvesta kuupäeva ega kellaaega ning see pole loodud veeru ajatempliga varustamiseks.

Lisateavet leiate artiklist rowversion. Lisateavet selle kohta, kuidas kasutada kirjekonfliktide vähendamiseks rowversioni, leiate artiklist Accessi andmebaasi SQL Serverisse migreerimine.

Lehe algusse

Suurte objektide haldamine

Accessis saate struktureerimata andmeid (nt faile, fotosid ja pilte) hallata andmetüübi Manus abil. SQL Serveri terminoloogias nimetatakse struktureerimata andmeid bloobiks (Binary Large Object, suur kahendobjekt) ja nendega töötamiseks on mitu võimalust:

FILESTREAM    Kasutab muutuvpikkusega kahendandmete tüüpi selleks, et andmebaasi asemel salvestada struktureerimata andmeid hoopis failisüsteemi. Lisateavet leiate artiklist Accessi FILESTREAM-i andmed koos Transact-SQL-iga.

FileTable    Talletab bloobid eritabelis, mille nimi on FileTable, ning võimaldab ühilduvust Windowsi rakendustega, nagu oleksid need talletatud failisüsteemis ja ilma klientrakendustesse muudatusi tegemata. FileTable’i kasutamiseks on vaja FILESTREAM-i. Lisateavet leiate artiklist FileTable’id.

Kaug-bloobisalv (RBS)    Otse serveris talletamise asemel salvestatakse suuri kahendobjekte (bloobe) kaubasalvelahendustesse. See säästab ruumi ja vähendab riistvara ressursse. Lisateavet leiate artiklist Suurte kahendobjektide (bloobide) andmed.

Lehe algusse

Hierarhiliste andmetega töötamine

Kuigi relatsioonandmebaasid, nt Access, on väga paindlikud, on nendes hierarhiliste seostega töötamine erand ning tihti on nende puhul vaja SQL-i keerukaid lauseid või koodi. Hierarhiliste andmete hulka kuuluvad näiteks organisatsiooniline struktuur, failisüsteem, keeletingimuste taksonoomia ja veebilehtedevaheliste seoste graaf. SQL Serveris on integreeritud andmetüüp hierarchyid ja hierarhiliste funktsioonide kogum, mis aitavad hierarhilisi andmeid hõlpsasti talletada ja hallata ning teha neis päringuid.

Lisateavet leiate artiklitest Hierarhilised andmed ja Juhend: Andmetüübi hierarchyid kasutamine.

Lehe algusse

JSON-teksti töötlemine

JavaScripti objektiesitus (JSON) on veebiteenus, mis kasutab andmete edastamiseks inimese jaoks loetavat teksti kui atribuudi-väärtuse paare asünkroonses brauseri-serveri suhtluses. Näiteks:

{
"firstName": "Mary",
"lastName": "Contrary",
"spouse": null,
"age": 27
}

Accessis pole integreeritud viise JSON-i andmete haldamiseks, kuid SQL Serveris saab JSON-i andmeid sujuvalt talletada, indekseerida ja ekstraktida ning päringuid sooritada. JSON-i teksti saab tabeli- või vorminguandmetes teisendada ja talletada JSON-i tekstina. Näiteks võib teil tekkida soov vormindada päringutulemeid veebirakenduse jaoks JSON-ina või lisada JSON-i andmestruktuure ridadesse ja veergudesse.

Märkus    JSON pole VBA-s toetatud. Alternatiivina saate VBA-s tarvitada XML-i, kasutades MSXML-i teeki.

Lisateavet leiate artiklist JSON-i andmed SQL Serveris.

Lehe algusse

Ressursid

Nüüd on sobiv aeg SQL Serveri ja Transact-SQL-i (TSQL) kohta lisateabe saamiseks. Nagu olete tähele pannud, on SQL Serveris palju Accessiga samasuguseid funktsioone, kuid ka võimalusi, mida Access lihtsalt ei paku. Selleks et saaksite oma teadmisi täiendada, on allpool toodud mõni õppematerjal:

Lehe algusse