Backup e recupero nel servizio Base Database
Il backup del database è fondamentale per garantire la sicurezza dei dati. Oracle offre diversi metodi per eseguire il backup del database.
La funzione Backup automatici gestiti da Oracle è il metodo preferito per eseguire il backup dei database Oracle Cloud perché puoi configurare facilmente le impostazioni di backup utilizzando la console. La funzione di backup automatici supporta Recovery Service e Object Storage come destinazione di backup per offrirti una soluzione di backup cloud completamente automatizzata con lo stesso costo. Non è necessario eseguire backup manuali o task di amministrazione dello storage di backup. È inoltre possibile memorizzare i backup nello storage locale. Ogni destinazione di backup ha i suoi vantaggi e requisiti che dovresti considerare, come descritto di seguito.
Servizio di recupero (consigliato)
Un servizio completamente gestito basato sulla tecnologia Zero Data Loss Recovery Appliance di Oracle on-premise che offre una moderna protezione della sicurezza informatica per i database Oracle. Funzionalità uniche e automatizzate proteggono le modifiche a Oracle Database in tempo reale, convalidano i backup senza sovraccarico del database di produzione e consentono un ripristino rapido e prevedibile in qualsiasi momento.
Se i tuoi backup sono attualmente configurati con lo storage degli oggetti, puoi passare senza problemi al servizio di recupero per ottenere funzionalità avanzate con lo stesso costo.
Per ulteriori informazioni su Recovery Service, vedere Informazioni su Oracle Database Autonomous Recovery Service.
Storage degli oggetti
Una soluzione di storage sicura, scalabile e su richiesta per i database.
Per ulteriori informazioni sullo storage degli oggetti, vedere Panoramica sullo storage degli oggetti.
Memoria locale
- I backup vengono memorizzati localmente nell'area di recupero rapido del sistema DB.
- Durabilità: bassa
- Disponibilità: Medio
- Tasso di backup e recupero: alto
- Vantaggi: backup ottimizzato e recupero rapido point-in-time.
- Svantaggi: se il sistema DB non è disponibile, anche il backup non è disponibile.
Al momento, Oracle non offre la possibilità di collegare volumi di storage a blocchi a un sistema DB, pertanto non puoi eseguire il backup dei volumi collegati alla rete.
Per i backup non gestiti, puoi utilizzare RMAN o dbcli e devi creare e gestire i tuoi bucket di storage degli oggetti per i backup.
Nota: se in precedenza si è usato RMAN o dbcli per configurare i backup e successivamente si sceglie di usare la console o l'API per i backup, viene creata una nuova configurazione di back-up associata al database. Ciò significa che non è più possibile utilizzare i backup non gestiti configurati in precedenza.
Per istruzioni dettagliate sulla creazione dei backup, vedere:
- Eseguire il backup di un database mediante la console
- Eseguire il backup di un database nello storage degli oggetti mediante RMAN
Per istruzioni dettagliate sul ripristino dai backup, vedere:
- Recupera un database mediante la console
- Recupera un database dallo storage degli oggetti mediante backup RMAN
- Recupera un database dall'area di memorizzazione degli oggetti OCI Classic
Criterio IAM necessario
Per utilizzare Oracle Cloud Infrastructure, un amministratore deve concedere l'accesso di sicurezza in un criterio. Questo accesso è necessario indipendentemente dal fatto che si stia utilizzando la console o l'API REST con un SDK, un'interfaccia CLI o unaltro strumento. Se viene visualizzato un messaggio che indica che non si dispone dell'autorizzazione o che non si dispone dell'autorizzazione, verificare con l'amministratore il tipo di accesso di cui si dispone e il compartimento di cui lavorare.
Se non si conoscono i criteri, vedere Guida introduttiva ai criteri e Criteri comuni.
Prerequisiti
Rivedere e assicurarsi che vengano soddisfatti tutti i prerequisiti riportati di seguito per l'operazione di backup e recupero.
Recovery Service
Per informazioni dettagliate sui prerequisiti del servizio di recupero, vedere Configura servizio di recupero.
Storage degli oggetti
- Il sistema DB richiede l'accesso allo storage degli oggetti, inclusa la connettività all'endpoint Swift applicabile. Oracle consiglia di utilizzare un gateway di servizi con la VCN per abilitare questo accesso. Vedere VCN e subnet.
- Bucket di storage degli oggetti esistente da usare come destinazione di backup. Puoi utilizzare la console o l'API di storage degli oggetti per creare il bucket. Vedere Gestione dei periodi fissi.
- Token di autenticazione generato da OCI. È possibile utilizzare la console o l'API IAM per generare la password. Vedere Gestione delle credenziali utente.
-
Il nome utente specificato nel file di configurazione del backup deve disporre dell'accesso a livello di tenancy allo storage degli oggetti. Un modo semplice per farlo è quello di aggiungere il nome utente al gruppo Administrators. Tuttavia, ciò consente l'accesso a tutti i servizi cloud. Un amministratore dovrebbe invece creare un criterio simile al seguente che limita l'accesso solo alle risorse necessarie nello storage degli oggetti per il backup e il ripristino del database:
Allow group <group_name> to manage objects in compartment <compartment_name> where target.bucket.name = '<bucket_name>' Allow group <group_name> to read buckets in compartment <compartment_name>Per ulteriori informazioni sull'aggiunta di un utente a un gruppo, vedere Gestione dei gruppi.
Per ulteriori informazioni sullo storage degli oggetti, vedere Panoramica sullo storage degli oggetti.
Informazioni generali
Affinché un'operazione di backup venga eseguita correttamente, il database e il sistema DB devono essere in stato "Disponibile". Oracle consiglia di evitare di eseguire azioni che potrebbero interferire con la disponibilità (ad esempio l'applicazione di patch e le operazioni Data Guard) mentre è in corso un'operazione di backup. Se un'operazione di backup automatico non riesce, il servizio di database riprova l'operazione durante la finestra di backup del giorno successivo. Se un backup completo su richiesta non riesce, puoi provare di nuovo l'operazione quando viene ripristinata la disponibilità del sistema DB e del database.
Oltre ai prerequisiti elencati, assicurarsi che siano soddisfatte le condizioni riportate di seguito per evitare errori di backup.
- La modalità di archiviazione del database è impostata su
ARCHIVELOG(impostazione predefinita). - La directory
/u01nel file system host del database dispone di spazio libero sufficiente per l'esecuzione dei processi di backup. - Il file .bash_profile per l'utente oracle non include alcun comando interattivo, ad esempio
oraenv, o che potrebbe generare un messaggio di errore o di avvertenza. - (Per i backup automatici) Non sono state apportate modifiche alla voce
WALLET_LOCATIONpredefinita nel file sqlnet.ora. - Non sono state apportate modifiche alle impostazioni di backup
RMANutilizzando i comandiRMANstandard.
Per ulteriori informazioni sui problemi che possono derivare dal mancato rispetto di queste linee guida, vedere Risolvere i problemi dei backup non riusciti.
Funzioni di backup gestito
Le informazioni riportate di seguito si applicano ai backup gestiti configurati utilizzando la console o l'API.
Nota: i database in un compartimento della zona di sicurezza devono avere backup automatici abilitati. Per una lista completa dei criteri che interessano le risorse di Base Database Service, vedere Criteri delle zone di sicurezza.
Attualmente sono supportati i due tipi di backup automatici riportati di seguito.
- Recovery Service: una soluzione di backup centralizzata, completamente gestita e standalone per i database.
- Storage degli oggetti: una soluzione di storage sicura, scalabile e su richiesta per i database.
Per allinearsi alla procedura consigliata da Oracle di utilizzare i privilegi amministrativi SYSBACKUP per le operazioni di backup e ripristino, l'automazione cloud crea un utente amministrativo comune denominato C##DBLCMUSER con il ruolo SYSBACKUP a livello di contenitore CDB$ROOT. Le operazioni di backup e ripristino vengono pertanto eseguite con l'utente che dispone dei privilegi minimi necessari. Le credenziali per questo utente vengono generate in modo casuale e gestite in modo sicuro dall'automazione cloud. Se l'utente non viene trovato o è BLOCCATO e SCADUTO, l'automazione cloud ricreerà o sbloccerà questo utente durante le operazioni di backup o ripristino.
Backup automatici dei redo log incrementali e archiviati
Quando si abilita la funzione di backup dello storage degli oggetti per un database, il servizio crea gli elementi riportati di seguito su base continuativa.
- Backup di livello settimanale 0, generalmente creato in un giorno di fine settimana specificato. Un backup di livello 0 è l'equivalente di un backup completo. Si noti che nella console i backup settimanali di livello 0 vengono visualizzati nell'elenco dei backup con tipo "incrementale" come i backup giornalieri di livello 1.
- Backup giornalieri di livello 1, ovvero backup incrementali creati ogni giorno per i sei giorni successivi al giorno di backup di livello 0.
- I backup di livello 0 e 1 vengono memorizzati nell'area di memorizzazione degli oggetti a cui è assegnato un OCID.
- Backup dei redo log archiviati in corso (con una frequenza minima ogni 60 minuti). Il campo Ora ultimo backup nella pagina dei dettagli del database in OCI Console visualizza l'ora degli ultimi redo log archiviati. Questo backup è diverso dai backup automatici di livello 0 e 1 in quanto si basa sui dati di log e non dispone di un OCID assegnato. L'ultimo backup del redo log archiviato può essere utilizzato per creare un nuovo database o per recuperare un database con una perdita di dati minima.
Conservazione backup
Se si sceglie di abilitare i backup automatici, è possibile scegliere tra uno dei periodi di conservazione forniti o un criterio personalizzato. Il sistema elimina automaticamente i backup incrementali alla fine del periodo retention scelto.
I seguenti periodi di conservazione sono disponibili per Recovery Service. I periodi di conservazione (in giorni) sono definiti nel criterio di protezione del servizio di recupero.
- Bronzo (14 giorni)
- Argento (35 giorni) (impostazione predefinita)
- Oro (65 giorni)
- Platino (95 giorni)
- Personalizzato (criterio di protezione definito dall'utente)
I seguenti periodi di conservazione sono disponibili per lo storage degli oggetti.
- 7 giorni
- 15 giorni
- 30 giorni (impostazione predefinita)
- 45 giorni
- 60 giorni
Backup della conservazione a lungo termine con il servizio di recupero
Il backup della fidelizzazione a lungo termine (LTR) ti consente di memorizzare backup completi per periodi fino a dieci anni per esigenze di compliance, normative o di altro tipo con una gestione e un'immutabilità complete del ciclo di vita LTR.
Per LTR con Recovery Service, il periodo di conservazione deve essere in giorni (90 - 3650) o in anni (1 - 10) da quando è stato creato il backup.
Per creare un backup LTR con il periodo di conservazione richiesto, Recovery Service non richiede la creazione di un nuovo backup di produzione completo, ma lo fa utilizzando backup operativi già esistenti nel sistema all'interno della finestra di recupero definita nel criterio. Per informazioni dettagliate, vedere Creare un backup su richiesta di un database.
Puoi modificare il periodo di conservazione per uno specifico backup LTR esistente entro il periodo di conservazione. Per informazioni dettagliate, vedere Modificare il periodo di conservazione di un backup di conservazione a lungo termine con il servizio di recupero.
Puoi ripristinare un backup LTR per creare un nuovo database entro il periodo di conservazione. Per informazioni dettagliate, vedere Creare un sistema DB da un backup utilizzando la console.
All'arresto del sistema DB, i backup LTR verranno eliminati in base al valore 'Opzioni di eliminazione dopo l'interruzione del database'.
- Elimina backup in 72 ore: tutti i backup, inclusi quelli LTR, verranno eliminati.
- Elimina in base ai criteri: i backup LTR verranno conservati in base ai criteri di conservazione di ogni backup LTR.
Nota: Oracle consiglia di scegliere l'opzione 'Elimina in base ai criteri' durante l'arresto di un sistema DB per garantire che i backup LTR vengano conservati.
Considera i seguenti fattori aggiuntivi per i backup LTR:
- I backup LTR continueranno a esistere indipendentemente da eventuali backup automatici configurati nel database.
- I backup LTR verranno eliminati automaticamente al termine del periodo retention specificato.
- Il ripristino in loco non è supportato per LTR.
- Per i database in una configurazione Data Guard, il backup LTR verrà creato solo per il database in cui è richiesto.
- Lo stato del database deve essere AVAILABLE per creare un LTR.
- LTR è supportato per database con keystore basati su file TDE o KMS.
- Tutte le chiavi di cifratura verranno mantenute per l'intero periodo di conservazione dell'LTR.
- È possibile annullare un LTR se si trova nello stato di "creazione".
- È possibile eliminare un backup LTR in qualsiasi momento dopo la sua creazione.
- Durante il ripristino, se il backup LTR in fase di ripristino è una versione principale della home del database supportata, verrà ripristinato alla RU più recente di tale versione.
- Durante il ripristino, se il backup LTR in fase di ripristino non è una versione principale della home del database supportata, verrà ripristinato in una qualsiasi delle versioni principali supportate, in base alla quale il database deve essere aggiornato a una qualsiasi delle versioni principali supportate.
Opzioni di ripristino
Per il database sono disponibili le opzioni di ripristino riportate di seguito. Questa operazione non è supportata per LTR.
- Ripristina alla versione più recente: ripristina il database all'ultimo stato valido noto con la minore perdita di dati possibile.
- Ripristina in base a indicatore orario: ripristina il database in base all'indicatore orario specificato.
- Ripristina in SCN: ripristina il database utilizzando il numero SCN (System Change Number) specificato. Questo SCN deve essere valido.
Nota: è possibile determinare il numero SCN da utilizzare accedendo all'host del database e eseguendo query su di esso oppure accedendo a log in linea o archiviati.
Criteri di protezione
Recovery Service utilizza i criteri di protezione per controllare la conservazione dei backup del database in Oracle Cloud.
Le policy di protezione forniscono una gestione automatizzata della retention per i database protetti, soddisfacendo i requisiti per gli ambienti regolamentati. Ogni database protetto deve essere associato a un criterio di protezione.
Un criterio di protezione determina il periodo massimo (in giorni) consentito per conservare i backup creati dal servizio di recupero. In base ai requisiti aziendali, puoi assegnare criteri separati per ogni database protetto o utilizzare un singolo criterio in tutti i database protetti in una VCN.
Per ulteriori informazioni, vedere Gestione dei criteri di protezione.
Database protetti
Il database protetto si riferisce a un database Oracle Cloud che utilizza Recovery Service per le operazioni di backup.
Per ulteriori informazioni, vedere Gestione dei database protetti.
Protezione dei Dati in tempo reale
Recovery Service offre protezione dei dati in tempo reale in modo da poter recuperare un database entro pochi secondi da un errore del database.
La protezione in tempo reale è il trasferimento continuo di modifiche di redo da un database protetto a Recovery Service. Ciò riduce la perdita di dati e fornisce un recovery point objective (RPO) vicino allo 0. Questa è un'opzione di costo aggiuntivo.
Per ulteriori informazioni, vedere Protezione dei dati in tempo reale.
Opzioni di eliminazione del backup dopo l'arresto del database
Quando si arresta un database, tutte le relative risorse vengono eliminate, insieme a eventuali backup automatici. I backup gestiti che utilizzano il servizio di recupero e la destinazione dello storage degli oggetti verranno eliminati in base alle opzioni dei criteri di conservazione selezionate.
È possibile utilizzare le opzioni riportate di seguito per conservare i backup del database gestito dopo l'arresto del database. Queste opzioni possono anche aiutare a ripristinare il database dai backup in caso di danni accidentali o dannosi al database.
- Mantieni i backup in base al periodo di conservazione: quando un database viene arrestato, i backup automatici del database associati al database arrestato e tutte le relative risorse verranno rimossi alla fine del periodo di conservazione specificato.
- Mantieni i backup per 72 ore, quindi elimina: quando un database viene arrestato, i backup automatici del database associati al database arrestato e tutte le relative risorse verranno conservati per 72 ore e quindi eliminati. I backup vengono conservati per 72 ore per evitare la cancellazione accidentale da parte dell'utente.
Pianificazione backup
Per i backup del Recovery Service, il processo di backup automatico viene avviato in qualsiasi momento o all'interno della finestra assegnata.
Per i backup dello storage degli oggetti, il processo di backup automatico utilizzato per creare i backup di livello 0 e 1 può essere eseguito in qualsiasi momento all'interno della finestra di backup giornaliera (tra mezzanotte e 6:00 AM). Facoltativamente, è possibile specificare una finestra di pianificazione di 2 ore per il database durante la quale inizierà il processo di backup automatico. Ci sono 12 finestre di pianificazione tra cui scegliere, ognuna a partire da un'ora pari (ad esempio, una finestra viene eseguita dalle 4:00-6:00 AM e la successiva dalle 6:00-8:00 AM). I job di backup non vengono necessariamente completati all'interno della finestra di pianificazione.
Per i backup dello storage degli oggetti, la finestra di backup predefinita compresa tra le 00:00 e le 06:00 nel fuso orario dell'area del sistema DB viene assegnata al database se non si specifica una finestra. Si noti che la finestra di pianificazione del backup predefinita è lunga sei ore, mentre le finestre specificate sono lunghe due ore.
Durante la pianificazione dei backup, tenere presenti i fattori riportati di seguito.
- Fuso orario della finestra di backup: i backup automatici abilitati per la prima volta dopo il 20 novembre 2018 su qualsiasi database verranno eseguiti tra la mezzanotte e le 6:00 AM nel fuso orario dell'area del sistema DB. Se hai abilitato i backup automatici in un database prima di questa data, la finestra di backup per il database continuerà a essere compreso tra la mezzanotte e le 6:00 UTC. È possibile creare una richiesta di servizio My Oracle Support per eseguire i backup automatici in una finestra di backup a scelta.
- Data Guard: in un'associazione Data Guard, puoi configurare i backup automatici e creare i backup del database primario. Tuttavia, non puoi configurare backup automatici o creare backup del database di standby. Inoltre, dopo un'operazione di switchover, è necessario configurare di nuovo i backup automatici per il database che ha assunto il ruolo primario nell'associazione Data Guard.
- Modifiche al periodo di conservazione: se in futuro si accorcia il periodo di conservazione automatica dei backup del database, i backup esistenti che non rientrano nel periodo di conservazione aggiornato vengono eliminati dal sistema.
- Costi dello storage degli oggetti: i backup automatici comportano costi di utilizzo dello storage degli oggetti.
Backup completi su richiesta
Puoi creare un backup completo del database in qualsiasi momento, a meno che il database non assuma il ruolo di standby in un'associazione Data Guard.
Backup standalone
Quando interrompi un sistema DB o un database, tutte le relative risorse vengono eliminate, insieme a eventuali backup automatici. I backup gestiti che utilizzano il servizio di recupero e la destinazione dello storage degli oggetti verranno eliminati in base alle opzioni dei criteri di conservazione selezionate. I backup completi rimangono nello storage degli oggetti come backup standalone. È possibile utilizzare un backup standalone per creare un nuovo database.
Nota:
- La lista dei backup visualizzati nella console non include i backup non gestiti (backup creati direttamente utilizzando
RMANodbcli). - Tutti i backup vengono cifrati con la stessa chiave master utilizzata per la cifratura del wallet TDE (Transparent Data Encryption).
Annulla backup completo o incrementale in esecuzione
Puoi annullare un backup in corso, consentendoti di liberare risorse di sistema. Nell'ambito del workflow Crea database e in modo indipendente (dopo la creazione del database), è possibile abilitare il backup automatico e selezionare la destinazione di backup desiderata. A seconda della destinazione di backup selezionata, è possibile disporre di uno o più backup completi e di diversi backup incrementali. Una volta avviato uno di questi backup, hai la possibilità di annullarli a metà strada. Puoi annullare qualsiasi backup in esecuzione (automatico o standalone) dalla console o dall'API. È possibile annullare un backup manuale che viene attivato quando si fa clic sul pulsante Crea backup. È inoltre possibile eliminare un backup manuale annullato.
Backup e ripristino da un database di Standby in un'associazione Data Guard
È possibile eseguire il backup e il ripristino da un database di standby in un'associazione Data Guard. Utilizzando questa funzione, puoi scaricare i backup nel database di standby, liberando così le risorse nel database primario.
Prima di iniziare, prendere nota delle procedure descritte di seguito.
- Puoi utilizzare il servizio di recupero o lo storage degli oggetti per eseguire il backup dei database in standby.
- Puoi pianificare i backup automatici e configurare i periodi di conservazione e le pianificazioni dei backup nel database di standby.
- Puoi creare un database in un altro dominio di disponibilità (AD) all'interno della stessa area o di un'area diversa da un backup del database di standby.
- I backup possono essere configurati solo sul database primario, solo sul database in standby o su entrambi i database primario e in standby. Tuttavia, quando è configurato, sia il database primario che quello in standby devono avere la stessa destinazione di backup.
- Per i backup nel Recovery Service, il database primario può essere ripristinato o recuperato dai backup del database di standby o del database primario. Analogamente, il database in standby può essere ripristinato o recuperato dai backup del database primario o del database in standby.
- Per i backup nello storage degli oggetti, il database primario e il database in standby possono essere ripristinati o recuperati solo dai rispettivi backup.
- La destinazione di backup del database primario e del database di standby in un'associazione Data Guard deve essere la stessa. Ad esempio, se la destinazione di backup del database primario è Recovery Service, la destinazione di backup del database di standby deve essere anche Recovery Service. Analogamente, se la destinazione di backup del database in standby è Recovery Service, anche la destinazione di backup del database primario deve essere Recovery Service.
- La destinazione di backup può essere modificata solo dopo aver disabilitato il backup nel database primario o in standby in un'associazione Data Guard. Ad esempio, se la destinazione di backup sia dei database primari che di standby è lo storage degli oggetti e si desidera modificare la destinazione di backup del server primario in un servizio di storage degli oggetti, disabilitare innanzitutto il backup in un database in standby.
- Se il backup automatico è stato configurato sul database primario, al momento dello switchover, i backup continueranno sul nuovo database di standby.
- Se il backup automatico è stato configurato in standby, al failover i backup continueranno nel nuovo database primario e i backup verranno disabilitati nel nuovo database di standby.
Per informazioni dettagliate sulla configurazione dei backup automatici mediante la console, vedere Configura backup automatici per un database in standby.
Ripristino tra più aree
Puoi utilizzare un backup esistente e ripristinarlo per creare un database (ripristino in loco) tra i domini di disponibilità all'interno della stessa area o in un'area diversa utilizzando un backup creato con Object Storage o Autonomous Recovery Service.
Puoi anche ripristinare un backup eseguito su un database configurato utilizzando wallet basati su host (wallet locali) o OCI Vault. Per ulteriori informazioni sulle chiavi di cifratura del database, vedere Gestisci chiavi di cifratura.
I prerequisiti riportati di seguito sono necessari per il ripristino tra più aree (all'interno della stessa tenancy) per Oracle Database Autonomous Recovery Service.
-
Peering VCN: entrambe le reti VCN nelle aree locali e remote devono essere sottoposte a peering tra le aree.
-
Aggiungere regole di sicurezza nelle reti VCN di origine e di destinazione.
-
Aggiungere le regole di entrata nell'origine.
-
Fare clic su Aggiungi regola di entrata e aggiungere i dettagli riportati di seguito per impostare una regola che consente il traffico HTTPS da qualsiasi posizione.
- Tipo di origine: CIDR
- CIDR di origine: specificare il CIDR della VCN in cui risiede il database.
- Protocollo IP: TCP
- Intervallo porte origine: Tutto
- Intervallo di porte di destinazione: 8005
- Descrizione: specificare una descrizione facoltativa della regola di entrata per facilitare la gestione delle regole di sicurezza.
-
Fare clic su Aggiungi regola di entrata e aggiungere questi dettagli per impostare una regola che consente il traffico SQLNet da qualsiasi posizione:
- Tipo di origine: CIDR
- CIDR di origine: specificare il CIDR della VCN in cui risiede il database.
- Protocollo IP: TCP
- Intervallo porte origine: Tutto
- Intervallo di porte di destinazione: 2484
- Descrizione: specificare una descrizione facoltativa della regola di entrata per facilitare la gestione delle regole di sicurezza.
-
Fare clic su Aggiungi regola di entrata e aggiungere i dettagli riportati di seguito per impostare una regola che consente il traffico HTTPS da qualsiasi posizione.
- Tipo di origine: CIDR
- CIDR di origine: specificare il CIDR della VCN di destinazione.
- Protocollo IP: TCP
- Intervallo di porte di origine: Tutto
- Intervallo di porte di destinazione: 8005
- Descrizione: specificare una descrizione facoltativa della regola di entrata per facilitare la gestione delle regole di sicurezza.
-
Fare clic su Aggiungi regola di entrata e aggiungere questi dettagli per impostare una regola che consente il traffico SQLNet da qualsiasi posizione:
- Tipo di origine: CIDR
- CIDR di origine: specificare il CIDR della VCN di destinazione.
- Protocollo IP: TCP
- Intervallo di porte di origine: Tutto
- Intervallo di porte di destinazione: 2484
- Descrizione: specificare una descrizione facoltativa della regola di entrata per facilitare la gestione delle regole di sicurezza.
-
-
Aggiungere le regole di uscita nella destinazione. Questi sono facoltativi se il traffico in uscita viene aperto per tutti gli IP e tutte le porte.
-
Fare clic su Aggiungi regola di uscita e aggiungere questi dettagli per impostare una regola che consente il traffico HTTPS da qualsiasi posizione:
- Tipo di origine: CIDR
- CIDR di origine: specificare il CIDR della VCN di origine.
- Protocollo IP: TCP
- Intervallo di porte di origine: Tutto
- Intervallo di porte di destinazione: 8005
- Descrizione: specificare una descrizione facoltativa della regola di entrata per facilitare la gestione delle regole di sicurezza.
-
Fare clic su Aggiungi regola di uscita e aggiungere questi dettagli per impostare una regola che consente il traffico SQLNet da qualsiasi posizione:
- Tipo di origine: CIDR
- CIDR di origine: specificare il CIDR della VCN di origine.
- Protocollo IP: TCP
- Intervallo di porte di origine: Tutto
- Intervallo di porte di destinazione: 2484
- Descrizione: specificare una descrizione facoltativa della regola di entrata per facilitare la gestione delle regole di sicurezza.
Nota: assicurarsi che la subnet del servizio di recupero sia presente nell'area di origine e sia collegata alla VCN di origine. Per ulteriori informazioni, vedere Creazione di una subnet del servizio di recupero nella VCN del database.
-
-
-
Eseguire il peering DNS tra le reti VCN locali e remote.
Audit e trace della conservazione dei file per i database mediante backup automatici
Oracle Database scrive i file di audit e trace nello storage locale del database nella directory /u01. Questi file vengono conservati per 30 giorni per impostazione predefinita, anche se è possibile modificare questo intervallo. Una volta al giorno, i file di audit e trace più vecchi di 30 giorni (o l'intervallo specificato dall'utente, se applicabile) vengono eliminati da un job di Oracle Scheduler. È inoltre possibile disabilitare il job Scheduler se si desidera conservare questi file in modo permanente. Utilizzare i comandi dbcli riportati di seguito per apportare modifiche a questo processo Scheduler.
-
Per modificare il periodo di conservazione dall'impostazione predefinita di 30 giorni:
dbcli update-database -in <dbName> -lr <number_of_days_to_retain_files>Ad esempio:
dbcli update-database -in inventorydb -lr 15 -
Per disabilitare il job giornaliero di scheduler per i file di audit e trace meno recenti:
dbcli update-schedule -i <schedulerID> -dAd esempio:
dbcli update-schedule -i 5678 -d
Utilizzare l'API
Per informazioni sull'uso dell'API e sulle richieste di firma, vedere API REST e Credenziali di sicurezza. Per informazioni sugli SDK, vedere Software Development Kit and Command Line Interface (interfaccia a riga di comando e kit di sviluppo software).
Utilizza le seguenti operazioni API per gestire i backup del database:
- ListBackup
- Recupera backup
- Crea backup
- Elimina backup
- Ripristina database
- UpdateDatabase - Per abilitare e disabilitare i backup automatici.
- CreateDbHome: consente di creare un database del sistema DB da un backup standalone.
Per la lista completa delle interfacce API per il servizio di database, vedere API del servizio di database.