Ayuda si posteas la estructura de las 4 tablas, a simple vista parece ser posible crear una única consulta relacionando (join) las tablas 1, 2 y 3 que devuelva toda la información necesaria en un paso, esto evitaría que tengas que consultar T2 por cada registro de T1 en el while, que es uno de los motivos principales de la lentitud. En caso de ser posible, esta consulta será la definición del cursor c1 en el código de ejemplo. Puede que sea algo como:
Código:
select
t1.usuario, t2.transaccion, t3.cliente, t3.saldo
from t1, t2, t3
where
t1.usuario = t2.usuario
and t2.cliente = t3.cliente
Después de tener esta consulta es cuando se analiza el plan de ejecución (informe de como se accede a las tablas) y ver como optimizar los tiempos, donde la solución puede estar en normalización de tablas, uso de índices, paralelismo, etc. El plan de ejecución lo obtienes con el comando EXPLAIN PLAN FOR tu_consulta_sql, ejemplo:
Código:
EXPLAIN PLAN FOR select * from dual;
En cuanto a la propiedad PARALLEL DEGREE N, el valor de N indica la cantidad de procesos en paralelo que se van a iniciar para recorrer los datos + 1, es decir, un degree de 4 implica 4 procesos esclavos para leer porciones de datos más un quinto proceso coordinador encargado de juntar cada porción. Por otro lado, el valor de N no es algo para configurar como parámetro de entrada en un procedimiento, esto se hace con un alter table, además de ser algo estático que se modifica en casos como cambios de hardware.
Tras optimizar la consulta, lo que sigue es evaluar el número de filas simultaneas que subes a memoria en cada fetch del cursor (este número se define con el valor de limit, en el código de ejemplo se suben 100 filas por fetch), aquí no hay receta, incrementa el valor mientras tengas mejoras de rendimiento, y te detienes cuando ya no hace la diferencia, es importante no pasarse con el valor, ya que si pones uno muy alto corres el riesgo de tener problemas de memoria.
Por último, comentas el particionamiento de tablas, esto es almacenar una tabla en diferentes segmentos (partes físicas) donde cada uno contiene información relacionada por algún criterio, por ejemplo una tabla de facturación particionada por año, en caso de una consulta por todas las facturas del año actual, la base de datos puede responder recorriendo una sola partición que es mucho menos trabajo que recorrer todas las filas. Esto se tiene que definir al momento de crear la tabla y no tiene relación con la propiedad degree.
Código:
create table t1
(id number,
fecha date )
partition by range(trunc(fecha, 'YEAR'))
(
partition p1 values less than (2011)
) ;
En tu caso, diría que el particionamiento no ayuda, ya que la única tabla candidata para esto parece ser T2, y por lo que veo, no tiene un criterio para agrupar la información.
Saludos