administracija podatkovne baze mysql - core · 2017. 11. 28. · podatkovne baze in spletnega...

Staš Kopina

ADMINISTRACIJA PODATKOVNE BAZE MySQL

Diplomsko delo

Maribor, junij 2014

ADMINISTRACIJA PODATKOVNE BAZE MySQL

Diplomsko delo

Študent: Staš Kopina

Študijski program: Informatika in tehnologije komuniciranja VS

Smer: Sistemska podpora informatiki in tehnologijam komuniciranja

Mentor: Viš. pred. doc. dr. Boštjan Brumen, univ. dip. inž. rač. in inf.

ii

ZAHVALA Zahvaljujem se mentorju doc. dr. Boštjanu Brumnu za pomoč in vodenje pri opravljanju diplomskega dela. Posebna zahvala velja tudi moji družini in dekletu, ki so me med študijem podpirali.

iii

Administracija podatkovne baze MySQL

Ključne besede: Podatkovne baze, administrator podatkovnih baz, MySQL, optimizacija

sistema

UDK: 004.65(043.2)

Povzetek

V diplomskem delu Administracija podatkovne baze MySQL smo predstavili naloge

administratorja podatkovne baze MySQL. Predstavljena je tudi namestitev sistema

MySQL z nastavitvenimi parametri, ki omogočajo boljšo optimizacijo sistema. Pri tem smo

se omejili na operacijski sistem Windows 7. Zavedajoč se pomembnosti optimizacije

sistema, smo vso pozornost usmerili v boljšo optimizacijo in poskušali predstaviti kar se

da najboljše rešitve.

iv

Administration MySQL database

Key words: Database, database administrator, MySQL, System Optimization

UDK: 004.65(043.2)

Abstract

In this thesis we describe the activities of a MySQL data base administrator.The MySQL

system installation on a Windows 7 Operating system with parameters settings that

enable better system optimization is described. With awareness of the importance of

system optimization, we deal with the better optimization and take an effort to find better

solutions.

v

KAZALO

1 UVOD ......................................................................................................................................... 1

2 MYSQL NAMESTITEV S POMOČJO UPORABNIŠKEGA VMESNIKA .................................. 2

3 NASTAVITVENI PARAMETRI – MY.INI ................................................................................. 10

4 SHANJEVALNI MEHANIZMI OZ. TIPI TABEL ....................................................................... 15

4.1 MyISAM Storage Engine .................................................................................................... 16

4.2 InnoDB Storage Engine ..................................................................................................... 21

4.3 MERGE Storage Engine ..................................................................................................... 25

4.4 MEMORY Storage Engine .................................................................................................. 28

4.5 ARCHIVE Storage Engine .................................................................................................. 29

4.6 FEDERATED Storage Engine ............................................................................................ 29

4.7 Napotki pri izbiri shranjevalnih mehanizmov .................................................................. 30

5 VARNOSTNI VIDIKI V MYSQL ............................................................................................... 32

5.1 Uporabniki in njihove pravice ........................................................................................... 32

5.2 Varnost ................................................................................................................................ 41

6 PROŽILEC (ANGL. TRIGGERS) IN OMEJITVE (ANGL. CONSTRAINTS) ........................... 48

7 PROCEDURE IN FUNKCIJE V MYSQL.................................................................................. 52

8 PRIMER UPORABE MYSQL ................................................................................................... 56

9 SKLEP ...................................................................................................................................... 61

10 VIRI ....................................................................................................................................... 62

vi

KAZALO SLIK

SLIKA 2-1 NAMESTITVENI KORAKI, SKOZI KATERE NAS VODI "ČAROVNIK" ........................................................................... 3

SLIKA 2-2 DODAJANJE NOVEGA UPORABNIKA ............................................................................................................... 6

SLIKA 2-3 MYSQL WORKBENCH ............................................................................................................................... 9

SLIKA 5-1 DIAGRAM PRIKAZUJE POSTOPEK PREVERJANJA PRIVILEGIJEV UPORABNIKA[1] ...................................................... 36

SLIKA 5-2 ADMINISTRATORJEV VMESNIK IN TRIJE KORAKI VNOSA NOVEGA UPORABNIKA Z NASTAVITVIJO PRIVILEGIJEV .............. 39

SLIKA 5-3 SCHEMA PRIVILEGES ............................................................................................................................... 40

SLIKA 8-1 E-R MODEL ........................................................................................................................................... 56

vii

UPORABLJENE KRATICE

MySQL - Open Source SQL database management system

PB - Podatkovna baza / Data

SQL - Structured Query Language

TCP/IP - Transmission Control Protocol/Internet Protocol

SSL - Secure Sockets Layer

SHA1 - Secure hash algorithm

MVCC - Multiversion Concurrency Control

E-R - Entity–Relationship model

PL/SQL - Procedural Language/Structured Query Language


1

1 UVOD

Danes živimo v dobi, ki naši celotni družbi »vsiljuje« povezanost z informacijskimi

storitvami, ki jih povezuje internet. Internet je v celoti sestavljen iz manjših omrežij, ki si

med seboj pošiljajo podatke. Iz nabora podatkov dobimo informacijo. Da pa lahko iz

podatkov tvorimo informacijo, moramo poskrbeti za beleženje le-teh. Še pred desetletji so

podatke shranjevali v arhivih. Ker pa smo sedaj prešli v informacijsko dobo, ki je

»zahtevala« velik nabor podatkov s hitrim dostopom, kar pa z arhivi ni bilo možno, jih je

zamenjala podatkovna zbirka oz. podatkovne baze (v nadaljevanju PB).

Da podatki ne bi bili zgolj podatki in bi iz njih lahko tvorili informacijo, je podatke treba

pravilno shranjevati. Za pravilno hierarhijo podatkov in optimalno delovanje podatkovnih

baz skrbi administrator – administrator PB.

Namen diplomske naloge je, da predstavimo delo administratorja PB. Predstavili bomo

namestitev MySQL PB z naborom vseh pripadajočih se programov za delo s PB in

administracijo. V celotni nalogi bomo poskušali predstaviti in opisati rešitve, ki temeljijo na

boljšem delovanju in optimizaciji MySQL PB. Podrobneje bomo predstavili shranjevalne

mehanizme oz. tipe tabel, lastnosti in princip delovanja.

Varnost v sistemih je ključnega pomena in zato bomo v poglavju Varnostni vidiki

predstavili najnujnejše varnostne ukrepe. V tem poglavju smo predstavili tudi pomembnost

dodeljevanja pravic uporabnikom, saj tudi to sodi k varnostnim ukrepom. Predstavili bomo

»napredne« bazne objekte, kot so prožilce, omejitve, procedure in funkcije, s katerimi

lahko del logike, ki bi jo morali razvijalci vključiti v aplikacijah, vključimo kar v MySQL. S

pomočjo »naprednih« baznih objektov lahko odkrijemo oz. preprečimo napako, ki bi lahko

nastala v PB.

Na koncu bomo s praktičnimi primeri zajeli celotno tematiko diplomske naloge in

predstavili administratorjevo praktično delo.


2

2 MYSQL NAMESTITEV S POMOČJO UPORABNIŠKEGA VMESNIKA

Za preprostejšo namestitev smo izbrali »MySql Installer«, ki vsebuje uporabniku prijazen

vmesnik za lažjo namestitev. Pri namestitvi sistema MySQL smo se omejili na operacijski

sistem Windows 7. Pred namestitvijo MySQL-a je treba namestiti programsko opremo

Microsoft.NET Framework 4.0+.

Začetna konfiguracija in nastavitev parametrov:

1. ustvari MySQL Server povezavo v MySQL delovnem okolju;

2. ustvari se konfiguracijska datoteka - my.ini, ki se med namestitvenim postopkom

dopolnjuje;

3. uvozi primere podatkovnih baz;

4. ustvari uporabniški računi z nastavitvijo primernih dovoljenj, katere temeljijo na

vlogah specifičnih uporabnikov, kot so administrator podatkovne baze (v

nadeljevanju PB), administrator varnostnih kopij ...;

5. »Advanced Configuration« vključuje opredelitev log datotek (error log, general log,

slow query log in bin log).[13]

Ob zagonu namestitvenega programa se nam pojavi »Welcom Screen«.

Ponudi nam tri možnosti:

1. Namestitev MySQL izdelka – čarovnik za namestitev.

2. O izdelku – opis in spoznavanje funkcionalnosti izdelka MySQL.

3. Viri – informacije in pomoč pri namestitvi in konfiguraciji MySQL-a.

Po izboru namestitve, nas čez celotno namestitev po korakih, ki so razvidni s slike 2-1,

vodi namestitveni čarovnik.


3

Slika 2-1 Namestitveni koraki, skozi katere nas vodi "čarovnik"

License Information

Namestitveni čarovnik najprej zahteva, da potrdimo licenco, s katero soglašamo s pogoji

podjetja Oracle, saj lahko le tako nadaljujemo z namestitvijo.

Find latest products

Ponuja nam možnost, da se povežemo z internetom za iskanje najnovejših komponent

MySQL. Če želimo, lahko komponente doda namestitvenemu paketu, če pa tega nočemo,

lahko ta korak izpustimo.

Izbrali smo »Povezava z internetom« in sprožili zahtevo, da poišče posodobitve. Ko je

iskanje končano, nas preusmeri na stran, kjer izberemo vrsto nastavitve.

Setup Type

Ponujene so možnosti različnih namestitvenih tipov, ki ponujajo specifične namestitve

glede na uporabnikove želje in zahteve. Izberemo lahko tudi namestitveno pot za

shranjevanje datotečnih ter namestitvenih datotek.

Developer Default

Namesti vse izdelke in orodja, ki so potrebni za razvojne namene MySQL.


4

Nastavitev vsebuje:

- MySQL Server,

- MySQL Workbench – uporabniški vmesnik za razvijanje in administracijo serverja,

- MySQL Visual Studio Plugin – delo z MySQL strežnikom iz Visual Studia,

- primeri in vaje za hitrejši in lažji začetek razvoja,

- dokumentacijo.

Server only

Namesti se samo MySQL Server, brez razvijalskih aplikacij.

Client only

Namesti potrebna orodja za razvoj aplikacij MySQL in ne vsebuje MySQL Server.

Koristno v primeru, če nameravate razvijati aplikacije na obstoječem strežniku.

Nastavitev vsebuje:

- MySQL Workbench – uporabniški vmesnik za razvijanje in administracijo serverja,

- MySQL Visual Studio Plugin – delo z MySQL strežnikom iz Visual Studia,

- MySQL konektorji – Connector / Net, Java, C / C++, ODBC in drugi,

- primeri in vaje za hitrejši in lažji začetek razvoja,

- dokumentacijo.

Full

Namesti celoten nabor aplikacij, ki so na voljo, vključno z MySQL Server, MySQL

Workbench, MySQL konektorji, dokumentacijo, vzorci in primeri ter veliko več.

Custom

Omogoča, da izberete točno določen izdelek, ki bi ga želeli namestiti. To omogoča tudi,

da izberete druge različice serverja - strežnika in arhitekture.

Check Requirements

Po izbranem tipu namestitve, MySQL Installer preveri vaš sistem za izvajanje potrebnih

zunanjih zahtev in nameščanje manjkajočih produktov.

Installation

Naslednje okno prikaže MySQL produkte, ki so načrtovani za vgradnjo. S potrditvijo

Execute se sproži namestitveni postopek.


5

Configuration

- Korak 1.

Po uspešni namestitvi vseh produktov nastopi korak, ki vključuje konfiguracijo izdelkov.

Idealna konfiguracija MySQL Serverja je odvisna od namembnosti računalnika.[13]

Server Configuration Type

Določa, koliko sistemskih virov bo dodeljenih MySQL Serverju. Na izbiro imamo

tri različne tipe namembnosti računalnika, s čimer omejimo delovanje MySQL-a

in preprečimo preobremenitev pomnilnika.

Development Machine – računalnik je namenjen razvijalstvu in so v sistemu

nameščeni tudi drugi razvijalski programi, ki potrebujejo nemoteno

delovanje pomnilnika. MySQL bo uporabljal le minimalno »količino«

pomnilnika.

Server Machine – računalnik bo izključno namenjen samo serverju in za

nemoteno delovanje potrebuje polovico pomnilnika.

Dedicated Machine – je izključno namenjen za poganjanje MySQL

podatkovne baze in spletnega strežnika. Za delovanje potrebuje celoten

pomnilnik.

Enable TCP/IP Networking

Omogočimo, da se lahko v bazo prijavimo z računalnika, ki je izven domačega

omrežja, v nasprotnem primeru lahko do baze dostopamo samo preko localhost

povezave. TCP/IP deluje preko porta 3306. Port lahko ročno tudi spremenimo na

želeno vrednost ter s potrditvijo dovoljujemo, da port odpremo v požarnem zidu.

Advanced Configuration

Funkcija vključuje dodatno nastavitev poti datotek v dnevniku napak (glej Korak

4).


6

Slika 2-2 Dodajanje novega uporabnika

- Korak 2.

Konfiguriramo izbrane podatke o svojem računu – definiranje root gesla. Tukaj se nahaja

tudi možnost dodajanje novih uporabnikov z vnaprej določenimi vlogami – različne ravni

delovanja – slika 2-2.[13]

Vloge, ki so nam ponujene:

- Backup Admin – varnostno kopiranje podatkov;

- DB Admin – ima vse privilegije;

- DB Designer – ustvarjanje in obratno inžinerstvo sheme baze podatkov;

- DB Manager – upravljanje podatkovnih baz;

- Instance Manager – vzdrževane strežnika;

- Monitor Admin –spreminjanje strežniških nastavitev;

- Process Admin – spreminjanje in ugašanje–kill uporabniških procesov;

- Replication Admin – vzpostavitev in upravljanje replikacij;

- Securty Admin – upravljanje prijav, odobravanje in preklic privilegijev

strežnika;

- User Admin – dodajanje in spreminjanje uporabnikov in uporabniških gesel.

-


7

- Korak 3.

Vkjučuje konfiguracijo imena storitve, kako je potrebno zagnati MySQL Server ob zagonu

sistema Windws in kateri uporabniški račun bo zagnan – ponuja možnost med Standard

System Account in Custom User.[13]

Opomba: V primeru, da izberemo možnost Custom User, mora

izbrani uporabnik imeti pravice za prijavo. Nastavitev

pravic v sistemu Windows 7: Star Menu, Control Panel,

Administrative Tools, Securty Policy, Local Policies,

User Rights Assignment, nato Log On As A Service.

Izberemo Add User or Group tukaj dodamo uporabnika,

s katerim se želimo prijaviti v sistem.[13]

- Korak 4.

Zadnji korak konfiguracije je na voljo le v primeru, če smo v prvem koraku vključili

možnost Advanced Configuration. Tukaj lahko izberemo, katere Log datoteke želimo

aktivirati – nastavimo tudi pot, za shranjevanje datotek na želeno mesto.[13]

Log datoteke so v MySQL lahko ključnega pomena, saj nam pomagajo odkrivati

napake in pripomore k proaktivnosti, da se izognemo težavam že vnaprej. Log

datoteke zagotovijo informacije, ki so potrebne za upravljanje strežnika.

Error Log – dnevnik napak se ustvari ob samem začetku, torej že ob prvem

zagonu MySQL strežnika. Beležijo se informacije o zagonu, izklopu strežnika in

kritične napake. Privzeto je datoteka shranjena v podatkovnem imeniku in se

imenuje <ime_strežnika>.err.

Vpis napak v dnevnik se začne z datumom in časom – YYMMDD HH:MM formatu,

nato sledi sporočilo, ki prikazuje, kaj se dogaja v bazi v tistem času.

Dnevnik napak je dragocen vir informacij pri odpravljanju težav s strežnikom, saj ta

ne vsebuje le zapisa podrobnosti o težavah strežnika, na katere je naletel, vendar

ima celotno zgodovino preteklih napak, ponovnega zagona strežnika (ročno ali

samodejno – mysql_safe).

General Query Log - splošen dnevnik poizvedb shranjuje vse informacije in

poizvedbe, ki so bile poslane MySQL strežniku. Vsaka poizvedba se zapiše v

