Utilizzare le tabelle cloud per memorizzare le informazioni di log e diagnostica
È possibile creare tabelle cloud in cui i dati delle tabelle risiedono nello storage cloud gestito da Oracle e i dati delle tabelle non consumano lo storage del database.
- Informazioni sulle tabelle cloud
È possibile creare tabelle cloud come alternativa complementare alle tabelle nel database. - Crea tabelle cloud
Mostra i passi per creare una tabella cloud in Autonomous Database. - Note tabella cloud
Fornisce note per l'utilizzo delle tabelle cloud.
Argomento padre: Sviluppa
Informazioni sulle tabelle cloud
È possibile creare tabelle cloud come alternativa complementare alle tabelle nel database.
Tutti i dati delle tabelle cloud vengono memorizzati nello storage degli oggetti gestito da Oracle. Lo storage degli oggetti gestito da Oracle è uno storage esterno, al di fuori del database, che Autonomous Database crea e gestisce.
È possibile utilizzare le tabelle cloud per memorizzare i dati di log dell'applicazione, le informazioni di diagnostica o per memorizzare altri dati non utilizzati di frequente. In alcune applicazioni esistenti che non vengono eseguite su Autonomous Database, è possibile memorizzare questo tipo di informazioni in file su un file system locale (ad esempio utilizzando le API UTL_FILE
). Tali meccanismi di registrazione e i file associati possono essere molto utili quando è necessario diagnosticare e risolvere gli errori dell'applicazione. Tuttavia, la memorizzazione delle informazioni nelle tabelle di database può utilizzare grandi quantità di storage del database per i dati che non vengono utilizzati di frequente. Utilizzando le tabelle cloud, i dati persistenti vengono salvati nello storage degli oggetti gestito da Oracle senza utilizzare lo storage del database.
Il parametro
CLOUD_TABLE_COMMIT_THRESHOLD
si applica a tutte le tabelle cloud e può essere impostato da qualsiasi utente con il privilegio ALTER SESSION
. Pertanto, le tabelle cloud non sono adatte ai dati critici per la sicurezza in cui le modifiche impegnate devono essere durature e devono essere immediatamente visibili ai lettori concorrenti. Per questo motivo, le tabelle cloud potrebbero non essere appropriate per casi d'uso quali le tabelle di log di audit.
Restrizioni SELECT e DML per le tabelle cloud
Le tabelle cloud funzionano come le normali tabelle di database con alcune restrizioni. È possibile utilizzare le istruzioni SELECT e DML, di manipolazione dei dati, con le seguenti eccezioni:
- istruzioni
MERGE
non supportate. - Le colonne
LOB
sono limitate a 10 MB di dati. - Il controllo della concorrenza DML è diverso e quindi:
LOCK TABLE
potrebbe non impedire il DML concorrente come per una tabella di database.INSERT
non acquisisce un blocco sulla tabella, pertanto INSERT non viene mai bloccato da operazioni DML concorrenti.- Le operazioni
UPDATE
eDELETE
acquisiscono entrambi un blocco esclusivo su una tabella cloud. Pertanto, le transazioniUPDATE
oDELETE
bloccano le operazioniUPDATE
oDELETE
concorrenti in una tabella cloud.
- Vengono applicati solo vincoli NOT NULL.
- Il DML è consentito in un Autonomous Database in lettura-scrittura così come lo è per qualsiasi altra tabella; le tabelle cloud consentono anche le operazioni DML in una copia aggiornabile.
Le tabelle cloud non supportano quanto segue:
- Indici
- Colonne invisibili
- Colonne virtuali
- Trigger DML
- Più di 996 colonne
- Colonne di tipo dati booleano
Operazioni di gestione del ciclo di vita e tabelle cloud
I dati delle tabelle cloud vengono memorizzati nello storage degli oggetti gestito da Oracle. Ciò significa che determinate operazioni su Autonomous Database gestiscono le tabelle cloud in modo diverso rispetto alle tabelle nel database, come indicato di seguito.
-
I dati delle tabelle cloud sono esclusi dal backup e dal recupero di un'istanza di Autonomous Database (non viene eseguito il backup dei dati e non è possibile ripristinare i dati delle tabelle cloud).
-
I dati delle tabelle cloud sono protetti tramite lo storage degli oggetti gestito da Oracle.
-
Le operazioni di gestione del ciclo di vita che influiscono sullo stato di un'istanza di Autonomous Database non hanno alcun impatto sui dati memorizzati nelle tabelle cloud.
La denominazione delle tabelle cloud nello storage degli oggetti viene definita in modo univoco per ogni istanza di Autonomous Database, in base al relativo OCID. Ciò significa che qualsiasi operazione che modifica o introduce un nuovo OCID per un database esistente ha un impatto sulle tabelle cloud. Di seguito viene descritto l'impatto delle operazioni del ciclo di vita sui dati delle tabelle cloud.
Operazione ciclo di vita | Disponibilità dati tabella cloud |
---|---|
Copia dello stesso database dell'area | Tabella cloud duplicata senza dati della tabella cloud |
Duplicazione del database tra più aree | Tabella cloud duplicata senza dati della tabella cloud |
Standby Autonomous Data Guard della stessa area (locale) | I dati delle tabelle cloud e delle tabelle cloud sono accessibili |
Standby Autonomous Data Guard tra più aree | La tabella cloud è disponibile in standby, senza i dati della tabella cloud |
peer di disaster recovery basato su backup della stessa area (locale) | I dati delle tabelle cloud e delle tabelle cloud sono accessibili |
peer di disaster recovery basato su backup tra più aree | La tabella cloud è disponibile in standby, senza dati della tabella cloud |
Operazioni di gestione del ciclo di vita che influiscono sull'SCN/indicatore orario di un'istanza di Autonomous Database, tra cui:
|
La tabella cloud continuerà ad essere aggiornata e lo stato precedente dei dati della tabella cloud non verrà conservato o ripristinato. Ciò significa che sono disponibili solo i dati della tabella cloud corrente. |
Operazioni di Lifecycle Management, tra cui:
|
Nessun impatto sulle tabelle cloud o sui dati delle tabelle cloud |
Buffer con tabelle cloud
Per impostazione predefinita, le modifiche DML alle tabelle cloud vengono esportate nello storage degli oggetti quando viene eseguito il commit del DML. Tuttavia, questo potrebbe non funzionare bene quando i DML sono strutturati come piccole transazioni con commit frequente. Per migliorare le prestazioni in questo scenario, impostare il parametro CLOUD_TABLE_COMMIT_THRESHOLD
per abilitare il buffering delle modifiche DML delle tabelle cloud all'interno di una sessione.
Quando il parametro CLOUD_TABLE_COMMIT_THRESHOLD
è impostato su un valore diverso da zero, il sistema considera il valore come una soglia di conteggio delle modifiche e le modifiche apportate alla tabella cloud vengono inserite nel buffer finché il numero di modifiche non raggiunge la soglia specificata. Quando viene raggiunta la soglia, le modifiche inserite nel buffer vengono esportate nello storage degli oggetti. Le modifiche nel buffer vengono esportate anche quando la sessione termina normalmente, anche se non è stato raggiunto il valore CLOUD_TABLE_COMMIT_THRESHOLD
. Prima di esportare le modifiche inserite nel buffer, le sessioni concorrenti non visualizzano le modifiche. In rari casi che comportano una scadenza imprevista del processo, è possibile che le modifiche inserite nel buffer non vengano mai esportate e che le modifiche non siano durature (ossia, le modifiche inserite nel buffer non vengono esportate nell'area di memorizzazione degli oggetti).
Per ulteriori informazioni, vedere CLOUD_TABLE_COMMIT_THRESHOLD.
Crea tabelle cloud
Mostra i passi per creare una tabella cloud in Autonomous Database.
Per creare una tabella cloud:
Utilizzare DROP TABLE
quando si desidera eliminare una tabella cloud.
Ad esempio:
DROP TABLE CLOUD_TABLE_TEST;
Le tabelle cloud non supportano il cestino.
Per ulteriori informazioni, vedere Note della tabella cloud.
Note tabella cloud
Fornisce note per l'utilizzo delle tabelle cloud.
Di seguito sono riportate le note per l'utilizzo delle tabelle cloud.
-
È possibile concedere privilegi
SELECT
,INSERT
eUPDATE
per una tabella cloud. Non è possibile concedere altri privilegi a una tabella cloud.Per ulteriori informazioni, vedere Configurazione dell'autorizzazione di privilegi e ruoli.
-
I vincoli della tabella cloud sono limitati ai vincoli in modalità
RELY DISABLE NOVALIDATE
, il che significa che il vincolo non viene applicato. L'unica eccezione è per i vincoliNOT NULL
.Le tabelle cloud supportano tutte le modalità di vincolo
NOT NULL
, inclusa la modalità predefinita (ENABLE VALIDATE
). Sono supportati i vincoliPRIMARY KEY
,UNIQUE
,FOREIGN KEY
eNOT NULL
; i vincoliCHECK
non sono supportati.È possibile dichiarare i vincoli in linea come parte di
COLUMN_LIST
.Ad esempio:
BEGIN
DBMS_CLOUD.CREATE_CLOUD_TABLE
( table_name => 'CLOUD_TAB_WITH_CONSTRAINTS', column_list => 'PK INTEGER, DATE_ID INT REFERENCES DATE_DIM(DATE_ID) RELY DISABLE NOVALIDATE, VAL NUMBER NOT NULL, CONSTRAINT CLOUD_TAB_PK PRIMARY KEY(PK) RELY DISABLE NOVALIDATE'); END; /Per ulteriori limitazioni relative alle tabelle cloud, vedere Note della tabella cloud.
-
Il pacchetto
DBMS_CLOUD
è un pacchetto con diritti di richiamo. La proceduraDBMS_CLOUD.CREATE_CLOUD_TABLE
consente solo di creare una tabella nello schema del chiamante.Per ulteriori informazioni, vedere Clausola Diritti dell'Invoker e Definier's Rights.
-
Il parametro
column_list
in una chiamata di proceduraDBMS_CLOUD.CREATE_CLOUD_TABLE
può includere la clausolaDEFAULT
, che funziona come la clausolaDEFAULT
inCREATE TABLE
. Per ulteriori informazioni, vedere CREATE TABLE.Ad esempio:
BEGIN
DBMS_CLOUD.CREATE_CLOUD_TABLE
( table_name => 'CLOUD_TABLE_TEST_DEFAULT', column_list => 'I INTEGER, STR2 VARCHAR2(32) DEFAULT ''ABC'''); END; /È quindi possibile inserire i valori predefiniti. Ad esempio:
INSERT INTO cloud_table_test_default (i) VALUES (1); 1 row created. INSERT INTO cloud_table_test_default VALUES (2, default); 1 row created. INSERT INTO cloud_table_test_default VALUES (3, null); 1 row created. INSERT INTO cloud_table_test_default VALUES (4, 'xyz'); 1 row created. COMMIT; Commit complete. SELECT * FROM cloud_table_test_default ORDER BY i; I STR2 - ---- 1 ABC 2 ABC 3 null 4 xyz
-
È possibile utilizzare il parametro di inizializzazione
CLOUD_TABLE_COMMIT_THRESHOLD
per abilitare il buffering per le tabelle cloud. Per ulteriori informazioni, vedere CLOUD_TABLE_COMMIT_THRESHOLD.