Preparación de la Conexión a Bases de Datos Oracle
Conectividad General y Requisitos
Es posible conectar Dataflow Gen2 en Microsoft Fabric a la base de datos de Oracle mediante conectores de Power Query. Para usar el conector de bases de datos de Oracle, es necesario instalar Oracle Client for Microsoft Tools (OCMT) en el ordenador que ejecuta la puerta de enlace de datos local.
Al conectarse a una base de datos de Oracle por primera vez, se debe seleccionar el tipo de credenciales para la conexión en Tipo de autenticación. Se recomienda elegir Básico si se tiene previsto iniciar sesión con un nombre de usuario y una contraseña de Oracle.
Configuración del Servidor y TNS
En el campo Servidor, se debe especificar la ubicación de la base de datos de Oracle a la que se desea conectar. El nombre de servicio de Oracle Net (alias TNS) es una dirección predefinida en el archivo tnsnames.ora.
Por lo tanto, al usar un alias TNS, el archivo tnsnames.ora debe configurarse correctamente y colocarse en el directorio de los archivos de configuración del cliente de Oracle especificados durante la instalación de OCMT.
Finalmente, en Tipo de autenticación, se selecciona el tipo de autenticación en la lista desplegable y se completa la configuración relacionada. Si todas las credenciales son correctas, la conexión se prueba y guarda exitosamente.
Gestión de Sesiones en Bases de Datos Oracle
Ciclo de Vida de las Sesiones
Las sesiones de Power BI, por ejemplo, pueden permanecer activas en la base de datos de Oracle durante aproximadamente 30 minutos después de actualizar un modelo semántico a esa base de datos. Solo después de este período, esas sesiones se vuelven inactivas o eliminadas en la base de datos de Oracle.
Identificación y Desconexión de Usuarios
Como administrador de la geodatabase, puede ser necesario identificar quién está conectado y qué conexiones bloquean recursos. También puede ser necesario eliminar determinadas conexiones si los usuarios no están presentes para desconectarse por sí mismos. Por ejemplo, un editor podría haber dejado ArcGIS Pro abierto durante la edición, bloqueando datos y evitando el acceso a otros o la alteración del esquema.
Además, es posible que se requiera que todos los usuarios se desconecten para aplicar un parche a la base de datos, restaurarla o comprimirla.
Privilegios Necesarios
Para desconectar usuarios de una geodatabase en Oracle, el administrador de la geodatabase debe agregarse al rol DBA o contar con los privilegios ALTER SYSTEM y SELECT_CATALOG_ROLE.
Precauciones al Desconectar Usuarios
Se debe tener especial cuidado al desconectar usuarios. Es crucial evitar desconectar sesiones activas, especialmente si el usuario conectado está en proceso de edición. Se recomienda desconectar solo:
- Sesiones que se dejaron abiertas pero que no se están utilizando (por ejemplo, si alguien olvidó la sesión abierta durante el fin de semana).
- Sesiones huérfanas que están bloqueando un objeto.
- Sesiones implicadas en una situación de bloqueo mutuo.
El primer paso siempre es determinar quién está conectado a la geodatabase. Si es necesario, se pueden eliminar conexiones.
Métodos para Gestionar Conexiones
Desde ArcGIS Pro
Se puede conectar a la geodatabase como usuario administrador (por ejemplo, usuario sde) desde ArcGIS Pro para ver las conexiones desde el cuadro de diálogo Administración de geodatabase y, en caso necesario, eliminarlas. Los pasos son:
- Iniciar ArcGIS Pro.
- Conectarse a la geodatabase como administrador de la misma.
- Hacer clic con el botón derecho en la conexión de base de datos y hacer clic en Administración > Conexiones.
Se mostrará una lista de todas las sesiones que están conectadas actualmente a la geodatabase. La propia sesión del administrador se muestra con texto en cursiva.
Cada conexión se identifica por el inicio de sesión utilizado, un ID interno, el tipo de conexión, el nombre del ordenador de origen y la hora de la conexión.
Idealmente, se debe contactar con los usuarios y pedirles que cierren la sesión.
Mediante Python (ArcPy)
También se pueden ejecutar funciones de ArcPy para automatizar el flujo de trabajo de gestión de conexiones. Esto implica crear un archivo de conexión de base de datos para el usuario administrador de la geodatabase, usarlo para conectarse, obtener una lista de todas las conexiones actuales y eliminar una conexión si es necesario.
Para crear un archivo de conexión de base de datos, se ejecuta la función CreateDatabaseConnection_management en una ventana de Python, guardando el nombre de usuario y la contraseña con el archivo. Un ejemplo es la creación de un archivo de conexión (oragdb.sde) en una carpeta temporal.
Un ejemplo de salida al listar usuarios podría ser similar a [ID=41, IsDirecConnection=True, Name=u'sde'].
Si no es posible contactar con los usuarios y es imperativo desconectarlos, se usa la información obtenida con la función ListUsers para identificar la conexión que se eliminará con la función DisconnectUser. Se debe especificar el ID de la conexión a eliminar.
Preparación de Conexiones para Migración con SQL Server Migration Assistant (SSMA)
Para migrar bases de datos de Oracle a SQL Server, es fundamental conectarse a la base de datos de Oracle que se desea migrar. Al conectarse, SQL Server Migration Assistant (SSMA) obtiene metadatos sobre todos los esquemas de Oracle y los muestra en el panel Explorador de metadatos de Oracle.
Gestión de la Conexión y Metadatos
La conexión a la base de datos permanece activa hasta que se cierra el proyecto de SSMA. Los metadatos sobre la base de datos de Oracle no se actualizan automáticamente; para hacerlo, se deben actualizar manualmente. Esto permite que SSMA cargue todos los objetos del esquema propiedad del usuario que se conecta.
En muchos escenarios, existen referencias entre esquemas entre procedimientos almacenados, y SSMA debe poder detectar todos los objetos a los que se hace referencia para una conversión correcta. Al conectarse a una base de datos, SSMA lee los metadatos y los agrega al archivo del proyecto, utilizándolos para convertir objetos a sintaxis de SQL Server y migrar datos.
Permisos y Configuración del Proveedor
Algunas características de SSMA requieren permisos adicionales, constituyendo un conjunto genérico de permisos necesarios para su correcto funcionamiento. Aunque es posible restringir el ámbito de la migración a un subconjunto de esquemas, puede ser difícil identificar correctamente todas las dependencias, lo que podría impedir que SSMA funcione correctamente.
En el cuadro Proveedor, se selecciona Proveedor de cliente de Oracle o Proveedor OLE DB, según el proveedor instalado. Se puede usar el modo estándar para especificar el nombre y el puerto del servidor, o el modo de nombre de servicio para especificar manualmente el nombre del servicio de Oracle. Un ejemplo de cadena de conexión OLE DB es:
Provider=OraOLEDB.Oracle;Data Source=MyOracleDB;User ID=myUser;Password=myPassword;
Al volver a abrir el proyecto de SSMA, es necesario reconectarse si se desea una conexión activa a la base de datos. Los metadatos del Explorador de metadatos de Oracle son una instantánea del momento de la primera conexión o de la última actualización manual. Para actualizar, se hace clic con el botón derecho en Esquemas (en el objeto de base de datos o en el esquema individual) y se selecciona Actualizar desde la base de datos.
Monitorización de Sesiones y Servicios en Oracle
Para comprender y gestionar mejor las conexiones, es esencial saber cómo visualizar las sesiones locales y los servicios de la base de datos.
Consulta de Procesos a Nivel de Sistema Operativo
Para consultar los procesos PGA de Oracle a nivel de sistema operativo, se pueden ejecutar comandos como usuario estándar del sistema operativo. Por ejemplo, en una terminal:
ps -ef | grep LOCAL
Este comando mostrará todos los procesos que contengan el texto "LOCAL". Los procesos de Oracle comienzan con su nombre, seguido del nombre de la base de datos (ej., "orlc1"). Cada proceso pertenece a una conexión local, para la cual Oracle creó un proceso servidor. El protocolo utilizado en estas conexiones locales es BEQ.
Si se establecen múltiples conexiones locales (por ejemplo, una con USR1 y otra con Sys en sqlplus), al repetir la consulta, aparecerán ambas conexiones, confirmando el uso del protocolo BEQ para cada una. Los datos también pueden mostrar la hora de creación de cada proceso, ayudando a diferenciarlos.
Consulta de Sesiones a Nivel de Base de Datos (v$session)
Para consultar las sesiones o conexiones a nivel de base de datos, se utiliza la vista v$session. Conectado a sqlplus como usuario Sys, se puede ejecutar:
select username, command, program from v$session;
Este comando muestra los usuarios, comandos y programas utilizados para acceder a la base de datos. El resultado puede mostrar un número considerable de registros (ej., 49 sesiones activas), ya que Oracle trata todos los procesos conectados a la base de datos como sesiones, incluyendo los procesos internos del sistema.
También se muestran usuarios con procesos asociados, aunque algunos procesos no tienen usuarios porque son procesos de background. En el resultado, se pueden identificar las conexiones de usuarios específicos como sys en sqlplus y USR1.
Consulta de Servicios de Base de Datos
Para consultar los servicios de la base de datos, se utiliza la vista v$system_parameter. La consulta:
select name, value from v$system_parameter where name='service_names';
Esta consulta revelará el nombre del servicio de la base de datos (ej., 'orlc1'). Para verificar, se puede consultar el nombre de la base de datos:
select name, value from v$system_parameter where name='db_name';
El resultado (ej., 'orcl1') suele coincidir con el nombre del servicio, especialmente si no se ha configurado un dominio de base de datos. La consulta para el dominio es:
select name, value from v$system_parameter where name='db_domain';
Si el dominio está vacío, el nombre del servicio generalmente coincide con el nombre de la base de datos.
Resolución de Problemas: Sesiones Inactivas en Aplicaciones PHP4
Un problema común reportado es la saturación de una base de datos Oracle con conexiones INACTIVAS desde una aplicación hecha en PHP4. Esto a menudo requiere un proceso manual para cerrarlas.
A pesar de modificar el código para eliminar las conexiones permanentes y usar funciones como ORA_CLOSE y ORA_LOGOFF, el problema de las conexiones inactivas puede persistir.
En situaciones donde la migración de la aplicación a PHP5 no es una opción inmediata debido a que está en producción, es crucial encontrar una solución para la gestión de sesiones en el entorno actual de PHP4. La resolución de este problema es un paso previo para poder planificar y ejecutar una futura migración.