Bulk Collect

[Sh3r3z4d4]

Hola chicos

Alguien me podria orientar acerca de lo que hace Bulk Collect por lo que he leido al parecer guarda los registros en memoria x lo cual me lleva a preguntarme en cual memoria?? quiza en memoria de la BD? o quiza de mi equipo? no se ademas por lo que entiendo cuando lei se puede utilizar para meter mas de una columna dentro de una variable en un select, por ejemplo

SELECT K200A, K200B, K400A
BULK COLLECT INTO V_variables
FROM TB_ALGORITMO_BAC

al menos sin la instruccion BULK COLLECT esto no seria posible a menos que utilizaras un cursor para recorrer mas de una fila, pero lo que no entiendo es como se mete en una variable mas de una fila??? , la variable V_variables se tendria que declarar como tabla???? no entiendo como se utiliza

Si alguien podria darme un idea de para que se usa comunmente o cual es su funcion especificamente, se los agradeceria enormemente

grax a todos

[huesos52]

La sentencia generada por un bulk Collect se almacena en RAM. De igual forma, pasa a hacer parte de la SGA y queda compartida para todas las instancias que la consultan. Es un mecanismo bastante rapido (en comparación con los cursores). Por otro lado, un cursor abre un espacio de memoria llamado "memoria SQL" y es apartado por cada sesion. Si no se cierran los cursores, esta memoria sql se crea para cada sesion cada vez que se instancia el cursor, perdiendo el control de crecimiento de la memoria.

saludos

[Sh3r3z4d4]

Grax x la respuesta

Aun me queda la duda de si la variable donde caiga el resultado de la consulta Bulk Collect debe ser declarada como tipo tabla y x k?

Si es declarada como tipo tabla quiere decir que te genera una tabla temporal?? (lo pregunto por que todos los ejemplos que vi con Bulk Collect la variable donde se almacenaba el resultado era siempre declarado como tabla) entonces no se si esto es forzoso cuando ocupas esta instrucción

Grax x sus repuesta

[matanga]

Una corrección al comentario de huesos52, los datos del bulk collect se almacenan en la PGA y solo están disponibles para la sesión que los crea.

Sh3r3z4d4, la idea es, dentro de un cursor, el fetch es la acción que recorre y sube los registros a memoria, y se puede definir de dos formas:

1. Un registro por cada fetch, tiene buen rendimiento con pocos registros y el código es más simple.
2. Múltiples registros por cada fetch (bulk collect), el código es un poco más complejo pero tiene mejor rendimiento con muchos registros.

Código:

--una tabla t1
create table t1 (id number(8), datos varchar2(30));

Código:

--ej. bulk collect
--en cada fetch se suben 100 registros a memoria
declare
 cursor c1 is select id, datos from t1;
 type type_t1 is table of c1%rowtype index by pls_integer;
 t type_t1;
begin
 open c1;
 loop
  fetch c1 bulk collect into t limit 100;
  exit when t.count = 0;
  for i in t.first..t.last loop
    --proceso de registros
  end loop;
 end loop;
end;
/

Código:

--ej. tradicional
--en cada fetch se sube un registro
declare
 cursor c1 is select id, datos from t1;
 var_id number(8);
 var_datos varchar2(30);
begin
 open c1;
 loop
  fetch c1 into var_id, var_datos;
  exit when c1%notfound
    --proceso de registros
 end loop;
end;
/

En cualquier caso, no necesitas de tablas temporales, como puedes ver en los dos ejemplos, la estructura de memoria para almacenar los registros del cursor es siempre una variable (type_t1 es un tipo de variable llamada collection).

Saludos

[huesos52]

Una corrección al comentario de huesos52, los datos del bulk collect se almacenan en la PGA y solo están disponibles para la sesión que los crea.

Lo digo por que ya lo viví.
tenía un paquete en PL donde instanciaba un objeto que hacia referencia a una tabla en memoria. Antes de hacer ciertas operaciones, no validaba contra la tabla, sino contra la tabla en momoria que habia cargado anteriormente. (para ganarme unas cuantas consultas)
En nuestra BD de QA, el procedimiento funcionaba de maravillas, pues la transaccionalidad de esta no se compara con producción. Al momento de pasarla a nuestro ambiente productivo, m dí cuenta que era bastante inestable en los resultados que generaba.

El problema estaba en la tabla en memoria, ya que otra sesión diferente iniciaba el paquete, instanciaba la tabla y hacia uso de la información que tenia cargada, mas no la que debia usar.

La solución fue evitar la validación contra la tabla en memoria y hacer uso de una consulta directamente a la BD.

Si el servidor está en modo dedicado, si hay una reserva de PGA por sesión, pero si es compartido, pensaría que las tablas en memoria pueden ser accequibles por diversas sesiones.

saludos

[matanga]

Por cada sesión se crea la estructura de memoria Private SQL Área, que es donde se almacena el valor que toman las variables al ejecutar un procedimiento, package, etc., esta área es siempre privada, es decir que no comparte información entre sesiones, independientemente de existir en la PGA cuando es Dedicated Server o en la SGA cuando es Shared Server.

Lo que comentas es curioso, habría que analizarlo con más detalle, una posible explicación puede ser el comportamiento de las collections cuando se las define dentro de un package, que se inicializan cuando comienza la ejecución pero, a diferencia de otras variables, no se destruyen cuando finaliza la ejecución, lo hacen cuando finaliza la sesión, y esto puede provocar, en el caso de una aplicación accediendo a la base a través de un pool de conexiones, que te encuentres con valores existentes por reutilizar una sesión.

Saludos