Tradueix

martes, 17 de enero de 2017

Oracle 12c Crear una nueva Pluggable Database

Han cambiado bastantes cosas en Oracle12c. El cambio mas importante sin duda és el nuevo sistema Multitenant que permite una mejor gestión de recursos al compartir algunos de ellos entre diferentes bases de datos alojadas en el mismo servidor, con el consiguiente ahorro.
Este sistema Multinenant conlleva la adopción de nuevos conceptos. Digamos que puedes crear una base de datos como las de toda la vida Non-Container y también puedes crear una base de datos de un nuevo tipo Container DB (CDB). Este nuevo tipo de bd permite alojar varias bases de datos BD en su interior que se llamaran Pluggable BD (PDB). Hay recursos comunes a todas las PDB que se alojaran en el espacio de la CDB contenedora y otros que seguiran en el espacio privado de la PDB. La gracia és que puedes coger una BD normal de Oracle 11, por ejemplo, y "enchufarla" como una PDB. Tambien puedes "desenchufar" una PDB y moverla a otra CDB, etc..  Para el usuario/cliente/app esta gestión es transparente, la conexión con la BD será igual tanto si es una bd PDB o no.

Vamos a ver como creamos una base de datos PDB desde Linux. Por esta vez, suponemos que ya tenemos una CDB creada. Es decir, ya tenemos una bd contenedora y queremos crear una PDB en su "interior". Hay varias maneras de hacerlo: Usando la semilla o clonando una PDB. Esta vez lo haremos usando la semilla puesto que queremos empezar una bd de cero. Suponemos que el SID de la CDB se llamará cdb01 y la PDB pdb01 en un alarde de imaginación.

1. Nos conectamos a la CDB como sysdba:

> export ORACLE_SID=cdb01
> sqlplus / as sysdba

 SQL*Plus: Release 12.1.0.2.0 Production on Tue Jan 17 11:38:10 2017 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

2. Comprobamos que estamos en la bd correcta:
SQL> show con_name
 CON_NAME 
------------------------------ 
CDB$ROOT 

3. Creamos una subcarpeta en la carpeta oradata del servidor donde se alojan los ficheros físicos de la bd:

> cd /u03/oradata/cdb01
> mkdir pdb01

si comprobamos el contenido de la carpeta u03/oradata/cdb01 deberian aparecer las carpetas :
pdb01
pdbseed

usaremos el contenido de pdbseed para crear la bd.


4. Volvemos al SQLPLUS y creamos la bd propiamente dicha con:
CREATE PLUGGABLE DATABASE pdb01 ADMIN USER admin identified by "password_de_admin"
default tablespace users
DATAFILE '/u03/oradata/cdb01/pdb01/users01.dbf'
size 250M AUTOEXTEND ON
FILE_NAME_CONVERT=(
'/u03/oradata/cdb01/pdbseed/',
'/u03/oradata/cdb01/cdb01/');

a lo que deberia responder al cabo de unos segundos:

Pluggable database created.

Comprobamos que se ha hecho correctamente:

SQL> show pdbs 
CON_ID CON_NAME          OPEN MODE RESTRICTED 
----------   ------------------------------ ----------             ---------- 
2            PDB$SEED            READ ONLY  NO 
3            PDB01                    MOUNTED

5. Abrimos la base de datos

 alter pluggable database pdb01 open;

a lo que responde:

Pluggable database altered.

6. Comprobamos que ha cambiado su estado:

SQL> show pdbs 

CON_ID  CON_NAME           OPEN MODE  RESTRICTED 
----------     ------------------------------ ----------             ---------- 
2             PDB$SEED            READ ONLY   NO 
3             PDB01                   READ WRITE NO

7. Opcionalmente crearemos mas tablespaces para alojar diferentes aplicaciones. Es una buena práctica. Se realiza como siempre:

CREATE TABLESPACE tablespaceapp DATAFILE '/u03/oradata/cdb01/pdb01/tablespaceapp01.DBF' SIZE AUTOEXTEND ON MAXSIZE UNLIMITED; 

 8. Añadimos en el fichero tnsnames.ora la nueva bd:

PDB01 = 
(DESCRIPTION = 
 (ADDRESS_LIST = 
 (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) 
 )
 (CONNECT_DATA = 
 (SERVICE_NAME = PDB01)
 )
 )






lunes, 19 de septiembre de 2016

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

viernes, 2 de septiembre de 2016

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 '';

jueves, 25 de abril de 2013

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:



lunes, 22 de abril de 2013

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 *


martes, 14 de febrero de 2012

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.




jueves, 3 de febrero de 2011

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.

Oracle Wars © 2008. Template by Dicas Blogger.

TOPO