![[admin-Z-G-1.gif]](admin-Z-G-1.gif)
Pierwszy krok po instalacji DBMS to zainicjowanie na dysku obszaru na bazy danych, tzw. klastra baz danych (klastra katalogu w terminologii SQL). Klaster to zbiór baz danych dostępnych w danej instalacji. Po zainicjowaniu klaster zawiera jedynie bazę danych template1. Nie należy jej używać do pracy, ponieważ pełni rolę szablonu do tworzenia kolejnych baz danych.
Klaster bazy danych jest pojedynczym katalogiem, zwanym katalogiem danych lub obszarem danych (data area). Katalog ten można wybrać dowolnie, typowe lokalizacje to /usr/local/pgsql/data lub /var/lib/pgsql/data. Do zainicjowania klastra bazy danych służy program initdb.
initdb [opcja ...] --pgdata | -D katalog
Położenie katalogu wskazujemy opcją -D, na przykład
$ initdb -D /usr/local/pgsql/data
Zamiast opcji -D można użyć zmiennej środowiskowej PGDATA.
Program initdb akceptuje następujące opcje:
--encoding=kodowanie--locale=locale--lc-collate=locale
--lc-ctype=locale
--lc-messages=locale
--lc-monetary=locale
--lc-numeric=locale
--lc-time=locale--locale.
--username=użytkownik--pwpromptinitdb tworzy nowy klaster bazy danych dla PostgreSQL. Utworzenia klastra polega na utworzeniu katalogów na dane baz danych, dzielonego (wspólnego) katalogu na tabele należące do całego klastra, oraz utworzeniu bazy danych template1. Baza ta zawiera tabele słownikowe, jej zawartość jest kopiowana do każdej nowo tworzonej bazy danych.
Gdy katalog klastra nie istnieje, program initdb usiłuje go utworzyć, zwykle jednak nie ma wymaganych uprawnień. Dlatego lepiej utworzyć ten katalog wcześniej (jako root) i zmienić mu właściciela na postgres:
root# mkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data root# su postgres postgres$ initdb -D /usr/local/pgsql/data
Jeśli katalog klastra nie jest pusty, initdb przerywa pracę.
Serwer bazy danych, tzw. postmaster, jest uruchamiany i zatrzymywany
poleceniem pg_ctl. Aby uruchomić serwer należy użyć wywołania
pg_ctl start -D katalog-klastra -l plik-logu -o "opcje"
na przykład
pg_ctl start -D /usr/local/pgsql/data -l log1 -o "-i"
Użycie opcji -i umożliwia łączenie się z serwerem przez TCP/IP.
Serwer zatrzymujemy poleceniem
pg_ctl stop -m tryb ...
Tryb może być jedną z wartości (wystarczy użyć pierwszej litery)
Wywołanie
pg_ctl status
podaje informacje o stanie serwera.
Nową bazę danych tworzymy poleceniem CREATE DATABASE
CREATE DATABASE nazwa
[[WITH] [OWNER [=] właściciel]
[ LOCATION [=] 'ścieżka' ]
[ TEMPLATE [=] szablon ] ]
Polecenie to jest rozszerzeniem SQL specyficznym dla PostgreSQL i nie występuje w SQL92. W SQL92 bazy danych nazywa się katalogami, nie określając sposobu ich tworzenia.
Aby użyć tego polecenia należy mieć uprawnienie CREATEDB. Aby utworzyć tego polecenia trzeba być połączonym z serwerem, dlatego aby utworzyć pierwszą baże należy się połączyć z bazą template1. Można też użyć skryptu createdb wywołujący to polecenie z poziomu shella.
Najprostszy przykład
=> CREATE DATABASE Testy;
Bazę danych można utworzyć w innej lokalizacji niż domyślna, jednak musi to być miejsce dostępne dla serwera PostgreSQL. Odwołanie do alternatywnej lokalizacji następuje przez zmienną środowiska, podającą absolutną ścieżkę dostępu do wskazanego katalogu. Zmienna ta musi być zdefiniowana przed wystartowaniem serwera. Dla czytelności nazwa takiej zmiennej rozpoczyna się zwykle od PGDATA (można np. użyć zmiennejPGDATA2).
Parametr ścieżka jest napisem i podaje inne od domyślnego położenie bazy danych w systemie plików, np. na innym dysku. Podana ścieżka powinna być wcześniej ,,przygotowana'' programem initlocation. Jeśli parametr ten nie zaczyna się slashem, to traktuje się go jako nazwę zmiennej środowiska (procesu serwera).
Parametr szablon podaje wzorzec, tzn. istniejącą bazę danych, na
podstawie której powstanie struktura nowej bazy, domyśłnie jest to
template1. Używając TEMPLATE = template0 można utworzyć
bazę danych zawierającą wyłącznie standardowe obiekty predefiniowane przez
PostgreSQL.
Aby utworzyć nową bazę danych w dodatkowym niestandardowym katalogu
~/private_db należy wykonać następujące czynności.
$ mkdir private_db
$ initlocation ~/private_db
The location will be initialized with username "postgres".
This user will own all the files and must also own the server process.
Creating directory /home/postgres/private_db
Creating directory /home/postgres/private_db/base
initlocation is complete.
$ psql postgres
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyrightfor distribution terms
\hfor help with SQL commands
\? for help on internal slash commands
\gor terminate with semicolon to execute query
\qto quit
postgres=> CREATE DATABASE inna WITH LOCATION = '/home/postgres/private_db';
CREATE DATABASE
=> \q$ _
Program initlocation tworzy dodatkowy obszar dla baz danych PostgreSQL:
initlocation katalog
Jeśłi argument nie zawiera znaku '/', i nie jest poprawną ścieżką,
to przyjmuje się, że jest to zmienna środowiska.
Aby użyć tego polecenia należy być zalogowanym jako główny administrator
bazy danych (postgres).
Inny przykład używający zmiennej środowiska:
$ export PGDATA2=/opt/postgres/data
Należy teraz zatrzymać i powtórnie uruchomić proces postmaster tak, żeby zawsze widział tę zmienną podczas startu. Po uruchomieniu go:
$ initlocation PGDATA2 $ createdb -D PGDATA2 testdb
Jest to odpowiednik wykonania:
$ initlocation /opt/postgres/data $ createdb -D /opt/postgres/data/testdb testdb
Polecenie DROP DATABASE usuwa podaną bazę danych.
Klaster PostgreSQL zawiera jedną lub więcej baz danych z dzielonym zbiorem użytkowników i grup. Pojedyncze połączenie może korzystać wyłącznie z jednej bazy danych.
Nie oznacza to, że konkretny użytkownik ma dostęp do wszystkich baz danych w klastrze, lecz jedynie że ma tę samą nazwę we wszystkich bazach.
Baza danych zawiera jeden lub więcej nazwanych schematów, które z kolei zawierają tabele i inne nazwane obiekty, np. funkcje. Schematy ograniczają widoczność nazw, tzn. w różnych schematach ta sama nazwa możę oznaczać inną tabelę czy funkcję. Użytkownik ma równocześnie do obiektów z wszystkich schematów, do których posiada uprawnienia.
Schematy najczęćiej tworzy się dla poszczególnych użytkowników. Inne zastosowanie to utworzenia osobnego schematu dla tabel i obiektów wspólnej aplikacji (z odpowidnim udzieleniem uprawnień do niego).
Schematy są podobne do katalogów w systemie plików, ale nie mogą być zagnieżdżane.
Do utworzenia schematu o podanej nazwie służy polecenie CREATE SCHEMA
CREATE SCHEMA ab123456;
Normalnie każdy użytkownik pracuje w jakimś schemacie, okreśłanym jako schemat bieżący. Do obiektu w innym schemacie uzyskuje się dostęp używając nazwy kwalifikowanej, składającej się z nazwy schematu i nazwy obiektu, oddzielonych kropką
SELECT * FROM ab123456.Gatunki;
Można też utworzyć tabelę w innym schemacie
CREATE TABLE ab123456.Posilki ( ... );
Pusty schemat uzuwa się poleceniem
DROP SCHEMA ab123456;
Jeśli natomiast usuwamy schemat wraz z jego obiektami, to należy użyć
DROP SCHEMA ab123456 CASCADE;
Administrator może tworzyć schematy dla innych użytkowników używając rozszerzonej postaci
CREATE SCHEMA [schemat] AUTHORIZATION użytkownik;
Jeśłi pominiemy nazwę schematu, będzie ona taka jak nazwa użytkownika.
Nazwy schematów rozpoczynające się pg_ są zarezerwowane.
Każda baza danych zawiera schemat public dostępny dla
wszystkich.
Listę (,,ścieżkę'') dostępnych schematów można obejrzeć poleceniem
SHOW search_path;
a zmieniać ją poleceniem SET
SET search_path TO myschema,public;
Aby mieć dostęp do obiektów w schemacie jest potrzebne uprawnienie USAGE do nieg, tworzenie obiektów wymaga dodatkowego uprawnienia CREATE.
Aby odebrać użytkownikom możliwość tworzenia obiektów w schemacie public (domyśłnie ją mają)
REVOKE CREATE ON public FROM PUBLIC;
Oprócz schematu public istnieje drugi systemowy schemat
pg_catalog, zawierający tabele systemowe i wbudowane obiekty.
W starszych wersjach PostgreSQL nazwy tabel rozpoczynające się
pg_ były zarezerwowane. Od wprowadzenia schematów już tak nie
jest, ale lepiej unikać tworzenia tabel o takich nazwach.
Katalogi systemowe to tabele, w których przechowuje się metadane schematów,
takie jak informacje o tabelach i kolumnach, oraz wewnętrzne informacje
systemu PostgreSQL. Można (mając odpowiednie uprawnienia) operować na
nich jak na zwykłych tabelach,np. dodawać kolumny lub wstawiać i usuwać
wiersze. Zwykle jednak robi się to pośrednio używając poleceń SQL, np.
polecenie CREATE DATABASE wstawia nowy wiersz do tabeli
pg_database (a także oczywiście tworzy bazę danych na dysku).
Większość katalogów kopiuje się podczas tworzenia bazy danych z szablonowej bazy danych, jednak niektóre są fizycznie współdzielone przez wszystkie bazy danych konkretnej instalacji.
Nazwy wszystkich katalogów systemowych rozpoczynają się od pg_.
Poniższa tabela podaje informacje przydatne zwykłym użytkownikom i
programistom.
Tabela 10-1. Katalogi systemowe PostgreSQL
| Nazwa katalogu | Zawartść |
pg_aggregate | funkcje agregujące |
pg_attrdef | domyślne wartości dla kolumn |
pg_attribute | kolumny tabel (,,atrybuty'') |
pg_cast | casts (konwersja typów danych) |
pg_class | tabele, indeksy, sekwencje (,,relacje'') |
pg_constraint | więzy z definicji tabel |
pg_conversion | informacje do konwersji kodowania znaków |
pg_database | bazy danych w klastrze |
pg_depend | zależności między obiektami w bazie danych |
pg_description | komentarze i opisy obiektów bazy danych |
pg_group | grupy użytkowników |
pg_index | dodatkowe informacje o indeksach |
pg_inherits | hierarchia dziedziczenia dla tabel |
pg_language | języki programowania funkcji |
pg_largeobject | wielkie obiekty |
pg_listener | powiadamianie asynchroniczne |
pg_log | status transakcji |
pg_namespace | schematy (przestrzenie nazw) |
pg_operator | operatory |
pg_proc | funkcje (procedury) |
rel_check | więzy CHECK dla całych tabel |
pg_rewrite | reguły przepisywania zapytań |
pg_shadow | użytkownicy baz danych |
pg_statistic | statystyki do optymalizacji |
pg_trigger | wyzwalacze |
pg_type | typy danych |
Uwagi:
pg_log nie jest tabelą, lecz plikiem binarnym (por. katalog
/proc w Linuksie).
pg_shadow nie jest widoczna dla zwykłych użytkowników. Zamiast niej
jest dostępna perspektywa pg_user.
Zmienna current_user podaje identyfikator bieżącego użytkownika
SELECT current_user;
Przydaje się przy tworzeniu perspektyw z tabeli (np. katalogowej) ukierunkowanych na użytkownika.
Rysunek 10-1 pokazuje główne encje i związki w katalogach systemowych (pokazano tylko kolumny kluczy pierwotnych i zewnętrznych).
Rysunek 10-1. Główne katalogi systemowe PostgreSQL
Normalnie PostgreSQL instaluje się w katalogu /home/local/pgsql,
nazywanym katalogiem domowym. Zawiera on szereg podkatalogów:
psql)
pg_shadow)
dzielone przez wszystkie bazy danych.
data).
Informacje o rzeczywistej instalacji PostgreSQL w danym środowisku można
uzyskać programem pg_config o składni
pg_config opcja ...
Zależnie od podanych opcji wypisuje on następujące informacje:
--bindir
Podaje położenie plików binarnych (wykonywalnych programów), np. programu
psql lub pg_config.
--includedir
Podaje położenie plików nagłówkowych dla programów użytkowych pisanych w C.
--includedir-server
Podaje położenie plików nagłówkowych dla programów serwera pisanych w C.
--libdir
Podaje położenie bibliotek.
--pkglibdir
Podaje położenie bibliotek ładowanych dynamicznie.
--configure
Podaje opcje przekazane do programu configure
podczas instalacji PostgreSQL.
--version
Podaje wersję PostgreSQL.
Informacje dla kolejnych opcji drukowane są w osobnych wierszach.
Kopię archiwalną bazy danych w SQL tworzy się programem
pg_dump baza-danych >plik-archiwum
Tak otrzymaną kopię archiwalną można wczytać programem psql
createdb -t template0 baza-danych psql baza-danych <plik-archiwum
Zarządzanie prostą instalacją PostgreSQL nie jest trudne, poza archiwizacją wymaga jednak okresowego wykonania pewnych czynności.
Polecenie SQL VACUUM powinno być uruchamiane regularnie. Ma ono trzy zadania do spełnienia:
Zwolnienie przestrzeni dyskowej pozostałej po usuniętych lub zmodyfikowanych wierszach.
Zaktualizowanie statystyk używanych przez program planowania zapytań PostgreSQL.
Ochrona przed zawinięciem identyfikatorów transakcji.
Podstawowej wersji polecenia VACUUM można używać podczas normalnej pracy bazy danych.
VACUUM [ FULL ] [ VERBOSE ] [ tabela ] VACUUM [ FULL ] [ VERBOSE ] ANALYZE [ tabela [ (kolumna [, ...] ) ] ]
Jeśłi pominięto tabelę, to VACUUM przetwarza wszystkie tabele.
Semantyka transakcji PostgreSQL jest oparta na porównywaniu identyfikatorów transakcji (XID). Ponieważ identyfikatory transkacji są liczbami 32 bitowymi, nie byłoby możłliwe dokonanie więcej niż 4 miliardów transakcji, z powodu zawinięcia identyfikatorów transakcji (transaction ID wraparound).
Do wersji 7.2 PostgreSQL 7.2 trzeba było wykonać ponownie initdb. Obecnie nie jest już to konieczne pod warunkiem zachowania następującego warunku: każda tabela w bazie danych musi być odśmiecana co najmniej co miliard transakcji. W praktyce bezpieczniej to robić co 500 milionów transakcji.