In-Memory Column Store - Cuando Solo - In-Memory - No Es Suficiente

3/5/2019 "In-Memory Column Store": Cuando solo "In-Memory" no es suficiente
Cuenta País Llamar

Menú
Oracle Technology Network / Artículos / Rendimiento y Disponibilidad de Base de datos
Framework para el Desarrollo "In-Memory Column Store": Cuando solo "In-Memory" no es suficiente
de Aplicaciones Por Flávio Soares (OCE), Joel Pérez & Sebastián D'Alessandro (OCE)
Application Express Publicado en Mayo 2016
Business Intelligence Esta es una serie de artículos dedicados a la nueva funcionalidad “Oracle In-Memory Column Store”, presente en la versión de base de datos Oracle
12c. Oracle lleva muchos años permitiendo la lectura de bloques directamente desde memoria RAM por medio de la utilización del buffer cache
Cloud Computing (v$bh). A lo largo de todos estos años realizó un gran trabajo perfeccionando continuamente el algoritmo LRU que utiliza, con el fin de optimizar las
Communications búsquedas de bloques calientes y poder mantenerlos el mayor tiempo posible en memoria, logrando de esta manera un acceso más rápido y
actuando como un verdadero “cache” para la base de datos.
Rendimiento y Disponibilidad
de Base de datos Con la incorporación de In Memory DB (IMDB), tanto la arquitectura como el rendimiento cambian diametralmente en comparación con el modo de
Data Warehousing lectura tradicional desde el buffer cache en la SGA, esto radica principalmente en la manera que Oracle almacena los datos en memoria. Tal como
su nombre lo indica, Oracle In-Memory Column Store, permite almacenar los datos en memoria de forma columnar, de manera totalmente
.NET optimizada para la lectura vía SDRAM y trabajando así como un verdadero DBMS orientado a columna: Column-oriented DBMS.
Lenguajes de Programación
Dinámicos No es necesario aclarar que el acceso a memoria RAM es más rápido que el acceso a disco (todo el mundo sabe esto), por lo tanto tampoco es
necesario comentar o demostrar las mejoras en materia de rendimiento que acarrea la utilización de IMDB.
Embedded
Surge entonces la pregunta: IMDB llegó para resolver todos los problemas relativos a la performance de un ambiente?
Arquitectura Enterprise
Enterprise Management
Lo que intentaremos mostrar en esta serie de artículos, es justamente la respuesta a esta pregunta. Utilizaremos para ello, casos representativos
con ejemplos y pruebas de la utilización de esta nueva característica que como cualquier otra, presenta ventajas, desventajas y mejores prácticas
Grid Computing en su utilización.
Identidad y Seguridad Es increíble la cantidad de DBAs y empresas que creen en la magia de un “alter table” donde todos los problemas de performance serán resueltos.
Java Pero esto no es así, IMDB de ninguna manera es sinónimo de “desconectar el cerebro del DBA”.
Linux De aquí en adelante, vamos a mostrar y ejemplificar un comportamiento bastante inusual en algunos ambientes con Oracle InMemory.
Service-Oriented Architecture Para esto, a través del utilitario Swingbench crearemos la tabla SOE.ORDER_ITEMS de 12G que será nuestra tabla de pruebas para la utilización
SQL & PL/SQL de IMDB.
Virtualización A continuación detalles de la tabla:
sys@ora01 SQL> @sizesoe.order_items
OWNER SEGMENT_NAME SEGMENT_TYPE SIZE_MB

------------------------- ------------------------------ ------------------ -------------
SOE ORDER_ITEMS TABLE 12,398.0
-------------
sum 12,398.0
1 rowselected.
sys@ora01 SQL>--Actualizando las estadísticas de la tabla:

sys@ora01 SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SOE', 'ORDER_ITEMS', method_opt =>
'FOR TABLE FOR ALL COLUMNS SIZE AUTO', cascade => true);
PL/SQL proceduresuccessfullycompleted.
sys@ora01 SQL> @tbstatsoe.order_items
=============================================
=== O B J E C T T A B L E ===
=============================================
OWNER: SOE TABLE: ORDER_ITEMS
Name Null? Type

