Estudio de rendimiento en memoria de Oracle 12c en la infraestructura de Dell
Resumen: Nuestro objetivo es ofrecer soluciones que simplifiquen la TI proporcionando soluciones de bases de datos, desarrollo personalizado, centros de datos dinámicos, computación flexible, alta disponibilidad, computación de alto rendimiento y soluciones de virtualización. ...
Síntomas
Se aplica a:
Base de datos de Oracle: 12.1.0.2
Caso de estudio:
La opción en memoria de Oracle 12c se introdujo en el conjunto de parches 12.1.0.2. Esta característica almacena copias de tablas y particiones, y otros objetos de base de datos en formato columnar, que es el almacén de columnas IM. El almacén de columnas IM es un área opcional del SGA y no reemplaza la caché del búfer. En cambio, ambas áreas de memoria pueden almacenar los mismos datos en diferentes formatos.
COLUMNA DE MENSAJERÍA INSTANTÁNEA Beneficios de rendimiento de la tienda:
Si los objetos de la base de datos en el almacén de columnas IM, la base de datos puede realizar exploraciones, combinaciones y agregaciones mucho más rápido que en el disco. Cuando En la memoria dará más rendimiento
- Consultar un número pequeño de columnas a partir de un número elevado de columnas
- Consultas que examinan un gran número de filas y aplican filtros
- Consultas que aplican datos agregados
- Consultas que combinan una tabla pequeña con una tabla grande (tabla de hechos)
Estudio 1:
La opción Oracle 12c In Memory se probó en la infraestructura de Dell.
Sistema operativo: RHEL 6.5
Base de datos: 12.1.0.2
Memoria: 512G
Tamaño de SGA: 450G
En Tamaño de la memoria: 300G
Tamaño de la base de datos: 1 TB
Estoy habilitando la opción inmemory mediante inmemory_size parámetro.
Sql> alter system set inmemory_size=300g scope=spfile;
Solo se aplicará después del reinicio de la instancia.
Podemos encontrar el tamaño de inmemory usando
SQL> show parameter inmemory;
| NOMBRE | TIPO | VALOR |
|---|---|---|
| inmemory_clause_default | string | |
| inmemory_force | cadena | PREDETERMINADO |
| inmemory_max_populate_servers | entero | 30 |
| inmemory_query | string | HABILITAR |
| inmemory_size | Número entero grande | 300G |
| inmemory_trickle_repopulate_servers_percent | entero | 10 |
| optimizer_inmemory_aware | Booleano | VERDADERO |
Tabla 1: Parámetro SQL inmemory
Después de eso, cree un espacio de tablas mediante el atributo In Memory
| Sql> create tablespace quest datafile '+DATA' size 10g default inmemory; |
Podemos cambiar en cualquier momento los parámetros de inmemory mediante la instrucción alter
| Misión de alteración del espacio de tablas de SQL> VALOR PREDETERMINADO INMEMORY MEMCOMPRESS PARA UNA ALTA CAPACIDAD; |
Después de que pueda crear cualquier tabla en este espacio de tablas, se almacenará automáticamente en el almacén de columnas IM.
Con BMF7.0 podemos cargar los datos en un espacio de tablas particular. Si habilitamos el parámetro inmemory en el nivel del espacio de tablas antes de cargarlo, tardará menos tiempo en comparación con sin el atributo inmemory.
Después de cargar los datos, podemos usar las diferentes técnicas de compresión y niveles de prioridad para completar los datos en el almacén de columnas IM. Los objetos se rellenan en el almacén de columnas IM, ya sea en una lista priorizada inmediatamente después de abrir la base de datos o después de examinarlos (consultarlos) por primera vez.
Estos son mis resultados de tiempo de ejecución en comparación con la infraestructura de Dell.
Podemos comprimir y completar los datos en el almacén de columnas de mensajería instantánea mediante diferentes métodos.
La tabla h_partsupp que tiene datos originales de 59,59 GB. Podemos usar diferentes técnicas de compresión para rellenar los objetos de la tabla en el almacén de columnas IM y ver la tasa de compresión.
| Técnicas de compresión | Relación | Datos comprimidos |
|---|---|---|
| Memcompress para la altura de consulta | 1.29 | 31.08 |
| Memcompress para consulta Low | 1,67 | 35.64 |
| Memcompress para una capacidad baja | 3.04 | 19.63 |
| Memcompress para una alta capacidad | 4.88 | 12.21 |
| Sin MemCompress | 1.17 | 50.86 |
Tabla 2: Relación de técnicas
de compresión: Después de eso, podemos generar una consulta en la tabla y ver los resultados del rendimiento de inmemory y sin In Memory.
Seleccione SQL> max (PS_SUPPLYCOST) de h_partsupp;
| Técnica de compresión | Sec |
|---|---|
| Memcompress para consulta alta | 15.97 |
| Memcompress para consulta Low | 18 |
| Memcompress para una capacidad baja | 18.13 |
| Memcompress para una alta capacidad | 99.86 |
| Sin inmemory | 2961 |
Tabla 3: Tiempo de las
técnicas de compresión Según los resultados, en la memoria ofrece más rendimiento (185 veces) en comparación con sin la memoria.
Estudio 2 :
La tabla h_part que tiene 29,27 Gb de datos originales. Podemos usar diferentes técnicas de compresión para rellenar los objetos de la tabla en el almacén de columnas IM y ver la tasa de compresión.
| Técnicas de compresión | Relación | Datos comprimidos |
|---|---|---|
| Memcompress para consulta alta | 3.32 | 8.43 |
| Memcompress para consulta Low | 2.77 | 10.09 |
| Memcompress para una capacidad baja | 5.77 | 4.85 |
| Memcompress para una alta capacidad | 7.96 | 3.51 |
| NO MemCpmpress | 1.24 | 22.49 |
Tabla 4: Relación de técnicas
de compresión Después de eso, podemos generar una consulta en la tabla y ver los resultados del rendimiento de inmemory y sin In Memory.
Sql> seleccione P_NAME de quest.h_part donde P_TYPE='SMALL BRUSHED NICKEL';
| Técnicas de compresión | sec |
|---|---|
| Memcompress para consulta alta | 6.04 |
| Memcompress para consulta Low | 6.26 |
| Memcompress para una capacidad baja | 8.86 |
| Memcompress para una capacidad alta | 19 |
| Sin memoria | 30 |
| SIN MEMCompress | 9.10 |
Causa
Consulte la información anterior
Resolución
Consulte la información anterior