Ogni tanto, indipendentemente dall'azienda per cui lavoro, mi viene chiesto di creare un nuovo database di produzione. Stavo lavorando proprio a questo compito oggi quando ho iniziato a pensare a quanto lavoro fosse necessario creare un database nuovo di zecca in passato, quanto il DBCA gestisce per noi oggi e quanto resta ancora da fare.
Attualmente disponiamo di un database di sviluppo e test per la nostra applicazione di terze parti. Distribuiremo l'applicazione alla produzione entro la fine della settimana, quindi mi è stato affidato il compito di impostare una versione di produzione di questo database. Il server di database di produzione è un cluster RAC a 3 nodi che è già stato impostato per me perché attualmente stiamo eseguendo altri due database sul cluster. Quindi questo mi risparmia la fase di installazione e configurazione dell'infrastruttura di rete e del software RDBMS. Ma quando ho iniziato a configurare il database, ho iniziato a pensare a quanto lavoro mi restava ancora da fare. E poiché raramente impostiamo database di produzione nuovi di zecca, alcune di queste attività non sono facilmente ricordabili come altre. Di seguito sono riportati i passaggi che ho seguito oggi per rendere operativo il database di produzione.
1. Utilizzando i database di sviluppo/test come guida, ho determinato i miei requisiti di memoria e di archiviazione su disco.
2. Ho verificato che il cluster RAC di produzione disponesse di memoria sufficiente per supportare le nuove istanze del database.
3. Ho collaborato con il mio Storage Admin per ottenere lo spazio di archiviazione su disco necessario montato sul cluster.
4. Ho quindi avviato il DBCA per creare il nuovissimo database. Ho esaminato la procedura guidata e inserito i valori appropriati, quindi ho lasciato che DBCA facesse la sua magia.
5. Non mi piace davvero il modo in cui il DBCA mi consente di creare/allocare i registri di ripristino, quindi dopo aver creato il database, ho creato i miei gruppi di registri di ripristino (multiplex ovviamente) e ho eliminato i gruppi di registri di ripristino creati dal DBCA per me.
6. Non riesco mai a capire come aggiungere un terzo file di controllo nel DBCA. Quindi, dopo aver creato il database, lo spengo, faccio una terza copia del file di controllo, aggiorno SPFILE con il fatto che ora ci sono 3 file di controllo e avvio il database.
7. Il DBCA ha messo il mio file di password e spfile in posizioni che non sono ottimali per me. Quindi li ho spostati. In $ORACLE_HOME/dbs ho creato dei softlink che puntano alle nuove posizioni. Quindi ho usato srvctl per aggiornare il percorso spfile in CRS.
8. Non ho mai usato il DBCA per impostare la modalità archivio. Quindi salto sempre quella parte del DBCA. Inoltre, mi piace l'idea di non archiviare i miei registri di ripristino quando il DBCA sta creando il database per accelerare tale processo. Quindi, a questo punto, ho impostato la registrazione dell'archivio per il database.
9. Il database verrà utilizzato con uno Standby e mi piace assicurarmi di avere un cambio di registro almeno una volta all'ora, quindi ho impostato ARCHIVE_LAG_TARGET su 3600.
A questo punto, il database barebone è configurato e pronto per l'uso. Ora è il momento di leggere il database per la nostra applicazione.
10. Ho impostato tutti i tablespace necessari per l'applicazione.
11. Ho impostato tutti gli utenti richiesti per l'applicazione.
12. Modificato lo spazio tabella predefinito del database in uno di quelli che ho creato sopra. Quindi è stato eliminato lo spazio tabella USERS.
13. Poiché si tratta di un database RAC, è necessario configurare il servizio per la connessione dell'applicazione.
14. Ora che il database è pronto per l'applicazione, è necessario configurare il database Standby. Questa operazione è stata eseguita facilmente utilizzando la procedura guidata Aggiungi database in standby in Controllo griglia.
15. Il nostro database Standby si trova su un cluster RAC a 2 nodi. La procedura guidata Aggiungi database standby crea un database a istanza singola in modo che la procedura guidata Converti in database cluster sia stata eseguita in Grid Control per rendere Standby un database RAC.
Infine, l'ultimo passaggio è stato quello di garantire che eventuali attività di manutenzione fossero estese al nuovo database. Ad esempio, i lavori cron per eliminare i vecchi file di registro dovevano essere modificati per la nuova istanza.
Oh! È un sacco di lavoro per impostare un database iniziale nel nostro ambiente di produzione. Come ho detto all'inizio, il DBCA fa molto lavoro per noi ora. E Grid Control automatizza anche gran parte del lavoro di creazione Standby. Ma ci sono ancora molti passaggi da fare.