------------------------------- -------- ------------------
1 ORDER_ID NOT NULL NUMBER(12)
2 LINE_ITEM_ID NOT NULL NUMBER(3)
3 PRODUCT_ID NOT NULL NUMBER(6)
4 UNIT_PRICE NUMBER(8,2)
5 QUANTITY NUMBER(8)
6 DISPATCH_DATE DATE
7 RETURN_DATE DATE
8 GIFT_WRAP VARCHAR2(20)
9 CONDITION VARCHAR2(20)
10 SUPPLIER_ID NUMBER(6)
11 ESTIMATED_DELIVERY DATE
================================================================================
Table Statistics
================================================================================
TABLE_NAME : ORDER_ITEMS
STATUS : VALID
LAST_ANALYZED : 29/03/2016 22:08:46
PARTITIONED : NO
TEMPORARY : N
DEGREE : 1
BUFFER_POOL : DEFAULT
CACHE : NO
CELL_FLASH_CACHE : DEFAULT Chat
COMPRESSION : DISABLED
RESULT_CACHE : DEFAULT
ROW_MOVEMENT : DISABLED
LOGGING : YES
SAMPLE_SIZE : 85789721
===============================================================================================================================
Column Statistics
===============================================================================================================================
ID# NAME ANALYZED NDV DENSITY # NULLS # BUCKETS SAMPLE HISTOGRAM
===============================================================================================================================
1 ORDER_ID 29-03-16 22:08 28434432 0.00000004 0 1 85789721 NONE
2 LINE_ITEM_ID 29-03-16 22:08 5 0.20000000 0 1 85789721 NONE
3 PRODUCT_ID 29-03-16 22:08 999 0.00100100 0 1 85789721 NONE
4 UNIT_PRICE 29-03-16 22:08 2000 0.00050000 0 1 85789721 NONE
5 QUANTITY 29-03-16 22:08 10 0.10000000 0 1 85789721 NONE
6 DISPATCH_DATE 29-03-16 22:08 124 0.00806452 0 1 85789721 NONE
7 RETURN_DATE 29-03-16 22:08 4507 0.00022188 84059125 1 1730596 NONE
8 GIFT_WRAP 29-03-16 22:08 6 0.16666667 0 1 85789721 NONE
9 CONDITION 29-03-16 22:08 3 0.33333333 0 1 85789721 NONE
10 SUPPLIER_ID 29-03-16 22:08 999 0.00100100 0 1 85789721 NONE
https://www.oracle.com/technetwork/es/articles/database-performance/in-memory-column-store-3030245-esa.html 1/5
11 ESTIMATED_DELIVERY 29-03-16 22:08 4507 0.00022188 0 1 85789721 NONE
===============================================================================================================================
IndexInformation
================================================================================================================================
INDEX_NAME COLUMNS ANALYZED DIST_KEYS DENSITY NUM_ROWS UNIQUE VISIBLE ST
================================================================================================================================
ITEM_ORDER_IX ORDER_ID 29-03-16 22:08 28434432 0.0000000 82834901 NO YES
ITEM_PRODUCT_IX PRODUCT_ID 29-03-16 22:08 999 0.0010010 79984685 NO NO
ORDER_ITEMS_PK LINE_ITEM_ID ,ORDER_ID 29-03-16 22:08 85615194 0.0000000 85615194 YES YES
sys@ora01 SQL>
Podemos ver que la tabla SOE.ORDER_ITEMS está con la opción “In Memory” deshabilitada:
sys@ora01 SQL>selectowner, table_name, inmemoryfromdba_tableswhereowner='SOE' and table_name='ORDER_ITEMS';
OWNER TABLE_NAME INMEMORY

----------------------- ---------------------------- --------
SOE ORDER_ITEMS DISABLED
1 rowselected.
Vamos a ejecutar una consulta sobre la tabla y luego analizar los resultados. Estamos forzando que la consulta sea ejecutada en “serie” y
obteniendo el máximo de estadísticas para el análisis, eso lo logramos utilizando los hints NO_PARALLEL y GATHER_PLAN_STATISTICS
respectivamente.
sys@ora01 SQL> SET TIMING ON

sys@ora01 SQL> SELECT /*+ monitor gather_plan_statisticsno_parallel */ SUM(quantity) FROM soe.order_items WHERE product_id=:p;
SUM(QUANTITY)
-------------
1376607
Elapsed: 00:00:43.51
1 rowselected.
sys@ora01 SQL>-– Buscando el sqlid del query anterior

