Quanto tempo impiegherebbe per aggiornare un Oracle DB 1T da 10g a 11g?


8

Quanto tempo impiegherebbe per aggiornare un DB Oracle con dati 1T da 10g a 11g di solito / all'incirca? Devo stimare i tempi di inattività perché è un problema. Grazie mille!

Risposte:


11

30-90 minuti secondo le migliori pratiche di Oracle per l'aggiornamento . Si tratta della stima più vicina che ti verranno fornite tutte le incognite in questa situazione.

La dimensione del database conta davvero pochissimo nel determinare quanto tempo richiederà l'aggiornamento. Ecco i principali fattori che incidono sulla durata (dal blog di aggiornamento di Oracle.com) :

  • Numero di componenti e opzioni di database installati: più componenti / opzioni sono stati installati, più script di aggiornamento dovranno essere eseguiti, più tempo ci vorrà

  • Statistiche di dizionario valide e non obsolete - anche se la creazione di statistiche di dizionario in alcune versioni precedenti di Oracle non è stata una brillante idea poiché il supporto del dizionario dei dati dovrebbe essere analizzato dal supporto dell'ottimizzatore basato su regole. Soprattutto prima di un aggiornamento. In caso contrario, ciò avverrà durante l'aggiornamento mentre il database viene avviato in una modalità di aggiornamento limitata causando ulteriori tempi di inattività.

  • Numero di righe in AUD $ se audit_trail è impostato su DB

  • Numero di sinonimi durante l'aggiornamento da Oracle 9i - i sinonimi verranno toccati e otterrà una nuova dipendenza nel dizionario in DEPENDENCY $ - se c'è un numero elevato (come 100.000), questo può richiedere del tempo

  • Numero di oggetti in XDB

  • A un tasso molto basso se COMPATIBILE verrà aumentato: Numero di file di dati e dimensione dei repository

Ecco alcuni altri fattori che potresti voler considerare che non sono correlati al nucleo dell'aggiornamento stesso:

  • Se lo script pre-aggiornamento è stato eseguito e i problemi risolti.
  • Quanti oggetti non validi ci sono.
  • Se l'aggiornamento è in atto (vs. Import / Export, Stream, Data Guard, ecc.)
  • Se DBUA o gli script vengono utilizzati per eseguire l'aggiornamento.
  • Se la nuova casa Oracle è preinstallata.
  • Velocità e velocità del disco.
  • Altre attività CPU / disco si verificano contemporaneamente.
  • Modalità registro archivio.
  • Altre modifiche apportate con l'aggiornamento.
  • Se è necessario un backup a freddo prima e / o dopo l'aggiornamento.
  • Eventuali set di patch o patch una tantum che verranno applicati.
  • Quanta verifica dell'aggiornamento deve essere eseguita prima che possa essere resa disponibile.

Probabilmente il fattore più grande che influenza l'aggiornamento è il fattore sconosciuto. Anche quando l'upgrade viene praticato in anticipo su hardware simile con set di dati simili, ecc. Possono ancora verificarsi cose che erano impreviste e possono influire drasticamente sulla durata. Tenendo presente ciò, è necessario imitare l'ambiente di produzione il più vicino possibile per gli aggiornamenti dei test. Cioè, il più vicino possibile al budget.

Se lo spazio è il problema che impedisce di testare l'aggiornamento, prendere in considerazione il ripristino del database in una casella di prova escludendo alcuni dei tablespace utente più grandi. Questo non ti darà una sensazione esatta per il momento, ma dovrebbe darti un campo di gioco più vicino e permetterti di superare molte delle incognite.


Leigh molto riflessivo, hai ragione. Grazie mille!
magqq,

5

Presumibilmente, hai un'istanza di sviluppo e test di questo database in esecuzione su hardware simile con un volume di dati simile e gli stessi componenti di database installati, giusto? E, presumibilmente, aggiornerai questi ambienti inferiori (e testerai che le applicazioni che usano questo database funzionano ancora correttamente), giusto?

Supponendo che sia il caso, avrei tempo quanto tempo ci è voluto per aggiornare il database di sviluppo e usarlo come stima del tempo necessario per aggiornare le altre istanze. Ci sono, ovviamente, una serie di fattori che determinano quanto tempo richiederà l'aggiornamento effettivo. La mia ipotesi è che il tempo di inattività dovrebbe probabilmente essere solo un'ora o due, ma stai molto meglio utilizzando il tempo effettivo richiesto per aggiornare lo sviluppo.


2
supponiamo che sia in un negozio economico, senza un ambiente simile nella struttura di test / sviluppo come nella produzione. Se è così ... qual è un consiglio abbastanza buono? :-)
Marian,

1
@Marian - Come ho detto, la mia ipotesi senza alcuna informazione è di un'ora o due. Ma se stai lavorando in un negozio economico che non acquista nemmeno un ambiente inferiore adeguato, riempirei in modo massiccio la mia stima perché presumo che qualcosa andrebbe storto durante l'aggiornamento. Se non hai intenzione di spendere per costruire ambienti inferiori adeguati, non puoi aspettarti grandi livelli di uptime.
Grotta di Giustino,

1
Anche se hai una piattaforma di sviluppo che ti darà un numero decente di palla da cui partire. Prendi quel numero e se ti sembra un po 'basso, doppio o triplo e dai quel numero alla direzione.
mrdenny,

3
@Marian - I saggi sanno però che è molto meglio sopravvalutare una finestra di downtime piuttosto che sottovalutarla. Se un'organizzazione non desidera fornire un ambiente adeguato affinché un DBA possa ottenere metriche ragionevoli, deve accettare una finestra di inattività molto più ampia di quella che farebbe se gli ambienti inferiori fossero adeguatamente forniti.
Justin Cave,

1
@magqq - L'aggiornamento stesso non dipende normalmente dai dati. Tuttavia, poiché in genere si desidera un backup completo prima di un aggiornamento, la fase di esecuzione del backup dipende in larga misura dalla dimensione del database.
Justin Cave,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.