Nos encontramos en algunos casos que una cambio de Service pack o una actualización grave sobre producción representa una incompatibilidad entre el trabajo de los usuarios y las tareas de desarrollo, sin llegar a exagerar como las instalaciones que hacíamos cuando heramos esclavos de las consultoras y a la “grupy” financiera de turno se le ocurría de debíamos tener el entorno de producción, el de preproducción y el de desarrollo. No es mala idea tener un lugar en el que poder trabajar con libertad tanto para desarrollo como para pruebas funcionales.

Axapta básicamente esta compuesto por un código fuente que se almacena en unos directorios dentro de unos archivos específicos y una base de datos. Todo esto no funciona sin un programa que interprete estos archivos y los enlace con la base de datos.

De esta manera para hacer un entorno de desarrollo a partir de producción solo debemos mantener esta coherencia directorio base de datos.

Ejemplo practico.

Tenemos una instalación tipo, 3.0 spX con una base de datos SQL server X.

Nuestra instalación se encuentra situada en “C:\Navision\Axapta Application\Appl” dentro del directorio tenemos los directorios de las diferentes aplicaciones. Normalmente Standard y producción.

Copiando producción y renombrar el directorio como Test ya tendríamos la mitad de nuestro entorno de desarrollo.

Después solo hay que realizar una copia de seguridad de la base de datos completa y restaurarla con otro nombre.

El último paso seria configurar el cliente o el AOS para que accedan al nuevo entorno y sincronicen los posibles cambios.

Bueno puestos a probarla, pues hay va el resumen de la instalación, lo cierto que esta nueva versión tiene muchas cosas nuevas que iremos descubriendo y probando, así rápido de decir que podremos configurar en nuestros clientes el consumo de memoria en función de la instalación he incluso en que cpu queremos que se ejecute nuestro aos. También hay nuevos conceptos que la parte de desarrollo que consiguen una perfecta integración y nos facilitara la vida a todos los X frikis. 

Diario de una instalación.

Herramientas:

-Windosw 2003 R2

-Oracle express 10 g

Después de hacernos con la copia de dynamics 2009 en el mercado negro por supuesto.

La tostamos por que queda muy chuli eso de ir enseñando el dvd por hay .. jejej…

y le damos cera a la instalación.

Uno empieza a darle a los botones todo loko de contento cuando se encuentra con que no se puede instalar en sql server 2000, el framework 3.5 y un par de cosillas mas, eso me pasa por darle y no leer las especificaciones de instalación.

Suerte que los pakistanies que ha puesto  M$ a trabajar en esta versión se han puesto las pilas y se nota que son de donde son… total q la cosa y a viene lista sin andar por hay buscando parches y otras fiestas…

Tras  pegarnos con la instalación de oracle, configurar el usuario y el active directori que no falte… (estos siempre barriendo pa su casa)

Una de las cosas mas interesantes que trae este pre-released es la posibilidad de consultar un log con todas las maldades que nos ha ido haciendo en el sistema, lo que proporcina una gran ayuda para solventar posibles errores.

Es importante que la instalación al igual que 4.0 nos envia bastante información al visor de sucesos.

Durante una de las pruebas el tablespaces de systema se nos quedo pequeño al configurar mal  la ubicación de tablas lo que nos produjo unos cuantos errores de sincronización, como unos 800, total que por suerte en 2 minutos se pudo averiguar la causa y solventarla.

Esta versión ya podemos decir que es un producto tecnologicamente mas competitivo y mas estable.

Estas son los comandos para crear un tablespaces de pruebas y un usuario valido, a la vez que la autentificación  externa.

SQL> alter system set os_authent_prefix =”OPS$” scope=SPFILE;
SQL> create user “OPS$DOM\ADMINISTRADOR” identified externally;

Usuario creado.

SQL> grant connect to “OPS$DOM\ADMINISTRADOR”;

Concesi¾n terminada correctamente.