datoteko, še preden jo strežnik prejme in z njo operira. Privzeto je datoteka

shranjena v podatkovnem imeniku in se imenuje <ime_strežnika>.log.


8

Primer poizvedbe shranjene v datoteki:

Datum in ura Tip poizvedbe Podrobnosti oz. opis

130810 17:09:18 10 Query SELECT * FROM sakila.address LIMIT 50, 10

10 Prepare SELECT TABLE_CATALOG AS TABLE_CAT,

TABLE_SCHEMA AS TABLE_SCHEM, TABLE_NAME, COLUMN_NAME,

SEQ_IN_INDEX AS KEY_SEQ, INDEX_NAME AS PK_NAME FROM

INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA LIKE ? AND

TABLE_NAME LIKE ? AND INDEX_NAME='PRIMARY' ORDER BY

TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX

130810 17:09:19 10 Execute SELECT TABLE_CATALOG AS TABLE_CAT,

TABLE_SCHEMA AS TABLE_SCHEM, TABLE_NAME, COLUMN_NAME,

SEQ_IN_INDEX AS KEY_SEQ, INDEX_NAME AS PK_NAME FROM

INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA LIKE 'sakila'

AND TABLE_NAME LIKE 'address' AND INDEX_NAME='PRIMARY' ORDER BY

TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX

10 Close stmt

Slow Query Log – je dnevnik, v katerega se shranjujejo poizvedbe, katere trajajo

dalj časa, kot smo določili v nastavitvah (long_query_time, privzeto 10 sekund). Je

idealen način za optimizacijo zmogljivosti. Vse poizvedbe, ki se pojavijo v tem

dnevniku, so primerne za revizijo – zmanjšanje vpliva uspešnosti strežnika.

Bin Log – MySQL podpira beleženje ukazov, ki omogočajo spreminjanje podatkov

v tabelah; ukazi, kot so INSERT, REPLACE, DELETE, GRANT in REVOKE,

skupaj z UPDATE, CREATE TABLE in DROP TABLE spadajo v isto kategorijo.

Vse te informacije so shranjene v bin datoteki, katera zagotavlja večji učinek

shranjevanja podatkov z večjo količino informacij. Mysqlbinlog pretvori binarno

datoteko v textovni dokument, ki je berljiv.

Priporočeno je, da se binarni dnevnik shrani na drug pogon ali napravo, kot je tista,

ki ima datoteke podatkovne baze MySQL, saj je ključnega pomena pri odkrivanju

okvar.[1][2]

MySQL Workbench

Po končani namestitvi strežnika smo v fazi, ko lahko začnemo z upravljanjem podatkovne

baze. Nemudoma bi lahko ustvarili novo PB, nove tabele, katere bi napolnili s podatki,

vendar naš namen je, da je vse optimizirano in skrbno načrtovano za kasnejše nemoteno

delovanje.


9

MySQL ima dve možnosti upravljanja z nastavitvenimi parametri (naloga administratorja

PB), in sicer:

- prva možnost je vnos nastavitvenih parametrov preko ukazne vrstice,

- kot druga možnost nam MySQL ponuja uporabniku prijaznejši način, in sicer

uporabniški vmesnik – MySQL Workbench, ki združuje vsa orodja za delo s

podatkovnimi bazami.

Za kasnejšo lažjo predstavo še nekaj besed o MySQL Workbench-u. Razdeljen je v tri

sklope, in sicer upravljanje PB, fizično načrtovanje PB in administracijo PB – vidno na sliki

2-3. Vsak sklop ima svoja specifična orodja za delo:

1) SQL Development: orodja za delo s PB. Uporabnik se najprej poveže s strežnikom,

šele nato lahko začne z delom (dodajanje novih PB, tabel, povpraševanj, vnos

podatkov ...).

2) Data Modeling: fizično načrtovanje PB (načrtovanje E-R diagramov).

3) Server Administration: nastavitev delovanja strežnika, dodajanje in urejanje

uporabnikov.[1][2][13]

Slika 2-3 MySQL Workbench


10

3 NASTAVITVENI PARAMETRI – MY.INI

MySQL strežnik uporablja veliko različnih uporabnikov, vsak uporabnik ima svoje

specifične zahteve. Treba je le urediti nastavitvene parametre, kateri se nahajajo v

datoteki my.ini. Za veliko večino projektov zadostuje privzeto urejena nastavitev

parametrov, katera se sprotno ureja med samo namestitvijo programa. Za zahtevnejše

projekte privzete nastavitve ne zadoščajo, saj bosta odzivni čas in hitrost delovanja zelo

opešala sistem, nakar bo treba optimizirati ter urediti nastavitvene parametre za hitrejše

delovanje strežnika. Datoteka my.ini omogoča vnos nastavitvenih parametrov, ki bi jih

morali drugače vnesti v ukazno vrstico, vsakič, ko zaženemo program.

Lokacija datotek

Datoteka z nastavitvenimi parametri – my.ini se nahaja v direktoriju

C:\ProgramData\MySQL\MySQL Server 5.6. MYSQL_HOME je spremenljivka, katera

vsebuje pot do datoteke. V primeru, da MYSQL_HOME ob zagonu strežnika ni nastavljen,

bo s pomočjo skripte mysqld_safe poskušala določiti pot:

BASEDIR in DATADIR predstavljata imena poti osnovnega imenika MySQL in

imenika podatkov,

če je my.ini datoteka v DATADIR in ne v BASEDIR imeniku, mysqld_safe določi

MYSQL_HOME za DATADIR,

v nasprotnem primeru, če MYSQL_HOME ni določen in datoteke my.ini ni v

imeniku DATADIR, skripta mysql_safe določi MYSQL_HOME za BASEDIR.[16]

DATADIR je podatkovni imenik, ki je bil določen v času nastavitve. Uporaba -datadir med

delovanjem sistema ne vpliva na to, kje strežnik išče opcijske datoteke. MySQL išče

opcijske datoteke v točno določenem vrstnem redu in v primeru, da datoteke, katero želi

uporabiti ne obstaja, datoteko ustvari z navadnim urejevalnikom besedila. V primeru, da

se ugotovi več danih izbir, ima prednost zadnja instanca.

Trije argumenti, ki vplivajo, kako MySQL bere datoteko z nastavitvenimi parametri:

–no-defaults – MySQL naj ne prebere datoteke

–defaults-file=/pot/do/datoteke – MySQL naj prebere le datoteko, ki je izrecno

določena, vse druge ignorira.

–defaults-extra-file=/pot/do/datoteke – MySQL naj po globalni nastavitveni

datoteki prebere še dodatno datoteko.


11

Z argumenti lahko rešimo težave v primeru, da želimo na istem gostitelju upravljati z več

strežniki. Tako lahko na vseh strežnikih uporabimo kopijo, ki določa vse skupne vrednosti,

ter hkrati niso le za en sam strežnik. Tako lahko za vsak strežnik dodatno nastavimo

nastavitvene parametre, glede na njegovo stojno opremo in s tem dosežemo učinkovitost.

Oblika nastavitvene datoteke

Datoteka je oblikovana in razdeljena na enega ali več delov oz. skupin, ki so med seboj

ločeni z imeni v oglatih oklepajih, kot je npr. [mysqld]. Prav tako, kot v programskih jezikih,

lahko dodamo komentarje, kateri služijo za boljše razumevanje dokumenta.

Komentarji se začnejo z # ali , in veljajo do konca vrstice. MySQL ne pozna večvrstičnih

komentarjev.

Pravilno komentiranje:

# Številka vrat, skozi katera bo potekal »promet« protokola TCP/IP

port=3308

Nepravilno komentiranje:

port=3308 # Številka vrat, skozi katera bo potekal »promet« protokola TCP/IP

- [group]: je del poglavja ali skupine, kot smo že omenili na začetku. Po navedbi

skupine sledijo nastavitve, ki so možne za to skupino. To določa programu, da od

tu in vse do naslednje »skupine«, veljajo nastavitve za to skupino strežnika.

- opt_name = value: je ukaz oz. opcija z vrednostjo, katera strežniku poda podatke

za delovanje po željah, ki smo jih navedli. Vsi ti ukazi so enakovredni ukazom, ki

se vnašajo v ukazno vrstico, le da pred opcijo izpustimo znak -. Presledki med

opcijskimi imeni in vrednostmi se prezrejo.[5][16][17]

Optimizacija my.ini datoteke

Med namestitvijo strežnika MySQL se hkrati v ozadju namestitve dopolnjuje tudi datoteka

z namestitvenimi parametri. Po končani namestitvi lahko brezpogojno upravljamo strežnik,

vendar se moramo zavedati, da so nastavitve posplošene za povprečen strežnik in ni

optimiziran našim zahtevam. Torej bomo morali sami poskrbeti za optimizacijo.

- InnoDB

Najprej optimizirajmo shranjevalni mehanizem InnoDB, saj je mehanizem privzeto izbran.

Če smo se odločili zanj, moramo poskrbeti za optimizacijo, saj privzete nastavitve ne

zadostuje za popoln sistem.[13]


12

Določimo lahko lokacijo, kot tudi velikost datotek tabel InnoDB. Uporabimo možnost

innodb_data_file_path v skupini [mysqld]. Določimo lahko več datotek hkrati, katere

ločimo s » ; «. Vsako datoteko lahko tudi omejimo na določeno velikost s » : «, npr.:

[Mysqld]

innodb_data_file_path = datoteka1: 50M; datoteka2: 60M: autoextend: max: 200M

Velikosti datotek označimo s K, M ali G, ki uprizarjajo KB, MB oz. GB. Datoteko1 smo

torej omejili s fiksno velikostjo 50MB, datoteko2 pa na 60MB, le da hkrati določamo, da se

lahko velikost datoteke dinamično spreminja, kar smo določili z autoextend. Kadar nismo

povsem prepričani glede velikosti datotek, lahko dodamo pogoj maksimalne velikosti

datoteke. Če bi datoteka presegla 60MB, z določitvijo max: 200M, razširimo dinamično

velikost datoteke do 200MB. Kadar ustvarite več datotek je priporočljivo, da se ustvari tudi

skupen »direktorij«, v katerih bodo shranjene te datoteke:

[Mysqld]

innodb_data_home_dir = / datoteka

innodb_data_file_path = datoteka1: 50M; datoteka2: 60M: autoextend: max: 200M

Lahko se nastavijo tudi absolutne vrednosti poti za podatkovne datoteke:

innodb_data_file_path = / dir/datoteka1: 50M

Nastavitvene parametre za InnoDB shranjevalni mehanizem, lahko prav tako nastavimo

glede na zahtevnost strojne opreme strežnika. S tem lahko optimiziramo sistem na višjo

raven in pri tem ne obremenimo delovanja strežnika. Podani primer nastvitvenih

parametrov je primeren za strežnike s kapaciteto delavnega pomnilnika 512MB in z

dvema trdima diskoma:

[mysqld]

innodb_data_file_path = disk1/ dir/datoteka1: 2000M ;/ disk2/ dir/datoteka2:

2000M: autoextend

#

# Strežniku lahko določimo maksimalno 50 – 80% pomnilnika

innodb_buffer_pool_size=256M

innodb_additional_mem_pool_size=20M

#

# Datoteki log dodelimo maksimalno 25% pomnilnika

innodb_log_file_size=64M


13

innodb_log_buffer_size=8M

#

innodb_flush_log_at_trx_commit=1

Splošne nastavitve za optimizacijo strežnika:

# Nastavitve za strežnik

[mysqld]

# Vrata omogočajo povezavo MySQL strežnika preko TCP/IP protokola

port = 3306

#

# Nastavitve za predpomnilnik moramo omejiti med 50% - 80% delavnega

pomnilnika

# strežnika

# Omejitev glede na bit operacijskega sistema

# 32-bit windows sistem lahko obremenimo na maksimalno 4GB

# 64-bit windows sistem dopušča večje obremenitve, omejitev je na 50% - 80%

maksimalne

# zasedenosti delavnega pomnilnika

key_buffer_size = 256M

#

# Največja velikost paketov - največja dovoljena velikost 1GB

max_allowed_packet = 1M

#

# Št. hkrati odprtih tabel

table_open_cache = 256

#

# Kadar pri povpraševanju sprožimo sortiranje podatkov z ORDER BY lahko pri

veliki

# količini podatkov zelo obremenimo strežnik

# Priporočljiva omejitev dovoljene velikosti je med 512kB in 2MB

sort_buffer_size = 1M

read_buffer_size = 1M

read_rnd_buffer_size = 4M

myisam_sort_buffer_size = 64M

thread_cache_size = 8


14

#

# Količina pomnilnika, ki je dodeljena za uporabo predpolnjenja poizvedb

query_cache_size= 16M

#

# Ni dostopa do MySQL strežnika z oddaljenega računalnika

skip-networking

#

# Replication Master Server (privzeto)

log-bin="STAS-bin"

#

# binary logg format - mixed priporočeno

binlog_format=mixed

#

# Id strežnika

server-id = 1

# Privzet shranjevalni mehanizem strežnika MySQL

default-storage-engine=INNODB

15

4 SHANJEVALNI MEHANIZMI OZ. TIPI TABEL

MySQL podpira različne shranjevalne mehanizme (angl. storage engines) za shranjevanje

tabel. Vsak shranjevalni mehanizem ima svoje prednosti in slabosti. Vsak izmed

mehanizmov je dokaj učinkovit, vendar z napačnim shranjevalnim mehanizmom lahko

oviramo zmogljivost delovanja.

Na primer, z Arhive shranjevalnim mehanizmom bomo manj učinkoviti pri branju in pisanju

istih tabel, kot če bi izbrali MyISAM. Torej izbira shranjevalnega mehanizma je zelo

pomembna pri delovanju podatkovne baze. Zato mora administrator PB zelo dobro

poznati delovanje posameznih mehanizmov, če želi, da njegova PB deluje po njegovih

željah. V nadaljevanju vam bomo predstavili nekaj najbolj pogosto uporabljenih

shranjevalnih mehanizmov.

Nekaj nasvetov pri izbiri shranjevalnega mehanizma:

Moramo vedeti, kolikšna je frekvenca zapisov.

Če je potrebna podpora transakcij.

Ali potrebujemo tuje ključe.

Zahteva po indeksiranju.

Velikost tabel in hitrost naraščanja.

Prenosljivost arhitekture tabel med operacijskimi sistemi.

Zahteve in prilagodljivost na spreminjajoče se zahteve glede podatkov.

Omeniti velja, da MySQL omogoča izbor shranjevalnih mehanizmov za posamezno

tabelo, s čimer lahko dobimo večjo uspešnosti delovanja PB. Torej, za tabele, ki bodo

namenjene dodajanju velikih količin podatkov, lahko izberete InnoDB. Tabele, katere bodo

obremenjene s transakcijami oz. veliko količino povpraševanj, je primernejši MyISAM

shranjevalni mehanizem. Izbor shranjevalnega mehanizma za posamezno tabelo je

edinstven za MySQL in je lahko ključnega pomena pri doseganju večje uspešnosti

delovanja PB.

16

V naši razpravi o shranjevalnih mehanizmih, bomo zajeli naslednje teme:

• MyISAM storage engine.

• InnoDB storage engine.

• MERGE storage engine.

• MEMORY storage engine.

• ARCHIVE storage engine.

• CSV storage engine.

• FEDERATED storage engine.

• NDB Cluster storage engine.

Nasvet: ob kreiranju nove tabele lahko dodate tudi možnost nastavitev shranjevalnega

mehanizma – CREATE TABLE (...) ENGINE=Storage engine, kjer je Storage engin eden

izmed zgoraj omenjenih shranjevalnih mehanizmov.

4.1 MyISAM Storage Engine

MyISAM je razširjena različica osnovnega ISAM shranjevalnega mehanizma s številnimi

dodatnimi optimizacijami in izboljšavami. MyISAM je optimiziran za hitrost in stiskanje ter

je prenosen med različnimi operacijskimi sistemi – enaka MyISAM tabela se lahko

uporablja v Windows in UNIX OS. Podpira velike tabele - velikosti vse do 256TB - ter