sys@ora01 SQL> @lastsql
HASH_VALUE SQL_ID CH# PLAN_HASH HASH_HEX SQL_TEXT

---------- ------------- ----- ------------ -------- ------------------------------------------------------------------
3284254310 97h2yq31w3gm6 0 2407813087 c3c1be66 SELECT /*+ MONITOR GATHER_PLAN_STATISTICS
NO_PARALLEL */ sum(QUANTITY) fromsoe.order_itemswhere PRODUCT_ID=:p
Vamos a analizar ahora la consulta con sql_id: 97h2yq31w3gm6.
sys@ora01 SQL> SET HEADING OFF LINES 32767

sys@ora01 SQL> SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(sql_id => '97h2yq31w3gm6', report_level=>'ALL', type =>
'TEXT') as report FROM dual;
SQL MonitoringReport
SQL Text
------------------------------
SELECT /*+ monitor gather_plan_statisticsno_parallel */ SUM(quantity) FROM soe.order_items WHERE product_id=:p
Global Information
------------------------------
Status : DONE (ALL ROWS)
SQL ID : 97h2yq31w3gm6
SQL Execution ID : 16777216
Duration : 44s
Module/Action : SQL*Plus/-
FetchCalls : 1
Binds
=====================================
| Name | Position | Type | Value |
=====================================
| :P | 1 | NUMBER | 509 |
=====================================
Global Stats
================================================================
| Elapsed | Cpu | IO | Fetch | Buffer | Read | Read |
| Time(s) | Time(s) | Waits(s)| Calls | Gets | Reqs | Bytes |
================================================================
| 44 | 4.92 | 39 | 1 | 251K | 250K | 2GB |
================================================================
SQL Plan MonitoringDetails (Plan Hash Value=2407813087)

================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Re
| | | | (Estim) | | Active(s)| Active| | (Actual)| Reqs | By
================================================================================================================================
| 0 | SELECT STATEMENT | | | | 39 | +2 | 1 | 1 | |
| 1 | SORT AGGREGATE | | 1 | | 39 | +2 | 1 | 1 | Chat
|
| 2 | TABLE ACCESS BY INDEX ROWID BATCHED | ORDER_ITEMS | 85876 | 697 | 40 | +1 | 1 | 306K | 249K |
| 3 | INDEX RANGE SCAN | ITEM_PRODUCT_IX | 85876 | 2 | 39 | +2 | 1 | 306K | 643 |
================================================================================================================================
1 rowselected.
sys@ora01 SQL> SET HEADING ON
Tenemos aquí el plan de ejecución de nuestra consulta sobre la tabla ORDER_ITEMS. Puede verse que demoró 44s en ser procesada, donde 39s
fueron gastados en I/O y 5s en utilización de CPU. La lectura total a disco fue de alrededor de 2G.
A partir de ahora, iniciaremos nuestra prueba con Oracle In-Memory 12c. El objetivo aquí es colocar nuestra tabla ORDER_ITEMS en modo In-
Memory Column Store y realizar nuevamente la misma consulta, para así poder obtener algunas conclusiones. El primer paso, como dijimos, es
cargar la columna en memoria:
sys@ora01 SQL> ALTER TABLE soe.order_items INMEMORY;
Table altered.
sys@ora01 SQL> ALTER SESSION SET "_inmemory_populate_wait"=TRUE;
Sessionaltered.
sys@ora01 SQL> EXEC DBMS_INMEMORY.POPULATE('SOE','ORDER_ITEMS');
PL/SQL proceduresuccessfullycompleted.
sys@ora01 SQL> COLUMN seg_inmem_size FORMAT 99,999,990.9 HEADING 'In-Memory|SIZE_MB'

