Copiar una tabla entre diferentes Bases de Datos MySQL

Queremos copiar una tabla de una base de datos MySQL a otra alojada en otro servidor.
Para ello haremos un export, moveremos el fichero exportado al servidor de la bd destino y haremos un import.
Se puede hacer directamente desde la misma máquina de origen mediante mysql conectado a la otra base de datos remota, pero supongamos que no tenemos ese permiso.

1. Exportamos la tabla que queremos copiar. Desde el terminal del sistema ejecutamos:
   mysqldump -p -user=usuario base_de_datos nombre_tabla > nombre_fichero.sql
2. Copiamos el fichero de un servidor a otro si la bbdd estuviera en otro servidor:
   scp nombre_fichero.sql usuario_del_sistema@servidor:/ruta/donde/guardarlo/
3. Importamos la tabla en la bd destino. Desde el terminal:
   mysql -uusuario -p -D base_de_datos < nombre_fichero.sql

Y eso es todo. Si abrimos el fichero exportado con un editor podremos ver las sentencias SQL necesarias para crear la tabla y las inserciones de los datos.

Hasta la próxima

Database Links de 10g a 11g

Para crear un dblink entre 10g i 11g:
-  la bbdd en la que vayas a buscar los datos és una 11g
-  la bbdd donde creas el dblink és 10g

hay que usar entrecomillado doble al definir el user i el password porque la 11g si que distingue entre mayúsculas y minúsculas. Por ejemplo:
create public database link

connect to "" identified by ""

using '';

Com crear una base de dades Oracle 10G manualment

Anem a crear una base de dades nova manualment sense l'assistent gràfic amb Oracle 10g.

És recomanable partir d'una base de dades ja feta i canviar els paràmetres a conveniència.

Per començar el primer que hem de fer és crear a mà, un arbre de directoris on aniran cadascun dels elements.

Suposem que tenim la següent ruta o similar: 

  /u01/app/oracle/admin

on admin conté una subcarpeta per cada base de dades. Creem una nova subcarpeta per la nova bd o bé copiem una altra subcarpeta sencera i buidem tot el contingut. Suposem que tenim una bd creada de nom bd i volem crear una nova bd de nom nova_bd:

 cp -r bd/ nova_bd

dins de nova_bd tenim la següent estructura:

drwxr-x--- 2 oracle oinstall 356352 Apr 24 13:03 adump
drwxr-x--- 2 oracle oinstall  86016 Apr 24 13:03 bdump
drwxr-x--- 2 oracle oinstall   4096 Apr 22 13:50 cdump
drwxr-x--- 2 oracle oinstall   4096 Apr 24 13:50 dpdump
drwxr-x--- 2 oracle oinstall   4096 Apr 22 13:50 pfile
drwxr-x--- 2 oracle oinstall   4096 Apr 24 12:59 scripts
drwxr-x--- 2 oracle oinstall 131072 Apr 24 13:03 udump

buidem cadascuna de les subcarpetes excepte la scripts que podrem aprofitar per modificar.

Decidim quin serà el SID de la base de dades. Per exemple: nova_bd (hi ha una limitació de 8 caràcters).

Creem el fitxer init.ora. Aquest fitxer conté els paràmetres d'inicialització de la bd. Podem copiar-ne un que ja tinguem d'una altra bd i modificar-lo canviant les diferents rutes que inclou a subcarpetes i el SID. El guardem a la carpeta $ORACLE_HOME/dbs/initnova_bd.ora.

Ens connectem amb:

sqlplus /nolog

connect sys as sysdba;

Creem un fitxer SPFILE (Server Parameter File): 

CREATE SPFILE='/u01/oracle/dbs/spfilenova_bd.ora'

 FROM PFILE='/u01/oracle/dbs/initnova_bd.ora';

Engeguem la instància però sense muntar-la:

startup nomount

Ara s'han creat els processos en background que permetran crear la bd. La bd en si encara no existeix. Per a crear la bd executem la comanda (les quantitats de memoria, les rutes i el nombre de redologs s'han d'ajustar en cada cas):