omogoča indeksiranje BLOB in TEXT stolpcev. Tabele in indeksi tabel se lahko stisnejo in

tako prihranimo prostor. Ta funkcija pride v poštev, ko shranjujemo velika BLOB ali TEXT

polja. VARCHAR polja lahko omejimo na določeno dolžino ali dinamično prilagodimo na

podatke v poljih, prav tako pa podpira iskanje zapisov katerega koli dela in pa tudi celoto.

Kot smo že omenili je MyISAM optimiziran prav za MySQL PB, zato ne preseneča, da so

izvajalci dodali veliko inteligence v ta shranjevalni mehanizem. Ob zagonu MySQL

samodejno preveri MyISAM tabele in v primeru napak le te tudi odpravi. Tabele podatkov

in indeksnih datotek je mogoče shraniti na različnih datotečnih sistemih. Zagotavlja visoko

zmogljivost ob velikih vnosih podatkov v tabele, pri posodobitvah in brisanju tabel. Velike

tabele je mogoče stisniti v manjše pakete, ki zasedejo manj prostora na disku.

Datoteke in imeniki

Vsi shranjevalni mehanizmi v MySQL uporabljajo eno ali več datotek za obdelavo operacij

v nizu podatkov, strukturiranih v skladu z arhitekturo shranjevalnega mehanizma. Imenik

17

data_dir vsebuje eno mapo za vsako shemo, ki je nameščena na strežniku. MyISAM ima

ločene datoteke za podatke o tabelah, indeksih in meta-podatkih:

table_name.frm – podatki o meta-podatkih,

table_name.MYD – podatki o vrsticah tabel,

table_name.MYI – podatki o indeksih.

MyISAM ima organizirane tabele tako, da jih lahko prenesemo z enega v drug strežnik na

preprost način, in sicer premaknemo le te tri omenjene datoteke. Ko se MySQL strežnik in

MyISAM zaženeta, strežnik najprej prebere datoteko table_name.frm, nato pa pridobljene

podatke, ki so podobni zapisu hash, shrani v predpomnilnik tabele.

■ Opomba: datoteka ni isto kot deskriptor datotek. Datoteka je zbirka podatkov, evidence

in podatkovnih strani, ki so povezane v logične enote. Deskriptor datotek je število, ki

ustreza datoteki oz. napravi, ki je odprta s posebnim postopkom. Naloga deskriptorja je,

da obvešča sistem, če je datoteka odprta za branje ali pisanje.

MyISAM uporablja samo indeksne podatke in ne beleži podatkov na straneh. Kot

sekvenčni dostop pomeni, da MyISAM zapisuje enega za drugim v eni sami datoteki

(.MYD). Zapise predpomnilnika bere preko IO_CACHE strukture v glavnem pomnilniku,

zapis za zapisom. Za razliko od InnoDB naloži in upravlja zapise podatkov v pomnilniku v

celoti, 16KB na stran. Torej, ker MyISAM podatkov ne shranjuje na disk v obliki strani, ne

zapravlja nepotrebnega prostora ob polnjenju med zapisi v datoteko .MYD (zato ima

dodaten prostor za vnašanje novih zapisov). Praktično gledano to pomeni, da je dejanski

del podatkov iz MyISAM tabele lahko manjši od enake tabele, ki jo upravlja InnoDB.

Vendar to dejstvo je zanemarljivo v primeru, ko se odločamo med shranjevalnimi

mehanizmi. Veliko lastnosti je, katere so bolj pomembne in pripomorejo k boljšemu

delovanju.

Za upravljanje indeksnih podatkov MyISAM uporablja 1KB strani (interno, razvijalci se na

to sklicujejo kot na indeks blok). Če bloka ni mogoče najti v predpomnilniku ključa, lahko

blok indeksa preberemo tudi z diska – temu služi .MYI datoteka.

Formati zapisov

Kadar analiziramo in ustvarjamo tabele (CREATE TABLE ali ALTER TABLE), MyISAM

določa dva različna formata zapisov tabel. Ali bomo podatke shranjevali v vsaki vrstici

tabele statične (fiksne) velikosti ali se bo dolžina podatkov v vsaki vrstici razlikovala

(dinamično).

18

Fizična oblika .MYD datoteke in evidence, ki jih vsebuje v datoteki, je odvisna od tega

razlikovanja.

Poleg fiksnih in dinamičnih oblik zapisa, shranjevalni mehanizem MyISAM pozna tudi

stisnjen format vrstic.

■ Opomba: MyISAM zapisi oblik se izvajajo v naslednjih izvornih datotekah:

- /myisam/mi_statrec.c (fiksni zapis), /myisam/mi_dynrec.c (dinamični zapis),

- /myisam/mi_packrec.c (stisnjen format zapisa).

1. Fiksni format zapisa

Kadar je format zapisa fiksne dolžine, bo .MYD dokumentacija vsebovala vsak zapis

MyISAM v zaporedju, z NULL bajtom (0x00) med vsakim zapisom. Vsak zapis vsebuje

bitno sliko zapisa glave. Omenimo naj, da se ta bitna slika ne navezuje na grafiko.

Bitna slika v programiranju pomeni skupek posameznih bitov, razporejenih v segmentih

(da bi jih uskladili v bitno strukturo), kjer je vsak bit v bajtu – »zastava«, katera predstavlja

neko stanje ali logično vrednost.

Na primer, bitna slika 1111 0101 v binarni (ali 0xF5 v šestnajstiški) obliki, ima drugi in

četrti bit izklopljen (nastavljen na 0), vsi ostali so vklopljeni (nastavljeni na 1). Upoštevajte,

da je bajt sestavljen iz bitov in je berljiv iz desne proti levi, torej prvi bit je najbolj desni bit.

MyISAM bitni zapis, glava za fiksne dolžine zapisov, je sestavljena iz naslednjih bitov v

tem vrstnem redu:

En bit predstavlja ali je bil zapis izbrisan - če je bit 0, pomeni, da se vrstica izbriše.

En bit za vsako polje v MyISAM shranjevalnem mehanizmu je lahko vrednost

NULL. Torej, če zapis vsebuje vrednost NULL v polju, pomeni, da ima bit vrednost

1, sicer je vrednost 0.

Skupna velikost glave zapisa bitne slike je odvisna od števila NULL zapisov oz. polj, ki jih

vsebuje tabela. Če tabela vsebuje osem NULL polj, torej od 0 – 7, je bitna slika glave

velikosti 1 bajt, 8 – 15 NULL polj, 2 bajta itn. Priporočljivo je, da se izogibamo poljem z

NULL vrednostjo, vendar ne bo praktičnega učinka na velikosti .MYD, razen, če tabela

vsebuje več kot sedem NULL polj. Po vsakem zapisu glave bodo vrednosti zapisov sicer v

vrstnem redu stolpcev, ki so opredeljeni v oblikovanju tabele. Upoštevati pa je potrebno,

da porabijo toliko prostora, kot zahteva vrsta podatkov. Ker se lahko zanese le na statično

dolžino vrstice podatkov za fiksni format zapisa, bo predpomnilnik, MyISAM

shranjevalnega mehanizma, vseboval informacije o največji dolžini vrstice podatkov. S

19

pomočjo te informacije, ko se podatki v vrsticah berejo vzporedno (skenirajo) po

posameznih MyISAM zahtevah za dostop, ni več potrebno preračunavati zamik zapisov v

predpomnilniku. Torej, namesto tega bo vedno nekaj x bajtov v predpomnilniku, kjer je x

največja dolžina vrstice »+« velikost glave bitne slike.

Kadar išče podatkovni zapis s ključem, predpomnilnik shranjevalnega mehanizma

MyISAM, lahko zelo hitro izvede iskanje potrebnih podatkovnih vrstic, s preprostim

množenjem vsote dolžine zapisa in velikosti glave bitne slike z interno številko zapisa, ki

je / se začne pri ničli. To omogoča hitrejši dostop do tabel s fiksno dolžino zapisov, vendar

lahko pride do povečanega dejanskega prostora na disku.

■Opomba: MySQL lahko »prisilite«, da uporabi specifičn format vrstic s pomočjo

možnosti ROW_FORMAT v vaši CREATE TABLE.

2. Dinamični format zapisa

Kadar MyISAM tabela vsebuje spremenljivo velikost tabel, kot so podatkovni tipi

VARCHAR, TEXT, BLOB ..., takrat je format zapisov v datoteko .MYD znan kot dinamičen

format zapisa. Podobno kot pri fiksnem formatu, ima prav tako vsak dinamični zapis

»glavo«, katera beleži podatke. Vsi ti podatki so zapisani v datoteki .MYD v točno

določenem zaporedju.

Glava dinamičnega zapisa je sestavljena iz več elementov. Ti elementi so:

Začetni element, ki zaseda 2 bajta, označuje začetek zapisa glave. To je potrebno

zato, ker se shranjevalni mehanizem ne more sklicevati na zapis glave, čeprav je

statično podoben fiksnemu formatu zapisa v .MYD datoteki.

Eden ali več bajtov, ki shranjujejo dejansko dolžino (v bajtih) zapisa.

Eden ali več bajtov, ki shranjujejo neuporabljeno dolžino (v bajtih) zapisa. MyISAM

pušča prostor v vsakem zapisu, ki omogoča podatku razširitev določene dodatne

velikosti, ne da bi morali premakniti zapis znotraj datoteke .MYD. Ta del zapisa v

glavi prikazuje, koliko prostega prostora še ostaja ob koncu vnosa podatkov

shranjenih v zapisu, torej na začetku naslednjega zapisa.

Bitna slika je podobna bitni sliki, ki se uporablja za zapis s fiksno dolžino, kar kaže

na NULL polja in ali je bil zapis izbrisan.

»Overflow« kazalec kaže na mesto v datoteki .MYD, ali je evidenca posodobljena

in ali zdaj vsebuje več podatkov, kot jih je bilo v prvotni dolžini zapisa. Lokacija

kazalca je preprosto naslov drugega zapisa, kjer je shranjeno preostanek zapisa

podatkov. Po tem zapisu v glavi se shrani dejanski podatek, nato sledi

neuporabljen prostor do naslednjega zapisa.

20

Dinamični zapis za razliko od fiksnega zapisa ne porabi celotne velikosti polja, ko se

vstavi vrednost NULL. Namesto tega shrani le eno vrednost NULL (0x00), namesto enega

ali več ničelnih vrednosti istega NULL polja zapisa s fiksno dolžino.

Pomembna razlika med fiksno in dinamično dolžino zapisa je povezana s posodobitvijo

zapisa. Za statično dolžino vrstice zapisa posodobitev podatkov nima nobenega vpliva na

samo strukturo zapisa, ker je dolžina podatkov, ki se vstavi enaka podatku, ki bo izbrisan.

Za razliko od dolžine vrstic zapisa v izrednem primeru, če bi morda vnosni podatek

presegel velikost, ki jo ima na razpolago. Izjemoma se lahko vstavi povezava v vrstico

naslednjega podatka, v katerem so ostali podatki (overflow kazalec). Razlog za to je

povezovanje, ki preprečuje potrebe za olajšanje preureditev več novih zapisov. Povezava

služi kot ogrodje za nove informacije, povezava bo opozorila na lokacijo naslova, ki je na

voljo na shranjevalnem mehanizmu v času posodobitve. Tovrstna razdrobljenost zapisov

podatkov lahko popravi ukaz optimizacija tabele (angl. OPTIMIZE TABLE) ali z zagonom

#> myisamchk-r.

Zaklepanje tabel v MyISAM

Da se zagotovi celovitost podatkov, shranjevalni motor MyISAM podpira samo eno vrsto

zaklepanja – zaklepanje tabele (angl. table locking). V določenih pogledih je lahko ta vrsta

zaklepanja »pomanjkljivost«, ampak za številne aplikacije se ta vrsta zaklepanja ter njeno

specifično izvajanje pri shranjevalnem mehanizmu MyISAM, precej dobro obnese oz.

deluje, in je lahko učinkovita tudi pri zelo visokih scenarijih vzporednosti.

MyISAM pozna tri različne tipe zaklepanja, glede na zahtevo jih povezuje »nit«:

Lokalno branje podatkov (angl. READ LOCAL): kadar povprašujemo s SELECT

stavkom, se v pomnilnik shrani kopija podatkovnega zapisa, nato MyISAM zaprosi

za READ LOCAL način zaklepanja podatkov. Ta tip zaklepanja ne preprečuje

vstavljanja v tabelo; če bodo podatki dodani, bodo dodani na konec datoteke. V

primeru, če bi želeli podatek vriniti v sredino podatkovne zbirke, moramo po

izvršitvi ukaza INSERT počakati, da se READ LOCK zaklepanje zaključi s

SELECT povpraševanjem.

Branje podatkov (angl. READ): v primeru, ko se .MYD datoteka uporablja zgolj za

pridobivanje informacij uporabniku (angl. client), se uporabi tip zaklepanja READ

(poimenovano tudi kot skupno zaklepanje). Z READ zaklepanjem onemogočimo

vse nadajljne operacije, kot so UPDATE, INSERT in DELETE.

21

Pisanje podatkov (angl. WRITE): zaklepanje se aktivira, kadar se nad določeno

tabelo izvajajo zahteve UPDATE, DELETE ,ali če prejme INSERT zahtevek, da naj

zapolni obstoječ prostor podatkovne zbirke, ki je bil prej izbrisan z ukazom

DELETE.

Torej, z READ LOCAL zaklepanjem, lahko MyISAM shranjevalni mehanizem, zapisuje

podatke v tabele brez zaklepanja za branje podatkov. Kako je to mogoče? MyISAM lahko

zahtevo INSERT, ki je bila zahtevana za tabelo s primarnim ključem (angl. primary key),

povečuje samodejno na konec indeks datoteke, za razliko od branja v indeksno datoteko,

da bi našli ustrezen prostor za vstavitev novih podatkov. Ker se nov ključ vedno doda na

konec indeksne datoteke za to vrsto datoteke, ni treba, da imajo SELECT operacije

zahtevane ključe ali podatke od kjerkoli drugje v tabeli. Iz teh razlogov je MyISAM odlična

izbira za tabele, katere večinoma beležijo podatke.

Na primer, izbor MyISAM je odlična izbira za tabele, ki vsebujejo podatke, do katerih

neprestano dostopamo, medtem ko se nemoteno dodajajo novi zapisi s frekvenco

dodajanja več tisoč zapisov na minuto.

Izbira indeksov

Čeprav dejanski podatki niso shranjeni v vrstnem redu primarnega ključa, MyISAM ne

vodi seznama kazalcev (kot interne številke zapisov) oz. podatka zapisov znotraj

indeksov. Ta ključ predpomnilnika vsebuje povezan seznam kazalcev, kateri se sklicujejo

na naslove v notranjosti datoteke .MYD, kjer so shranjeni dejanski podatki vrstic. Ne glede

na število indeksov, ki so »pritrjeni« na MyISAM tabele, se vsi indeksi izvajajo z uporabo

ne-nakopičene oz. gručaste organizacije. MyISAM podpira tri različne tipe indeksov, s

katerimi lahko pridobimo podatke s svojega ključnega predpomnilnika – B- drevo (angl. B-

tree), R-drevo (angl. R-tree) in FULL TEXT. [1][2][4][5]

4.2 InnoDB Storage Engine

Shranjevalni mehanizem InnoDB je bil prvič predstavljen v različici 4.0. Je zelo učinkovita

oblika tabel, ki zagotavlja polno podporo transakcij v MySQL ter ne ogroža hitrosti in

zmogljivosti. Maksimalna velikost InnoDB tabel je veliko manjša v primerjavi z MyISAM

tabelami, dosežejo lahko le do 64TB. Asinhroni vhod / izhod ter zaporedno branje izboljša

hitrost pridobivanja podatkov, s čimer optimizira datoteke in upravljanje pomnilnika.

22

Inno DB podpira samodejno ustvarjanje hash indeksov, kar izboljša uspešnost,

zanesljivost in hitrost delovanja baze podatkov kot rezultat. InnoDB tabele ujamejo, včasih

tudi presegajo, delovanje in uspešnost MyISAM tabele.

