Jednou za čas, bez ohledu na to, pro kterou společnost pracuji, jsem požádán, abych založil novou produkční databázi. Právě na tomto úkolu jsem dnes pracoval, když jsem začal přemýšlet o tom, kolik práce dalo v minulosti vytvořit zbrusu novou databázi, kolik toho za nás dnes DBCA zvládne a kolik toho ještě zbývá udělat.
V současné době máme vývojovou a testovací databázi pro naši aplikaci třetích stran. Aplikaci uvedeme do produkce do konce týdne, takže jsem dostal za úkol nastavit produkční verzi této databáze. Produkční databázový server je 3-uzlový RAC cluster, který mi již byl nastaven, protože na clusteru aktuálně provozujeme dvě další databáze. Takže mi to ušetří krok instalace a konfigurace Grid Infrastructure a softwaru RDBMS. Ale když jsem začal zakládat databázi, začal jsem přemýšlet o tom, kolik práce mi ještě zbývá. A protože jen zřídka zakládáme zcela nové produkční databáze, některé z těchto úkolů se nepamatují tak snadno jako jiné. Níže jsou uvedeny kroky, kterými jsem dnes prošel, abych zprovoznil produkční databázi.
1. Pomocí dev/test databází jako svého průvodce jsem určil své požadavky na paměť a diskové úložiště.
2. Ověřil jsem, že produkční cluster RAC má dostatek paměti pro podporu nových instancí databáze.
3. Pracoval jsem se svým správcem úložiště, abych získal potřebné diskové úložiště připojené ke clusteru.
4. Potom jsem spustil DBCA, abych vytvořil zcela novou databázi. Prošel jsem průvodcem a vyplnil příslušné hodnoty a nechal jsem DBCA, aby udělala své kouzlo.
5. Opravdu se mi nelíbí, jak mi DBCA umožňuje vytvářet/přidělovat redo logy, takže po vytvoření databáze jsem vytvořil své vlastní skupiny redo logů (samozřejmě multiplexované) a zrušil jsem skupiny redo logů, které pro mě DBCA vytvořila.
6. Nikdy nemohu přijít na to, jak přidat 3. kontrolní soubor do DBCA. Po vytvoření databáze ji tedy vypnu, udělám 3. kopii kontrolního souboru, aktualizuji SPFILE s tím, že jsou nyní 3 kontrolní soubory a spustím databázi.
7. DBCA umístil můj soubor s hesly a spfile do míst, která pro mě nejsou optimální. Tak jsem je přesunul. V $ORACLE_HOME/dbs jsem vytvořil softwarové odkazy ukazující na nová umístění. Potom jsem použil srvctl k aktualizaci umístění spfile v CRS.
8. Nikdy jsem nepoužil DBCA k nastavení režimu archivace. Takže tu část DBCA vždy přeskakuji. Kromě toho se mi líbí myšlenka nearchivovat své redo logy, když DBCA vytváří databázi, aby se tento proces urychlil. V tuto chvíli jsem tedy nastavil protokolování archivu pro databázi.
9. Databáze bude používána s pohotovostním režimem a chtěl bych zajistit, abych měl přepínač protokolu alespoň jednou za hodinu, takže jsem nastavil ARCHIVE_LAG_TARGET na 3600.
V tomto okamžiku je databáze holých kostí nastavena a připravena k použití. Nyní je čas načíst databázi pro naši aplikaci.
10. Nastavil jsem pro aplikaci všechny požadované tabulkové prostory.
11. Pro aplikaci jsem nastavil všechny požadované uživatele.
12. Změnil jsem výchozí tabulkový prostor databáze na jeden z těch, které jsem vytvořil výše. Poté zrušil tabulkový prostor USERS.
13. Protože se jedná o databázi RAC, musíme nastavit službu, aby se aplikace připojila.
14. Nyní, když je databáze připravena pro aplikaci, musíme nastavit pohotovostní databázi. To bylo snadno provedeno pomocí průvodce přidáním pohotovostní databáze v Grid Control.
15. Naše pohotovostní databáze je na 2uzlovém clusteru RAC. Průvodce přidáním pohotovostní databáze vytvoří databázi s jednou instancí, takže byl spuštěn průvodce Převést na klastrovou databázi v Grid Control, aby se pohotovostní režim stal RAC databází.
Posledním krokem bylo zajistit, aby všechny úkoly údržby byly rozšířeny na novou databázi. Například úlohy cron pro odstranění starých souborů protokolu bylo třeba upravit pro novou instanci.
Páni! To je hodně práce, než nastavit počáteční databázi v našem produkčním prostředí. Jak jsem řekl na začátku, DBCA za nás nyní dělá hodně práce. A Grid Control automatizuje také spoustu práce při vytváření pohotovostního režimu. Ale je v tom ještě spousta kroků.