sys@ora01 SQL> COLUMN seg_orig_size_megs FORMAT 99,999,990.9 HEADING 'ORIGINAL|SIZE_MB'
sys@ora01 SQL> COLUMN seg_megs_not_populated FORMAT 99,999,990.9 HEADING 'NOT POPULATE|SIZE_MB'
sys@ora01 SQL> COLUMN populate_status HEADING 'POPULATE|STATUS'
sys@ora01 SQL> SELECT
2 inst_id
3 , v.owner
4 , v.segment_name
5 , v.populate_status
6 , v.inmemory_size/1024/1024 seg_inmem_size
7 , v.bytes/(1024*1024) seg_orig_size_megs
8 , v.bytes_not_populated/(1024*1024) seg_megs_not_populated
9 , v.inmemory_priority
10 , v.inmemory_compression
11 FROM v$im_segments v
12 WHERE UPPER(segment_name) LIKE UPPER(CASE WHEN INSTR('&1','.') > 0 THEN substr('&1',instr('&1','.')+1) ELSE '&1' END)
13 AND UPPER(owner) LIKE UPPER(CASE WHEN INSTR('&1','.') > 0 THEN SUBSTR('&1',1,instr('&1','.')-1) ELSE user END)
14 /
POPULATE In-Memory ORIGINAL NOT POPULATE In-Memory In-Memory

OWNER SEGMENT_NAME STATUS SIZE_MB SIZE_MBSIZE_MB PRIORITY COMPRESSION
-------------------- -------------------------- --------- ------------- ------------- ------------- --------- -------------
SOE ORDER_ITEMS COMPLETED 3,554.1 12,398.0 0.0 NONE FOR QUERY LOW
1 rowselected.
Podemos ver en la vista v$im_segments que nuestra tabla está totalmente cargada (“populada”) en el área de memoria de In Memory, con un
tamaño aproximado de 3500M.
Con la tabla ya en memoria, vamos a ejecutar la misma consulta y verificar los resultados. Antes, vamos a hacer un “flush” del buffer cache/shared
pool para que las acciones de la prueba anterior no sean tenidas en consideración.
sys@ora01 SQL> ALTER SYSTEM FLUSH SHARED_POOL;
Systemaltered.
sys@ora01 SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;
Systemaltered.
sys@ora01 SQL> SELECT /*+ monitor gather_plan_statisticsno_parallel */ SUM(quantity) FROM soe.order_items WHERE product_id=:p;
SUM(QUANTITY)
-------------
1376607
Elapsed: 00:00:43.03
1 rowselected.
sys@ora01 SQL> @lastsql
HASH_VALUE SQL_ID CH# PLAN_HASH HASH_HEX SQL_TEXT

---------- ------------- ----- ------------ -------- ---------------------------------------------------------
3284254310 97h2yq31w3gm6 0 2407813087 c3c1be66 SELECT /*+ monitor gather_plan_statisticsno_parallel */
SUM(quantity) FROM soe.order_items WHERE product_id=:p

SQL Text
---------------------------------------
SELECT /*+ monitor gather_plan_statisticsno_parallel */ SUM(quantity) FROM soe.order_items WHERE product_id=:p
Global Information
---------------------------------------
Duration : 44s
FetchCalls : 1
Binds
=====================================
=====================================
| :P | 1 | NUMBER | 509 |
===================================== Chat
Global Stats
=================================================================
| Elapsed | Cpu | IO | Fetch | Buffer | Read | Read |
| Time(s) | Time(s) | Waits(s) | Calls | Gets | Reqs | Bytes |
=================================================================
| 44 | 4.92 | 39 | 1 | 251K | 250K | 2GB |
=================================================================