InnoDB tabele so prenosljive med različnimi različicami operacijskih sistemov, arhitektura

transakcij je zelo »stabilna« ter s preverjanjem napak ob zagonu naredi MySQL še bolj

robusten. Shranjevalni mehanizem InnoDB obravnava nekatere pomanjkljivosti MyISAM

shranjevalnega mehanizma. Zagotavlja izvršitev omejitve tujih ključev in vse transakcije

zmožne obdelovanja. Velika »moč« InnoDB shranjevalnega mehanizma izvira prav iz

zaklepanja, saj ima multiversion nadzor sočasnosti – MVCC (angl. multiversion

concurrency control). InnoDB ima podporo na več ravneh »izolacije« transakcij, kar

omogoča nadzor nad tem, kako so transakcije obdelane.

Izvrševanje razmerij tujih ključev

InnoDB uveljavlja referenčne integritete tujih ključev (angl. foreign key), razmerje na ravni

baze podatkov. Ob kreiranju nove tabele - CREATE TABLE, z dodanim tujim ključem, je

najprej potrebno preveriti klavzulo reference med tabelo »starš«, katera ima primarni ključ

in novo tabelo, da se preveri obstoj ključa, ko se vstavi zapis v tabelo »otrok«. Pogost

primer razmerja starš-otrok je enak scenariju stranka – naročilo in stranka – naročilnica –

postavka, kar pomeni, da lahko vsebuje eno ali več podrobnosti o naročilu.

Upoštevati je potrebno, da mora biti najprej kreirana tabela s primarnim ključem in šele

nato lahko kreiramo tabele s tujimi ključi, katere se sklicujejo na tabelo s primarnim

ključem.

Primer kreiranja tabel, katere bodo v relaciji stranka – naročilnica – postavka:

mysql> CREATE TABLE stranka (

> id INT NOT NULL AUTO_INCREMENT,

> ime_priimek VARCHAR(30) NOT NULL,

> naslov VARCHAR(100) NOT NULL,

> PRIMARY KEY (id)) ENGINE = INNODB;

mysql> CREATE TABLE narocilnica (


> stranka_id INT NOT NULL,

> datum_narocila INT NOT NULL,

> PRIMARY KEY (id),

> FOREIGN KEY (stranka_id) REFERENCES stranka (id)) ENGINE = INNODB;

23

mysql> CREATE TABLE postavka (


> narocilo INT NOT NULL,

> produkt VARCHAR(30) NOT NULL,

> PRIMARY KEY (id),

> FOREIGN KEY (narocilo) REFERENCES narocilnica (id)) ENGINE = INNODB;

Zaklepanje tabel v InnoDB

Raven privzetega zaklepanja InnoDB shranjevalnega mehanizma je zaklepanje vrstic.

Prav tako lahko zaklene celotno tabelo, kot MyISAM. Zaklepanje tabel je bolj učinkovito iz

pomnilniške perspektive, medtem ko zaklepanje vrstic je ključnega pomena za aplikacije,

katere namen je velika frekvenca branja, pisanja in je pri tem odločilna hitrost ter pogosta

posodobitev podatkov.

Porodi se vprašanje, kako je lahko zaklepanje celotne tabele bolj učinkovito, saj veže večji

blok zapisov. Pri zaklepanju tabel, MyISAM »postavi ključavnico« na informacijsko

strukturo tabel, katera nit je v skupni rabi branja in pisanja. Uporabi se le en sam zapis, ki

poteče v relativno kratkem času (navadno nanosekundi). Raven zaklepanja vrstic beleži

velik logični blok informacij o zaklenjenih vrsticah, nad katerimi se izvajajo transakcije,

posledično obremeni procesor in pomnilnik. InnoDB pri zaklepanju vrstic uporablja

notranjo tabelo, ki vsebuje podatke o ključih. Podoben učineku hash stiskanja, kateri

beleži primarne ključe tabel (eden izmed razlogov, zakaj InnoDB tabele moraj imeti

primarni ključ).

Pri sistemih, kjer je velika verjetnost, da bo več uporabnikov hkrati sprožilo zahtevek po

transakciji UPDATE ali SELECT, je priporočeno izbrati možnost OLTP/OLAP4.

Kadar zaklepamo celotno tabelo, mora zahtevek za branje počakati, da se zahtevek za

pisanje v celoti konča, šele nato lahko beremo podatke v tabeli. Pri zaklepanju vrstic pa

velja samo za vrstico, nad katero se izvaja zahtevek pisanja, za vse ostale podatke v

tabeli pa se lahko zahteva zahtevek za branje podatkov. Zaklepanje vrstic in shranjevalni

mehanizem InnoDB sta odlična kombinacija, kadar se odločamo med shranjevalnimi

mehanizmi, katerih bo privzeta naloga izvajanje velikih frekvenc pisanja in branja

podatkov.

Prav tako kot MyISAM, InnoDB izvaja mehanizem, ki omogoča vstavljanje podatkov na

konec podatkovne datoteke, kar je v primeru InnoDB vedno konec nakopičenih indeksov,

brez hkratne izdaje izključnega zaklepanja tabele.

24

Datoteke in imeniki

Organizacija datotek v InnoDB je drugačna, kot v MyISAM. Med tem, ko strežnik MySQL

vzdržuje datoteko .frm za vsako tabelo InnoDB, podobno pri MyISAM, InnoDB ohranja

tudi svoje meta informacije o svojih tabelah. S tem ni mogoče na preprost način prenesti

InnoDB bazo podatkov iz enega strežnika v drugega s pomočjo kopiranja tabel. Privzeto

se vse InnoDB tabele zgledujejo po zasnovi Oracle z istim imenom. Tabele so sestavljene

iz več datotek, njihova velikost je omejena na velikost operacijskega sistema in se

dinamično spreminja. V datoteki my.ini, se privzeto ime začne z ibdata in nato s številko.

Primer iz datoteke:

innodb_data_home_dir = /usr/local/var/

innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend

V ibdata so vsi podatki o tabelah in indeksih InnoDB tabel. Ibdata datoteke se nahajajo v

innodb_data_home_dir, med tem, ko so .frm datoteke v glavnem imeniku MySQL –

data_dir. Datoteka je sestavljena z InnoDB, kar pomeni, da tvori prostor tabel InnoDB.

Tabele lahko vsebujejo poljubno število datotek, autoextend funkcija zagotavlja, da lahko

velikost tabel sorazmerno narašča z bazo podatkov. To pomeni tudi, da omejene velikosti

datotek (na primer, 2GB v večini distribucij) je mogoče »prekoračiti«, saj lahko tabela

vsebuje več datotek, za razliko od MyISAM (.MYD datoteka).

Tabele imajo dve »notranji« datoteki oz. segmenta, vendar ti segmenti niso vidni. En

segment se uporablja za gručaste podatkovne strani indeksa, drug segment se uporablja

za sekundarne indekse, ki temeljijo na gručastem ključu. Razlok za to je narejen tako, da

se lahko zapisi zaporedno dodajo v velike bloke, tako podatke kot tudi sekundarne

indekse strani v tabeli.

Za izvajanje sistema InnoDB za procesiranje transakcij, nastanejo tudi dnevniki datotek. V

datoteki my.ini lahko nastavimo parametre, kje se shranjujejo dnevniki:

innodb_log_group_home_dir = /usr/local/var/

innodb_log_arch_dir = /usr/local/var/

To so imeniki, kjer so shranjene glavne log datoteke in log arhivi datotek. Privzeto so te

datoteke poimenovane ib_logfile in nato sledi število, ki predstavlja segment dnevnika. Od

različice MySQL 4.1.1 naprej se lahko določi, da se organizacija datotek formata InnoDB,

nastavi tudi za MyISAM shranjevalni mehanizem. Da omogočimo to obliko datoteke,

vstavimo opcijo innodb_file_per_table pod odsek Mysqld v my.ini datoteki. Vendar ne

smemo pozabiti, da se ta možnost ne sme onemogočiti in niti ne sme dovoliti, da se

25

prenese InnoDB shema na drug računalnik s kopiranjem .ibd datotek, kot to lahko storimo

z .MYD datotekami, MyISAM shranjevalnega mehanizma.

■Opomba: trenutni tabeli ni mogoče ročno dodeliti več ibdata datotek, zato ni možno, da

so InnoDB tabele shranjene ločeno na več ločenih diskovnih ali drugih napravah.

Organizacija podatkovne strani

InnoDB shranjuje, tako na disku kot tudi v pomnilniku, podatke o zapisih in indeksih v

16KB velikih straneh. Strani so organizirane v datotekah ibdata kot obseg 64 zaporednih

strani. Razlog za to je, da zagotovi dovolj velik del prostora na disku in v pomnilniku, da se

lahko, kolikor je le mogoče, podatki zapisujejo sekvenčno. To je proaktivno stališče pri

vzdrževanju, na način defragmentacije sistema.[1][2][4][5]

Ostali shranjevalni mehanizmi

Čeprav sta MyISAM in InnoDB najpogosteje uporabljena shranjevalna mehanizma,

MySQL ponuja tudi druge shranjevalne mehanizme, ki so bolj specifični.

4.3 MERGE Storage Engine

Je virtualna tabela, kombinacija več MyISAM tabel, ki so združene v eno samo tabelo.

Takšna kombinacija tabel je mogoča le v primeru, da imajo vse tabele, ki so vključene,

popolnoma identično strukturo tabel. Vsaka razlika v vrsticah ali indeksih lahko prepreči

uspešnost združitve tabel. MERGE shranjevalni mehanizem uporablja indekse njegovih

združitvenih tabel. Torej nima svojih lastnih indeksov, kar pomeni, da ne moremo izboljšati

hitrosti delovanja. Omogoča SELECT, DELETE in UPDATE operacije ter je zelo priročno,

kadar združujemo podatke različnih tabel. Pospeši delovanje združitve in iskanja med več

tabelami.

26

Spajanje tabel iz več tabel MyISAM:

mysql> CREATE TABLE primer1 (

-> id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

-> ime_priimek CHAR(20));

mysql> CREATE TABLE primer2 (

-> id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

-> prebivalisce CHAR(20));

mysql> INSERT INTO primer1 (ime_priimek) VALUES ('Staš Kopina'),('tabela1');

mysql> INSERT INTO primer2 (prebivalisce) VALUES ('Maribor'),('tabela2');

mysql> CREATE TABLE virtual (

-> id INT NOT NULL AUTO_INCREMENT,

-> sporocilo CHAR(20), INDEX(id))

-> ENGINE=MERGE UNION=(primer1,primer2);

Upoštevati je potrebno, da so definicije stolpcev v vseh treh tabelah enake. Namesto

primarnega ključa, ki je opredeljen v spajanju tabel, je normalen indeks, ki se uporablja za

kolone.

Primer MyISAM tamele – beleženje prometa letališča:

mysql> CREATE TABLE dnevnik_prometa (

> id INT UNSIGNED NOT NULL AUTO_INCREMENT,

> destinacija_potovanja VARCHAR(255) NOT NULL,

> tip_letala VARCHAR(255) NOT NULL,

> datum_poleta TIMESTAMP NOT NULL,

> PRIMARY KEY (id),

> INDEX (datum_poleta, destinacija_potovanja(30))) ENGINE=MYISAM;

Čeprav je ta tabela preprosta, se lahko hitro napolni z veliko informacijami tekom enega

meseca. Predstavljajmo si, da se tekom meseca v naši tabeli, dnevnik_prometa, zabeleži

20.000 podatkov. Sčasoma bo količina podatkov zavzela veliko prostora na disku. Da bi

rešili nastalo zmedo velike tabele, lahko ustvarimo mesečne tabele, poimenovane

dnevnik_prometa_yymm, kjer je yy leto in mm mesec. Za izdelavo poročila na koncu leta,

preprosto kreiramo novo tabelo s shranjevalnim mehanizmom MERGE, katera bo

ustvarila virtualno tabelo in s tem povezala vse tabele, ki jih želimo združiti.

27

Kreiranje MERGE tabele, združenje tabel:

mysql> CREATE TABLE dnevnik_prometa_12 (

> id INT UNSIGNED NOT NULL AUTO_INCREMENT,

> destinacija_potovanja VARCHAR(255) NOT NULL,

> tip_letala VARCHAR(255) NOT NULL,

> datum_poleta TIMESTAMP NOT NULL,

> INDEX (id),

> INDEX (datum_poleta, destinacija_potovanja(30)))

> ENGINE=MERGE

>UNION=(dnevnik_prometa_1201, dnevnik_prometa_1202, dnevnik_prometa_1212)

> INSERT_METHOD=NO;

S tem smo ustvarili tabelo s podatki za celotno leto 2012. V nastavitvenem parameteru

UNION, določimo katere tabele vse bomo povezali v eno samo tabelo.

INSERT_METHOD=NO, nastavitveni parameter, ki omogoča enkratno vstavljanje zapisa

v tabelo. Ustvarili smo indekse na id, datum_poleta in destinacija_potovanja, ker se bo

večina povpraševanj zahtevalo prav po teh stolpcih, ki so združeni v novi tabeli.

Upoštevati je potrebno tudi, da nismo definirali primarnega ključa v MERGE tabeli, saj bi

povzročilo napako. Do napake bi prišlo, ker MERGE shranjevalni mehanizem za združitev

ne more uveljaviti primarnega ključa nad združenimi UNION tabelami.

Sedaj imamo lažji dostop do vseh podatkov.

Zbrani podatki MERGE tabele:

mysql> SELECT LEFT(destinacija_potovanja, 30) AS 'Destinacija',

>COUNT(*) AS 'Št. poletov'

> FROM dnevnik_prometa_12

> WHERE datum_poleta BETWEEN '2012-01-01' AND '2005-01-10'

> GROUP BY LEFT(destinacija_potovanja, 30)

> HAVING 'Št. poletov' > 20

> ORDER BY 'Št. poletov' DESC

> LIMIT 5;

Rezultat povpraševanja nam vrne prvih pet najbolj obiskanih destinacij (ki so omejene na

30 znakov), v prvih desetih dneh januarja 2012 in število poletov, večje od 20.

28

Zavedati se je potrebno, da ima MERGE tabela tudi nekatere pomembne omejitve. Ne

morete uporabiti REPLACE zahtevka na MERGE tabelo, UNIQUE INDEX se ne izvaja na

celoto nabora kombiniranih podatkov. [1][2][4][5]

4.4 MEMORY Storage Engine

MEMORY shranjevalni mehanizem shranjuje svojo celotno vsebino zapisov, podatke in

indekse v pomnilnik. Za svoje delovanje uporablja hash indekse, kar pripomore k

hitrejšemu delovanju - deluje vsaj 30 odstotkov hitreje kot MyISAM. So dostopni in

delujejo na enak način kot MyISAM ali ISAM. Podatki, ki so shranjeni v Memory tabelah,

so nam na voljo le v času trajanja MySQL strežnika, to pomeni, če se strežnik MySQL

zruši ali izklopi, se podatki izbrišejo - ta lastnost je velika pomanjkljivost shranjevalnega

mehanizma Memory.

Čeprav tabela nudi zmogljivost pri doseganju hitrosti, so primernejše, če jih uporabljamo

za začasno shranjevanje in upravljanje s podatki. Zato je zelo pomembno vedeti, da vsi

podatki, shranjeni v MEMORY tabeli, služijo zgolj kot začasen podatek in bo možno ta

podatek z lahkoto pridobiti z aplikacijo ali skripto. Ko ustvarimo MEMORY tabelo se

ustvari datoteka table_name.frm, ki vsebuje definicije tabel. Nahaja se v imeniku

/data_dir/schema_name. Da se izognemo ustvarjanju MEMORY tabel po vsakem novem

zagonu sistema, imamo možnost, da v ukazno vrstico vnesemo ukaz --init-file=file,.

Datoteka naj vsebuje SQL stavek, ki se uporablja za zapolnitev MEMORY tabele iz

obstoječih tabel.

Veliko krat se nam zgodi, da za določene poizvedbe, ki si jih želimo poenostaviti,

potrebujemo dodatne tabele s katerimi bomo operirali samo enkrat. Takrat je idealno, da

