sql >> Database >  >> RDS >> Oracle

InMemory DUPLICATE Verwarring in Oracle RAC

De meeste mensen kennen waarschijnlijk de nieuwe Oracle 12.1.0.2-functie, de InMemory-databaseoptie. Wanneer deze optie op Oracle RAC wordt gebruikt, kan de DBA de DUPLICATE-clausule specificeren om een ​​object in alle gevallen in het InMemory-kolomarchief te laten dupliceren. Deze clausule is voor Oracle Engineered Systems zoals Exadata. In niet-engineered systemen lijkt Oracle deze clausule echter toe te staan, maar het werkt niet zoals je zou verwachten. Om dit te illustreren, volgt u dit voorbeeld, dat werd uitgevoerd op een RAC-database met twee knooppunten op mijn MacBook Pro met VirtualBox... absoluut geen Engineered-systeem.

Eerst wordt een tabel gemaakt en vervolgens gewijzigd voor INMEMORY DUPLICATE.

SQL> maak tabel db_objs 2 als select * Van dba_objects;
Tabel gemaakt.
SQL> verander tabel db_objs inmemory duplicaat;
Tabel gewijzigd.

Zou het instellen van deze clausule geen foutmelding moeten geven, aangezien dit een niet-geconstrueerd systeem is?

De tabel is geverifieerd om aan te tonen dat DUPLICATE is opgegeven.

SQL> selecteer inmemory,inmemory_duplicate 2 van user_tables waar table_name='DB_OBJS';
INMEMORY INMEMORY_DUPL-------- -------------INGESCHAKELD DUPLICEREN

Een eenvoudige "select *" vorm van de tabel wordt uitgegeven op instantie 1. We kunnen dan verifiëren dat de tabel InMemory is.

SQL> selecteer inst_id,owner,segment_name,populate_status,inmemory_duplicate 2 van gv$im_segments;
INST_ID OWNER SEGMENT_NA POPULATE_ INMEMORY_DUPL---------- ---------- ---------- --------- --- ---------- 1 SCOTT DB_OBJS VOLTOOID DUPLICAAT

Merk op dat de resultaten hierboven laten zien dat het segment alleen in instantie 1 is. Dezelfde tabel wordt opgevraagd in instantie 2, maar een query op GV$IM_SEGMENTS toont nog steeds alleen instantie 1.

Van voorbeeld 1:

SQL> selecteer avg(object_id) van db_objs;
AVG(OBJECT_ID)-------------- 11095.2049
Verstreken:00:00:00.01
Uitvoeringsplan--------------------------------------------- -------------Plan hash-waarde:1349857420
----------------------------------------------- ----------------------------------------
| ID | Operatie | Naam | Rijen | Byte | Kosten (%CPU)| Tijd |
----------------------------------------------- ----------------------------------------
| 0 | KIES VERKLARING | | 1 | 5 | 10 (0)| 00:00:01 |
| 1 | AGGREGAAT SORTEREN | | 1 | 5 | | |
| 2 | TABELTOEGANGSINGEHEUGEN VOL | DB_OBJS | 21319 | 104K| 10 (0)| 00:00:01 |
----------------------------------------------- ----------------------------------------

Van voorbeeld 2:

 
SQL> selecteer avg(object_id) van db_objs;
AVG(OBJECT_ID)-------------- 11095.2049
Verstreken:00:00:00.03
Uitvoeringsplan--------------------------------------------- -------------Plan hash-waarde:1349857420
----------------------------------------------- ----------------------------------------
| ID | Operatie | Naam | Rijen | Byte | Kosten (%CPU)| Tijd |
----------------------------------------------- ----------------------------------------
| 0 | KIES VERKLARING | | 1 | 5 | 4 (0)| 00:00:01 |
| 1 | AGGREGAAT SORTEREN | | 1 | 5 | | |
| 2 | TABELTOEGANGSINGEHEUGEN VOL | DB_OBJS | 21319 | 104K| 4 (0)| 00:00:01 |
----------------------------------------------- ----------------------------------------

Dus vanuit beide instanties werd de tabel INMEMORY geopend. Maar we kunnen zien dat alleen instantie 1 het segment InMemory heeft.

Alle tekens wijzen erop dat de DUPLICATE-clausule werkt aan een niet-engineered systeem, waarvan we weten dat het een fout is. DBA_TABLES lijkt erop te wijzen dat DUPLICATE hier in het spel is. Het Explain Plan zorgt voor instemming. Maar GV$IM_SEGMENTS is het daar niet mee eens en laat zien dat DUPLICATE niet werkt in dit systeem.


  1. Nieuw in PostgreSQL 12:gegenereerde kolommen

  2. Vergelijk datums die zijn opgeslagen als string met behulp van Datetime

  3. SQL, querybuilders en ORM's vergelijken

  4. milliseconden verwijderen uit een orakel tmstmp-veld