================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | R
| | | | (Estim)| | Active(s)| Active | | (Actual) | Reqs | B
================================================================================================================================
| 0 | SELECT STATEMENT | | | | 39 | +2 | 1 | 1 | |
| 1 | SORT AGGREGATE | | 1 | | 39 | +2 | 1 | 1 | |
| 3 | INDEX RANGE SCAN | ITEM_PRODUCT_IX | 85876 | 2 | 39 | +2 | 1 | 306K | 643 |
================================================================================================================================
1 rowselected.
sys@ora01 SQL> SET HEADING ON
Como podemos ver, nada ha cambiado en relación a la primera ejecución. Resulta interesante la siguiente apreciación, con la tabla cargada
totalmente en memoria (vía IMDB) la cantidad de lecturas físicas de la segunda ejecución resultó similar a la primera. El tiempo total insumido
tampoco ha cambiado, fue de aprox. 44s para retornar los datos.
Ahora bien, si la tabla ORDER_ITEMS está ahora totalmente disponible en memoria vía “InMemory Column Store”, ¿porque Oracle termina
haciendo la misma cantidad de lecturas a disco?. No debería buscar los datos en memoria y evitar esa gran cantidad de lecturas fisicas?
Como regla general (de igual manera ocurre en SmartScan de Exadata) para que el optimizador decida utilizar InMemory debe existir un acceso
“FULL SCAN” sobre la tabla. Observando el plan de ejecución de la consulta, vemos que en este caso el camino escogido por Oracle es utilizar
INDEX ITEM_PRODUCT_IX (vía INDEX RANGE SCAN).
================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | R
| | | | (Estim) | | Active(s)| Active | | (Actual)| Reqs | B
================================================================================================================================
| 3 | INDEX RANGE SCAN | ITEM_PRODUCT_IX | 85876 | 2 | 39 | +2 | 1 | 306K | 643
El Whitepaper de Oracle Database In-Memory 12c es muy claro en cuanto a esta cuestión, aclara que una recuperación de datos será realizada
utilizando In-memory solo cuando el acceso a la tabla sea vía FULL SCAN. De esta manera, nuestra consulta jamás accederá a los bloques
presentes en la
RAM ya que el optimizador esta escogiendo un camino a través de un índice ITEM_PRODUCT_IX.
Podemos resolver esta situación agregando un hint FULL a la consulta o dejando el índice ITEM_PRODUCT invisible. Veamos el resultado:
sys@ora01 SQL> alter indexsoe.ITEM_PRODUCT_IX invisible;
Indexaltered.
sys@ora01 SQL> SELECT /*+ MONITOR GATHER_PLAN_STATISTICS NO_PARALLEL */ sum(QUANTITY)

from soe.order_itemswhere PRODUCT_ID=:p;
SUM(QUANTITY)
-------------
1376607
Elapsed: 00:00:00.05
1 rowselected.

SQL Text
------------------------------
SELECT /*+ MONITOR GATHER_PLAN_STATISTICS NO_PARALLEL */ sum(QUANTITY) fromsoe.order_itemswhere PRODUCT_ID=:p
Global Information
----------------------------------------
Instance ID : 1
Session : SYS (1150:44245)
Duration : .041563s
Service : SYS$USERS
Program : sqlplus@Flavios-MacBook-Pro.local (TNS V1-V3)
FetchCalls : 1
Binds
=====================================
=====================================
| :P | 1 | NUMBER | 509 |
=====================================
Global Stats
============================================================================
| Elapsed | Cpu | IO | Other | Fetch | Buffer | Read | Read |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls | Gets | Reqs | Bytes |
============================================================================
| 0.04 | 0.04 | 0.00 | 0.00 | 1 | 249 | 18 | 144KB |
============================================================================