si kreiramo MEMORY tabelo in vanjo s preprostim SQL ukazom napolnimo podatke:

INSERT INTO letala_memory SELECT tip_letala FROM dnevnik_prometa_12;

Ko kreiramo MEMORY tabelo lahko neposredno v izjavi CREATE TABLE implementiramo

algoritme indeksov, npr. B-drevo:

mysql> CREATE TABLE dnevne_cene_vozovnic

> let VARCHAR(8) NOT NULL,

> prvi_razred DECIMAL(6,2) NOT NULL,

> ekonomski_razred DECIMAL(6,2) NOT NULL,

> datum DATE NOT NULL,

> INDEX USING BTREE (datum, vir)) ENGINE = MEMORY;

29

Kaj je začasna tabela? Ali je isto kot tabela, ki je ustvarjena kot Memory shranjevalni

mehanizem?

Začasna tabela in tabela Memory nista enaki. Memory tabela deluje na osnovi

»mehanizem = spomin«, kar je v nasprotju z začasno tabelo, katera je ustvarjena, da

obstaja le v času delovanja strežnika oz. deluje za eno sejo odjemalca.

Začasna tabela je podprta v vseh shranjevalnih mehanizmih za shranjevanje podatkov v

PB MySQL, vendar se samodejno izbrišejo, ko zapremo povezavo s strežnikom.

Kot taka pride v poštev za prehodne seje, ki temeljijo na shranjevanju podatkov ali

izračunov. Ker ni odvisna od sej, lahko dva popolnoma različna mehanizma hkrati

souporabljata isto tabelo, ne da bi prišlo do nasprotij. [1][2][4][5]

4.5 ARCHIVE Storage Engine

Zagotavlja način shranjevanja velikih zapisov, ki so vidni kot manjši berljivi zapisi v

stisnjeni obliki. Ključna značilnost tega shranjevalnega mehanizma je njegova sposobnost

za stiskanje zapisov, vstavljanje in razširjanje. Mehanizem je podprt s strani zlib knjižnice

– programska oprema za stiskanje podatkov. Ima odlične lastnosti za shranjevanje

dnevnikov in arhivnih podatkov, kateri zavzemajo preveč prostora na disku. Archive

shranjevalni mehanizem ni namenjen za pogosto branje podatkov, podpira le INSERT in

SELECT operacije. Ne podpira indeksov, kar pomeni, da opravlja popolno skeniranje

tabel v času branja. Archive ima boljše lastnosti stiskanja kot MyISAM, saj podpira

operacije branja in pisanja ter porabi manj prostora na disku. ARCHIVE shranjevalni

mehanizem v MySQL ni privzeto določen in ga je potrebno ročno dodat v datoteko z

nastavitvenimi parametri, kar storimo tako, da v ukazno vrstico vnesemo ukaz:

--with-archive-storage=engine option.

Indeksi niso dovoljeni v tabelah ARCHIVE. Edina metoda za pridobivanje podatkov temelji

na skeniranju celotne tabele podatkov. [1][2][4][5]

4.6 FEDERATED Storage Engine

Podpira dostop do baze podatkov na oddaljenih strežnikih. Do podatkov dostopamo na

enak način, kot bi to storili na lokalnem strežniku, saj nima svojih lastnih tabel in služi zgolj

povezovanju. FEDERATED v MySQL ni privzet shranjevalni mehanizem, zato je treba z

ukazom --with-federated-storage-engine optimizirati, da želimo uporabiti ta tip tabele. Ko

je ustvarjen shranjevalni mehanizem - ENGINE=FEDERATED, se na lokalnem strežniku

ustvari .FRM datoteka. To pomeni, da se tabele in vse nastale datoteke kreirajo na

30

oddaljenem strežniku. Ko dostopamo do zapisov s pomočjo FEDERATED shranjevalnim

mehanizmom, MySQL uporablja mysql odjemalec API, katerega naloga je, da posreduje

zahtevane podatke iz oddaljenega v lokalni strežnik. Potrebno je omeniti, da pri

pridobivanju podatkov iz oddaljenega strežnika s pomočjo FEDERATED shranjevalnim

mehanizmom, ohrani prvotni tip tabele, kar pomeni, da če povprašujemo iz InnoDB tabel,

bo mehanizem poskrbel, da se podatki pretvorijo nazaj v prvotno stanje – v InnoDB.

[1][2][4][5]

4.7 Napotki pri izbiri shranjevalnih mehanizmov

Spoznali smo lastnosti posameznih shranjevalnih mehanizmov, njihove prednosti in

slabosti. MySQL ponuja možnost, da znotraj iste podatkovne baze, vsaki tabeli dodelimo

drug shranjevalni mehanizem in s tem prilagodimo zmogljivost. Za izbor idealnega

shranjevalnega mehanizma je treba skrbno preučiti algoritme, ki se izvajajo nad indeksi,

za ustrezno vrsto podatkov, ki jih želimo shraniti. Shranjevalni mehanizmi se med seboj

razlikujejo, posledično zagotavljajo različne algoritme indeksov.

Pri izbiri indeksnih algoritmov bo na primer InnoDB izbral algoritem B-drevo ali hash

indeks, kateri temelji na oceni nabora podatkov. V primeru, ko izberemo FULL TEXT ali

»prostorsko« indeksiranje, je najboljša in trenutno edina možnost, da izberete MyISAM.

Prav tako je najboljša izbira takrat, kadar shranjujemo veliko podatkov in hkrati ne

izvajamo, oz. zelo poredko, da posodabljamo (UPDATE) ali brišemo (DELETE) podatke.

Pri poizvedbi COUNT, je priporočljivo izbrati shranjevalni mehanizem MyISAM, saj

področje MyISAM indeksiranja zagotavlja takojšnje rezultate poizvedb, medtem ko

InnoDB pri veliki količini podatkov razpade, ker mora skenirati indeksne podatke, da bi

našel število vrstic v tabeli. Zasledili smo podatek, da razvijalci odpravljajo tovrstno

napako in izboljšujejo tovrstno poizvedbo.

Za obdelavo transakcij in pri določenih aplikacijah, katere pogosteje upravljajo prijavo v

sistem (lahko pride do več prijav hkrati), je primernejši InnoDB shranjevalni mehanizem.

Prav tako ima InnoDB lastnost uveljavitve omejitev tujih ključev v primeru, ko imamo

relacijo med dvema tabelama, ki je povezana s tujim ključem. Zelo priporočljiv je pri

aplikacijah za spletne strani, katere uporabljajo seje (angl. session), saj temelji na

intenzivni ažurnosti sej spletnih aplikacij. Nove seje so ustvarjene, spremenjene ali

uničene v ciklu novih prejetih zahtev HTTP. Zaradi tega so seje nato razporejene in vnovič

preslikane v tabelo podatkov. Tukaj pride v poštev lastnost InnoDB shranjevalnega

mehanizma, katera temelji na ravni zaklepanja vrstic, saj omogoča hiter in takojšen

dostop prošenj transakcij branja in pisanja. V današnjem hitrem tempu življenja hočemo,

31

da sta hitrosti odzivov na spletu zelo hitri, torej v tem primeru bi lahko pomislili na

shranjevalni mehanizem MEMORY, katerega lastnost je prav hitrost, vendar so razlog,

zakaj je vseeno boljše izbrat InnoDB. Razlog je, da MEMORY shranjevalni motor ne

podpira TEXT in BLOB podatkov, saj ne more vključiti besedila v hash algoritem. Spletne

seje podatke shranjujejo prav v TEXT, kot serijski niz vrednosti.

Zelo pomembno je, kadar se odločamo kateri tip shranjevalnega mehanizma izbrati, da se

predvsem zavedamo tega, da z »življenjsko dobo« podatkovne baze, kot tudi aplikacije,

lahko pride do sprememb podatkov, aplikacije ... Priporočljivo je tudi, da si ustvarimo

testno okolje in predvidene spremembe vedno prej testiramo v testnem okolju.[1][2][4][5]

32

5 VARNOSTNI VIDIKI V MYSQL

V tem poglavju vam bomo predstavili, kako administrator skrbi za varnost podatkovne

baze, kako nadzoruje uporabnike, ki souporabljajo podatkovno bazo.

5.1 Uporabniki in njihove pravice

Dodeljevanje uporabniških pravic uporabnikom je zelo pomembno opravilo

administratorja, saj mora skrbno poznati delovanje MySQL-a, kako preverja privilegije

uporabnikov. MySQL upravlja nize tabel, ki so v podatkovni bazi. Ena izmed teh tabel je

tabela, ki beleži »dodeljene« oz. odobrene pravice uporabnikom (angl. grant table). Ob

zagonu strežnika se vsebina tabele naloži v pomnilnik sistema. Kadar ročno spreminjamo

tabelo za dodajanje pravic uporabnikom (v MySQL 5.0.2+ različicah), se hkrati podatki

tudi takoj dodajo v pomnilnik.

Drugi podatkovni strežniki uporabljajo še dodatno shemo dodeljevanja pravic, dve osnovni

obliki, ki sta prav tako v MySQL: odobreno (angl. granted), preklicano (angl. revoked) in

privzeto (angl. default). Kadar je uporabniku dodeljena privzeta vloga pravic, podeduje

celoten nabor dovoljenj skupine, kateri pripada. MySQL ne podpira skupin in tako ni

mogoče podedovati lastnosti dodeljenih pravic, drugih uporabnikov.

Primer sintaks:

GRANT priv_type ON {*.* | * | db_name.* | table_name} TO username;

REVOKE priv_type ON {*.* | * | db_name.* | table_name} FROM username;

V MySQL so pravice uporabnikov razdeljene na več različnih ravneh uporabe, in sicer:

globalno (angl. global), na ravni podatkovne baze (angl. database), tabele (angl. table),

stolpcev (angl. column) in rutinsko (angl. routine). Prav tako v istem vrstnem redu MySQL

preverja stopnjo privilegijev uporabnikov. Najprej v najvišji stopnji (globalno) in če tukaj ne

najde potrebnega privilegija, išče naprej po stopnjah navzdol. Ko se privilegij na ustrezni

ravni najde, se zahtevi ugodi. Dodeljenih je lahko več privilegijev na različnih ravneh

hkrati.

33

Globalno področje privilegijev

Privilegiji tabele mysql.user so v celoti na najvišji ravni privilegijev – globalni. Prav tako

velja, da so vse podatkovne baze na strežniku enako priviligirane. Administrator mora

uporabniku, kateremu dodeli globalni privilegij povsem zaupati, saj mu s tem omogoča

celoten nabor opravil, s katerimi lahko operira nad podatkovno bazo.

Primer, kako uporabniku dodati področje globalnega privilegija:

mysql> GRANT PROCESS ON *.* TO 'root'@'localhost';

Query OK, 0 rows affected (0.00 sec)

Za spreminjanje tabele s stavkom ALTER TABLE, mora imeti uporabnik privilegij za

CREATE, ALTER in INSERT. ALTER omogoča uporabniku, da preimenuje tabelo, vendar

hkrati s tem tvegamo, da trenutni uporabnik preimenuje tabele, ki jih uporablja MySQL.

Hkrati se lahko določi tudi več privilegijev, katere med sebolj ločimo z vejico:

mysql> GRANT SELECT, INSERT, DELETE, UPDATE ON *.*

-> TO 'username'@'localhost';


Področje privilegijev za podatkovno bazo

Uporabniku, kateremu je dodeljen privilegij za raven podatkovne baze, lahko dostopa in

upravlja podatkovno bazo, za katero je pridobil privilegij. S tem pridobi tudi privilegije nižjih

slojev, torej privilegije na ravni tabel, stolpcev in rutin. Za dodelitev tega privilegija sta

možna dva načina, in sicer s sintakso, kjer lahko takoj določimo, za katero podatkovno

bazo uporabniku dodeljujemo privilegij, ali samo z »*«, kar pomeni, da dodeljujemo

privilegij za trenutno podatkovno bazo (pomanjkljivost drugega načina je, da v primeru, če

ni trenutne podatkovne baze, posledično uporabnik prejme privilegij na globalni ravni – kar

lahko privede do varnostnega tveganja).

Primer sintakse, kjer uporabniku takoj določimo privilegij določene podatkovne baze:

mysql> GRANT SELECT ON podatkovna_baza.*

-> TO 'username'@'localhost', 'username_2'@'localhost';


Področje privilegijev za tabele

Uporabnik prejme privilegij samo za določeno tabelo. Primer sintakse, kjer ustvarimo

novega uporabnika, mu dodelimo privilegij za določeno tabelo, hkrati ga omejujemo, da

bo lahko opravil le operacije branja, vstavljanja, spreminjanje vrednosti in brisanje

podatkov:

34

mysql> GRANT SELECT, INSERT, UPDATE, DELETE

-> ON podatkovna_baza.tabela TO 'nov_uporabnik'@'primer.si';


Področje privilegijev za začasne tabele

Uporabniku lahko na enak način, kot ostalim tabelam, dodelimo privilegij za začasno

tabelo, vendar hkrati prejme vse privilegije za »nadrejeno« tabelo. V MySQL ni podprt

ločen način dodeljevanj pravic, torej prvotnim in začasnim tabelam. Kadar smo v položaju,

da določenemu uporabniku res ne želimo dodeliti privilegijev prvotne tabele, ampak le za

začasno tabelo, Dietrich Feist na spletni strani MySQL opisuje način, kako je mogoče

rešiti nastali problem.

»Priporoča, da ustvarite ločeno podatkovno bazo, izključno za delo z začasnimi tabelami.

Le tako lahko določite ločene privilegije.

Naslednji koraki opisujejo vzpostavitev ločene podatkovne baze za začasne tabele:

1. Ustvarite podatkovno bazo za začasne tabele:

mysql> CREATE DATABASE zacasna;

2. Dodelimo privilegije uporabniku za delo v novi podatkovni bazi:

mysql> GRANT SELECT, INSERT, UPDATE, DELETE,

->DROP, ALTER, CREATE TEMPORARY TABLES

-> ON zacasna.*


3. Globalni privilegij za tabelo podjetje, ki je v prvi bazi, kjer:

mysql> GRANT SELECT, INSERT, UPDATE, DELETE

-> ON podjetje.*


Treba je vedeti, da username (uporabnik) potrebuje predpono CREATE TEMPORARY

TABLE s predpono zacetna. (predstavlja podatkovno bazo), če je bila tabela ustvarjena v

drugi podatkovni bazi.

mysql> USE podjetje;

mysql> CREATE TEMPORARY TABLE zacetna.zaposleni SELECT * FROM

zaposleni;

Postopek je podoben pristopu, kako drugi strežniki podatkovnih baz omogočajo, da

upravljate z različnimi nabori dovoljenj za tabele in začasne tabele.«

35

Področje privilegijev za stolpce

Priviligiramo lahko tudi posamezne stolpce (en ali več stolpcev) znotraj tabele:

mysql> GRANT SELECT (stranka_id, prijava, ime_priimek, postna_st)

-> ON trgovina.stranka TO 'username'@'localhost';


V primeru, da uporabniku izrecno ne določimo privilegija za dodajanje novih podatkov,

pride do odstopanja SQL standarda, saj je dodajanje podatkov privzeta operacija.

Rutinsko področje privilegijev

Pri rutinskem privilegiju določimo uporabniku, katere funkcije lahko izvaja v podatkovni

bazi. V primeru, ko dodeljujemo rutinski privilegij za določeno podatkovno bazo, ki še ni

bila ustvarjena, MySQL standard to dopušča in velja le za podatkovno bazo. Torej, če bi

želeli dodeliti privilegij za stolpce ali tabele, katere še niso ustvarjene znotraj podatkovne

baze, žal tega ne moremo storiti vnaprej. To lahko storimo šele takrat, ko so stolpci oz.

tabele ustvarjene.

Primer: navesti je potrebno podatkovno bazo, rutinsko ime oz. funkcijo.

mysql> GRANT EXECUTE ON podatkovna_baza.ShowIndexSelectivity TO

'username'@'localhost';


Način, kako MySQL preverja privilegije in nadzoruje dostop uporabnikov

