Transcript TKOC - TechNetKlub

SQL 2012 TKOC
Magas
Rendelkezésreállás I.
Király István
Microsoft Certified Trainer
Microsoft Certified Systems Engineer
Miről lesz szó a mai napon?
Miért van szükségem magas rendelkezésre állásra?
Az informatikától megkövetelik a minél kevesebb állást, kieső
bevételek, elvesztett ügyfelek, presztízs stb.
Tervezett leállás:





Patch-elés
Hardver vagy szoftver frissítés
Rendszerkonfiguráció módosítása
Adatbázis karbantartás
Alkalmazás upgrade





„Human error”
Site disasters
Hardware hiba
Adat sérülés
Szoftver hiba
Nem tervezett leállás
Database mirroring
Failover clustering
Transactional and peer-to-peer replication
Log shipping
Backup and restore


Tranzakciós naplók replikálása
másodlagos szerverekre
Az elsődleges szerveren létrejövő
esetleges hibák is replikálódnak
Primary
server
Back up
transaction log
files
Restore
transaction log
files
Secondary
server
Működési lépések
1
Tranzakciós naplók rendszeres mentése az elsődleges szerveren
2
Az SQL Server Agent átmásolja a tranzakciós log mentéseket a másodlagos
szerverekre
3
A tranzakciós log mentések visszaállítása a másodlagos szervereken
Server and database
Primary server
and database
Secondary server
and database
Optional monitor server
Description
Elsődleges adatbázis helye
Másodlagos adatbázis helye log másolás célja
Opcionális, monitor szerver
Monitorser
ver
Restore
transaction log
files
Back up
transaction log
files
Primary
server
Secondary
server
Log shipping követelmények
Minimum SQL Server 2005 megléte
Full vagy bulk-logged recovery model
SQL Server Agent beállítása, automatikus indulás
Sysadmin jogosultság az összes szerver példányon
Collation beállítások ellenőrzése, egyezősége
Mentés és helyreállítással kapcsolatos beállítások
Az SQL Server service account rendelkezzen írási/olvasási jogosultsággal a
backup könyvtáron
A COPY JOB proxy accountja rendelkezzen olvasási joggal a backup könyvtáron
és írási joggal a copy könyvtárra
Az SQL Server Service account és a restore job accountja a másodlagos szerver
copy könyvtárán rendelkezzen írási/olvasási joggal.
Log Shipping
Witness Server (Optional)
Client Session
Database Mirroring Session
Principal Server (Online
database)
Mirror Server
(Standby database)
Ajánlás
Leírás
A mirror és a principal szerver
hardverfelépítése legyen megközelítőleg
azonos
Failover esetén nem lesz belassulás
Megúszhatjuk a telefoncsörgést 
Mirror szerver teljesítménye legyen közel
azonos a principal szerverével
A rendszer válaszideje nagyban függ, hogy a
commit mikor érvényesül a mirror szerveren
A mirror megszűnésének állapota legyen
minél rövidebb
Minél később áll vissza az eredeti állapot annál
több adatot kell pótolni a logokból
Működés módja
Magyarázat
Automatic failover
Teljesen automatizált működési mód
Szükséges egy 3. ún witness server
Manual failover
Kézi failover lehetősége
Tranzakciók konzisztenciája biztosított
Forced service
Aszinkron működési mód
Tranzakciók veszhetnek el
Database state
Description
SYNCHRONIZED
A mirror rendben működik
SYNCHRONIZING
A mirror szerver felzárkózik a principalhoz
SUSPENDED
Pl: pause mirror
PENDING_FAILOVER
Csak a principal serveren, failover folyamat közben
DISCONNECTED
Hálózati problem a partner nem látható illetve a witness nem
látható
"Server=Partner_A; Failover_Partner=Partner_B;
Database=AdventureWorks; Network=dbmssocn"
SQL Mirror