Ovatko SQL-tietokantasi turvassa?
Johdanto
Kuka käyttää tietokantoja? Kaikenlaiset monikansalliset, valtiolliset, kunnalliset, viranomais- sekä kaupalliset tahot kuin myös yhdistykset tarvitsevat toimintaansa tietokantoja. Tietokannat voivat sijaita pilvipalveluiden takana sekä ylipäätään erilaisissa laitteissa, kuten palvelimissa, pöytätietokoneissa, kännyköissä, tai sulautetuissa järjestelmissä. SQL-tietokannat ovatkin hallinneet maailmaa jo useiden vuosikymmenien ajan, ja ovat tänä päivänä yhä eniten käytetyin tietokantojen ilmenemismuoto. Pienemmissä yrityksissä voi olla vain kourallinen yksittäisiä tietokantoja, kun taas suuressa monikansallisessa yhtiössä tai softatalossa niitä voi olla jopa miljoonittain. Jokaista tietokantaa tulee hoitaa eri tavoin. SQL-tietokannat eivät pysy ajan saatossa toimintakuntoisina huoltamattomina. Tämä blogini tekee katsauksen tietokannanhallinnan eri aspekteihin juuri tästä näkökulmasta: Mitä tulisi valvoa, jotta vältytään tietokanta-alustojen erilaisilta vaaratilanteilta?
Mietitäänpä ensin, mitä tietokannat sisältävät. SQL-tietokantoihin tallennetaan sekä yrityksen transaktionaalinen data (OLTP), että niistä summattu ja jalostettu historiatieto (datamart, Data Warehouse). Transaktionaalisia SQL-tietokantoja ovat tyypillisesti erilaiset SCM-tietokannat sekä ERP-tietokannat, talousohjelmistojen tietokannat, CRM-tietokannat sekä muut sisällönhallinnalliset tietokannat ja rekisterit ja erilaiset tietovarastot. Yleisesti ottaen tietokantoja tarvitaan miltei poikkeuksetta sellaisissa sovelluksissa ja järjestelmissä, jotka keräävät paljon dataa, ovat reaaliaikaisia tai historioivat dataa päätöksenteon tueksi. Toisin sanoen, SQL-tietokanta sisältää liiketoiminnan kannalta keskeistä, kriittistä tietoa. Ilman tätä tietoa monet yritykset, yhteisöt ja laitteet eivät yksinkertaisesti pysty toimimaan.
Kun tietokantasi sanoo poks
Mitä tapahtuu, jos tietokantaa pyörittävä fyysinen alusta tai jokin softakonfiguraatio hajoaa niin, että tulee käyttökatko? Miten tästä toivutaan? Kuinka monta päivää, tuntia, minuuttia tai jopa sekuntia kyetään toimimaan ilman toimivaa tietokanta-alustaa ja miten paljon dataa ollaan valmiita käyttökatkon takia menettämään? Entä kuinka tällaisista kriisitilanteista toivutaan mahdollisimman luotettavasti, nopeasti ja tehokkaasti? Kaikkeen tähän vastauksena on DBA (Database Administrator), siis henkilö, joka pitää huolta tietokannoista teknisesti. Minun mielestäni jokaisella softatalolla, keskisuurella sekä suuryrityksellä tulisi olla vähintään yksi DBA, joskus jopa tiimi, jonka lisäksi yrityksen on hyvä käyttää ulkoisia, erityisluontoisia DBA-palveluita kokeneelta ulkoiselta toimijalta. Tämä siksi, että tuskin kukaan DBA hallitsee kaikkia tietokannanhallinnan osa-alueita täydellisesti ja ulkoiset toimijat ovatkin hyvin usein erikoistuneet joihinkin tiettyihin vaativiin DBA-toimintoihin. Tällöin omalle DBA:lle ja / tai konesalipalveluntarjoajan DBA-tiimille säästyy paremmin resursseja yrityksen SQL-tietokantojen ydintoiminnoista huolehtimiseen ja luonteeltaan usein väliaikaiset mutta vaativat spesialistien tehtävät voidaan jättää kolmansille osapuolille. Näin saadaan laadukkain ja kustannustehokkain kokonaisratkaisu.
Seuraavissa kappaleissa käyn läpi keskeisiä näkökulmia tietokantojen ylläpitämisen suhteen: Mikä voi mennä pieleen. Vastaamme on tullut DB Pro:n ja DB Pro Services:in toimintavuosien varrella useita satoja erilaisia Microsoft SQL Servereiden ongelmakohtia, jotka olemme, uskallan sanoa, yli 99-prosenttisesti, kyenneet tehokkaasti ratkaisemaan!
Saatavuus
Tietokantojen saatavuus on kaiken A ja O. Jos esimerkiksi yhteys liiketoimintakriittiseen tietokantaan lakkaa, peli on menetetty ja aletaan laskea vahinkojen määrää. Suuremmissa yrityksissä vahingot ovat tällöin tyypillisesti kymmenistä tuhansista euroista miljooniin euroihin päivässä. Mitä sitten pitäisi tehdä, jotta tällaiselta vältyttäisiin?
SQL-tietokantapalveluiden saatavuuden osalta seurattaviin kohteisiin kuuluvat mm. erilaiset julkiset tietokantapalvelut (IaaS, PaaS, SaaS), data centerit, verkko, tallennuskapasiteetti sekä fyysiset palvelimet. Ohjelmistoteknisiä osa-alueita ovat mm. virtualisointi ja hyperkonvergenssi kuten Nutanix ja VMware, erilaiset korkean käytettävyyden (HA) ratkaisut sekä käyttöjärjestelmät, SQL-tietokannanhallintajärjestelmät ja tietokannat itsessään varmuuskopioineen.
Kokemukseni mukaan tyypillisimmät virheet ovat vastoin parhaita käytäntöjä tehdyt laite- ja tietokantakonfiguraatiot, alimitoitettu kapasiteetti sekä inhimilliset erehdykset. Yleisiä syitä tietokantojen saatavuusongelmiin ovat mm. ennakoimattomat työkuormahuiput, standalone-palvelimen vikaantuminen, jolloin tietokannatkin lakkaavat toimimasta, tai HA-ratkaisussa tietokannanhallintajärjestelmän palvelinnoodien vikautunut yliheitto, kun työkuormaa ei saada onnistuneesti siirrettyä vikaantuneelta palvelimelta toiselle, sekä riittämätön kapasiteetti kun yhden tai useamman vikaantuneen palvelininstanssin työkuormaa uudelleenohjataan yliheitettyyn palvelimeen. Muita hyvin tyypillisiä tapauksia ovat tietokantojen datatiedostojen epäoptimaaliset konfiguraatiot tallennusjärjestelmää vasten, korruptoituneet tietokannat sekä toimimattomat tietokantapalautukset sekä vakavat lukkotilanteet (deadlock) operatiivisissa tietokannoissa, pintaa raapaistaakseni.
Näiden ehkäisemiseksi voidaan auditoida tietokanta-alustan konfiguraatiot sekä toteuttaa ne parhaiden käytäntöjen mukaan. Täytyy myös muistaa, että jokaisella rauta- ja softatoimittajalla on useimmiten omat suosituksensa. Myöskään tietokantabackupeilla ei tee mitään ilman säännönmukaisia palautustestauksia ja operatiivisella tietokannalla voi joutua äkkiä heittämään vesilintua, ellei indeksien ja statistiikkojen huoltoajot ole konfiguroitu tietokantaympäristölle optimaalisella tavalla ja niin edelleen.
Suorituskyky
Huonontunut SQL-tietokannan suorituskyky voi pahimmillaan aiheuttaa saatavuusongelman. Heikko SQL-tietokannan suorituskyky voi tuottaa erittäin huonon käyttäjäkokemuksen ja näin nakertaa käyttäjien työmotivaatiota sekä ennen kaikkea hidastaa organisaation normiprosesseja ja sitoa ylimääräisiä henkilöstöresursseja merkittävästi käyttäjäkunnan osalta, joskus jopa useita kymmeniä prosentteja. Tälle hintalapun laskeminen voi olla jopa hieman pelottavaa. Esimerkiksi softataloille tämä on todella kriittistä: Tietokannan on toimittava mahdollisimman tehokkaasti, koska jokainen uusi softan käyttäjä on kertoimena X tietokantaratkaisun kustannusrakenteelle: Ohjelmointivirheiden vaikutukset kumuloituvat ja onnistunut käyttäjäkokemus on keskeinen imagoasia.
Tyypillisiä SQL Server -tietokantojen suorituskyvyn pullonkauloja löytyy mm. käyttöjärjestelmäasetuksista, tietokantainstanssien konfiguraatioista, tietokantojen asetuksista ja kompressoinnista, tietokantataulujen partitioinnista, indeksoinnista, -statistiikasta ja niiden huoltoajoista sekä eritoten T-SQL-koodista. Kokemukseni mukaan 70% performanssiongelmista johtuukin huonosta T-SQL-koodista ja epäoptimaalisista asetuksista, loput 30% laiteongelmista ja eritoten kapasiteettivajeesta.
Performanssiongelmia voidaan ehkäistä diagnosoimalla huonosti toimivat tietokantapalvelimet ja tietokannat, tyypillisesti käyttämällä jotain ulkoista ohjelmistoa kuten SQL Governor-ohjelmistomme, jolloin saadaan sekä kokonaiskuva, että detaljitason löydökset kaivettua systeemistä nopeasti esille kokeneen DBA:n avustamana ja kohdennettua korjaavat toimenpiteet priorisoidussa järjestyksessä oikeisiin kohteisiin.
Kapasiteetti
Kun palvelinalustan fyysinen kapasiteetti ei riitä, palvelin alkaa hidastua ja pahimmillaan aiheuttaa epäkäytettävyystilanteen. Juuri siksi SQL-tietokantojen huolellinen kapasiteettisuunnittelu on tärkeää. Fyysisessä kapasiteetissa tyypillisimmät rajat SQL-tietokannoilla tulevat vastaan tallennuskapasiteetissa (IOPS / throughput, levylatenssi) sekä prosessorikapasiteetissa ja muistissa, joskus myös verkossa. Esimerkiksi prosessorin ylikuormittuminen on usein kriittinen ongelma OLTP-tyyppisessä tietokantapalvelimessa: Suoritettavia tehtäviä on prosessorilla enemmän kuin se ehtii parhaimmillaankaan hoitaa.
Paras keino välttää SQL-tietokantojen kapasiteettivaje suunniteltaessa uutta ympäristöä on pitkälliseen historia- ja trenditelemetriikkaan perustuva analyysi, jossa pyritään ottamaan huomioon mm. palvelinkapasiteetin peruskuorma eli baseline, sen kausivaihtelut, kuormapiikit, sekä palvelukatkosten ja patchayksen aiheuttamat anomaliat palvelin- instanssi- sekä tietokanta- ja aina datafile-tasolla saakka. Tällä tavalla pystytään ennakoimaan ja tarkasti laskemaan nykyhetken ja tulevaisuuden kapasiteettitarpeet. SQL Governor-ohjelmistossamme on useita kansainvälisiä patentteja sisältävät laskentamoduulit, joilla voidaan tarkasti määrittää tämänhetkinen sekä tulevaisuuden kapasiteettitarve palvelin-, instanssi- ja kanta sekä datafile-kohtaisesti sekä laskemaan auki erilaiset HA- ja migraatio ja konsolidointiskenaariot esimerkiksi on premisestä pilvialustaan tai toisinpäin. Olemme käyttäneet SQL Governor-ohjelmistoamme menestyksellisesti lukemattomissa migraatioissa ja pilvitransitioissa vuosien varrella.
Tietoturva
Tietoturvaa ei ole kenelläkään vara lakaista maton alle, etenkään näinä aikoina. Tässä ennaltaehkäisevä toiminta on kaiken keskiössä. SQL-tietokantaympäristöissä on lukuisia asetuksia, jotka tulee ottaa huomioon mahdollisimman tietoturvallisessa ratkaisussa. Täytyy varautua myös siihen, että tietokannat joutuisivat joka tapauksessa vääriin käsiin. Tällöin on syytä kryptata kaikki liiketoimintakriittinen tieto, ja jo mieluiten tänä päivänä symmetrisillä, kvanttiturvallisilla tiedonsalausalgoritmeillä.
Tietoturvaan liittyy paljon vastuuta ja vaaranpaikkoja. Blackbelt DBA-tiimimme tarjontaan kuuluvat myös SQL Server -ympäristöjen tietoturva-auditoinnit. Auditoinnin lopputuloksena saat hyvän käsityksen tietokanta-alustasi turvallisuudesta sekä mahdollisista haavoittuvuuksista, sekä ohjeet haavoittuvuuksien korjaamiseksi.
Avain hyvinvoivaan SQL-tietokanta-alustaan on jatkuva seuranta
SQL-tietokanta on kuin viritetty kilpa-auto: Se vaatii määräaikaishuoltoja sekä jatkuvaa seurantaa. Kokenut DBA kykenee usein ennakoimaan epäkäytettävyystilanteita ja muita vaaran paikkoja seuraamalla esimerkiksi tietokantojen lukkotilanteita, raudan resource spillejä, wait statistiikan trendejä, kyselysuunnitelmien resurssikulutuksen kausiluontoisuutta ja kehitystä sekä indeksoinnin kokonaistehokkuutta.
Vanha kansanviisaus kuuluu; ”hätä ei tule kello kaulassa”. Näin tekoälyn aikakaudella uskallan kuitenkin haastaa tätä viisautta. Ennakoivaa analytiikkaa hyödyntävä SQL Governor-tuotteemme tarjoaa tähän kaikkeen tehokkaan, monella tapaa ennaltaehkäisevän työkalupaletin, jolla saat kattavan kokonaiskuvan SQL-tietokantaympäristöstäsi 24 / 7 / 365 ja pystyt usein ennakoimaan poikkeustilanteita, jolloin DBA:lle jää enemmän aikaa reagoida sekä näin keskittyä sinne missä apua tarvitaan. Blackbelt DBA:mme yhdessä SQL Governorin kanssa voi olla juuri sinun SQL-tietokantaympäristösi ”tapaturmavakuutus”.
Kiinnostuitko? Ota yhteyttä niin keskustellaan lisää!
Jani K. Savolainen
jani.savolainen@dbproservices.fi
0440353637
CEO & Chairman
DB Pro Services Oy
Sinua saattaa kiinnostaa myös:
SQL tietokanta-historia
Ennakoiva analytiikka
Power BI pro ja eri lisensiointimallit