MySQL svoje nadzorniške procese »izvršuje« po dveh korakih. V prvem koraku procesa

MySQL identificira uporabnika in nato v drugem koraku določi, s čim lahko operira

uporabnik – preveri uporabnikove privilegije. Slika 5.1 prikazuje potek procesa, ki se

izvaja, ko MySQL preverja privilegij uporabnika. Če uporabnik ne izpolnjuje vseh meril za

dostop, MySQL vrne kodo napake, ki opisuje ustrezen razlog zavrnitve zahtev.[1]

36

Slika 5-1 Diagram prikazuje postopek preverjanja privilegijev uporabnika[1]

Dodajanje novih uporabnikov

Kot smo že na začetku omenili, ima MySQL dva načina vnosa nastavitvenih parametrov in

tudi v tem poglavju bomo opisali postopek vnosa uporabnikov s pomočjo MySQL

Workbench.

Opozorilo: kadar želimo upravljati z uporabniškimi računi, moramo najprej poskrbeti za

povezavo s strežnikom, in sicer z uporabnikom, ki ima privilegij GRAND OPTION oz. je

skrbnik zbirke podatkov.

37

Vsa administrativna opravila lahko izvajamo le z root uporabnikom, seveda, če tega

izrecno ne priviligiramo drugemu uporabniškemu računu. V MySQL Workbench,

natančneje v tretjem sklopu – Server Administration, se prijavimo kot root uporabnik. Ob

prijavi s strežnikom so nam ponujene možnosti upravljanja s strežnikom, kot tudi možnost

dodajanje novih uporabnikov in njegovih privilegijev (angl. Users and Privileges), kot je

razvidno s Slike 5-2.

Dodajanje novega uporabnika začnemo s klikom na gumb Add Account v zavihku Server

Access Management. Ponujeni so nam trije »podzavihki«: prijava (angl. Login), nastavitev

privilegijev (angl. Administrative Roles) in omejitve računa (angl. Account Limits).

Login – vnos naslednjih podatkov:

prijavno oz. uporabniško ime (angl. Login Name),

Authentication Type, obdržimo privzeto nastavitev na »Standard«, saj s tem

določimo, da za preverjanje uporabnika, njegovega gesla in privilegijev uporabimo

zgoraj opisan postopek preverjanja (Slika 5-2),

Limit Connectivity to Hosts Matching, s tem uporabniku določimo gostitelja oz.

strežnik, do katerega bo lahko dostopal. Privzeta nastavitev »%« se navezuje na

privzeti strežnik (angl. localhost),

ter na koncu še vnos gesla.

Administrative Roles:

Na voljo imamo več različnih administratorjev, katere smo opisali že v poglavju

Namestitev. Vsak ima svoje privilegije, izberemo lahko več administratorskih

privilegijev, ponujena je tudi možnost, da sami izberemo, katere privilegije bomo

določili novemu uporabniku:

o ALTER

o ALTER ROUTINE

o CREATE

o CREATE ROUTINE

o CREATE TABLESPACE

o CREATE TEMPORARY TABLES

o CREATE USER

o CREATE VIEW

o DELETE

o DROP

o EVENT

o EXECUTE

38

o FILE

o GRANT OPTION

o INDEX

o INSERT

o LOCK TABLES

o PROCESS

o REFERENCES

o RELOAD

o REPLICATION CLIENT

o REPLICATION SLAVE

o SELECT

o SHOW DATABASES

o SHOW VIEW

o SHUTDOWN

o SUPER

o TRIGGER

o UPDATE

Omejitve računa:

Max. Queries: omejimo št. povpraševanj v eni uri,

Max. Updates: št. posodobitev v eni uri,

Max. Connections: št. povezav na strežnik v eni uri,

Concurrent Connections: št. sočasnih povezav na strežnik.

39

Slika 5-2 Administratorjev vmesnik in trije koraki vnosa novega uporabnika z nastavitvijo privilegijev

Za vsakega uporabnika lahko določimo lastno shemo privilegijev. To pomeni, da ima

uporabnik s privilegiji ustvarjanja novih tabel lahko sočasno omejitev ustvarjanja tabel v

neki drugi PB. Zelo priporočljivo je, da si ustvarimo hierarhijo uporabnikov. Npr. združimo

uporabnike z istimi lastnostmi delovanja v sistemu z enakimi privilegiji in od tega ne

odstopamo.

V zaznamku Scheme Privileges torej določimo uporabnikom dodatne omejitve – Slika 5-3.

Npr. novo kreiranega uporabnika želimo omejiti, da v PB »test« sme samo dostopati do

podatkov - s poizvedbo SELECT.

40

Slika 5-3 Schema Privileges

Praktični nasvet: priporočena shema skupin uporabnikov - s tem želimo doseči, da imajo

uporabniki, ki pripadajo posamezni skupini, samo tiste privilegije, ki jih potrebujejo:

Administratorji PB

Uporabniki PB

o Super uporabniki – imajo dostop do vseh PB

o Ostali uporabniki – imajo dostop le do določenih PB

o Oblikovalci – imajo dostop do vseh povezav relacij neke PB

41

Lastnosti dobre prakse:

Pri dodeljevanju privilegijev je treba upoštevati, da uporabniku dodelimo le nujno

potrebne privilegije, ki jih potrebuje za svoje delo.

Izogibajte se uporabe WITH GRAND OPTION.

Izogibanje globalnih privilegijev vsem uporabnikom lahko pripomore k večji

varnosti.

Da bi razbremenili sistem za nadzor dostopa, ne dodeljujte privilegijev brezglavo,

saj bi s tem oteževali nastavitve in obremenili sistem.

Zelo učinkovito je, da se poglobimo na ravni upravljanja skupnih vlog uporabnikov. S tem

omogočimo boljše upravljanje velikih skupin uporabnikov, ki jih razporedimo skupaj glede

skupnih dejavnostih.[1][13]

5.2 Varnost

Kadar načrtujemo podatkovno bazo in arhitekture celotnega sistema, ne smemo pozabiti

na načrtovanje varnosti podatkovne baze, kot tudi na varnost celotnega sistema. Varnost

v informacijskih sistemih je bistvenega pomena, kar pomeni, da brez ustrezne varnosti ne

bomo imeli popolno optimiziranega sistema. V podatkovnih bazah lahko nastopijo

naslednje »varnostne težave«:

Časovna omejitev: čas je zelo pomemben dejavnik, ko načrtujemo varovanje.

Pomanjkanja znanja o varnosti sistemov

Pomanjkanje informacij o podatkih: tukaj ne gre za pomanjkanje znanja o izbiri

varnostne rešitve, ampak gre za to, da se morda ne zavedamo, kako zelo so

pomembni podatki in npr. kadar bi izvajali varnostno kopijo podatkov, bi le te

prenašali preko javnega omrežja in s tem ogrozili krajo pomembnih informacij.

Komunikacija med razvijalci: ključnega pomena je tudi komunikacija med razvijalci

aplikacij ter administratorjem podatkovne baze, da je tako s stališča razvijalca, kot

administratorja PB zagotovljena maksimalna varnost sistema.

Slaba navada: zaupanje v »stare« tehnike dodeljevanje privilegijev nas lahko

zavedejo in morda odvrnejo od pozornosti, ki bi jo morali posvetiti varnosti.

Sprejemanje tveganih odločitev: tveganje je slab razlog za varnost.

Težav v varnosti je veliko in že z majhnimi posegi lahko rešimo velike težave. Zavedati se

moramo, da podatki niso edina šibka točka napadov, saj velika večina napadalcev svoje

42

napade na informacijske sisteme izvede, kar preko PB, če sistem ni primerno varovan.

Velika grožnja so lahko tudi uporabniki, katerih privilegiji niso skrbno dodeljeni in lahko

napako administratorja PB izkoristijo.

Velikokrat se vprašamo ali je naš sistem popolnoma varen? Na to vprašanje je težko

odgovoriti in pritrditi, da smo 100% varni, saj sami težko odkrijemo varnostno »luknjo«.

Načrtovanje varnosti in njene politike moramo vzeti zelo resno ter se ga lotiti skrbno in

premišljeno. Pri načrtovanju varnostnih rešitev nikakor ne smemo zanemarit dejstva, da

se sistemi med seboj razlikujejo. Torej, začnemo zmeraj z »ničle«, saj zmeraj ni nujno, da

že obstoječa rešitev prinese iste rezultate, kot jih je morda v drugem sistemu. Previdnost

ni odveč niti kadar izbiramo osebje, katero vam bo pomagalo pri načrtovanju in kasnejši

izvedbi varnostne politike. Svojim razvijalcem morate popolnoma zaupati.

Veliko pozornost moramo posvetiti tudi kasnejšemu odkrivanju varnostnih težav.

Velikokrat se zgodi, da pride do varnostnih incidentov. Ob vsakem sumu oz. kršitvi

varnosti v primeru večjega projekta, obvestite člane ekipe, da nastalo tehnično napako

raziščete, sprejmete in poiščete najboljšo rešitev in nato izvedite ukrepe (zaostrite

varnost, prekličite nepotrebna dovoljenja, poškodovano oz. ogroženo PB obnovite s

pomočjo varnostnih kopij, ustrezno ukrepajte zoper kršitelju). Vsak korak načrtovanja in

izvedbo varnostne rešitve, kršitev in rešitev tehnične težave je priporočljivo dokumentirati.

Osnovni varnostni ukrepi dobre prakse

V tem poglavju vam bomo predstavili nekaj najosnovnejših ukrepov dobre prakse, ki so

povezani z varnostjo sistema. Nikakor ne smemo pozabiti, da moramo zaščititi tudi

računalnik, na katerem bomo imeli vzpostavljen strežnik MySQL. Kakorkoli, naš namen je,

da vam predstavimo varnost MySQL strežnika.[21]

Omejitev dostopa na daljavo – kadar dostopamo do strežnika iz lastnega

računalnika je priporočljivo, da omejimo dostop do strežnika preko TCP/IP. To

storimo tako, da v datoteki »my.ini« ročno spremenimo nastavitveni parameter. V

odseku [mysqld] dodamo parameter - skip-networking. Druga možna rešitev je, da

prav tako v odseku [mysqld] dodamo naslednji parameter, s katerim omogočimo

samo lokalno povezavo - bind-address = 127.0.0.1, vendar s to možnostjo hrati

dopuščamo, da sami upravljamo z dodajanjem možnosti prijave na daljavo drugim

uporabnikom s tako imenovano shemo privilegijev – mysql> GRADT SELECT, ON

ime_baze * TO 'uporabnik'@'host';

Sprememba korenskega imena in gesla – »root« je privzeto uporabniško ime

administratorja strežnika. Da bi zavedli morebitne hekerje, MySQL v novejših

43

različicah (5.0.2+) ponuja možnost preimenovanja administratorjevega

uporabniškega imena na preprost način, in sicer z ukazom – RENAME USER root

TO nov_uporabnik; nato lahko spremenimo tudi geslo - UPDATE mysql.user SET

Password = PASSWORD('novo_geslo') WHERE User = 'root'. Da uveljavimo novo

geslo, moramo ponovno zagnati strežnik. Da pa se izognemo temu postopku,

preprosto strežniku ukažemo, da smo v sistemu spremenili privilegij, to storimo s

preprostim ukazom - FLUSH PRIVILEGES. MySQL v različicah 4.1+ za zaščito

gesel uporablja 41-bitno hash enkripcijo. Zanimivost – »SHA1 je kriptografska

hash funkcija, rezultat je izražen kot 160 bitno (20 bajtov), 40 mestno šestnajstiško

število. SHA1 je razvila NSA ter je naslednik MD5«. Ugotovitev: če uporabimo

dvojno kriptiranje SHA1, dobimo enak rezultat enkripcije, kot ga uporablja MySQL

v različicah 4.1+.[19][20]

o Rezultat dvojnega kriptiranja SHA1

mysql> SELECT SHA1(UNHEX(SHA1('mypass')));

+---------------------------------------------------------------+

| SHA1(UNHEX(SHA1('mypass'))) |

+----------------------------------------------------------------+

| 6c8989366eaf75bb670ad8ea7a7fc1176a95cef4 |

+----------------------------------------------------------------+

1 row in set (0.09 sec)

o Hash kriptiranje v MySQL 4.1+

mysql> SELECT PASSWORD('mypass');

+--------------------------------------------------------------------------+

| PASSWORD('mypass') |

+--------------------------------------------------------------------------+

| *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |

+--------------------------------------------------------------------------+


Odstranimo možnost prijave kot anonimni uporabnik (angl. anonymous account),

če ne želimo, da se v našo PB prijavi kdorkoli. MySQL privzeto omogoča prijavo

uporabnika brez gesla in tako neposredno dopušča prijavo na PB, vendar ima

omejena dovoljenja - DROP USER ''@'LOCALHOST';

MySQL ima testno zbirko podatkov, ki je namenjena testiranju in je hkrati ranljiva,

saj omogoča anonimno prijavo. Če se želite izogniti morebitnim napadom preko

testne zbirke podatkov, je priporočljivo, da jo izbrišete – DROP DATABASE test;

Priporočljivo je zaščititi tudi datotečni imenik, v katerem se nahajajo podatki

MySQL in so v »lasti mysql«. Do imenika naj ima dostop le root uporabnik.

44

S preprostim ukazom »SHOW DATABASES« na zelo preprost način prikažemo

seznam vseh podatkovnih baz. Tudi to lahko ogroža varnost sistema, saj lahko

napadalec s preprostim ukazom razbere seznam vseh podatkovnih baz, ki so na

strežniku. Če želite, lahko onemogočite uporabo »SHOW DATABASES« ukaza.

To storite tako, da v datoteki z nastavitvenimi parametri (my.ini) v odseku [mysqld]

dodamo vrstico - skip-show-database.

O beleženju dnevnikov smo že pisali, da olajšajo iskanje napak. Naj omenimo, da

beleženje dnevnikov lahko hkrati izkoristimo za varnostne razloge. Kako? V

dnevnike se beležijo vsa povpraševanja, ki se izvršijo nad podatki in tako bi lahko

zasledili, ali v našem sistemu poizvedujejo o podatkih nezaželene osebe. Hkrati je

priporočljivo omejiti dostop do dnevnikov.

V celotnem postopku namestitve se beležijo vsi podatki, ki smo jih kot

nastavitvene parametre nastavili na strežniku. Naloga sprotnega beleženja je,

odkrivanje morebitnih napak, če pride do napake med namestitvijo. Z analizo

zgodovine podatkov lažje odkrijemo napako. Po uspešni namestitvi vedno

poskrbimo, da izbrišemo zgodovino podatkov – mysql_history.[21]

Povezovanje s SSL šifriranjem

Za varnejši prenos podatkov med dvema strežnikoma je priporočljivo uporabiti SSL

šifriranje, saj s tem omogočimo varnejšo sinhronizacijo. Na primeru bomo skušali razložiti,

kako sinhronizirati povezavo dveh strežnikov s šifriranjem SSL.[18][22]

Preverimo ali imamo podporo ssl:

mysql> show variables like '%ssl%';

+--------------------+-------------------+

| Variable_name | Value |

+--------------------+-------------------+

| have_openssl | DISABLED |

| have_ssl | DISABLED |

| ssl_ca | |

| ssl_capath | |

| ssl_cert | |

| ssl_cipher | |

| ssl_crl | |

| ssl_crlpath | |

| ssl_key | |

+--------------------+-------------------+

45

Rezultat poizvedbe nakazuje, da je SSL onemogočen. V datoteki my.ini v odseku [mysqld]

dodamo vrstico ssl, s katero omogočimo šifriranje SSL. Rezultat:

mysql> show variables like '%ssl%';

+------------------------+--------------+


+------------------------+--------------+

| have_openssl | YES |

| have_ssl | YES |

| ssl_ca | |

| ssl_capath | |

| ssl_cert | |

| ssl_cipher | |

| ssl_crl | |

| ssl_crlpath | |

| ssl_key | |

+------------------------+---------------+

9 rows in set (0.29 sec)

Naslednji korak je izdelava certifikatov, CA, strežniški (angl. server) in uporabniški (angl.

client ) certifikat, ki jih potrebujemo za SSL povezavo. Namestiti je potrebno OpenSSL

