.: En una bbdd TimesTen podemos tener estos archivos:
- DataStore (nombreDataStore.ds0 y nombreDataStore.ds1), que son los ficheros en los que se validan los ficheros de log cuando se realizan los Checkpoints. Existen dos para garantizar la consistencia de los datos y aportar la tolerancia a fallos, ya que al realizar el checkpoint se van validando los ficheros de log de manera alterna.
- Ficheros de log (nombreDataStore.log[secuencia]), en caso de que el "logueo" en disco este habilitado se van generando estos ficheros que contienen todas las transacciones que se van realizando en la bbdd. Son los ficheros que se utilizan para validar los datos en el DataStore a la hora de realizar un Checkpoint.
Normalmente la bbdd TimesTen cada vez que realiza un Checkpoint borra los ficheros de log, de todos modos, se puede saber el número de log necesario para la bbdd y que no deberíamos borrar llamado desde ttisql a ttLogHolds:
Command> call ttLogHolds;
- Ficheros .res (nombreinstancia.res0/.res1), ficheros que genera TimesTen cuando la bbdd está configurada para "loguear" todas las transacciones para posteriormente ser validadas en el DataStore mediante un Checkpoint. Estos ficheros se utilizan para evitar que se llene el filesystem y pueda dejar la bbdd corrupta, estos ficheros son encargados de reservar cierto espacio en el filesystem.
lunes, 8 de enero de 2007
:: Off Topic :: Ampliar filesystem en Linux sin LVM
.: Hoy he estado probando como ampliar un filesystem de un sistema Linux que no tenga configurado LVM. Como nota inicial el filesystem debe estar desmontado, en caso de querer ampliar un filesystem que sea necesario para que el sistema pueda ejecutarse, podremos utilizar una "live cd", por ejemplo Knoppix.
1.- Conseguimos la información del disco físico sobre el que está el filesystem que queremos ampliar (supongamos el segundo disco scsi "/dev/sdb"):
# fdisk -s /dev/sdb --> informa sobre el tamaño total del disco en bloques.
# fdisk -l /dev/sdb --> informa sobre las particiones y sus tamaños dentro del disco.
2.- Desmontamos el filesystem:
# umount /dev/sdb1 --> desmontamos el filesystem concreto que queremos ampliar.
3.- Se cambiar la configuración para que no corrija los problemas del disco (fdisk -n) y se deshabilita el "journal" de ext3.
# fsck -n /dev/sdb1
# tune2fs -O ^has_journal /dev/sdb1
4.- Utilizamos "fdisk" para particionar el disco.
# fdisk /dev/sdb
Con "fdisk" borramos la partición que queremos ampliar y a continuación creamos la nueva partición con el tamaño final que queramos. Hay que tener en cuenta que debe de comenzar en el mismo cilindro que la original.
5.- Comentamos la entrada del filesystem que estamos manejando en /etc/fstab y reiniciamos:
6.- Realizamos una comprobación del filesystem con la opción "-f" que permite hacer el "check" aunque el filesystem parezca vacio o limpio:
# e2fsck -f /dev/sda1
7.- Ajustamos el nuevo tamaño que tendrá el filesystem sin especificar tamaño:
# resize2fs /dev/sda1
8.- Hacemos lo mismo que en el punto 3, solo que ahora habilitamos el ext3:
# fsck -n /dev/sdb1
# tune2fs -j /dev/sdb1
9.- Descomentamos la linea referente a el filesystem en "/etc/fstab" y reinicamos.
Ya tendríamos funcionando nuestro filesystem con todos nuestros datos y con el nuevo espacio asignado. Para ext2, sería lo mismo pero sin la opción del "journal", ya que ext3 = ext2 + journal.
1.- Conseguimos la información del disco físico sobre el que está el filesystem que queremos ampliar (supongamos el segundo disco scsi "/dev/sdb"):
# fdisk -s /dev/sdb --> informa sobre el tamaño total del disco en bloques.
# fdisk -l /dev/sdb --> informa sobre las particiones y sus tamaños dentro del disco.
2.- Desmontamos el filesystem:
# umount /dev/sdb1 --> desmontamos el filesystem concreto que queremos ampliar.
3.- Se cambiar la configuración para que no corrija los problemas del disco (fdisk -n) y se deshabilita el "journal" de ext3.
# fsck -n /dev/sdb1
# tune2fs -O ^has_journal /dev/sdb1
4.- Utilizamos "fdisk" para particionar el disco.
# fdisk /dev/sdb
Con "fdisk" borramos la partición que queremos ampliar y a continuación creamos la nueva partición con el tamaño final que queramos. Hay que tener en cuenta que debe de comenzar en el mismo cilindro que la original.
5.- Comentamos la entrada del filesystem que estamos manejando en /etc/fstab y reiniciamos:
6.- Realizamos una comprobación del filesystem con la opción "-f" que permite hacer el "check" aunque el filesystem parezca vacio o limpio:
# e2fsck -f /dev/sda1
7.- Ajustamos el nuevo tamaño que tendrá el filesystem sin especificar tamaño:
# resize2fs /dev/sda1
8.- Hacemos lo mismo que en el punto 3, solo que ahora habilitamos el ext3:
# fsck -n /dev/sdb1
# tune2fs -j /dev/sdb1
9.- Descomentamos la linea referente a el filesystem en "/etc/fstab" y reinicamos.
Ya tendríamos funcionando nuestro filesystem con todos nuestros datos y con el nuevo espacio asignado. Para ext2, sería lo mismo pero sin la opción del "journal", ya que ext3 = ext2 + journal.
jueves, 4 de enero de 2007
:: Cosillas importantes de ttMigrate
.: Al recuperar desde la bbdd destino si superamos el parámetro PermSize (tamaño máximo para un DataStore donde se alojan tablas, indices, secuencias ... hablaré de los diferentes parámetros en próximos post) nos dará un error y dejará en el DataStore solo los objetos importados integramente.
Si intentamos recuperar un objeto que ya existe en el DataStore este objeto no será recuperado, habría que borrarlo previamente. En el caso de que se intenten recuperar varios objetos y uno exista ya en el DataStore, dará un mensaje sobre el objeto existente y continuará con la recuperación del resto.
Como añadido final a este hilo, si el tamaño del DataStore supera el tamaño configurado para "shmmax" (comentado ya en este blog) aparecerá el siguiente error al intentar cargar el DataStore en memoria:
836: Cannot create data store shared-memory segment, error 22
703: Subdaemon connect to data store failed with error TT836
Para solventar este problema bastará con subir el valor del "shmmax"
Si intentamos recuperar un objeto que ya existe en el DataStore este objeto no será recuperado, habría que borrarlo previamente. En el caso de que se intenten recuperar varios objetos y uno exista ya en el DataStore, dará un mensaje sobre el objeto existente y continuará con la recuperación del resto.
Como añadido final a este hilo, si el tamaño del DataStore supera el tamaño configurado para "shmmax" (comentado ya en este blog) aparecerá el siguiente error al intentar cargar el DataStore en memoria:
836: Cannot create data store shared-memory segment, error 22
703: Subdaemon connect to data store failed with error TT836
Para solventar este problema bastará con subir el valor del "shmmax"
miércoles, 3 de enero de 2007
:: Migrando DataStores
.: Para poder realizar pruebas y testeos, una vez instalado TimesTen en una máquina diferente a las de producción he buscado la forma de traerme los datos del entorno de producción al entorno de pruebas.
En producción tenemos una versión 5.1.4, mientras que yo me he bajado la última versión disponible de TimesTen ... una 6.0.4.
Dada la situación para poder exportar los datos y luego recuperarlos en una versión superior de TimesTen tenemos disponible la utilidad ttMigrate.
Su funcionamiento es bastante sencillo, obteniendo un fichero binario donde además de los datos tenemos los objetos de la bbdd (tablas, definiciones de "cache groups", vistas y secuencias)
Aparte nos permitiría mover datos desde un linux de 32bits a otro de 64bits ... esto es aplicable a cualquier otra plataforma.
ttMigrate -c dsn="nombredsn" ficherobinario.dat
Donde ficherobinario.dat es el nombre del fichero donde se guardarán todos los datos de la bbdd y el que utilizaremos en la máquina desde la que queremos importar los datos, del siguiente modo:
ttMigrate -r dsn="nombredsn" ficherobinario.dat
Y ya está, así de sencillo.
Yo he exportado toda la bbdd, pero también podemos limitar por nombres de tabla, objetos de un determinado usuario etc.
En producción tenemos una versión 5.1.4, mientras que yo me he bajado la última versión disponible de TimesTen ... una 6.0.4.
Dada la situación para poder exportar los datos y luego recuperarlos en una versión superior de TimesTen tenemos disponible la utilidad ttMigrate.
Su funcionamiento es bastante sencillo, obteniendo un fichero binario donde además de los datos tenemos los objetos de la bbdd (tablas, definiciones de "cache groups", vistas y secuencias)
Aparte nos permitiría mover datos desde un linux de 32bits a otro de 64bits ... esto es aplicable a cualquier otra plataforma.
ttMigrate -c dsn="nombredsn" ficherobinario.dat
Donde ficherobinario.dat es el nombre del fichero donde se guardarán todos los datos de la bbdd y el que utilizaremos en la máquina desde la que queremos importar los datos, del siguiente modo:
ttMigrate -r dsn="nombredsn" ficherobinario.dat
Y ya está, así de sencillo.
Yo he exportado toda la bbdd, pero también podemos limitar por nombres de tabla, objetos de un determinado usuario etc.
martes, 2 de enero de 2007
::Cambiar el nº de puerto del demonio TimesTen
.: Con la utilidad ttmodinstall podemos cambiar los puertos por lo que está escuchando nuestra bbdd TimesTen. Si no tenemos el directorio de instalación de TimesTen dentro del path, el script lo encontraremos en (con TimesTen instalado por defecto):
/opt/TimesTen/nombre_instancia/bin/ttmodinstall
Ejecutando esta aplicación podremos cambiar el puerto configurado para la instancia como para el demonio (listener) de Timesten.
El script ttmodinstall se encarga de reiniciar el demonio de TimesTen si hemos realizado algún cambio en alguno de los puertos. El reinicio lo realiza con pregunta previa, si no lo reiniciamos en ese momento tendremos que volver a ejecutar ttmodinstall ya que no guarda los cambios hasta que no se reinicia desde la opción que aparece al ejecutar el propio script
/opt/TimesTen/nombre_instancia/bin/ttmodinstall
Ejecutando esta aplicación podremos cambiar el puerto configurado para la instancia como para el demonio (listener) de Timesten.
El script ttmodinstall se encarga de reiniciar el demonio de TimesTen si hemos realizado algún cambio en alguno de los puertos. El reinicio lo realiza con pregunta previa, si no lo reiniciamos en ese momento tendremos que volver a ejecutar ttmodinstall ya que no guarda los cambios hasta que no se reinicia desde la opción que aparece al ejecutar el propio script
:: Instalando TimesTen en RedHat AS 4.0
.: Voy a poner los pasos que he seguido para instalar un TimesTen 6.0.4 en una RedHat AS 4.0 update2.
El software de TimesTen se puede bajar de manera gratuita desde la web de Oracle ... así que podemos "juguetear" con esta bbdd y aprender de manera más o menos sencilla, ya que no necesitamos grandes sistemas para poder instalar y configurar diversos entornos basados en TimesTen :)
En primer lugar debemos modificar una serie de párametros del kernel. Debemos configurar el tamaño del segmento máximo de memoría, por defecto está configurado a 32Mb, se cambiaría del siguiente modo (no es necesario reiniciar):
/sbin/sysctl -w kernel.shmmax=268435456
Ya lo tenemos configurado a 256Mb.
El segundo lugar debemos incluir la siguiente linea en /etc/sysctl.conf y debemos reiniciar acto seguido para que los cambios tengán efecto:
kernel.sem = "250 32000 100 100"
Descomprimimos el paquete que nos hemos bajado desde Oracle:
tar xvzf timesten604.linux86.tar.gz
Se creará un nuevo directorio llamado linux86, entramos y ejecutamos:
./setup.sh
Nos solicita un nombre para la instancia. Cada nueva instalación deberá tener un nombre único de instancia. Dentro de una instancia podemos configurar varios DataStores
Please choose an instance name for this installation? [ tt60]
Seleccionamos si queremos soporte para "Cache connect" a Oracle o no, por ahora solo instalamos con la primera opción (sin "Cache Connect")
Please select a product :
[1] Oracle TimesTen in-Memory Database
[2] Oracle TimesTen in-Memory Database sith CAche Connect to Oracle
Ahora nos solicita que componente queremos instalar, elegiremos la opción 1, es decir, instalamos todo.
[1] Client/Server and Data Manager
[2] Data Manager Only
[3] Client Only
Nos solicita donde queremos instalar TimesTen, lo dejamos en /opt
Where would you like to install the tt60 instance of Timesten? [/opt]
Installing into /opt/TimesTen/tt60 ...
Creating /opt/TimesTen/tt60
Uncompressing ...
Nos avisa de la necesidad de 64Mb en disco para poder instalar y acto seguido nos pregunta el path dónde queremos instalar un DataStore de demostración (DemoDataStore), por defecto en: /var/TimesTen/tt60
En este punto comienza la configuración de la red. El puerto por defecto para el demonio de TimesTen es 16000, nos pide confirmación de la utilización de este puerto o si queremos cambiarlo, lo dejamos por defecto:
Do you want to user the default port number for the TimesTen daemon? [yes]
Habilitamos el control de accesos, por defecto nos da la opción de "no":
Would you like to enable datastore access control) [no] yes
Los logs de la actividad los guarda por defecto en /var/log/messages junto a los mensajes del sistema, nos solicita si queremos que esto sea así o cambiar la ubicación. De momento lo configuramos por defecto ya que hay utilidades del propio TimesTen que leen del fichero de log y filtran por lo que necesitemos.
Would you like to specify a different location for TimesTen syslog messages? [no]
El sistema de instalación procede a levantar el demonio de TimesTen para proceder a instalar el cliente:
Starting TimesTen Daemon: [ OK ]
Se procede a la instalación del cliente espeficicando las opciones configuradas anteriormente en el servidor.
El software de TimesTen se puede bajar de manera gratuita desde la web de Oracle ... así que podemos "juguetear" con esta bbdd y aprender de manera más o menos sencilla, ya que no necesitamos grandes sistemas para poder instalar y configurar diversos entornos basados en TimesTen :)
En primer lugar debemos modificar una serie de párametros del kernel. Debemos configurar el tamaño del segmento máximo de memoría, por defecto está configurado a 32Mb, se cambiaría del siguiente modo (no es necesario reiniciar):
/sbin/sysctl -w kernel.shmmax=268435456
Ya lo tenemos configurado a 256Mb.
El segundo lugar debemos incluir la siguiente linea en /etc/sysctl.conf y debemos reiniciar acto seguido para que los cambios tengán efecto:
kernel.sem = "250 32000 100 100"
Descomprimimos el paquete que nos hemos bajado desde Oracle:
tar xvzf timesten604.linux86.tar.gz
Se creará un nuevo directorio llamado linux86, entramos y ejecutamos:
./setup.sh
Nos solicita un nombre para la instancia. Cada nueva instalación deberá tener un nombre único de instancia. Dentro de una instancia podemos configurar varios DataStores
Please choose an instance name for this installation? [ tt60]
Seleccionamos si queremos soporte para "Cache connect" a Oracle o no, por ahora solo instalamos con la primera opción (sin "Cache Connect")
Please select a product :
[1] Oracle TimesTen in-Memory Database
[2] Oracle TimesTen in-Memory Database sith CAche Connect to Oracle
Ahora nos solicita que componente queremos instalar, elegiremos la opción 1, es decir, instalamos todo.
[1] Client/Server and Data Manager
[2] Data Manager Only
[3] Client Only
Nos solicita donde queremos instalar TimesTen, lo dejamos en /opt
Where would you like to install the tt60 instance of Timesten? [/opt]
Installing into /opt/TimesTen/tt60 ...
Creating /opt/TimesTen/tt60
Uncompressing ...
Nos avisa de la necesidad de 64Mb en disco para poder instalar y acto seguido nos pregunta el path dónde queremos instalar un DataStore de demostración (DemoDataStore), por defecto en: /var/TimesTen/tt60
En este punto comienza la configuración de la red. El puerto por defecto para el demonio de TimesTen es 16000, nos pide confirmación de la utilización de este puerto o si queremos cambiarlo, lo dejamos por defecto:
Do you want to user the default port number for the TimesTen daemon? [yes]
Habilitamos el control de accesos, por defecto nos da la opción de "no":
Would you like to enable datastore access control) [no] yes
Los logs de la actividad los guarda por defecto en /var/log/messages junto a los mensajes del sistema, nos solicita si queremos que esto sea así o cambiar la ubicación. De momento lo configuramos por defecto ya que hay utilidades del propio TimesTen que leen del fichero de log y filtran por lo que necesitemos.
Would you like to specify a different location for TimesTen syslog messages? [no]
El sistema de instalación procede a levantar el demonio de TimesTen para proceder a instalar el cliente:
Starting TimesTen Daemon: [ OK ]
Se procede a la instalación del cliente espeficicando las opciones configuradas anteriormente en el servidor.
:: DataStores
.: Un DataStore es dónde se guardan los datos de una bbdd TimesTen, siendo manejados desde un segmento de memoria. Un DataStores contiene la colección de tablas, índices y resto de objetos de la bbdd.
TimesTen puede manejar varios DataStores, identificándose por su nombre lógico único y una serie de atributos que se definen en su configuración.
DSN --> Data Source Name
- Un DSN identifica a un DataStore.
- Un DataStore puede estar referenciado por varios DNS.
Cuando la bbdd está trabajando el DataStore está cargado en memoria.
TimesTen puede manejar varios DataStores, identificándose por su nombre lógico único y una serie de atributos que se definen en su configuración.
DSN --> Data Source Name
- Un DSN identifica a un DataStore.
- Un DataStore puede estar referenciado por varios DNS.
Cuando la bbdd está trabajando el DataStore está cargado en memoria.
:: Definiendo TimesTen
.: TimesTen es un software de bbdd que ofrece alto rendimiento en la captura, registro, uso y distribución en tiempo real perseverando en la integridad y en la disponibilidad de los datos.
Este software, denominado de "real time" ofrece una gran velocidad de acceso a los datos ya que estos son cargados en memoria al iniciar la instancia o mejor dicho el DataStore.
Como añadido, tiene la posibilidad de realizar réplicas entre diferentes tablas en DataStores ubicados en diferentes máquinas. La répica puede ser bidireccional o unidireccional de una o varias tablas, ofreciendo grandes posibilidades.
Este software, denominado de "real time" ofrece una gran velocidad de acceso a los datos ya que estos son cargados en memoria al iniciar la instancia o mejor dicho el DataStore.
Como añadido, tiene la posibilidad de realizar réplicas entre diferentes tablas en DataStores ubicados en diferentes máquinas. La répica puede ser bidireccional o unidireccional de una o varias tablas, ofreciendo grandes posibilidades.
lunes, 1 de enero de 2007
:: Probando ... probando
.: En este blog hablaré de mis vivencias con TimesTen una bbdd en tiempo real propietaria de Oracle. Definición, estructura, configuraciones, instalaciones ... problemas ;)
Suscribirse a:
Comentarios (Atom)
