Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Proyecto Administracion ORACLE PDF
Proyecto Administracion ORACLE PDF
Administración
Oracle
Título Pág
1 PostgresSQL --------------------------------------------------------- 3
Características
La última serie de producción es la 9.0. Sus características técnicas la hacen una de las bases de datos más potentes y
robustas del mercado. Su desarrollo comenzó hace más de 15 años, y durante este tiempo, estabilidad, potencia,
robustez, facilidad de administración e implementación de estándares han sido las características que más se han tenido
en cuenta durante su desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia
de usuarios accediendo a la vez a el sistema.
A continuación tenéis algunas de las características más importantes y soportadas por PostgreSQL:
Generales
Programación / Desarrollo
SQL
• SQL92,SQL99,SQL2003,SQL2008
• Llaves primarias (primary keys) y ajenas (foreign keys)
• Check, Unique y Not null constraints
• Restricciones de unicidad postergables (deferrable constraints)
• Columnas auto-incrementales
• Indices compuestos, únicos, parciales y funcionales en cualquiera de los metodos de almacenamiento
disponibles, B-tree, R-tree, hash ó GiST
• Sub-selects
• Consultas recursivas
• Funciones 'Windows'
• Joins
• Vistas (views)
• Disparadores (triggers) comunes, por columna, condicionales.
• Reglas (Rules)
• Herencia de tablas (Inheritance)
• Eventos LISTEN/NOTIFY
Podeis consultar la lista completa en ingles de características disponibles en todas las versiones en la dirección
http://www.postgresql.org/about/featurematrix
Límites
Algunos de los limites de PostgreSQL son:
Límite Valor
Máximo tamaño base de dato Ilimitado (Depende de tu sistema de almacenamiento)
Máximo tamaño de tabla 32 TB
Máximo tamaño de fila 1.6 TB
Máximo tamaño de campo 1 GB
Máximo numero de filas por tabla Ilimitado
Máximo numero de columnas por tabla 250 - 1600 (dependiendo del tipo)
Máximo numero de indices por tabla Ilimitado
2 Diferencias entre Oracle y PostgresSQL:
Antes de realizar las migraciones entre estos dos SGBD vamos a realizar una pequeña comparativa entre ellos, en la que
trataremos los siguientes puntos:
– Sintaxis.
– Elementos.
– Rendimiento.
SINTAXIS:
En este primer punto veremos algunas diferencias que nos hemos encontrado entre la sintaxis de Postgres y Oracle.
También os dejamos link de las diapositivas del tema de “Administración de Oracle” que hemos utilizado en clase, y
otro link a una web en la que encontramos la sintaxis utilizada en Postgres para su administración, por si quisiéramos
comparar las diferencias existentes.
Un punto que caracteriza a Postgres, es que puede ser administrado desde el sistema operativo (mediante línea de
comandos al más puro estilo Linux) o desde un cliente SQL, y existen diferencias en la sintaxis de las órdenes. Solo
mostraremos la administración a través de un cliente SQL, pero podemos ver la administración desde el sistema
operativo (y muchísima más información sobre PostgresSQL) aquí.
1- La primera diferencia que nos encontramos son algunos tipos de datos, en concreto nosotros hemos tratado los
siguientes:
ORACLE POSTGRES
varchar2() varchar()
number int(para enteros),float(para decimales)
2- En la creación de usuarios, para especificar la contraseña del usuario tenemos que poner “WITH PASSWORD” en
lugar de “IDENTIFIED BY” como hacíamos en Oracle.
3- Nos encontramos con una característica de Postgres, que no encontramos en Oracle, y es la posibilidad de crear
reglas, las cuales sirven para poner condiciones a los updates, inserts o deletes en tablas o clases, y en Oracle tenemos
que utilizar triggers para ello (en postgres también existen los triggers).
Creación de Reglas:
4- En Postgres no existen los procedimientos, aunque existen “AGGREGATE” que son funciones de agregado de datos
5- En Postgres tenemos la posibilidad de realizar funciones y triggers en varios lenguajes de programación, y también
tenemos la posibilidad de definir el lenguaje que queramos, como por ejemplo Pl-sql, lo cual nos serviría para
migraciones, o para realizar funciones compatibles con Oracle.
En general, no existen grandes diferencias entre la sintaxis de Postgres y Oracle en lo que respecta a la creación de
tablas, vistas, etc. aunque si algunos parámetros que se llaman de forma distinta o bien no existen en uno u otro.
ELEMENTOS:
La ausencia de comparativas (en internet) entre estos SGBD, ha dificultado la tarea de realizar este “análisis” de
similitudes y diferencias. Resulta curioso pero Oracle en su licencia prohíbe las comparativas sin su consentimiento:
“- disclose results of any program benchmark tests without our prior consent;”
http://www.oracle.com/technetwork/testcontent/standard-license-088383.html
En las siguientes tablas podemos ver una información sobre Oracle y Postgres, además de comparar las principales
características de estos dos SGBD:
Información general:
Características fundamentales
Información acerca de que características fundamentales de las RDBMS son implementados nativamente.
Tablas y vistas
Información acerca de que tablas y vistas (unas más básicos que otras) son soportados nativamente.
Índices
Información acerca de que índices (otros como los índices básicos B-/B+) son soportados nativamente.
Otros objetos
Información acerca de que otros objetos son soportados nativamente.
Particionamiento
Información acerca de que métodos de particionamiento son soportados nativamente.
RENDIMIENTO:
En este link encontramos una comparativa de rendimiento entre distintos SGBD, en concreto SQL Server, Oracle y
PostgreSQL, pero nosotros obviaremos el producto de Microsoft ya que nuestro proyecto se centra en los otros dos
sistemas mencionados.
El estudio se basa en la medición del tiempo de ejecución de consultas de distinta complejidad, las cuales tienen los
siguientes elementos:
Para esta comparativa se usaron las versiones ORACLE 10g XE y PostgreSQL 8.2.5, que no son las últimas versiones de
ambos sistemas, por lo que los resultados pueden variar en la actualidad.
Otro factor a tener en cuenta es el Pc en el que son llevadas a cabo las pruebas, el cual es bastante “cortito” por
decirlo de algún modo:
Y bien es conocido Oracle por consumir bastantes recursos, con lo cual sale perjudicado, pero no obstante mostraremos
los resultados para comprobar empíricamente como se comportan en igualdad de condiciones estos dos sistemas.
Según los resultados obtenidos en este análisis de rendimiento en consultas de complejidad baja PostgreSQL es 1.6
veces más rápido que Oracle, en consultas de complejidad media esta diferencia se reduce a 1.1, y en consultas de
complejidad alta Oracle es 1.6 veces más rápido que PostgreSQL.
3 Instalación de postgres y pgadmin en Debian Squeeze:
Para instalar PostgresSQL solamente tenemos que hacer lo siguiente:
Ya tenemos corriendo PostgresSQL, y para comprobarlo miramos los puertos que ha abierto el servidor:
Ahora instalaremos una aplicación gráfica que nos hará más sencillo el manejo de PostgresSQL:
Conexiones remotas:
Por motivos de seguridad postgres no tiene activo el aceptar conexiones remotas. Para activar esta característica
realizaremos los siguientes pasos:
# nano /etc/postgresql/8.4/main/pg_hba.conf
Cambiamos el método “ident” por “md5” para que sea este el método de autenticación:
#listen_addresses = ‘localhost’
listen_addresses = ‘*’
#password_encryption = on
3- Cambiaremos la contraseña que nos trae por defecto postgres, para ello:
# passwd postgres
Nos pide la nueva contraseña en este caso postgres (ya que se trata de un proyecto académico, elegimos
esa por sencillez).
Ya podemos acceder a administrar nuestro servidor PostgresSQL a través de pgadmin, al cual accederemos a través del
menú Aplicaciones → Programación → pgAdmin III.
Ahora debemos realizar una conexión de pgAdmin a nuestro sistema gestor de bases de datos, para ello tenemos que
pulsar en el botón realizar una nueva conexión :
Nos aparecerá la siguiente ventana, la cual rellenaremos indicándole el nombre de nuestra conexión, como Servidor
localhost y lo demás lo dejamos por defecto.
Como podemos ver en la siguiente captura ya esta creada nuestra conexión con la BD.
*Observando el explorador de objetos de pgAdmin podemos ver una pestaña catalogo. En ella podemos encontrar las
tablas que son el equivalente al diccionario de datos de Oracle, también podemos encontrar triggers, funciones...
4 Creación de objetos en Postgres:
Para crear tablas en postgresSQL desplegaremos en el menú el esquema “public” y pulsamos botón derecho del ratón
encima del icono “Tablas”, y escogemos la opción “Nueva tabla” en el menú desplegable:
Nos aparecerá una ventana en la que podemos crear la tabla mediante esta interfaz gráfica, en la cual a través de las
diferentes pestañas que tenemos arriba podemos asignarle todas las propiedades de tabla:
O también podemos hacerlo utilizando un editor de SQL, que es el método que vamos a utilizar.
Para ello pulsaremos en el icono y se abrirá un editor SQL en el que crearemos la tabla:
Antes de seguir añadiremos a Postgres el lenguaje plpgsql para procedimientos, ya que por defecto no viene activo. Para
ello ejecutamos en el editor SQL la siguiente sentencia:
Crearemos una serie de elementos que serán los que luego migremos. Esos elementos son los siguientes:
Usuarios:
Tablas:
Establecemos los permisos para que el usuario “jefe” pueda consultar las dos tablas y el usuario“pringui”
solo la tabla EMPLEADOS:
Por último introducimos datos en las tablas. Esto lo haremos del mismo modo que con Oracle:
Navicat:
Nos descargamos Navicat, programa que sirve para la administración de varios SGBD y permite la conexión a varios de
ellos simultáneamente.
Lo hemos instalado en Windows, y no hay ningún paso a resaltar de la instalación ya que es el típico “siguiente,
siguiente”.
Nota*: Para poder realizar la conexión con Oracle necesitamos tener instalados unos paquetes, los cuales podemos
descargar de la página de descargas de Oracle. Una vez allí nos descargamos el paquete instantclient-basic-win32-
11.2.0.1.0.zip y instantclient-sqlplus-win32-11.2.0.1.0.zip. Para poder descargar el paquete debemos estar registrados.
Configuramos Navicat para poder realizar la conexión con Oracle, para ello nos vamos al menú Tools → Options y
elegimos OCI del menú de la izquierda, y veremos lo siguiente:
Hacemos click derecho sobre el icono de la conexión de Postgres, y seleccionamos Data Transfer en el menú
desplegable:
- Elegimos la base de datos y el esquema en los que están las tablas que queremos migrar.
- Seleccionamos las tablas que queremos incluir en la migración.
En la derecha vemos el menú Target en el que elegiremos el SGBD destino de las tablas.
Pulsamos “Start”.
*Nota: Al comprobar vemos que las tablas han sido migradas con todos sus registros, pero ni rastro de las
constraints ni de los índices, por lo que habría que migrarlos a mano.
7 Scripts de migración Postgres – Oracle:
Migración de usuarios:
Nos devolverá como resultado el listado de todos los usuarios del sistema.
Vamos al menú Archivo → Exportar y elegimos “no entrecomillado” y desmarcamos Nombres de columnas.
Por último seleccionamos el fichero al que queremos que vaya el resultado en nuestro caso script_usuarios.
Ahora nos vamos a un cliente SQL de Oracle, ejecutamos el script y obtenemos como resultado:
Haremos un script que tome los usuarios que tengan el permiso “rolcanlogic” en Postgres:
Hacemos lo mismo que con el anterior script, lo ejecutamos en Postgres y de nuevo lo exportamos a un fichero
y el resultado lo editamos para dejar los usuarios a los que migramos anteriormente:
*Nota: El permiso“rolcanlogin”es el equivalente a“create session”pero hemos decidido hacer el script con
rol“connect”para que los usuarios puedan hacer consultas a los objetos de su esquema.
Por último asignaremos al usuario administrador como propietario de las tablas (más tarde deberíamos
asignarle los permisos a jefe y pringui sobre las mismas):
8 Migracion de tablespace y tablas: Oracle - Postgres:
En este punto de nuevo utilizaremos Navicat, repitiendo los mismos pasos que en el punto 6 pero eligiendo esta vez
como Source nuestro servidor Oracle y como Target nuestro servidor Postgres.
Para poder migrar las tablas debemos desmarcar la opción del recuadro rojo:
Si no lo desmarcamos intentará borrar las tablas en el servidor Postgres antes de migrarlas, y como no existen nos arroja
un fallo.
Comprobamos que se ha completado correctamente:
Con Navicat no podemos migrar vistas, procedimientos, triggers, etc, sin embargo podemos utilizar la opción de exportar
a un fichero esos objetos, y una vez tengamos ese fichero hacer las modificaciones de sintaxis para adaptarlos al otro
SGBD y por último ejecutarlos. Esto se puede hacer tanto en un sentido como en el otro.
Por ejemplo, tenemos la vista “NOMBRE_DEPTOS”, la cual exportamos a un fichero llamado dname.sql:
El contenido de ese fichero es el siguiente:
/*
Navicat Oracle Data Transfer
Oracle Client Version : 11.2.0.1.0
-- ----------------------------
-- View structure for "NOMBRE_DEPTOS"
-- ----------------------------
CREATE VIEW "NOMBRE_DEPTOS" AS
SELECT dname
FROM dept;
Nos vamos a Postgres y hacemos los cambios pertinentes en la sintaxis, en este caso solo tenemos que poner
“dname” y “dept” en mayúsculas puesto que en Oracle todo se guarda en mayúsculas, y al pasar las tablas a
Postgres se pasa todo en mayúsculas también.
Ejecutamos en Postgres:
Y ya tenemos la vista migrada. Como dijimos anteriormente podemos hacer este mismo proceso para todos los objetos
que no hemos conseguido migrar con Navicat o con scripts, tanto en un sentido como en otro.
9 Scripts de migración Oracle - Postgres:
Migración de usuarios:
Lo ejecutamos en SQL Developer y nos devuelve un listado con los usuarios del sistema, pero dejaremos solo
dos para migrar:
Nota*: Hemos intentado encontrar un parámetro para hacer que la contraseña expirara al iniciar sesión el
usuario y encontramos el parámetro“VALID UNTIL”, este parámetro funciona con una fecha, y no al inicio de
sesión. Por otra parte no hace falta asignarle permisos de crear sesión puesto que en Postgres los usuarios
pueden conectarse por defecto.
CONCLUSIÓN:
Este proyecto nos ha servido para darnos cuenta de la minuciosidad y de la dificultad para
llevar a cabo una migración completa y correcta entre estos SGBD, tanto en un sentido
como en otro, ya que hay que salvar importantes diferencias en su arquitectura interna y
su funcionamiento en general.
Concretamente las mayores diferencias que nos hemos encontrado son el sistema de
permisos, el cual se almacena de manera muy distinta en ambos SGBD, los distintos
lenguajes de programación utilizados para funciones, triggers, etc., que fuerzan a que se
tengan que migrar a mano.
Así que podemos determinar que en caso de tenernos que enfrentar a una migración
debemos ser muy organizados y sobre todo armarnos de paciencia.