Su consejo es correcto, sería mejor realizar todas las tareas de la base de datos a la vez. Hay 2 impactos principales en el rendimiento de su escenario
- El cambio de contexto de pro*c entre el motor SQL y el motor PL/SQL para ejecutar sus subprocesos varias veces. Por lo general, el mayor problema en muchas llamadas PL/SQL desde una aplicación cliente.
- La sobrecarga de la pila de red (TNS) en las comunicaciones entre su aplicación pro*c y el motor de la base de datos, especialmente si su aplicación está en un host físico diferente.
Habiendo dicho eso, está creando un grupo de conexiones en el extremo de la aplicación, el agente de escucha TNS también debe tener un grupo de procesos de sombra del servidor heredados esperando cada conexión de red (esto se configura en listener.ora).
El inicio/cierre de sesión de OCI cuando el proceso de sombra ya está esperando la conexión es muy rápido y no es un factor importante en la latencia. No me preocupo por esto a menos que se deba iniciar un nuevo proceso de sombra en el servidor. llamada muy cara. Como está utilizando la agrupación de conexiones en el lado del cliente, esto generalmente no es un problema, sino algo a considerar debido a los subprocesos en sus llamadas. Una vez que agote el grupo de procesos de sombra del servidor, notará una gran degradación si el agente de escucha TNS tiene que iniciar más procesos de sombra del servidor.
Editar en respuesta a las nuevas preguntas:
-
Está muy relacionado. Como se señaló anteriormente, debe minimizar la cantidad de llamadas plsql y sql dentro de su aplicación C++. Cada llamada PLSQL dentro de su aplicación C++ invoca el motor SQL que luego invoca el motor PLSQL para la llamada al procedimiento. Entonces, si divide su procedimiento en 2, está duplicando los cambios de contexto de SQL a PLSQL, que es el cambio más costoso como se describe en el artículo de Tom Kyte y mi propia experiencia personal.
-
Se responde en 1. Pero como dije anteriormente, la sobrecarga de comunicaciones es la segunda a menos que sus hosts estén en diferentes redes físicas y los tipos de datos que está transfiriendo. Por ejemplo, los parámetros de objetos de C++ grandes y los conjuntos de resultados de Oracle grandes con muchas llamadas obviamente afectarán la latencia de las comunicaciones con viajes de ida y vuelta. Recuerde que con más llamadas PLSQL también está agregando más tráfico SQLNET para la configuración de cada conexión y conjunto de resultados.
-
no hay 3. pregunta
-
PLSQL a SQL dentro del motor PLSQL es insignificante, así que no se obsesione con eso. Coloque todas sus llamadas SQL dentro de 1 llamada PLSQL para obtener el máximo rendimiento. No divida las llamadas solo para ser más elocuente con el alto rendimiento.
