|
Reload DB v replikačním systému (bez inicializace replikací) |
Top Previous Next |
|
Seznam témat:
Následující postup popisuje jak provést kompletní rebuild databáze, aniž by byl dotčen její momentální stav v replikačním systému. Protože tento postup je složitější o sejmutí stavu replikačních počitadel před akcí a jejich opětovné nastavení po reloadu, je vhodné zvážit, zda není lepší použít jednodušší obyčejný reload, po kterém se pouze replikační systém resetuje (počitadla se uvedou do výchozích stavů). Pro použití tohoto jednoduššího postupu je pouze nutné zajistit prázdnost replikačních schránek (na FTP), nejlépe opakovaným spouštěním repl. agenta (DBREMOTE) na všech uzlech repl. systému. Tento jednodušší postup reloadu , inicializace replikací pak zde: Notes Link.
Postup reloadu DB v replikačním systému
1. Provést unload databáze. 2. Pomocí ISQL uschovat výsledek tohoto dotazu: select * from sys.sysremoteuser 3. Ukončit SQL server - v dalších bodech lze používat jen lokální engine 4. Pomocí příkazu v příkazové řádce dblog <jméno_log_souboru> zjistit a poznamenat si koncový ofset LOGu. 5. Překopírováním si uschovat soubor .LOG použitý v bodu 4. a přejmenovat jej třeba na oskarold.log Vznikne tím tzv. offline log. Přípona .log musí být zachována! 6. Původní databázové soubory lze zahodit (netýká se souboru z bodu 5.) 8. Provést reload spuštěním reloadovacího skriptu (připojen je pouze DBA-SQL v ISQL) 9. Soubor .LOG vzniklý minulým krokem smazat (vznikne znovu při spuštění serveru). K němu přidat také offline LOG získaný v bodu 5 (se jménem např. oskarold.log). 10.Provést v příkazové řádce příkaz dblog -x 0 -z nnnn <jméno_DB_souboru>, kde nnnn je číslo získané v bodu 4. 11.Spustit ISQL a provést tento příkaz (viz pozn.4 níže): call SYS.sa_setremoteuser(106, 4462996, 4462996, 3, 0, 4462673, 4462673, 2, 0) kde hodnoty odpovídají sloupcům získaným v bodě 2. 106 - 1.sloupec - POZOR může se v nové DB lišit - jedná se o user_id(remote_usera) - viz bod 12. 4462996 - 9.sloupec 4462996 - 10.sloupec 3 - 11.sloupec 0 - 12.sloupec 4462673 - 14.sloupec 4462673 - 15.sloupec 2 - 16.sloupec 0 - 17.sloupec
12.Pokud nejsou user_id(remote_usera) u staré a nové DB stejné, je třeba opravit a znovu zavolat proceduru SYS.sa_setsubscription (viz reloadovací skript - kapitola SQL Remote).
Pozn.1: Během provádění bodů 1. až 11. nesmí dojít k sehrání dat replikačním agentem (dbremote.exe)
Pozn.2: Po několika úspěšných replikačních cyklech kdy se truncation point pro SQL Remote (zjistit utilitou DBLOG.EXE) posune za konec stareho LOGu, lze starý (offline) LOG soubor smazat (viz bod 5.) To lze zajistit i automaticky
Pozn.3: Pro rozběhnutí replikačního systému po reloadu je nezbytně nutné, aby koncový offset starého LOGu (offline) byl shodný s počátečním offsetem nového LOGu (online) a aby byl starý soubor LOG přítomen vedle nového LOGu nebo v jiném adresáři, pak je nutno jej uvést na konci příkazové řádky pro dbremote.exe
Pozn.4: Pro vygenerování SQL skriptu pro bod 11. lze s výhodou použít tento select (aplikovat na starou DB) select 'call SYS.sa_setremoteuser('+cast(user_id as char(5))+','+ cast(log_sent as char(15))+','+ cast(confirm_sent as char(15))+','+ cast(send_count as char(15))+','+ cast(resend_count as char(15))+','+ cast(log_received as char(15))+','+ cast(confirm_received as char(15))+','+ cast(receive_count as char(15))+','+ cast(rereceive_count as char(15))+');' from sys.sysremoteuser order by user_id; output to d:\orea\update_remote.sql quote ''
V tom případě je tím nahrazen bod 2.
Pozn.5: Zdroje chyb jsou tyto: - při manipulacemi s lokálními databázemi se omylem provádí příkazy na jiné DB než je žádoucí, doporučuje se dodržovat postup - manipulace s lokálními databázemi - koncový offset starého logu je sejmut před unloadem, ale pro funkci offline logu u nové DB je použit log po unloadu (offsety pak na sebe nenavazují, protože i pouhým připojením k DB se už offset posouvá).
Související témata |