Documentación interna de Codigo: Imprescindible.

Buenas,

hacia tiempo que no actualizaba mi blog pero ya era hora!!

En el dia dia de la dura programación y despues de saber que el titulo que te ha costado 5 años conseguir tiene el mismo valor que un cuadro del Ikea, solo que firmado por el Rey, te encuentras con esto en un codigo que estás modificando:

/* Modificacion 20-Agosto-2004. Compruebo fecha de carga del nombre del

fichero contra el rango de fechas de vigencia de TABLA_1.

En caso de salirse del intervalo, hago como si el fichero no hubiera existido jamas.

Nota del programata: Este programa es una mierda, por mussshos parches que pongamos,

la estructura no vale pa ná, pdta: este programa me tiene frito,

mañana seguram tenga que cambiar alguna otra cosa...

Bueno, ahora es junio 2005, un año despues llega la nueva version, a ver que pasa...

jeje, soy yo otra vez, pero en abril del 2006, veo que el codigo sigue igual de retorcido.

Este comentario no tiene fin alguno, pero no veas lo que relaja. */

Con estas cosas normal que Zapatero nos quite el titulo, bueno... y lo bien que no lo pasamos!!!

Java Struts: Capa Vista - Creacción de un ActionForms

nPasos para la creación de un ActionForms:

• nLa clase ActionForms es Abstracta -> Creación de una subclase para obtener los datos del formulario.

• nDentro de la subclase se debe definir un atributo por cada campo que se desea capturar del formulario HTML.

• nAl enviar el formulario se crea una instancia de LoginForm y se completa a partir de los parámetro de petición. El marco Strut lo realiza haciendo coincidr cada nombre de parámetro de petición con el nombre de atributo de la subclase ActionForm:

package com.tutorial.struts.forms;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.*;
/**
* Bean de formulario para que el usuario se valide.
**/
public class LoginForm extends ActionForm
{
private String password = null;
private String email = null;
public void setEmail(String email)
{
this.email = email;
}

public String getEmail()
{
return (this.email);
}

public String getPassword()
{
return (this.password);
}

public void setPassword(String password)
{
this.password = password;
}

Java: Modelo Vista Controlador en Struts ( MVC )

Una aplicación basada en Struts, tiene un componente básico llamado ActionServlet. Este es un servlet, que tramita las peticiones de los clientes delegando a un componente definido por el usuario por cada petición.

Este Servlet es el punto central del framework, aunque no es necesario que todas la actividad fluya a través de él. En una aplicación basada en Struts se pueden hacer peticiones a una JSP que contengan o no “tag libraries” de Struts, sin pasar por el Servlet ActionServlet.

El ActionServlet (controlador) de Struts captura y encamina las peticiones HTTP que llegan a la aplicación (toma la decisión de a dónde enviar la petición HTTP), a otros componentes de aplicación. Estos componentes pueden ser páginas JSP o instancias de una subclase de la clase org.apache.struts.action.Action que el propio framework suministra.

Cuando se inicia el Servlet ActionServlet, carga y analiza la información de un fichero que contiene la configuración de la aplicación para aplicar las características de Struts. Entre otras cosas, el fichero de configuración define las correspondencias que existen entre las peticiones HTTP que captura el Servlet controlador y las acciones que van a tratar esa petición.

Estas correspondencias son manipuladas como instancias de la clase org.apache.struts.action.ActionMapping

Backup en Oracle.

El comando para invocar la utilidad para exportación de datos se debe lanzar desde la línea de comandos del sistema operativo. El comando es exp.
La sentencia es:

exp / buffer= 1048576 full= yes file= export.dmp log= export.log

Se exportará toda la información de un determinado usuario sobre un archivo de sistema
operativo (export.dmp), el cual se creará en el directorio desde el cual se esté lanzando el
comando. Para ello, se utiliza un buffer de 1 Mb.
Todas las secuencias se almacenan en un archivo histórico con el fin de visualizar al final
la operación, si todo ha terminado correctamente (export.log).
Uno de los métodos más cómodos para lanzar la operación de exportación es el comando
siguiente:

exp / parafile= parametro.txt

En el archivo parámetro.txt sería donde introduciríamos los parámetros de exportación. Con
este método, se podría realizar varios estándares de exportación de datos, creando varios
archivos de parámetros según el caso.

Parámetros de Exportación
Estos parámetros se pueden incluir en la misma línea de comandos del ejecutable de expor-
tación o dentro de un archivo de parámetros determinado (PARFILE):

• BUFFER: Especifica, en bytes, el tamaño del buffer asignado para los accesos a los registros de un objeto.
  

• COMPRESS: Este parámetro está indicado para el tratamiento de las cláusulas de almacenamiento de los objetos. Con el valor de COMPRESS= YES, la exportación calculará el espacio ocupado por cada uno de los objetos accedidos para que, con una importación posterior, todo este espacio ocupado por la información del objeto se agrupe en una única extensión.
  

• CONSISTENT: Tiene la función de mantener la consistencia en la exportación de datos, en el caso de que éstos puedan ser modificados mientras la exportación se está llevando a cabo. Debe tener el valor CONSISTENT= YES.
  

• CONSTRAINTS: Sirve para indicar el proceso que también exporte las constraints de las tablas.
  

• DIRECT: Este parámetro indica el modo en el que se va a realizar la exportación de datos, convencional o directa.
  

• FEEDBACK: Este parámetro sirve, básicamente, para realizar un seguimiento del número de filas que se van exportando.
  

• FILE: Sirve para especificar el nombre del archivo binario donde la utilidad va a ir almacenando los datos exportados. La extensión por defecto es DMP, aunque se podría especificar otra extensión.
  

• FULL: cuando está en yes, sirve para exportar toda la información de una base de datos.
  

• GRANTS: Cuando está en yes, se exportará los permisos de los objetos en relación.

8. Procesamiento Paralelo en Oracle (III). Cómo se usa:

En las sentencias CREATE/ALTER, puede indicarse el grado de paralelismo de sentencias DML con la cláusula PARALLEL (DEGREE d, INSTANCES i), siendo d e i números enteros positivos:

• DEGREE:el número de CPUs

• INSTANCES: nodos de base de datos distribuida

• El número ideal de procesos esclavos paralelos que trabajan sobre una sentencia viene determinado por los siguientes factores:

• Los valores DEGREE e INSTANCES, especificados en la cláusula PARALLEL o en el hint

• El número de CPUs de la máquina y de instancias

• El número de particiones a ser accedidas

• El mínimo valor del parámetro FREELISTS (listas de transacciones libres) en la cláusula STORAGE de entre todos los índices globales a ser actualizados.

El número real de procesos está limitado por la disponibilidad de las instancias, y el mínimo se calcula a partir del parámetro PARALLEL_MIN_PERCENT. Las consultas se paralelizan cuando hay un hint en la sentencia SELECT o se ha especificado la cláusula PARALLEL para la tabla.

Cuando se acceden a varias tablas, se elige de todas ellas el hint o valores PARALLEL que definan un mayor grado de paralelismo, como referencia para el grado total de paralelismo de la consulta. El uso del paralelismo es fácil. Sin embargo, existen ciertas restricciones en su uso.

El soporte de las restricciones es limitado: si alguna se viola, la sentencia se ejecuta en serial (no da error).

7. Procesamiento Paralelo en Oracle (II). Operaciones que soportan Paralelismo

Existe un alto grado de afinidad entre el paralelismo y el particionamiento en Oracle, pues se usa el mapeo partición-dispositivo. Este es un nuevo beneficio de las tablas particionadas.

Consulta paralela: soporta paralelismo dentro de una partición, pero se puede usar también en tablas no particionadas.

Nuevas opciones, paralelizadas por partición (no hay paralelismo dentro de cada partición):

1. INSERT... SELECT... con carga directa sobre tablas particionadas.
2. DELETE sobre tablas particionadas.
3. UPDATE sobre tablas particionadas.
4. INSERT... SELECT... con carga directa sobre tablas no particionadas.

Las operaciones paralelas siempre tienen un proceso maestro que coordina los procesos esclavos. El tipo de operación determina cuándo y cómo se paraleliza la operación. Existen tres métodos de paralelización:

• Por rangos de rowid (sólo consultas paralelas): Se aplica a consultas de tablas particionadasy no particionadas. Proporciona paralelismo dentro de una partición: variosprocesos esclavos pueden estar accediendo a una partición
  

• Por procesos esclavos (INSERT en tablas no particionadas): Se aplica sólo enROWID, las filas se distribuyen entre los procesos paralelos que insertan en sendos segmentos temporales. Posteriormente, se asigna a cada fila de los segmentos temporales un rowid, y se mueven a la tabla destino tras la HWM. Ejemplo:
  INSERT...SELECT... sobre tablas no particionadas. Como las nuevas filas no tienen

INSERT /*+PARALLEL(TABLA1,3)*/ INTO TABLA2 SELECT * FROM TABLA1;

• Por partición (sólo tablas particionadas): No hay paralelismo dentro de una partición para operaciones DML. Un proceso esclavo puede ser asignado a más de una partición para compartir recursos. Ejemplo, suponiendo que la tabla “pedido” está particionada:
  

UPDATE /*+PARALLEL(PEDIDO,3)*/ PEDIDO SET PENDIENTE = ʼFʼ;

Por defecto, el paralelismo está desactivado, pudiéndose hacer sólo consultas paralelas.

• La sentencia ALTER SESSION ENABLE PARALLEL DML, que permite la ejecución paralela de DML ha de ser la primera de la transacción.

• Cada operación PDML ha de terminar con COMMIT o ROLLBACK (si no, error). En una transacción, tras una DML en serie (salvo SELECT), se ignoran los hints o cláusulas paralelas, y se continúa en serial.

• El nuevo atributo de V$SESSION, PMDL_ENABLED, permite consultar si una sesión tiene habilitada el PDML. V$PQ_SESSTAT da información de las sentencias PDML.

6. Procesamiento paralelo en Oracle.(I)

Las operaciones DML paralelas aceleran el acceso a grandes tablas, cuando se modifican al menos un 1% de las filas.
Son útiles en entornos DSS o Datawarehouse, y en ciertas operaciones OLTP (OnLine Transaction Processing).
Muchas operaciones paralelas requieren tablas e índices particionados, excepto INSERT... SELECT...
La principal ventaja es el rendimiento: el paralelismo puede acelerar la velocidad de proceso de transacciones DML.

Por ejemplo, si en una tabla particionada en 3 particiones se ejecuta una sentencia del tipo

UPDATE PEDIDO SET PENDIENTE = 'F';

La modificación se aplica a todas las filas que cumplen dicha condición, las cuales hay que buscar en toda la tabla (suponiendo que no existe un índice por el atributo "pendiente").

Para mejorar el rendimiento, es posible usar directivas de paralelismo en la misma sentencia SQL:

UPDATE /*+PARALLEL(PEDIDO,3)*/ PEDIDO SET PENDIENTE = 'F';

En este caso, la modificación se realiza en paralelo en las tres particiones, reduciendo el tiempo de procesamiento a la tercera parte aproximadamente.

Con Parallel DML se ejecuta la sentencia como una simple transacción sobre una única sesión: El control de la atomicidad de la tranascción es máximo (commit/rollback único).
Otros beneficios que obtendremos con el procesamiento paralelo sera:

• No es necesario tener multiples sesiones que ejecuten operaciones sobre los mismos datos.
• Dividir el trabajo por rangos rangos conocidos de de rowid o por claves.
• Coordinar de forma manual el trabajo en paralelo o multiples instancias.