program, s katerim bomo ustvarili certifikate. Celoten postopek ustvarjanja certifikatov

izvajamo v cmd (Command Prompt). Ustvarimo imenik, v katerega bomo ustvarjali vse

certifikate mkdir C:\certs:

CA certifikat

openssl genrsa 2048 > "C:/certs/ca-key.pem"

openssl req -new -x509 -nodes -days 1000 -key "C:/certs/ca-key.pem" >

"C:/certs/ca-cert.pem"

Strežniški certifikat

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout "C:/certs/server-

key.pem" > "C:/certs/server-req.pem"

openssl x509 -req -in "C:/certs/server-req.pem" -days 1000 -CA "C:/certs/ca-

cert.pem" -CAkey "C:/certs/ca-key.pem" -set_serial 01 > "C:/certs/server-cert.pem"

Uporabniški certifikat

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout "C:/certs/client-key.pem"

> "C:/certs/client-req.pem"

openssl x509 -req -in "C:/certs/client-req.pem" -days 1000 -CA "C:/certs/ca-

cert.pem" -CAkey "C:/certs/ca-key.pem" -set_serial 01 > "C:/certs/client-cert.pem"

46

Vsebina mape certs, ko smo ustvarili certifikate:

Directory of C:\certs

20.01.2014 16:20 <DIR> .

20.01.2014 16:20 <DIR> ..

20.01.2014 16:11 1.415 ca-cert.pem

20.01.2014 15:59 1.675 ca-key.pem

20.01.2014 16:20 1.285 client-cert.pem

20.01.2014 16:19 1.704 client-key.pem

20.01.2014 16:19 1.115 client-req.pem

20.01.2014 16:16 1.285 server-cert.pem

20.01.2014 16:15 1.708 server-key.pem

20.01.2014 16:15 1.115 server-req.pem

Najprej na kratko pojasnimo, kako delujejo certifikati. Naloga certifikata je identifikacija

drugih strežnikov oz. uporabnikov, kateri pošljejo zahtevek za povezavo.

Sedaj moramo prenesti datoteke ca-cert.pem, client-cert.pem in client-key.pem na drug

strežnik, s katerim želimo vzpostaviti varno povezavo SSL.

Strežniku nastavimo poti do certifikatov, v datoteki my.ini dodamo vrstice:

ssl-ca = "C:/certs/ca-key.pem"

ssl-cert = "C:/certs/server-cert.pem"

ssl-key = "C:/certs/server-key.pem"

Poskrbeti moramo še za identifikacijo strežnikov, s tem določimo, kateri je privzeti (angl.

master) oz. podrejen (angl. slave). V datoteki my.ini na privzetem strežniku dodamo

vrstico server-id=1, na podrejenem strežniku pa server-id=2.

Po končanih nastavitvah moramo kreirati uporabnika, kateremu določimo ssl šifrirno

povezavo:

mysql > GRANT ALL ON baza.* TO 'ssl_uporabnik'@'192.168.0.2' IDENTIFIED

BY 'geslo' REQUIRE SSL;

47

Da preverimo, ali povezava deluje, moramo vnesti naslednji parameter:

mysql > SHOW STATUS LIKE 'ssl_cipher';

+------------------------+------------------------------------+


+------------------------+------------------------------------+

| Ssl_cipher | DHA-RAA-AES316-SHA |

+------------------------+------------------------------------+


48

6 PROŽILEC (ANGL. TRIGGERS) IN OMEJITVE (ANGL. CONSTRAINTS)

Že samo iz imena lahko razberemo, da se specifičen oz. več specifičnih SQL stavkov

»sproži« v primeru, če se pojavi pričakovan dogodek ali napaka. S prožilci torej lahko

rešujemo nastale težave, za katere smo predvidevali, da se lahko zgodijo. S prožilci torej

odkrijemo in odpravimo napako neposredno z MySQL in tako preprečimo napako, ki bi jo

moral rešiti programer v aplikaciji, ki upravlja PB. Primeri prožilcev, ki se pogosto

uporabljajo v praksi: beleženje sprememb podatkov, ustvarjanje kopij podatkov pred

spremembo, samodejni izračuni ...

Izvršna naloga prožilca je, da se izvede po vnosu (angl. INSERT) posodobitev (angl.

UPDATE) in brisanju (angl. DELETE) podatkov iz tabele, posledično se torej prožilci

vedno nanašajo na določeno tabelo in se lahko izvedejo pred ali po vnosu novih

podatkov. Da lahko uporabnik kreira prožilec, mora imeti privilegij TRIGGER. Za izjemo,

pri kreiranju prožilca lahko navedemo uporabnika, kateremu dopuščamo, da lahko izvaja

prožilec. To storimo z dodatno klauzolo CREATE DEFINER = 'uporabnik@localhost'

TRIGGER ime_prozilca.[13][23]

Na preprostem primeru bomo lahko bolje razumeli delovanje prožilca:

V letalski družbi želijo ob vsakem vnosu novega poleta v PB, še dodaten vnos, in sicer

vnos podatka o uporabniku, ki je vnesel nov polet ter čas vnosa. Ker se želijo izogniti

ročnemu vnosu in s tem optimizirati sistem, bo za vnos poskrbel sistem oz. prožilec.

» mysql> CREATE TRIGGER Vnos_poleta_ai

-> AFTER INSERT ON Poleti

-> FOR EACH ROW

-> INSERT INTO Dnevnik_prijav (Uporabnik, Opomba, Cas)

-> VALUES (CURRENT_USER(), 'Dodan nov vnos', NOW());

Query OK, 0 rows affected (0.04 sec) «

Definicija prožilca:

Kreiramo prožilec, CREATE TRIGGER in ga poimenujemo. Nato sledijo štirje

ključni »deli«.

Določitev časa sprožitve, pred (angl. BEFORE) ali po (angl. AFTER).

Dogodek se sproži po eni izmed INSERT, DELETE ali UPDATE operaciji, ki se

izvaja nad tabelo. Šele nato vsebuje telo SQL stavka, ki določa novo operacijo.

49

Priporočljivo je tudi primerno poimenovanje prožilcev, da lahko že iz samega

poimenovanja prožilca razberemo, čemu »služi«. V poimenovanju na koncu

uporabimo prvi črki določitve časa in dogodka, ki se bosta izvajala s pomočjo

prožilca, primer:

AFTER INSERT – poimenovanje_ai

BEFORE UPDATE – poimenovanje_bu

Prožilci imajo tudi slabo lastnost. Če med delovanjem prožilca pride do napake, prožilec

preprosto dokonča svojo nalogo in ne bo prekinjen, kot bi se pričakovalo. Ker MySQL

nima vgrajenega mehanizma, ki bi v primeru, ko se pojavi napaka preprosto prekinil

prožilec, moramo sami poskrbeti in že vnaprej predvideti morebitne napake. Obstaja tudi

rešitev, da odpravimo to slabo lastnost prožilca, in sicer omejitve.

Rešitev temelji izključno na tem, da z omejitvami sami sprožimo napako in s tem prisilimo

MySQL, da prekine delovanje prožilca. Specifične rešitve za prekinitev prožilcev ni, saj se

iz primera v primer razlikujejo. Obstajajo pa načini, s katerimi lahko to tudi dosežemo:

podatke vstavimo v polje, ki ne obstaja; vstavimo vrednost NULL v polje, ki ima omejitev

NOT NULL ...

Priporočljivo je, da se prožilci z omejitvami izvedejo že pred vnosom, brisanjem ali

posodobitvijo podatkov v tabelah.

Primer prožilca z omejitvijo:

V letalski družbi želijo v terminal seznam letališč, dodati možnost dodajanje novih letališč;

vendar hkrati želijo, da se sistem omeji na vnos podatka, in sicer število pristajalnih stez,

ki pa ne sme biti manjše od 3. Nastali problem lahko rešimo s prožilcem in omejitvijo.

» mysql> DELIMITER //

mysql> CREATE TRIGGER Letalisce_bi

-> BEFORE INSERT ON Letalisce

-> FOR EACH ROW

-> BEGIN

-> IF NEW. StPristajalnihStez < 3 THEN

-> CALL Podatek_ni_pravilen;

-> END IF;

-> END//

Query OK, 0 rows affected (0.06 sec) «

50

Vnos napačnega podatka:

» mysql> INSERT INTO Letalice

-> (LetalisceID, KodaLetalisca, ImeLetalisca,

-> Kraj, KraticaDrzave, StPristajalnihStez,

-> StTerminalov) VALUES (207, 'LTN',

-> 'Luton Airport', 'London', 'GB', 2, 1);

ERROR 1305 (42000): PROCEDURE db1.Podatek_ni_pravilen does not exist «

V našem primeru torej dobimo rezultat o napaki, saj smo prožilec omejili, da se mora

izvesti že pred vnosom podatka v tabelo. Tako smo preprečili napačen vnos in hkrati tudi

dobili sporočilo o napaki.

V današnjem času zmeraj iščemo načine, kako si olajšati delovanje. Poglejmo si primer,

kako iz tabele prekopiramo podatke za obdobje 30 dni, ki jih želimo arhivirati. Da se

izognemo fizičnemu kopiranju, si lahko stvari poenostavimo s pomočjo prožilcev in

omejitev.

Ustvarimo novo tabelo identično tabeli iz katere želimo prekopirati podatke:

mysql> CREATE TABLE Racuni_arhiv LIKE Racuni;


Za novo tabelo želimo, da je tipa arhiv:

mysql> ALTER TABLE Racuni_arhiv ENGINE=ARCHIVE;


Records: 0 Duplicates: 0 Warnings: 0

mysql> DELIMITER //

mysql> CREATE EVENT Racuni_dan

-> ON SCHEDULE EVERY 1 DAY

-> STARTS '2014-01-1 00:00:00' ENABLE

-> DO

-> BEGIN

-> INSERT INTO Racuni_arhiv

-> SELECT * FROM Racuni

-> WHERE DatumVnosa <=

-> DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY);

-> END//


51

Najprej smo ustvarili dogodek (angl. CREATE EVENT), ki smo ga poimenovali

Racuni_dan. Določili smo, da se naj začne 1.1.2014 in dnevno naslednjih 30 dni tudi

izvaja, nato s preprostim SQL stavkom vnesemo podatke iz tabele Racuni v novo tabelo

Racuni_arhiv.

52

7 PROCEDURE IN FUNKCIJE V MYSQL

Procedure in funkcije v MySQL opravljajo eno ali več nalog. Njihova naloga oz. namen,

kot tudi sintaksa, je podoben drugim programskim jezikom. Sintaksa procedure je

sestavljena iz dveh delov, glave in telesa. Glava je sestavljena iz imena procedure in

parametrov. Telo pa je sestavljeno iz deklaracije in izvršitve procedure. Načeloma prvoten

namen procedur je, da opravijo svojo »nalogo« in se po končanju zaključijo ter ne vračajo

vrednosti. S pomočjo OUT parametra lahko procedura poda tudi končno vrednost.

Funkcije so podobne proceduram in se razlikujejo le v tem, da funkcija vedno vrne

vrednost. Glava funkcije določa vrsto oz. tip vrednosti, ki jo funkcija na koncu

vrne.[1][13][23]

Sintaksa procedur in funkcij:[13]

» CREATE

[DEFINER = { uporabnik | CURRENT_USER }]

PROCEDURE poimenovanje ([parameter_proc[,...]])

[ ...] zakljucek

CREATE

[DEFINER = { uporabnik | CURRENT_USER }]

FUNCTION poimenovanje ([parameter_fun [,...]])

RETURNS vrednost

[lastnosti ...] zakljucek

parameter_proc:

[ IN | OUT | INOUT ]

parameter_fun:

ime parametra vrednost

uporabnik:

ko ustvarjamo proceduro oz. funkcijo lahko izrecno določimo, kateri

uporabnik lahko izvaja oz. kliče

vrednost:

vrednosti, ki jih podpira MySQL

53

lastnosti:

COMMENT 'string'

| LANGUAGE SQL

| [NOT] DETERMINISTIC

| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL

DATA }

| SQL SECURITY { DEFINER | INVOKER }

zakljucek:

Veljavna SQL rutinska izjava «

Procedure imajo tri vrste parametrov:

S parametrom IN podamo določeno vhodno vrednost, s katero potem procedura

operira in se med izvedbo lahko tudi spremeni, ni pa nujno. Parameter je

namenjen predvsem shranjevanju podatkov v tabele.

Začetna vrednost parametra OUT je NULL in med izvajanjem operacij prejme

končno vrednost shranjenega podatka iz želene tabele. Parameter OUT je

podoben tipu vrednosti, ki jo vrne funkcija.

Parameter INOUT združuje vlogi IN ter OUT parametrov. Proceduri podamo

vrednost, s katero želimo, da operira in v »zameno« pričakujemo tudi končno

vrednost.

V primeru, da nismo izrecno določili vrste parametra, bo parameter pridobil privzeto

vrednost IN parametra.

54

Primer:

Najprej ustvarimo proceduro. Z »DELIMETER //« MySQL-u nakažemo, da bomo

ustvarili proceduro, vrednost » // « lahko poljubno izberemo, vendar ne sme biti

enaka vrednosti » ; «, ki jo uporabljamo za zaključek SQL stavka. Proceduro

zaključimo z END in pripisom vrednosti, ki smo jo določili na začetku, v našem

primeru » // «.[1]

mysql> DELIMETER //

-> CREATE PROCEDURE VnosOsebe (

-> IN ImeOsebe VARCHAR(20), PriimekOsebe VARCHAR(50))

-> BEGIN

-> INSET INTO Osebe(Ime, Priimek),

-> VALUES (ImeOsebe, PriimekOsebe);

-> SELECT Ime, Priimek FROM Osebe WHERE Ime=ImeOsebe;

-> END//


Ko smo ustvarili proceduro jo moremo aktivirati. To storimo tako, da kličemo

proceduro.

mysql> CALL VnosOsebe('Staš', 'Kopina');

+------------+--------------+

| Ime | Priimek |

+------------+--------------+

| Staš | Kopina |

+------------+--------------+


Preprost primer prikazuje kreiranje nove procedure, ki izpiše število oseb. S proceduro in

funkcijo se torej izognemo vnovičnim vnosom dolgih SQL stavkov.

Procedure, kot tudi funkcije, podpirajo dodatna določila, ki se uporabljajo za dodatno

opredelitev shranjenih lastnosti:

COMMENT določa opise oz. komentarje.

DETERMINISTIC določilo pomeni, da neglede na vhodni podatek, ne spremeni

končnega rezultata.

LANGUAGE določa, da znotraj procedur in funkcij velja izključno SQL jezik.

55

CONTAINS SQL določa, da rutina vsebuje SQL, vendar dopušča alternativo za

READS SQL DATA (branje podatkov iz tabel), MODIFIES SQL DATAm(pisanje

podatkov v tabelo) in NO SQL (ne vsebuje SQL stavkov).

SQL SECURITY določa kateri privilegij naj upošteva kadar se izvaja procedura oz.

funkcija. Naj upošteva uporabnika, ki je ustvaril proceduro oz. funkcijo (DEFINER)

ali uporabnika (INVOKER), ki se sklicuje oz. sproži klic.

Za primer funkcije smo izbrali bolj kompleksen primer, da predstavimo zmogljivosti, ki jih

premore SQL:[1]

mysql> DELIMITER //

mysql> CREATE FUNCTION IzpisDneva()

-> RETURNS VARCHAR(255)

-> BEGIN

-> DECLARE Sporocilo VARCHAR(255);

-> CASE DAYOFWEEK(NOW())

-> WHEN 2 THEN

-> SET Sporocilo = 'Ponedeljek';

-> WHEN 3 THEN

-> SET Sporocilo = 'Torek';

-> WHEN 4 THEN

-> SET Sporocilo = 'Sreda';

-> WHEN 5 THEN

-> SET Sporocilo = 'Četrtek';

-> WHEN 6 THEN

-> SET Sporocilo = 'Petek';

-> WHEN 7 THEN

-> SET Sporocilo = 'Sobota';

-> ELSE