SQL>
create tablespace AXDATA datafile ‘C:\oraclexe\oradata\XE\AXDATA.dbf’
size 50M autoextend on;

create tablespace AXINDEX datafile ‘C:\oraclexe\oradata\XE\AXINDEX.dbf’
size 50M autoextend on;

Rápido y conciso no ???

No hay para mas que el jefe me pide cerrar  iva y no llegamos..

JAJJAJAJA

When setting up an Oracle database to work with Axapta it is often (normally) configured as a dedicated database server for the following reasons:

· Until now this has been the default behavior of an Oracle database.

· Early versions of the multithreaded server was known to be unstable and with some annoying bugs.

The backside of configuring the database as a dedicated server is:

· Each new database connection creates a process / thread on the server.

· Each new database connection allocates more memory for PGA purposes than a similar multithreaded connection.

As you increase the number of concurrent users in an Axapta system you will also increase the administrative burden of the Oracle database server, because you will start new processes / threads on the database server for each new Axapta session. At one point this task of switching between processes / threads will be so overwhelming big part of the servers activity that it will “kill performance” on the server.

Large Oracle Axapta installation with several hundred concurrent Axapta session are therefore more or less forced to configure their database as a multi threaded server.

Axapta running in 2-tier mode has in average 3-4 database connection, which is why configuring your Oracle database as multithreaded will ease the database servers tasks of administer the processes / threads and decrease the consumption of memory. Even though Axapta in 2-tier mode is more expensive database connection wise compared to 3-tier mode you will still benefit from using multithreaded server when running Axapta in 3-tier mode.

This document describes in short how to your Oracle database as a multithreaded server.

1. Oracle init.ora parameters

If you want to understand the way a multithreaded server works compared to a dedicated server, then you can read about this in the following 2 Oracle manuals:

· Oracle Concepts

· Oracle Administrator guide

The following Oracle kernel parameters must or can be specified in order to make the Oracle database server run in multithreaded server mode. A detailed description of these parameters can be found in the “Oracle Reference” manual.

Parameters  
mts_dispatchers:   Controls the protocol and number of dispatcher processes started at instance start. In the most simple way you just specify the protocol and the number of dispatcher processes stated at instance start:
·    mts_dispatcher=”(protocol=<protocol>)(dispatchers=<n>)”

<protocol> would typically be TCP and <n> is the number of dispatchers. You can specify multiple MTS_DISPATCHERS in the initialization file, but they must be adjacent to each other.

To specify that you want to start 5 dispatchers for the TCP/IP protocol at instance start you must specify as follows:
·    mts_dispatcher=”(protocol=TCP)(dispatchers=5)”

mts_max_dispatchers:  Specifies the maximum number of dispatcher processes allowed to be running simultaneously. Default: 5 or the number of dispatchers configured, whichever is greater. For most systems, a value of 200 – 250 connections per dispatcher provides good performance.
mts_servers :  Specifies the number of server processes that you want to create when an instance is started up. If system load decreases, this minimum number of servers is maintained. Therefore, you should take care not to set mts_servers too high at system startup.
mts_max_servers:   Specifies the maximum number of shared server processes allowed to be running simultaneously. If artificial deadlocks occur too frequently on your system, you should increase the value.
Default: Derived from mts_servers (either 20 or 2*mts_servers) .
Tests in out benchmark lap shows that in order to avoid artificial deadlocks in a 3-tier environment you should specify mts_max_servers as 1.2 * Number of active Axapta sessions. If you have 500 concurrent Axapta sessions, then you should specify mts_max_servers to be 600.
instance_name :  Name of the instance. Default value is the instance’s SID. NB! Due to a bug in Oracle 8.1.7 you must specify this parameter in order to run multithreaded server.

2. Start of multithreaded database environment