CREATE DATABASE nova_bd
   USER SYS IDENTIFIED BY
   USER SYSTEM IDENTIFIED BY
   LOGFILE GROUP 1 ('//oradata/nova_bd/redo01.log') SIZE 50M,
           GROUP 2 ('//oradata/nova_bd/redo02.log') SIZE 50M,
           GROUP 3 ('//oradata/nova_bd/redo03.log') SIZE 50M,
    MAXLOGFILES 5
   MAXLOGMEMBERS 5
   MAXLOGHISTORY 1
   MAXDATAFILES 100
   MAXINSTANCES 1
   CHARACTER SET WE8ISO8859P1
   NATIONAL CHARACTER SET AL16UTF16
   DATAFILE '/oradata/nova_bd/system01.dbf' SIZE 1024M REUSE
   EXTENT MANAGEMENT LOCAL
   SYSAUX DATAFILE '/oradata/nova_bd/sysaux01.dbf' SIZE 1024M REUSE
   DEFAULT TEMPORARY TABLESPACE temp
      TEMPFILE '/oradata/nova_bd/temp01.dbf'
      SIZE 32767M REUSE
   UNDO TABLESPACE undotbs1
      DATAFILE '/oradata/nova_bd/undotbs01.dbf'
      SIZE 11065M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

Creem el tablespace de dades:

CREATE TABLESPACE users LOGGING
     DATAFILE '/oradata/nova_bd/users01.dbf'
     SIZE M REUSE AUTOEXTEND ON NEXT  M MAXSIZE UNLIMITED
     EXTENT MANAGEMENT LOCAL;

Creem el tablespace d'índexs:

CREATE TABLESPACE indx LOGGING
     DATAFILE '/oradata/dspdi/indx01.dbf'
     SIZE M REUSE AUTOEXTEND ON NEXT       EXTENT MANAGEMENT LOCAL;

Finalment, correrem uns scripts que ens crearan les vistes de les taules del diccionari de dades:

SQLPLUS /NOLOG

CONNECT SYS AS SYSDBA;

@<$ORACLE_HOME>/rdbms/admin/catalog.sql

@<$ORACLE_HOME>/rdbms/admin/catproc.sql

Més info , tot i que és per a 10G 10.1:

http://docs.oracle.com/cd/B12037_01/server.101/b10739/create.htm

Error arrancando el Listener (TNS-00525: Insufficient privilege for operation)

lsnrctl
LSNRCTL> start
Starting /u01/app/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.1.0 - Production
System parameter file is /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/udlnet-01-075/listener/alert/log.xml
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
TNS-12555: TNS:permission denied
 TNS-12560: TNS:protocol adapter error
  TNS-00525: Insufficient privilege for operation
   Linux Error: 1: Operation not permitted


Si esto sucede es posible que haya algún problema de permisos con algo contenido en la carpeta temporal.
Por ello, eliminar mejor el contenido de las siguientes carpetas /tmp i /var/tmp i otorgar permisos a las mismas o cambiar su usuario propietario:

chown oracle:oinstall /var/tmp

su -
cd /tmp/
rm -rf *

cd /var/tmp/
rm -rf *

TNSNAMES y DBLINKS (Î)

El tema de la creación de un DATABASE LINK és una de esas tantas cosas que muchas veces configuramos sin saber siquiera que estamos haciendo, echando mano a la socorrida táctica del copy&paste.

Solo cuando falla alguna cosa nos damos cuenta de que necesitamos saber mas sobre el tema.

Un DATABASE LINK és un recurso de Oracle (muy preciado) que nos permite conectar bases de datos diferentes de forma sencilla.

Antes de entrar en la creación de un dblink propiamente dicho como objeto lógico de la bbdd intentaremos entender como funciona la comunicación del servidor Oracle.

Tendremos que prestar atención a los siguientes componentes:

• Tenemos una BBDD target a la cual queremos acceder. La llamaremos dbtarget.
• Tenemos una BBDD origen DESDE la cual queremos acceder a datos de la dbtarget. La llamaremos dborigen.
• El fichero tnsnames.ora en la bbdd origen. Contiene las direcciones de las bases de datos a la que podremos acceder.
• El fichero de configuración listener.ora i el proceso asociado lsnrtcl que escucha las peticiones de conexión procedentes de los clientes y gestiona el tráfico de estas peticiones.
• El DBLINK propiamente dicho. És un objeto a nivel lógico de la base de datos que podremos utilizar en nuestro código SQL para acceder a tablas de la otra bbdd y trabajar con ellas como si estuvieran en nuestra base de datos dborigen.
• El software SQL*Net y su fichero de configuración SQLnet.ora. Este software controla las comunicaciones de red del servidor Oracle y permite acceso remoto a los datos entre programas y la bbdd, o bien, entre varias bases de datos Oracle. Su configuración se guarda en el fichero de texto SQLNet.ora que se puede editar directamente o mediante un asistente gráfico.