-> SET Sporocilo = 'Nedelja';

-> END CASE;

-> RETURN Sporocilo;

-> END//

S pomočjo procedur in funkcij v MySQL omogočimo razvijalcem aplikacij, da svojo logiko

preselijo na strežnik PB in sistem privedejo do točke, ki omogoča večjo varnost in

doslednost s strani MySQL-a.

56

8 PRIMER UPORABE MYSQL

V poglavju bomo zajeli celotno tematiko diplomske naloge in jo predstavili s praktičnim

pristopkom predstavitve. Izhajali bomo iz preprostega E-R diagrama in poskušali s primeri

prikazati naloge adminstratorja PB.

Najprej kreiramo novo PB s preprostim ukazom:

CREATE DATABASE bazaZaposlen;

Brezhibno delovanje PB je treba premišljeno načrtovati. Poudariti je treba velik del

načrtovanja E-R modela oz. diagram (slika 8-1), ki neposredno služi tudi h kasnejšemu

hitremu vpogledu, npr. kako povpraševati po določenih podatkih.

Z natančno logičnim E-R modelom predstavimo podatkovni model, ki je razumljiv

uporabnikom in strokovnjakom. [24]

Slika 8-1 E-R model

E-R model nam je lahko prav tako v pomoč in služi kot načrt sosledij dogodkov, kadar

ustvarjamo nove tabele.

V poglavju Shranjevalni mehanizmi smo spoznali več vrst mehanizmov in predstavili

njihov specifični namen, najbolj razširjena sta INNODB in MyISAM, še posebaj ko naše

tabele ne služijo nekemu specifičnemu namenu.

57

Pri kreiranju tabel smo se omejili na shranjevalni mehanizem INNODB, kreirali privzete in

tuje ključe ter indekse:

CREATE TABLE bazaZaposlen.zaposlen(

idZaposlen INT not null auto_increment,

datum_rojstva DATE null,

emso INT(13) null,

ime VARCHAR(45) null,

priimek VARCHAR(45) null,

naslov VARCHAR(50) null,

PRIMARY KEY(idZaposlen))

ENGINE = INNODB;

CREATE TABLE bazaZaposlen.delo(

idDelo INT not null auto_increment,

delovno_mesto VARCHAR(45) null,

vrsta_dela VARCHAR(45) null,

PRIMARY KEY(idDelo))

ENGINE = INNODB;

CREATE TABLE bazaZaposlen.zaposlitev(

idZaposlitev INT not null auto_increment,

datum_zaposlitve DATE null,

vrsta_dela VARCHAR(45) null,

zaposlen_idZaposlen INT not null,

delo_idDelo INT not null,

PRIMARY KEY(idZaposlitev),

INDEX(zaposlen_idZaposlen),

INDEX(delo_idDelo),

FOREIGN KEY(zaposlen_idZaposlen) REFERENCES zaposlen(idZaposlen),

FOREIGN KEY(delo_idDelo) REFERENCES delo(idDelo))

ENGINE = INNODB;

58

Vnos testnih podatkov bi lahko uvrstili v kategorijo varnosti, saj z njihovo pomočjo

odkrivamo morebitne napake, preverjamo odziv PB ob morebitnih vnosih napačnih

podatkov itn., ter jih nato uspešno odpravimo.

Z vnosom testnih podatkov zgolj poskrbimo, da preverimo delovanje PB in jih nato

izbrišemo. Pri vnosu podatkov smo s pomočjo procedure pristopili k načinu hitrejšega in

učinkovitejšega vnosa večih podatkov in se izognili dolgotrajnemu vnosu.

Vnos podatkov v posamezne tabele:

Zaposleni:

delimiter $$

CREATE PROCEDURE bazazaposlen.testZaposlen (IN id INT, IN datumVnos DATE, IN

emsoVnos INT(13), IN imeVnos VARCHAR(45),

IN priimekVnos VARCHAR(45), IN naslovVnos VARCHAR(45))

MODIFIES SQL DATA

BEGIN

INSERT INTO bazazaposlen.zaposlen (idZaposlen, datum_rojstva, emso, ime, priimek,

naslov)

VALUES (id, datumVnos, emsoVnos, imeVnos, priimekVnos, naslovVnos);

END$$

Delo:

delimiter $$

CREATE PROCEDURE bazazaposlen.testDelo(IN id INT, IN delovnoVnos

VARCHAR(45), IN vrstaVnos VARCHAR(45))

MODIFIES SQL DATA

BEGIN

INSERT INTO bazazaposlen.delo (idDelo, delovno_mesto, vrsta_dela)

VALUES (id, delovnoVnos, vrstaVnos);

END$$

Zaposlitev:

delimiter $$

CREATE PROCEDURE bazazaposlen.testZaposlitev(IN id INT, IN datum DATE, IN

vrstaVnos VARCHAR(45), IN zaposlenIDVnos INT, IN deloIDVnos INT)

MODIFIES SQL DATA

BEGIN

INSERT INTO bazazaposlen.zaposlitev(idZaposlitev, datum_zaposlitve, vrsta_dela,

zaposlen_idZaposlen, delo_idDelo)

VALUES (id, datum, vrstaVnos, zaposlenIDVnos, deloIDVnos);

END$$

59

Naj omenimo, da kadar kreiramo proceduro oz. funkcijo, se le-ta "nahaja" v PB in jo s

preprostim ukazom kličemo, kadar želimo. V našem primeru, kadar bomo želeli vnesti nov

podatek:

call bazazaposlen.testZaposlen(1, '12.2.1990', 123456, 'Staš', 'Kopina', 'Maribor');,

call bazazaposlen.testDelo(1, 'Administrator PB', 'administracija');

call bazazaposlen.testZaposlitev(1, '7.4.2014', 'administracija', 1, 1);

Vnos testnih podatkov, kot smo ga prikazali z zgornjim primerom, je zamuden proces, če

želimo vnesti npr. več kot 20 testnih podatkov. V veliko pomoč nam je PL/SQL, ki je

proceduralni jezik in je nadgradnja SQL-a. PL/SQL je podoben programskim jezikom, saj

vsebuje podobno sintakso pogojev in zank, prav tako ima spremenljivke. [25][26]

S primerom vnosa podatkov s PL/SQL jezikom smo želeli zgolj prikazati eno izmed

naprednejših možnosti, ki so vse pogostejše:

CREATE PROCEDURE testni_podatki(vnosStPonovitev INT) IS

datum_rojstva DATE;

emso INT(13,0);

ime VARCHAR(45);

priimek VARCHAR(45);

naslov VARCHAR(45);

BEGIN

FOR st_ponovitev IN 1..vnosStPonovitev LOOP

ime := 'Staš';

priimek := 'Kopina';

naslov := 'Maribor';

-- naključni datum med letom 1930 in 1990 --

datum_rojstva := dbms_random.value(7000,28000);

-- naključno št., ki ustreza za emso --

emso := dbms_random.value(1000000000000,9000000000000);

-- vsakemu vnosu dodamo zaporedno št. da se podatki razlikujejo --

ime := ime ||' '|| TO_CHAR(st_ponovitev);

priimek := priimek ||' '|| TO_CHAR(st_ponovitev);

naslov := naslov ||' '|| TO_CHAR(st_ponovitev);

-- vnos podatkov --

INSERT INTO bazazaposlen.zaposlen (idZaposlen, datum_rojstva, emso,

ime, priimek, naslov)

60

VALUES (st_ponovitev, datum_rojstva, emso, ime, priimek, naslov);

END LOOP

END;

■Opomba: administrator PB in administrator podatkov imata popolnoma drug spekter

nalog, ki jih opravljata. Administrator podatkov je odgovoren za upravljanje s podatki in

sodeluje pri kreiranju PB in tako skrbi za kakovost podatkov.[27]

Tako je priporočljivo ustvariti uporabnika s privilegiji, ki ustrezajo njegovim specifičnim

nalogam, za katere je zadolžen in smo jih opisali v poglavju Uporabniki in njihove pravice.

Kreirali smo dva uporabnika in vsakemu dodelili privilegij:

CREATE USER 'zaposlen1'@'localhost' IDENTIFIED BY 'geslo1';

Privilegij uporabniku dovoljuje pregled nad zaposlenimi z omejitvo, da lahko

pridobi podatke le o imenu, priimku in izobrazbi zaposlenih:

GRANT SELECT (ime, priimek, izobrazba) ON bazaZaposlen.Zaposlen TO

'zaposlen1'@'localhost';

CREATE USER 'zaposlen2'@'localhost' IDENTIFIED BY 'geslo2';

Drug uporabnik bo lahko dodajal podatke:

GRANT SELECT, INSERT ON bazaZaposlen TO 'zaposlen2'@'localhost';

61

9 SKLEP

V diplomskem delu smo predstavili naloge administratorja PB s pomočjo nabora MySQL

orodij, ki smo jih namestili na operacijskem sistemu Windows 7. Na samem začetku si

nismo predstavljali same obsežnosti administratorjevega dela ter širokega nabora znanja,

ki ga mora obvladati za delo s PB. Da bi zagotovili ustrezno predstavitev nalog

administratorja PB, smo povzeli le tiste, za katere smo bili mnenja, da so pomembna za

lažje razumevanje in boljšo ponazoritev del, ki jih upravlja. Namen diplomskega dela je

predvsem teoretično opisati naloge in znanje. In ker menimo, da za lažje razumevanje

problematike lahko ponazorimo s praktičnim delom, smo v zadnjem poglavju s

»preprostimi« primeri želeli teoretičen del predstaviti v praktični obliki in tako bolje

ponazorili naloge, ki jih opravlja administrator PB.

Teoretičen del smo začeli z opisom namestitve samega sistema MySQL in v sosledju

nadaljevali v zaporedju, ki se nekako približuje praktičnemu postopku izvršitvenih korakov,

ki so v praksi nujni za optimizacijo sistema. Tako smo po opisu namestitve predstavili

nastavitvene parametre, ki služijo za boljšo optimizacijo sistema in s tem lahko kar se da

najbolje izkoristimo delovanje sistema. Tukaj moramo omeniti, da smo predstavili zgolj

primer za povprečno računalniško opremo, saj se računalnika oprema - zmogljivosti -

med seboj razlikujejo. Sledi predstavitev shranjevalnih mehanizmov oz. tipov tabel.

Poglavju smo namenili veliko pozornosti, saj smo v času preučevanja videli, kako zelo

pomembno je izbrati pravilni tip tabele, katere so njegove prednosti in slabosti, saj

neposredno s pravilno izbiro postrežemo tudi po boljši varnosti sistema, ki smo jo opisali v

naslednjem poglavju. Varnostni vidiki v sistemih predstavljajo širok spekter ukrepov, ki jih

mora administrator predvideti in odpraviti. Ker bi lahko na temo varnostni vidiki v MySQL

razglabljali v nedogled, smo se v diplomskem delu omejili zgolj na najnujnejše varnostne

ukrepe, ki izhajajo iz dobre prakse. Administratorji PB lahko neposredno pripomorejo tudi

k boljši optimizaciji aplikacij, saj s pomočjo »naprednih« baznih objektov v PB vključijo

logiko. Predstavili smo predvsem namen uporabe naprednih baznih objektov s preprostimi

primeri, zajeli smo prožilce, omejitve, procedure in funkcije.

Namen diplomske naloge je predstaviti delo in naloge administratorja PB ter teoretična

predstavitev. Vendar smo sprotno poskrbeli tudi na ponazoritev s primeri. Ker se

zavedamo, da lahko s primeri skrbno predstavimo tematiko oz. teoretični del, smo na

koncu, v zadnjem poglavju, s preprostimi primeri skušali bolje predstaviti naloge

administratorja PB. Namen primerov je zgolj predstaviti celoto diplomske naloge na

praktični ravni.

62

10 VIRI

[1] Michael Kruckenberg in Jay Pipes, Pro MySQL. Berkeley (CA) : Apress, 2005. ISBN

978-1-4302-0048-2.

[2] Vikram Vaswani, MySQL Database Usage & Administration. The McGraw-Hill

Companies, 2010. ISBN: 978-0-07-160549-6.

[3] Janet Valade, PHP & MySQL for dummies. Wiley Publishing, Inc., 2010. ISBN: 978-0-

470-52758-0.

[4] Sheeri Cabral in Keith Murphy, MySQL Administrator`s Bible. Wiley Publishing, Inc.,

2009. ISBN: 978-0-470-41691-4

[5] Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz in

Derek J. Balling, High Performance MySQL. O’Reilly Media, Inc. 2008. ISBN: 978-0-596-

10171-8

[6] Brad McGehee, Mastering SQL Server Profiler, Copyright Brad McGehee 2009, ISBN

978-1-906434-11-3

[7] Seyed M.M. “Saied” Tahaghoghi, Hugh E. Williams, Learning MySQL, Copyright ©

2007 O’Reilly Media, ISBN: 978-0-596-00864-2

[8] Ryan K. Stephens, Ronald R. Plew, Data

Publishing, ISBN 0-672-31758-3

[9] Vivek Rajendran Msc-IT, MySQL DBA in 10hrs, Version 2.7, Is copyrighted by

NiveeInfotech UK Limited

[10] Brett McLaughlin, PHP & MySQL the missing manual, Published by O’Reilly Media,

Inc., ISBN: 978-1-449-32557-2

[11] Tim Converse, Joyce Park, Clark Morgan, PHP5 and MySQL® Bible, Wiley

Publishing, Inc., ISBN: 0-7645-5746-7

[12] Ken Simmons, Sylvester Carstarphen, Pro SQL Server 2012 Administration, Apress,

ISBN: 978-1-4302-3915-4

[13] MySQL 5.6 Reference Manual: Including MySQL Cluster NDB 7.3 Reference Guide.

Dostopno na: http://dev.mysql.com/doc/

[14] Podatkovne baze. Dostopno na: http://colos1.fri.uni-

lj.si/ERI/RACUNALNISTVO/PODATKOVNE_BAZE/index.html

[15] 10 essential performance tips for MySQL. Dostopno na:

http://www.infoworld.com/d/data-management/10-essential-performance-tips-mysql-

192815?page=0,0

63

[16] Configuration Files. Dostopno na:

http://books.gigatux.nl/mirror/highperfmysql/0596003064/hpmysql-CHP-1-SECT-2.html

[17] My.ini. Dostopno na: http://opensourcedba.wordpress.com/2011/01/12/mysql-basics-

part-3-%E2%80%93-your-my-cnf-or-my-ini-file/

[18] SSL. Dostopno na: http://www.howtoforge.com/how-to-set-up-mysql-database-

replication-with-ssl-encryption-on-debian-lenny

[19] SHA1. Dostopno na: http://en.wikipedia.org/wiki/SHA-1, http://www.sha1hash.com/

[20] SHA1 password. Dostopno na: http://www.palominodb.com/blog/2011/12/04/hashing-

algorithm-mysql-password

[21] Osnovni varnostni ukrepi. Dostopno na:

http://www.symantec.com/connect/articles/securing-mysql-step-step,

http://www.slideshare.net/LenzGr/mysql-backup-and-security-best-practices,

http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips

[22] SSL izdelava certifikatov. Dostopno na: http://www.howtoforge.com/how-to-set-up-

mysql-database-replication-with-ssl-encryption-on-debian-lenny

[23] Procedure in funkcije. Dostopno na: http://plsql-tutorial.com/plsql-passing-

parameters-procedure-function.htm, http://www.codingpedia.org/ama/optimizing-mysql-

server-settings/

[24] E-R diagram. Dostopno na: http://sl.wikipedia.org/wiki/Entitetni-odnosni_model

[25] PL/SQL vodič. Dostopno na: http://www.tutorialspoint.com/plsql/

[26] Pl/SQL wiki. Dostopno na:

http://en.wikipedia.org/wiki/PL/SQL#PL.2FSQL_Program_Unit

[27] Administrator podatkov. Dostopno na: http://www.s-

sers.mb.edus.si/gradiva/rac/moduli/podatkovne_baze/06_uporabniki/03_datoteka.html

administracija podatkovne baze mysql - core · 2017. 11. 28. · podatkovne baze in spletnega...

Documents