After you has changed the Oracle initialization parameters in your init.ora file, then you must bounce the database (shutdown and start again). This you have to do to let the dispatcher processes be registered by the listener process and thereby start the database as multithreaded. When running a multithreaded database you must always start the listener processes before you start the database. If the database is started before the listener, then the database will start the dispatcher processes, but because the listener don’t know their existence the database will run as a dedicated server.

Check in your alert log for your database that the dispatchers has started. Just after the start banners of the database and non-default system parameters you should find 2 lines looking something like this:

starting up 5 shared server(s) …

starting up 2 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=tcp))’…

To make sure that the listener has registered the dispatcher processes correctly start the listener control utility and list services supported by the listener (bold text indicates the commands you have to execute):

C:\>lsnrctl

LSNRCTL for 32-bit Windows: Version 8.1.7.0.0 – Production on 14-MAY-2001 12:37:27

(c) Copyright 1998 Oracle Corporation. All rights reserved.

Welcome to LSNRCTL, type “help” for information.

LSNRCTL> set password oracle

The command completed successfully

LSNRCTL> services

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=wk0-kma-dev-nt4)(PORT=1

21)))

Services Summary…

AXDB has 3 service handler(s)

DEDICATED SERVER established:0 refused:0

LOCAL SERVER

DISPATCHER established:0 refused:0 current:0 max:1022 state:ready

D001 <machine: WK0-KMA-DEV-NT4, pid: 338>

(ADDRESS=(PROTOCOL=tcp)(HOST=wk0-kma-dev-nt4.intern.dd.dk)(PORT=1196))

DISPATCHER established:0 refused:0 current:0 max:1022 state:ready

D000 <machine: WK0-KMA-DEV-NT4, pid: 337>

(ADDRESS=(PROTOCOL=tcp)(HOST=wk0-kma-dev-nt4.intern.dd.dk)(PORT=1195))

The command completed successfully

In the case above is the listener named “listener” (the default value) and there is no database explicit specified in the listener SID_LIST_<listener> in the listener.ora file.

To check that the connection is established in shared mode you can query services again and check if the established counter for one of the dispatchers has been increased.
The listener.ora file used in the above shown example look like:

# LISTENER.ORA Network Configuration File: D:\ORACLE\NETWORK\ADMIN\listener.ora

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = wk0-kma-dev-nt4)(PORT = 1521))

)

(DESCRIPTION =

(ADDRESS = (PROTOCOL = IPC)(KEY = WK0KMA))

)

)

PASSWORDS_LISTENER= (oracle)

From Axapta point of view you don’t have to change anything to utilize the new setup at the database unless you for some reason wants to connect to the database in dedicated mode. To do so you have make a new entry in your tnsnames.ora file where you (SERVER=DEDICATED) in your CONNECT_DATA section for that entry.

AXDBTCP.WORLD = (DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(Host = dbserver)(Port = 1521))

)

(CONNECT_DATA = (SID = AXDB)(SERVER=DEDICATED))

)

Be aware that for Oracle databases running on a Windows server is TCP/IP the only supported protocol for multithreaded connections.

os_authent_prefix  

Con un prefijo tipo ‘ops$’ nos sevira,  de manera que oracle sepa identificar si el usuario del SO que solicita la conexión esta creado en oracle autorizando el acceso.  Crearemos un usuario  en oracle como este:

-- Windows

CREATE USER "OPS$DOMINIO.COM\DBO" IDENTIFIED EXTERNALLY;

GRANT CONNECT TO "OPS$DOMINIO.COM\DBO";

Crearemos un usuario en nuestro dominio en este caso DBO .Oracle –> OPS$dominio\DBOWin –> DBOY podremos finalizar la instalación.Ni que decir tiene que debemos crear un tablespace de datos otro de indices etc. (Vamos lo típico en estos casos).http://www.oracle-base.com/articles/misc/OsAuthentication.php Para finalizar recomendaros que ORACLE + SUSE Linux  + AX es la mejor combinación para un optimo rendimiento de la instalación y evitar los sustos que nos dará Microsoft con el día a día que ya sabemos todos.  Un saludo.