================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Activ
| | | | (Estim) | | Active(s)| Active | | (Actual)| Reqs | Bytes | (%)
================================================================================================================================
| 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 1 | | |Chat
| 1 | SORT AGGREGATE | | 1 | | 1 | +0 | 1 | 1 | | |
| 2 | TABLE ACCESS INMEMORY FULL | ORDER_ITEMS | 85876 | 7880 | 1 | +0 | 1 | 306K | 12 | 98304 |
================================================================================================================================
1 rowselected.
sys@ora01 SQL>
Ahora si podemos percibir el verdadero poder de INMEMORY. Observe el tiempo de ejecución, bajo de 44s a solo 0.4s. Vemos también que la
operación de acceso no es más por indice(INDEX RANGE SCAN) y ahora si esvía TABLE ACCESSINMEMORY FULL, lo que muestra que la
recuperación de los datos para la tabla ORDER_ITEMS fue realizada exclusivamente desde memoria. Otro punto importante es la cantidad de
lecturas físicas que de 2G cayó a 144kb. El tiempo utilizado de 0.4s fue exclusivamente tiempo de CPU en procesar los datos (CPU Time(s)).
Llegamos hasta aquí con algunas conclusiones:
Vamos a mejorar el rendimiento colocando todas nuestras tablas en IMDB? No existe otro camino que probar. Cada ambiente es único y existen
múltiples variables en el medio del camino. Como en las pruebas que realizamos, aun activando IMDB, no notamos mejora alguna hasta que
analizamos y corregimos.
Por qué Oracle decide un acceso utilizando un índice (vía INDEX), siendo que mis datos están en memoria? Bueno, eso será explicado en
profundidad en próximos artículos, pero básicamente Oracle considera que el costo del uso de un índice es menor, por eso termina optando por la
utilización de INDEX. Existen algunos parámetros de la base de datos que influyen también sobre esta decisión pero vamos a tratar eso en
profundidad luego.
Si IMDB solo funciona en presencia de un acceso vía FULL SCAN, debo dejar todos mis índices invisibles?NUNCA!!! Eso es un mito que surgió con
Exadata, el índice no es un enemigo!. Un acceso vía índice puede ser muchas veces más beneficioso , ya que el objetivo del índice es justamente
economizar lecturas sobre el disco. TI es un mundo lógico y debe ser siempre abordado, con una aproximación sistemática (sysematic aproach). No
existe magia. En futuros artículos vamos a profundizar mejor sobre este tema.
Vamos a necesitar modificar nuestras aplicaciones para utilizar IMDB? Como deja bien claro la documentación de Oracle, no es necesario tocar ni
una coma en la aplicación para utilizar IMDB. Ahora nos hacemos otra pregunta: Vamos a tener rendimiento en todas las tablas que fueron subidas
a INMEMORY? De nuevo .. Depende, es necesario probar para obtener la respuesta.
IMDB mejora realmente el rendimiento? Sí, es extremadamente beneficioso en performance comparado con todo lo disponible en el mercado. Como
dijimos en el comienzo del artículo, no es necesario explicar la enorme diferencia de velocidad entre el acceso a memoria RAM en contraposición
con el acceso a disco. Todos ya lo sabemos. Pero si, es necesario por otro lado, entender cómo aprovechar los beneficios de esta caracteristica de
la mejor forma. Como pudimos ver con un simple ejemplo, una consulta de prueba cayó de 44s a 0,4s y lo más importante sin modificar ni una coma
en la consulta.
Mi aplicación OLTP está repleta de índices, voy a tener alguna ganancia con IMDB? Probablemente. Pero de nuevo: es necesario “probar”. Siempre
se debe evaluar estadísticas, índices, hints, etc.
En próximos artículos trataremos muchas más cosas interesantes sobre esta nueva funcionalidad de Oracle.
Hasta la próxima.
Flavio Soares es un senior DBA Oracle, solucionador de problemas y Consultor Oracle Certificado como OCP/OCE RAC. Especialista en Exadata,
alta disponibilidad y replicación de datos con diversas soluciones Oracle. Flavio ofrece información frecuente para la comunidad de Oracle a través
de sus artículos a través de OTN Portugués.
Joel Pérez es un experto DBA (Oracle ACE Director, OCM Cloud Admin. & OCM11g) con más de 15 años de experiencia real en el mundo de
tecnología Oracle, especializado en diseño e implementación de soluciones de: Cloud, Alta disponibilidad, Recuperación contra desastres,
Upgrades, Replicación y toda área relacionada con bases de datos Oracle. Consultor Internacional con trabajos, conferencias y actividades
relacionadas en más de 50 países alrededor del mundo. Habitual Orador en eventos Oracle alrededor del mundo como: OTN LAD, OTN MENA,
OTN APAC y más. Joel se ha caracterizado siempre por ser un pionero en materia de tecnología Oracle desde los inicios de su carrera siendo el
primer latinoamericano en ser nombrado "OTN Expert" en el año 2003, uno de los primeros Oracle ACE en el programa ACE en el año 2004, unos
de los primeros OCP Cloud en el mercado global en el año 2013 y como uno de los mayores logros de su carrera, recientemente en el 2014 fue
honorificado como uno de los primeros "OCM Database Cloud Administrator" del mundo. En la actualidad Joel Pérez esta radicado en el continente
de Asia con base en Beijing, China llevando a cabo operaciones profesionales como "ChiefTechnologist& MAA, HA Arquitect" para YunheEnmo
(Beijing) Technology Co. Ltd.  Perfil OCM Joel Pérez: http://education.oracle.com/education/otn/JoelPerez.htmp>
Sebastián D'Alessandro es un Senior DBA con más de 12 años de experiencia en tecnología Oracle, focalizado principalmente en seguridad de
base de datos, soluciones de alta disponibilidad, disaster recovery y virtualización. Actualmente desarrolla su actividad como consultor e instructor
de manera independiente.
Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los
productos Oracle.
E-mail this page Printer View
Contáctenos Cloud Acciones principales Temas clave

