Parece que esta es una de las áreas en las que la funcionalidad PL/SQL ha evolucionado a lo largo de los lanzamientos cuando Oracle ha implementado diferentes optimizaciones.
Tenga en cuenta que esto también significa que algunas de las respuestas enumeradas en el OP también son específicas de la versión, incluso si no se mencionan explícitamente en esas preguntas/respuestas. Cuando pase el tiempo y finalice el uso de versiones anteriores de Oracle (¿soñando despierto?), esa información quedará obsoleta (podría llevar décadas).
La conclusión anterior está respaldada por la siguiente cita del capítulo 12 Ajuste de las aplicaciones PL/SQL para el rendimiento de Referencia del lenguaje PL/SQL 11g R1 :
Este problema ya no se menciona en 11g R2 ni 12c R1 versión del documento. Esto está en línea con la evolución del capítulo 3 Tipos de datos PL/SQL.
Respuesta:
Dado que 11gR2 no hace ninguna diferencia con el uso de memoria de punto de vista para usar varchar2(10) o varchar2(32767) . ¡El compilador Oracle PL/SQL se encargará de los detalles sucios de manera óptima!
Para las versiones anteriores a 11gR2, existe un punto límite en el que se utilizan diferentes estrategias de administración de memoria y esto está claramente documentado en la Referencia del lenguaje PL/SQL de cada versión. .
Lo anterior solo se aplica a las variables solo de PL/SQL cuando no hay una restricción de longitud natural que pueda derivarse del dominio del problema. Si una variable varchar2 representa un GTIN-14
entonces uno debería declarar eso como varchar2(14) .
Cuando las interfaces de variables PL/SQL con una columna de tabla usan %type -atributo ya que es la forma sin esfuerzo de mantener sincronizados el código PL/SQL y la estructura de la base de datos.
Resultados de la prueba de memoria:
Ejecuto un análisis de memoria en Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 con los siguientes resultados:
str_size iterations UGA PGA
-------- ---------- ----- ------
10 100 65488 0
10 1000 65488 65536
10 10000 65488 655360
32767 100 65488 0
32767 1000 65488 65536
32767 10000 65488 655360
Porque los cambios de PGA son idénticos y dependen solo de iterations y no str_size Concluyo que el tamaño declarado de varchar2 no importa. Sin embargo, la prueba puede ser demasiado ingenua:¡los comentarios son bienvenidos!
El guión de prueba:
-- plsql_memory is a convenience package wrapping sys.v_$mystat s and
-- sys.v_$statname tables written by Steven Feuerstein and available in the
-- code-zip file accompanying his book.
set verify off
define str_size=&1
define iterations=&2
declare
type str_list_t is table of varchar2(&str_size);
begin
plsql_memory.start_analysis;
declare
v_strs str_list_t := str_list_t();
begin
for i in 1 .. &iterations
loop
v_strs.extend;
v_strs(i) := rpad(to_char(i), 10, to_char(i));
end loop;
plsql_memory.show_memory_usage;
end;
end;
/
exit
Ejemplo de ejecución de prueba:
$ sqlplus -SL <CONNECT_STR> @memory-test.sql 32767 10000
Change in UGA memory: 65488 (Current = 1927304)
Change in PGA memory: 655360 (Current = 3572704)
PL/SQL procedure successfully completed.
$