Para el caso que nos ocupa podemos obviar el SQL*Net, pues entendemos que está previamente configurado y funcionando (si no fuera así no funcionaria el acceso a la bbdd por red y no estariamos intentando crear un dblink sino, a buen seguro tendriamos otras prioridades/urgencias). Tan solo mencionar que en SQLNet se define entre otras cosas, la forma en la que un cliente se comunicará con nuestra base de datos. 

Dos de estas posibles formas són:

• TNSNAMES: Mediante un fichero de configuración tnsnames.ora en el cliente.
• EZCONNECT: Conectando directamente con la base de datos Oracle mediante el protocolo TCP/IP. Esta forma elimina la necesidad de buscar nombres de servicios de red. Permite a los clientes conectarse solo con la IP, el puerto, el nombre del servicio, el usuario y el password. Todo ello en una url de este estilo:
  username/password@[//]host[:port][/service_name]
  Este modo nos permite, por ejemplo, configurar conexiones a la bbdd en nuestro SQLDeveloper en local o en nuestra aplicación Java.

Pues bien, en este fichero definimos cual de estas formas se permitiran y que prioridad buscará. Este és el parámetro:

NAMES.DIRECTORY_PATH = (TNSNAMES, EZCONNECT)

El metodo TNSNAMES o también llamado Local Naming Method requiere de un fichero de configuración tnsnames.ora que se aloja en:

• cualquier cliente que se comunique de esta forma con la bbdd.
• en el propio servidor de base de datos Oracle cuando este funcione como cliente (o sea siempre, si  queremos ejecutar un sqlplus en el propio servidor o queremos conectar este server Oracle con otro, via dblinks). Encontraremos este fichero alojado en la carpeta $ORACLE_HOME/network/admin.

Por ahora ya hay suficiente. En el próximo post entraremos en el fichero tnsnames.ora y veremos como se usa.

Hasta pronto.

Crear un usuari de consulta

El que en altres entorns podria resultar senzill, crear un usuari de consulta, en el mon d'Oracle no és obvi.
Per qué?

Doncs un usuari, no és només una connexió, si no que va lligat irremediablement a un esquema de la bbdd. Quan crees un usuari, crees per força un esquema associat, o sigui, un propietari d'una sèrie d'objectes que podrà crear (o no) aquest usuari.
Però molts cops el que volem és una entrada, una visió diferent a unes dades que ja existeixen, a uns objectes que són d'un altre propietari. I a més volem que la forma d'accés a aquests objectes sigui diferent de la que té el propietari, evidentment, si no ja ens valdria el usuari propietari. El cas més comú deu ser el desig de crear un usuari que només pugui consultar les dades d'un esquema però sense esborrar.
Una aproximació a aquest problema seria:

1. crear un esquema nou, per exemple UCONSULTA.
2. des de l'esquema on tenim les dades (p.ex: UPROPIETARI) donar accés de consulta a totes les taules: GRANT SELECT ON to UCONSULTA;
3. quan entrem amb el usuari UCONSULTA, podem fer select * from UPROPIETARI.

Això està be, però te alguns inconvenients:

• el que faci anar l'usuari UCONSULTA ha de saber a priori el nom de les taules que vol accedir, doncs veurà els noms enlloc.
• s'ha de fer el GRANT de tots els objectes un a un o fer un script que ho faci automàticament.

Per al primer inconvenient, la sol·lució (parcial) és, al crear l'usuari UCONSULTA, afegir el següent privilegi:

• GRANT SELECT ANY DICTIONARY TO UCONSULTA

Això permet a l'usuari UCONSULTA accedir al diccionari de dades, lo qual li permet veure els noms de les taules dels altres esquemes de la bbdd, però de tots, no només del que voliem. Ja deia que era una sol·lució parcial...

Per al segon inconvenient, una altra sol·lució (parcial) és, al crear l'usuari UCONSULTA, afegir el següent privilegi:

• GRANT SELECT ANY TABLE TO UCONSULTA

Això permet a l'usuari UCONSULTA veure el contingut de TOTES les taules de tots els esquemes de la BBDD. Si això no suposa cap problema doncs és una via possible. (Ja deia que era una sol·lució parcial).

No m'agrada cap de les sol·lucions, la veritat.

p.d.: no em faig responsable dels problemes de seguretat que es puguin causar.

Redo log (I)

Ya decía yo que me tocaba luchar en todas las batallas. Ahora el "enemigo" se llama Redo log. Ya dicen que para vencer a tu enemigo hay que entenderlo. Así que después de empaparme con la documentación online de Oracle voy a intentar escribirlo a mi manera para ver si lo recuerdo.
Todo ha empezado cuando la bbdd ha ralentizado su funcionamiento hasta límites sospechosos. He acudido al fichero que vive en /opt/app/oracle/admin//bdump/alert_.log y he visto el siguiente texto:

Thread 1 advanced to log sequence 19962
Current log# 11 seq# 19962 mem# 0: /opt/app/oracle/oradata//redo1.log
Thread 1 cannot allocate new log, sequence 19962
Checkpoint not complete

¿Que está pasando?
Algún problema con los redo log, eso seguro.

Los redo log son dos o más ficheros pre asignados que guardan los cambios que se van produciendo en la base de datos a medida que ocurren. Cada instancia de la base de datos tiene sus redo log para proteger la bbdd en caso de fallo de instancia.

¿Y porque aparece por aquí la palabra Thread?
En una configuración típica solo hay una instancia para una misma base de datos, pero en un entorno de cluster de Oracle, hay más de una instancia para una misma base de datos y cada instancia tiene su propio Thread de redo logs para evitar un atasco si usaran los mismos redo log.

¿Pero que contienen los ficheros redo log?
Los ficheros redo log contienen redo records (registro de redo) y así me quedo la mar de ancho (¿qué van a tener sino los ficheros sino registros?). Bueno, un redo record o redo entry (entrada de redo) a su vez contiene algo llamado change vector (vector de cambio) que es una descripción de un cambio hecho en un solo bloc de la bbdd. Estos registros contienen la información necesaria para reconstruir todos los cambios hechos en una bbdd incluido los segmentos de rollback.

¿Cual es el ciclo de vida de un redo log?
Como casi todo en este loco mundo de la informática empieza en la memoria. Las redo entries (entradas de redo) causadas por algún cambio en la bbdd originado por alguna sentencia SQL (INSERT, UPDATE, DELETE, CREATE, ALTER, o DROP) se generan en el espacio de memoria del usuario y procesos de Oracle las copian al redo log buffer del SGA. Las redo entries toman espacio secuencial del redo log buffer. Que por cierto, como casi todo en Oracle, el tamaño de este buffer se puede definir ajustando el parámetro de inicialización LOG_BUFFER. Es importante ajustar bien el tamaño de este buffer. A mayor tamaño se reducen las operaciones I/O aumentando el rendimiento.

Copiar a disco.
Cuando se produce un commit, es decir, se finaliza la transacción, el proceso de Oracle LGWR copia los redo records del redo log buffer, ojo, solo los correspondientes a la transacción que se ha cerrado, al fichero de redo log en el disco.
Sin embargo, no es necesario que esto suceda solo cuando se produzca un commit. También se realiza el proceso cuando:

• se ha llenado el buffer de redo log
• se ha hecho commit de otra transacción

En este caso se copia todo el contenido del buffer de redo log a disco, incluso aquellas entradas de las que aún no se ha realizado un commit. Estas entradas serán permanentes si se produce un commit en posterioridad.
Sigamos el curso normal. Acabamos de hacer un commit de una transacción. El proceso LGWR graba las redo entries en el fichero de redo log y le asigna un número llamado System Change Number (SCN) que identifica unequivocamente cada transacción dentro del fichero de redo log. Solo cuando absolutamente todas las entradas de redo log de la transacción están a salvo guardadas en nuestro fichero, es cuando se envía el aviso al usuario de que se ha realizado un commit con éxito.

Redo log en disco.

El redo log está compuesto por 2 ficheros como mínimo, pero pueden ser mas. ¿Porque 2? Porque se tiene que garantizar que mientras uno esté activo el otro pueda estar siendo archivado, o más bien al revés, garantizamos que mientras uno está siendo archivado (siempre y cuando estemos en modo ARCHIVELOG del cual ya hablaremos más tarde) haya otro como mínimo que esté activo.
El proceso LGWR guarda en los ficheros de redo log de un modo circular. Es decir, empieza por el primero y cuando este está lleno, continua por el siguiente disponible. En cuanto ha llenado el último disponible, vuelve a empezar por el primero y empieza el ciclo de nuevo.
El comportamiento cuando cambia de un fichero a otro varía en función de si tenemos activado o no el modo ARCHIVELOG. Si lo tenemos activado, al saltar a otro fichero, el que abandonamos se archiva en disco en un espacio habilitado a tal efecto.

(Continuará...)

links:
Managing Oracle redo logs
Oracle Concepts - Online redo log management
http://kerneltrap.org/node/14286
AskTom