Ventas en EE. UU.: Descripción general de Cloud Descargue Java ERP, EPM (Finanzas)
+1.800.633.0738 Solutions Descargue Java para HCM (RR. HH. y talento)
Reciba una llamada de Oracle Software (SaaS) desarrolladores
Mercadeo
Contactos globales Plataforma (PaaS) Pruebe Oracle Cloud CX (Ventas, servicio, comercio)
Directorio de soporte Infraestructura (IaaS) Suscríbase a los correos
Soluciones sectoriales
electrónicos
Datos (DaaS) Base de datos
Acerca de Oracle Prueba gratuita de la nube
Noticias MySQL
Información de la empresa Middleware
Comunidades Eventos Sala de prensa
Java
Revistas
Carreras Oracle Code Sistemas de ingeniería
JavaOne Historias de éxito de los clientes
Blogs
Todos los eventos de Oracle
© Oracle Mapa del sitio Términos de uso y privacidad Preferencias para cookies Opciones de publicidad
Chat

In-Memory Column Store - Cuando Solo - In-Memory - No Es Suficiente

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

In-Memory Column Store - Cuando Solo - In-Memory - No Es Suficiente

Cargado por

Copyright:

Formatos disponibles

3/5/2019 "In-Memory Column Store": Cuando solo "In-Memory" no es suficiente

Cuenta País Llamar

Oracle Technology Network / Artículos / Rendimiento y Disponibilidad de Base de datos

Virtualización A continuación detalles de la tabla:

sys@ora01 SQL> @sizesoe.order_items

OWNER SEGMENT_NAME SEGMENT_TYPE SIZE_MB

sys@ora01 SQL>--Actualizando las estadísticas de la tabla:

sys@ora01 SQL> @tbstatsoe.order_items

OWNER: SOE TABLE: ORDER_ITEMS

Name Null? Type

sys@ora01 SQL>selectowner, table_name, inmemoryfromdba_tableswhereowner='SOE' and table_name='ORDER_ITEMS';

OWNER TABLE_NAME INMEMORY

sys@ora01 SQL> SET TIMING ON

sys@ora01 SQL>-– Buscando el sqlid del query anterior

HASH_VALUE SQL_ID CH# PLAN_HASH HASH_HEX SQL_TEXT

Vamos a analizar ahora la consulta con sql_id: 97h2yq31w3gm6.

sys@ora01 SQL> SET HEADING OFF LINES 32767

SQL Plan MonitoringDetails (Plan Hash Value=2407813087)

sys@ora01 SQL> SET HEADING ON

sys@ora01 SQL> ALTER TABLE soe.order_items INMEMORY;

sys@ora01 SQL> EXEC DBMS_INMEMORY.POPULATE('SOE','ORDER_ITEMS');

sys@ora01 SQL> COLUMN seg_inmem_size FORMAT 99,999,990.9 HEADING 'In-Memory|SIZE_MB'

POPULATE In-Memory ORIGINAL NOT POPULATE In-Memory In-Memory

sys@ora01 SQL> ALTER SYSTEM FLUSH SHARED_POOL;

sys@ora01 SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

sys@ora01 SQL> @lastsql

HASH_VALUE SQL_ID CH# PLAN_HASH HASH_HEX SQL_TEXT

sys@ora01 SQL> SET HEADING OFF LINES 32767

SQL Plan MonitoringDetails (Plan Hash Value=2407813087)

sys@ora01 SQL> SET HEADING ON

RAM ya que el optimizador esta escogiendo un camino a través de un índice ITEM_PRODUCT_IX.

sys@ora01 SQL> alter indexsoe.ITEM_PRODUCT_IX invisible;

sys@ora01 SQL> SELECT /*+ MONITOR GATHER_PLAN_STATISTICS NO_PARALLEL */ sum(QUANTITY)

sys@ora01 SQL> SET HEADING OFF LINES 32767

SQL Plan MonitoringDetails (Plan Hash Value=3419397814)

Llegamos hasta aquí con algunas conclusiones:

E-mail this page Printer View

Contáctenos Cloud Acciones principales Temas clave

También podría gustarte

sys@ora01 SQL> SELECT /+ MONITOR GATHER_PLAN_STATISTICS NO_PARALLEL / sum(QUANTITY)