Para aquellos administradores de bases de datos que deban tratar con un tal Dynamics Ax 2009 y sus secuaces (desarrolladores, consultores, etc ) dejo aquí un par de cosillas que se deben saber(o te deben decir) cuando unimos ax2009 y sql server 2008. A veces se puede apuntar a la base de datos como fuente del problema pero no siempre es así.  Algunos requerimientos a tener en cuenta para la instalación de Ax2009 son que el usuario con el que quieran acceder para hacer la instalación debe ser usuario de DOMINIO y en sql server debe ser miembro de rol dbcreator y securityadmin para poder crear la nueva base  de datos desde el instalador de Ax. Una vez instalado (o durante el proceso de instalación) los problema con la base de datos que nos podemos encontrar pueden ser:

Caso 1:
Otro problema conocido en la sincronización de datos puede producirse por la falta de permisos. El mensaje dice algo así:

Por el motivo que sea nos podemos encontrar que en nuestra base de datos Oracle tenemos muchos tablespace y para hacer un poquito de limpieza decidamos resumir los que estén duplicados. Entoces nos dirigimos a OEM y vemos una maravillosa liista de 50 tablespace con nombres sin sentido, algunos vacíos y otros por triplicado por que han llegado al tamaño que consideran máximo (en lugar de tres datafiles) etc etc... Llega el momento de ponerse manos a la obra.

Recordar que para ver el contenido de un tablespace nos podemos dirigir a Oracle Enterprise Manager y en la sección Administración>tablespaces marcar el que queramos, seleccionar en el desplegable Mostrar Dependencias y luego pulsando Ir. Luego veremos una segunda pestaña Dependientes. Ahí se muestran todos los objetos dependientes del tablespace (contenidos, vamos).

En execucions batch que facin un bolcat massiu de dades en una mateixa taula utilitzant un insert o update per registre dins d'un bloc pel motiu x es poden optimitzar amb l'ús de paràmetres (si el client ho permet) o si fem servir odbc amb bind variables.

Recordem els passos que segueix Oracle per processar una consulta:

1) Validació Sintáctica
2) Validació Semàntica
3) Optimització
4) Generació del QEP (Query Execution Pla)
5) Execució del QEP (Query Execution Pla)

In batch runs to make a massive data dump into the same table using an INSERT or UPDATE for register within a block, the process can be optimized with the use of parameters (if client supports it) or if we use ODBC with bind variables.
Recall the steps taken by Oracle to process a query:
1) Sintactic Validation 
2) Semantic Validation
3) Optimization 
4) Generation of the QEP (Query Execution Plan)
5) Implementation of the QEP (Query Execution Plan)
Sentences can pick up the parameters by value (where salary > 1000) or once the sentence is compiled using Bind Variables (where salary>: b1). The advantage of the second option is that Oracle compile the sentence only one-time and reuses the compiled code for each of the values for the parameters.
But we must be aware because in the latter case because Oracle can't calculate the degree of selectivity of a query and, instead, apply a degree of selectivity by default (associated with each type of operation), which can give in wrong decisions.

En Oracle SQL, se pueden optimizar ejecuciones batch que hagan un volcado masivo de datos en una misma tabla usando sentencias de insert o update por registro dentro de un bloque. Se pueden optimizar con el uso de parámetros (si el cliente lo permite) o si usamos odbc con bind variables.

Normalmente para analizar lo que pasa unas horas antes bastaría con consultar los datos históricos del Enterprise Manager pero no tenemos datos como el detalle de sesiones activas (si la cantidad total) o el estado o programa de cada una de ellas. También consultar las instantáneas en la consola web pero el problema sigue siendo el mismo, la falta de detalle. Pero no todo es insalvable y podemos en tres pasos completar esta información con algo más de detalle.

Paso 1: Crear una tabla con los datos que necesitaremos con un campo fecha.

Paso 2: Crear un procedimiento para alimentar la tabla con datos.

Paso 3: Crear un job con el usuario indicado para acumular datos.

Esta técnica puede ser “cutre” pero muchas veces sirve para analizar con más detalle y a nuestro gusto ciertas estadísticas que son visibles mediante vistas v$ que muestran el estado actual de la base de datos y que directamente no muestran un estado anterior en el tiempo.