Backups locales y backups remotos

Deja un comentario

El programa GBAK nos permite realizar backups locales y backups remotos.

  • En un backup local, la Base de Datos que está en el Servidor copiamos a nuestro disco duro local
  • En un backup remoto, la Base de Datos que está en el Servidor copiamos en el Servidor

NOTA: En todos los ejemplos de abajo el comando se ve en 3 líneas para que sea más fácil visualizarlo, pero debe escribirse en 1 sola línea.

Caso 1. Backup local

Ejemplo 1. El backup lo realiza el usuario SYSDBA o el creador de la Base de Datos

GBAK -backup -user NombreUsuario -password Contraseña 
\\SERVIDOR-PC\C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Ejemplo 2. El backup lo realiza un usuario que tiene el rol RDB$ADMIN

GBAK -backup -user NombreUsuario -password Contraseña -role RDB$ADMIN
\\SERVIDOR-PC\C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Ejemplo 3. El backup se hace mediante conexión por TCP/IP

GBAK -backup -user NombreUsuario -password Contraseña 
192.168.1.1:C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Si el usuario que quiere realizar el backup no es SYSDBA ni el creador de la Base de Datos entonces sí o sí debe tener el rol RDB$ADMIN y además deberá especificarlo para que el backup pueda realizarse con éxito.

La Base de Datos que se encuentra en la computadora cuyo nombre es SERVIDOR-PC o cuya dirección IP es 192.168.1.1 será copiada al disco duro local del usuario. Desde luego que estos son ejemplos, en tu caso tanto el nombre de la computadora o la dirección IP pueden ser distintos. El programa GBAK puede encontrarse en el disco duro local o en cualquier otra computadora. Si se encuentra en otra computadora debe estar en una carpeta compartida o no se lo podrá ejecutar.

Caso 2. Backup remoto

Ejemplo 4. Un backup remoto usando el nombre de la computadora

GBAK -backup -service \\SERVIDOR-PC\service_mgr -user NombreUsuario -password Contraseña 
C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Ejemplo 5. Un backup remoto usando la dirección IP de la computadora

GBAK -backup -service 192.168.1.1:service_mgr -user NombreUsuario -password Contraseña 
C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Para que el backup remoto pueda realizarse se debe llamar al administrador de servicios o service manager de una computadora que tenga instalado al Servidor del Firebird.

Cuando se usa el service manager el backup termina más rápido, eso significa que los backups remotos son más rápidos que los backups locales.

Comentarios:

  1. El programa GBAK debe poder acceder a la Base de Datos. Para ello se puede usar la ubicación de la Base de Datos  (como en los ejemplos anteriores) o un alias que se haya especificado en el archivo ALIASES.CONF (que es lo recomendable)
  2. Como el programa GBAK copiará todo el contenido de la Base de Datos entonces solamente podrá finalizar con éxito si es ejecutado por el usuario SYSDBA, por el creador de la Base de Datos, o por un usuario que se conecte con el rol RDB$ADMIN. Eso es muy lógico, si un usuario tiene acceso restringido a una Base de Datos no se le puede permitir copiar todo el contenido de ella.
  3. La conexión a la Base de Datos puede realizarse mediante named-pipes (o sea, especificando el nombre de la computadora, como en el Ejemplo 1.) o mediante su dirección IP (como en el Ejemplo 3.)
  4. Si se quiere realizar un backup remoto entonces hay que usar la opción -service. Esta opción puede recibir un solo parámetro, el cual se llama service_mgr. El service_mgr solamente existe en las computadoras que tienen al Servidor del Firebird instalado. Por ese motivo, si la computadora desde donde se realiza el backup no tiene instalado al Servidor del Firebird hay que llamarlo al service_mgr desde una computadora que sí lo tenga instalado. Se lo puede llamar usando el nombre de la computadora (como en el Ejemplo 4.) o la dirección IP de la computadora (como en el Ejemplo 5.). Desde luego que si la computadora desde donde se ejecuta al programa GBAK tiene instalado al Servidor del Firebird entonces no será necesario escribir esos prefijos.
  5. Cuando se hace un backup remoto, la carpeta en donde se copiará el backup debe estar compartida. El programa GBAK es un programa más, para el Sistema Operativo no tiene algo de especial, es uno más del montón. Por lo tanto, para que pueda copiar el backup en una carpeta debe tener derecho de escritura en esa carpeta. Si la carpeta está en otra computadora, entonces debe estar compartida, sí o sí.
  6. Cuando se quiere realizar un backup hay que diferenciar dos cosas: 1) El programa GBAK debe poder conectarse a la Base de Datos, como si se tratara de un usuario humano más. Es por eso que debe especificarse el usuario, la contraseña, y quizás el rol. 2) El programa GBAK debe poder crear un archivo en una carpeta de un disco duro. Es por eso que debe tener permiso de escritura en esa carpeta.
  7. Cuando se realiza un backup remoto, hay que ver a la carpeta destino desde el punto de vista del Servidor. En los ejemplos 4. y 5. la carpeta C:\SISTEMAS\BACKUPS\ es una carpeta que se encuentra en la misma computadora donde se encuentra el Servidor. No es una carpeta local, es una carpeta remota, y se la ve como local, pero es local para el Servidor.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Agregando el usuario SYSDBA en Firebird 3

8 comentarios

En las versiones anteriores de Firebird, ya por defecto en el archivo de seguridad (SECURITY.FDB en 1.x y SECURITY2.FDB en 2.x) existía un usuario llamado SYSDBA y con la contraseña masterkey.

Bien, ese ya no es el caso con Firebird 3, ahora ningún usuario predeterminado existe, ni siquiera SYSDBA. Por lo tanto, nosotros debemos crearlos.

Siempre el usuario SYSDBA tendrá acceso al 100% de las bases de datos, pero como no existe un usuario SYSDBA nosotros lo crearemos. ¿Cuál es la ventaja de esto? Que SYSDBA ya no tendrá por defecto la contraseña masterkey sino la contraseña que a nosotros se nos ocurra asignarle.

Con las versiones 1.x y 2.x si un intruso quería conocer el contenido de una Base de Datos lo tenía muy fácil:

  1. Copiaba o hacía un backup de la Base de Datos
  2. Copiaba o restauraba esa Base de Datos en otra computadora, en una donde conociera la contraseña del usuario SYSDBA.
  3. Listo

Ahora, con Firebird 3 algo así ya no le será posible. ¿Por qué no? Porque si copia o restaura la Base de Datos en otra computadora tendrá un gran problema ¿cuál es la contraseña del usuario SYSDBA que se necesita para conectarse a la Base de Datos? Desde luego que no será masterkey (salvo que el Administrador sea un verdadero bobo) y si no conoce esa contraseña no conseguirá el acceso. Claro, puede copiar también el archivo de seguridad (SECURITY3.FDB por defecto) pero estará en la misma: si no conoce la contraseña no conseguirá la conexión. Y además, en un entorno donde la seguridad sea muy importante el archivo de seguridad no será SECURITY3.FDB sino otro archivo con totalmente otra estructura y ubicado donde se haya especificado en DATABASES.CONF (quizás en otra carpeta de otro disco duro de otra computadora).

En síntesis, la tarea del intruso ahora será mucho más dificultosa. No imposible, porque en Informática la seguridad al 100% es imposible de conseguir, pero sí muchísimo más dificultosa que en las versiones anteriores del Firebird.

¿Cómo agrego al usuario SYSDBA?

Recuerda que al instalar Firebird 3 ningún usuario existe, ni siquiera SYSDBA, entonces ¿cómo hacemos para agregar al usuario SYSDBA y con la contraseña que se nos ocurra asignarle?

Mediante el siguiente comando:


GSEC -add SYSDBA -pw Secreto -user SYSDBA

El programa GSEC.EXE lo encontrarás en la misma carpeta donde instalaste el Firebird 3.

Y la contraseña que elijas no será Secreto, ese es solamente un ejemplo.

Conclusión:

Para hacerle la vida muchísimo más difícil a los intrusos ahora en Firebird 3 el usuario SYSDBA no existe por defecto sino que debemos crearlo nosotros. Así mismo tampoco tiene una contraseña por defecto, su contraseña inicial será la que le asignemos al crearlo, la muy famosa masterkey ya no existe (salvo que alguien sea muy bobo como para asignársela al usuario SYSDBA).

Para agregar al usuario SYSDBA y asignarle su contraseña inicial (la cual no debería ser masterkey) usamos el programa GSEC.EXE que se encuentra en la misma carpeta donde instalamos al Firebird 3.

Artículos relacionados:

¿Por qué Firebird 3?

Los archivos de configuración del Firebird 3

Entendiendo a los plug-in del Firebird 3

Parametrizando el archivo DATABASES.CONF

El índice del blog Firebird21

El foro del blog Firebird21

Haciendo backups con GBAK (3)

Deja un comentario

En artículos anteriores ya vimos mucho sobre la parte teórica de hacer backups en general, y de hacer backups con GBAK en particular, así que vayamos ahora a la parte práctica:

La sintaxis general de GBAK

GBAK <opciones> -USER <usuario> -PASSWORD <contraseña> <origen> <destino>

Opciones: con ellas le indicamos a GBAK lo que queremos hacer

Usuario: es el nombre del usuario que realizará el backup o la restauración. Debe ser SYSDBA o el creador de la Base de Datos o un usuario con el rol RDB$ADMIN.

Contraseña: es la contraseña del usuario que realizará el backup o la restauración

Origen: si se hará un backup es nombre completo de la Base de Datos (la cual generalmente tiene la extensión .FDB) o un alias definido en el archivo ALIASES.CONF; si se hará una restauración es el nombre completo del archivo de backup (el cual generalmente tiene la extensión .FBK)

Destino: si se hará un backup, es el nombre del archivo que será generado (generalmente con la extensión .FBK); si se hará una restauración es el nombre que tendrá la nueva Base de Datos (generalmente con la extensión .FDB)

Tipos de opciones

Las opciones de GBAK pueden ser de tres tipos:

  1. Opciones generales
  2. Opciones del backup
  3. Opciones de la restauración

Las opciones generales son las que se pueden usar en ambos casos (es decir, cuando se hace el backup o cuando se hace la restauración) y son las siguientes:

nodbtriggers Impide que se desencadenen los triggers de la Base de Datos.

-pas[sword] <contraseña> La contraseña que el usuario utiliza para conectarse a la Base de Datos. Alternativamente se puede usar -fet[ch_password] para no escribir la contraseña

-fet[ch_password] <nombre_archivo> En lugar de escribir la contraseña en la línea de comandos se puede extraerla de un archivo, de esta manera si hay un curioso mirando lo que escribes no podrá saber cual es tu contraseña

-m[etadata] Solamente hace el backup o la restauración de los metados, los datos introducidos por los usuarios serán ignorados

-role <nombre_del_rol> Si el usuario usó un rol

-se[rvice] <hostname[/port]>:service_mgr Cuando se está haciendo el backup: el archivo se crea en el Servidor, usando para ello al Service Manager. Cuando se está haciendo la restauración: la Base de Datos se crea en el Servidor, usando para ello el Service Manager. Tanto la Base de Datos como el archivo de backup como el archivo de log deben encontrarse en uno de los discos duros del Servidor y cuando se los especifica debe hacerse desde la perspectiva del Servidor, aún cuando se llame a GBAK desde una computadora remota. La ventaja de usar el Service Manager es que el backup y la restauración se hacen muy rápido.

-u[ser] Nombre del usuario de la Base de Datos

-v[erbose] Muestra en la pantalla lo que está haciendo GBAK

-y [nombre_archivo> Crea un archivo de log y escribe todos los mensajes de GBAK que normalmente se mostrarían en la pantalla en el archivo de log. El archivo de log no debe existir. Por lo tanto, si existe, hay que borrarlo antes de ejecutar a GBAK. Si se usa la opción -se[rvice] el archivo de log debe encontrarse sí o sí en uno de los discos duros del Servidor.

-y suppress No muestra los mensajes de GBAK en la pantalla ni los escribe en un archivo de log

-z Muestra la versión de GBAK y del Servidor del Firebird

Las opciones del backup son las que solamente se usan cuando se está realizando el backup y son las siguientes:

-b[ackup_database] Se desea realizar un backup. Es opcional.

-co[nvert] Convierte las tablas externas en tablas internas

-e[xpand] Crea un archivo de backup no comprimido. Por lo tanto, ocupará más espacio en el disco duro

-fa[ctor] n Factor de bloqueo para los dispositivos de cinta

-g[arbage_collect] No recolecta la basura durante el backup, por lo tanto el backup terminará más rápido. Debes usar esta opción cuando inmediatamente después del backup harás un Sweep

-ig[nore] Ignora los checksums mientras realiza el backup

-l[imbo] Ignora las transacciones en limbo mientras realiza el backup

-nt Formato no transportable. Debes usarlo solamente cuando estás 100% seguro que la restauración se hará en el mismo Sistema Operativo y con la misma versión del Firebird

-t[ransportable] Crea un backup que es transportable entre Sistemas Operativos y versiones del Firebird. Es la opción por defecto

Las opciones de la restauración son las que solamente se usan cuando se está restaurando el backup y son las siguientes:

-bu[ffers] Establece el tamaño del caché para la Base de Datos restaurada

-c[reate_database] Restaura a una nueva Base de Datos (el nombre de la nueva Base de Datos no debe existir)

-fix_fss_d[ata] Repara códigos UNICODE_FSS de los datos que estaban mal formados

-fix_fss_m[etadata] Repara códigos UNICODE_FSS de los metadatos que estaban mal formados

-i[nactive] Todos los índices son restaurados como inactivos

-k[ill] No crea los archivos de shadow que fueron definidos en el backup

-mo[de] read_write La Base de Datos restaurada será read/write (o sea: lectura y escritura). Es el valor por defecto

-mo[de] read_only La Base de Datos restaurada solamente podrá ser leída y no se podrán realizar cambios en ella

-n[o_validity] No restaura las restricciones de validación. Sirve para restaurar datos que no cumplen con las restricciones y que no podrían ser restaurados de otra manera

-o[ne_at_a_time] Lo normal es que la restauración se haga en una sola transacción para toda la Base de Datos. El problema es que si se encuentra algún error entonces ninguna tabla será restaurada. Con esta opción se abre una transacción para cada tabla y después de restaurarla se ejecuta el COMMIT. De esta manera se puede restaurar parcialmente una Base de Datos corrupta.

-p[age_size] <tamaño_página> Pone el tamaño de la página de la Base de Datos. Los valores posibles son 4096, 8192, 16384. El valor por defecto es 4096.

-r[eplace_database] Restaura sobre una Base de Datos existente. Esto solamente puede ser realizado por SYSDBA o por el creador de la Base de Datos que será sobre-escrita. ¡¡¡CUIDADO!!! No hay que restaurar sobre una Base de Datos que está siendo usada.

-rep[lace_database] Igual que la opción anterior. Es simplemente una nueva abreviación.

-r[ecreate_database] o[verwrite] Restaura sobre una Base de Datos existente. Solamente puede ser ejecutada por SYSDBA o por el creador de la Base de Datos que será sobre-escrita. Si la Base de Datos está siendo usada el Firebird te lo advertirá porque es algo que no deberías hacer, de todas maneras: debes ser cuidadoso

-use_[all_space] Normalmente cuando se realiza la restauración cada página de la Base de Datos es escrita en un 80%, en cambio si se usa esta opción cada página será llenada al 100%. Es muy útil cuando la Base de Datos restaurada será read-only (y por lo tanto ya no será modificada), porque ahorra mucho espacio en el disco duro.

Ejemplo Nº 1. Un backup normal

GBAK -v -USER SYSDBA -PASSWORD masterkey D:\BASESDATOS\CONTA.FDB D:\BACKUPS\CONTA.FBK

Si en el archivo ALIASES.CONF hemos definido CONTA=D:\BASEDATOS\CONTA.FDB también se podría escribir:

GBAK -v -USER SYSDBA -PASSWORD masterkey CONTA D:\BACKUPS\CONTA.FBK

La opción -v nos muestra en la pantalla lo que está haciendo GBAK.

Ejemplo Nº 2. Un backup con archivo de log

DEL D:\BACKUPS\CONTA.LOG

GBAK -v -USER SYSDBA -PASSWORD masterkey -y D:\BACKUPS\CONTA.LOG D:\BASESDATOS\CONTA.FDB D:\BACKUPS\CONTA.FBK

El archivo de log no debe existir, por eso se lo borra primero. Todo lo que GBAK hubiera mostrado en la pantalla será escrito en el archivo de log, así ese archivo podrá ser revisado cuando se lo necesite.

Ejemplo Nº 3. Una restauración normal

GBAK -c -v -USER SYSDBA -PASSWORD masterkey D:\BACKUPS\CONTA.FBK D:\BASESDATOS\CONTA2.FDB

La Base de Datos restaurada tiene un nombre distinto (CONTA2.FDB) al de la Base de Datos original (CONTA.FDB), esa es la práctica normal y la más recomendada.

Ejemplo Nº 4. Restaurando a una Base de Datos de sólo lectura

GBAK -c -v -mode read_only -use_all_space -USER SYSDBA -PASSWORD masterkey D:\BACKUPS\CONTA.FBK D:\BASESDATOS\CONTA3.FDB

Como -mode es read_only entonces la Base de Datos será de sólo lectura, y como será de sólo lectura entonces se establece que cada página esté llena al 100%, ahorrando así mucho espacio en el disco duro.

Ejemplo Nº 5. Backup y restauración al mismo tiempo

Es muy útil para verificar que el archivo de backup se encuentra en perfecto estado. Un archivo de backup que no se encuentra en perfecto estado puede ser inútil e inservible, por lo tanto una muy buena medida administrativa es verificar que está ok.

GBAK -c [opciones] <base_de_datos_origen> stdout | GBAK -r [opciones] stdin <base_de_datos_destino>

Como puedes ver aquí el programa GBAK se ejecuta dos veces:

  • La primera vez, en lugar de crear al backup en el disco duro (que es lo normal) lo crea en stdout que es la salida estándar (la cual por defecto es la pantalla de la computadora)
  • La barra vertical significa que el programa que se encuentre a continuación (y que en este caso también es GBAK pero podría ser otro) tome como entrada la salida del primer programa ¿en qué lugar? en donde se encuentre stdin
  • El primer GBAK crea el archivo de backup, el segundo GBAK restaura ese archivo de backup

Esta es una forma simplificada de realizar un ciclo backup/restore normal:

  • Con GBAK conectarse a una Base de Datos y crear un archivo de backup
  • Con GBAK leer el archivo de backup y crear una nueva Base de Datos

Artículos relacionados:

Entendiendo a las bases de datos

Entendiendo a los metadatos del programador

Los triggers de la Base de Datos

Haciendo backups con GBAK (1)

Haciendo backups con GBAK (2)

El índice del blog Firebird

El foro del blog Firebird21

 

Delegando el otorgamiento de derechos

9 comentarios

Lo usual es que el creador de la Base de Datos o el usuario SYSDBA se encarguen de otorgarles derechos (también llamados “permisos” o “privilegios”) a los usuarios y a los roles. Sin embargo, en organizaciones grandes esto puede requerir de mucho tiempo entonces tienen la posibilidad de delegar parte de su autoridad en otros usuarios, para que estos otros usuarios también puedan otorgar derechos.

El comando que sirve para otorgar derechos se llama GRANT. A su vez, el comando que sirve para quitar derechos se llama REVOKE y sus sintaxis son las siguientes:

GRANT
   {<privilegios> ON <objeto> | rol}
   TO <beneficiario>
   [WITH {GRANT|ADMIN} OPTION]
   [{GRANTED BY | AS} [USER] otorgador]
REVOKE
   [{GRANT|ADMIN} OPTION FOR]
   {<privilegios> ON <objeto> | rol}
   FROM <beneficiario>
   [{GRANTED BY | AS} [USER] otorgador]

La clásula WITH GRANT OPTION significa que el usuario que recibió ese derecho puede otorgarlo a otros usuarios, si lo desea. Desde luego que solamente puede otorgar los derechos que posee y nada más.

La cláusula WITH ADMIN OPTION se otorga a los roles y significa que el usuario que tiene un rol puede otorgar ese rol a otros usuarios, si lo desea. Por supuesto que solamente puede otorgar su propio rol y nada más.

La cláusula GRANTED BY se usa para que aparezca como otorgador del derecho no quien lo hizo, sino otro usuario. ¿Y por qué se haría eso? Para que ese otro usuario pueda revocar el derecho.

Existe un rol especial, llamado RDB$ADMIN, que le permite a quien lo recibe tener los mismos derechos que el usuario SYSDBA pero solamente en esta Base de Datos. O sea que en la práctica quien posee el rol RDB$ADMIN puede actuar como si fuera el usuario SYSDBA.

Ejemplos:

Conectado como SYSDBA:

GRANT SELECT ON BANCOS TO MARCELA WITH GRANT OPTION;

SYSDBA le otorgó a MARCELA el derecho de hacer SELECT en la tabla BANCOS y también le permite a MARCELA otorgar ese derecho a otros usuarios.

GRANT R_CONTABILIDAD TO SILVIA WITH ADMIN OPTION;

SYSDBA le otorgó a SILVIA el rol R_CONTABILIDAD y también le permite asignar ese rol a otros usuarios.

GRANT RDB$ADMIN TO FATIMA

SYSDBA le otorgó a FATIMA el rol RDB$ADMIN el cual le permite a FATIMA tener todos los derechos sobre todos los objetos de esta Base de Datos. En otras palabras: FATIMA es exactamente igual que SYSDBA en esta Base de Datos, puede hacer todo lo que SYSDBA puede hacer.

GRANT R_CONTABILIDAD TO MARCELA WITH ADMIN OPTION GRANTED BY FATIMA;

SYSDBA le otorgó a MARCELA el rol R_CONTABILIDAD y también le permite otorgar ese rol a otros usuarios, pero lo hizo en nombre de FATIMA. ¿Por qué en nombre de FATIMA? Para que FATIMA pueda, si lo desea, quitarle ese rol a MARCELA.

 Conectado como MARCELA:

GRANT SELECT ON BANCOS TO DIANA;

MARCELA tiene el derecho de otorgar el SELECT a la tabla BANCOS, así que se lo otorga a DIANA. Desde ahora ambas (MARCELA y DIANA) pueden hacer SELECT a la tabla BANCOS.

GRANT INSERT ON BANCOS TO DIANA;

Esto falla y será rechazado por el Firebird porque MARCELA no tiene el derecho de otorgar INSERT en la tabla BANCOS. Ella tiene el derecho de otorgar SELECT en la tabla BANCOS pero no tiene el derecho de otorgar INSERT en la tabla BANCOS y por lo tanto no se le permitirá hacerlo.

GRANT ALL ON BANCOS TO DIANA;

Esto falla por la misma razón: MARCELA solamente puede otorgar el derecho de SELECT y ninguno más. Si intenta otorgar otro derecho entonces será rechazada. Aquí intentó otorgar todos los derechos y fue rechazada.

GRANT SELECT ON PRODUCTOS TO DIANA;

Esto también fallará, porque MARCELA puede otorgar el derecho de hacer SELECT en la tabla BANCOS, pero no puede otorgar el derecho de SELECT en la tabla PRODUCTOS, nunca se le otorgó ese derecho y ella no puede otorgar un derecho que no posee.

REVOKE SELECT ON BANCOS FROM DIANA;

MARCELA le había otorgado el derecho de hacer SELECT en la tabla BANCOS a DIANA, así que MARCELA puede quitarle ese derecho. Desde este momento DIANA ya no podrá hacer SELECT a la tabla BANCOS.

Conectado como SILVIA

GRANT R_CONTABILIDAD TO DIANA;

SILVIA le otorgó el rol R_CONTABILIDAD a DIANA, desde ahora DIANA ya es miembro de ese rol.

GRANT R_CONTABILIDAD TO MIRTHA WITH ADMIN OPTION;

SILVIA le otorgó el rol R_CONTABILIDAD a MIRTHA y también le dió el derecho de asignar ese rol a otros usuarios.

Conectado como FATIMA

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto falla, no se le permite a FATIMA otorgarle derechos sobre la tabla PRODUCTOS a MIRTHA. ¿Y por qué falla, acaso FATIMA no posee el rol RDB$ADMIN? Sí, pero no lo usó en el momento de conectarse, por eso falló el GRANT.

Conectado como FATIMA y usando el rol RDB$ADMIN

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto sí funciona ok porque ahora FATIMA se conectó usando el rol RDB$ADMIN y por lo tanto en esta Base de Datos tiene exactamente los mismos derechos que el usuario SYSDBA.

Artículos relacionados:

Agregando, modificando y borrando usuarios

El índice del blog Firebird21

Un archivo de lotes para mantenimiento de la Base de Datos

2 comentarios

Por el uso (y abuso) diario las bases de datos normalmente van perdiendo performance, volviéndose más lentas todas las operaciones que se realizan en ellas. Una forma de mantener a la Base de Datos saludable es a través del siguiente archivo .BAT

CLS

@ECHO OFF

ECHO IMPORTANTE: El nombre de la Base de Datos NO DEBE TENER LA EXTENSION para que este archivo .BAT funcione bien.

@ECHO ON

SET ISC_USER=SYSDBA

SET ISC_PASSWORD=masterkey

SET CarpetaFirebird=C:\Program Files\Firebird\Firebird_2_5\bin\

SET CarpetaBaseDatos=E:\SQL\DATABASES\

SET CarpetaBackup=E:\SQL\BACKUPS\

SET NombreBaseDatos=INTEGRAL

C:

CD "%CarpetaFirebird%"

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -shut single -force 0

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -validate -full -ignore

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -mend -ignore

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -online

IF EXIST "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG" DEL "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG"

GBAK "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" "%CarpetaBackup%%NombreBaseDatos%.FBK" -e -g -ig -l -nt -b -v -y "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG"

IF EXIST "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG" DEL "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG"

IF EXIST "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB" DEL "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB"

GBAK "%CarpetaBackup%%NombreBaseDatos%.FBK" "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB" -o -r -v -REP -y "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG"

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -shut -force 0

E:

IF EXIST "%NombreBaseDatos%_ANTERIOR.FDB" DEL "%NombreBaseDatos%_ANTERIOR.FDB"

RENAME "%NombreBaseDatos%.FDB" "%NombreBaseDatos%_ANTERIOR.FDB"

IF EXIST "%NombreBaseDatos%.FDB" DEL "%NombreBaseDatos%.FDB"

RENAME "%NombreBaseDatos%_NEW.FDB" "%NombreBaseDatos%.FDB"

C:

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -online

@PAUSE

Como seguramente ya sabes, los archivos .BAT son los archivos de lotes (batch, en inglés) del antiguo Sistema Operativo D.O.S. y que el Windows ha heredado. En estos archivos .BAT puedes escribir varios comandos, los cuales se ejecutarán en el mismo orden establecido.

Este archivo .BAT realiza las siguientes tareas:

  1. Borra la pantalla
  2. Muestra un mensaje al usuario
  3. Establece las variables de entorno. Son todas las que empiezan con la palabra SET. Fíjate que para no estar escribiendo el nombre del usuario y su password en cada comando GFIX y GBAK que hay más abajo, se asignaron sus valores a dos variables. No es obligatorio hacer así, pero se escribe menos.
  4. El nombre de la Base de Datos debe escribirse sin la extensión (o sea, sin el .FDB). Por eso, aunque el nombre real de la Base de Datos usada en este ejemplo es INTEGRAL.FDB en la variable se escribió solamente INTEGRAL
  5. El comando GFIX -shut single -force 0 permite que solamente el usuario SYSDBA pueda estar conectado a la Base de Datos, nadie más. El -force 0 cerrará inmediatamente todas las conexiones. ¿Qué implica eso? Que este archivo .BAT solamente debe ejecutarse cuando nadie está usando la Base de Datos. De lo contrario, los usuarios que estén conectados perderán la conexión y posiblemente el trabajo que estaban haciendo.
  6. Los siguientes dos comandos GFIX sirven para validar y corregir errores en la Base de Datos
  7. El cuarto comando GFIX vuelve a permitir que otros usuarios se conecten a la Base de Datos
  8. Antes de realizar el backup se verifica si existe el archivo LOG (en los archivos de LOG se guarda información con respecto a la ejecución de un comando). Si existe, se lo borra
  9. Se realiza el backup y las tareas que realizó se guardan en un archivo de LOG, que es un archivo de texto que puede ser revisado en cualquier momento
  10. Idénticamente, antes de restaurar el backup se verifica si existen su archivo de LOG y un archivo con el mismo nombre del que será restaurado. Si existen, se los borra
  11. Se realiza la restauración del backup
  12. Nuevamente se desconecta a todos los usuarios. Esto es necesario para que el nombre de la Base de Datos pueda ser cambiado, si alguien la estuviera usando, su nombre no podría cambiarse
  13. Se cambian los nombres de dos archivos
  14. Y finalmente, se vuelve a permitir que todos los usuarios puedan conectarse a la Base de Datos

Si en el punto 14. obtienes un error, no te preocupes, significa que todos ya podían conectarse y le volviste a pedir que todos se pudieran conectar.

Algunos puntos importantes a recordar:

  1. Este archivo .BAT debe estar en la computadora del Servidor, no funcionará remotamente
  2. Debes crear un archivo de texto con la extensión .BAT para que funcione. Para mayor facilidad, puedes colocar un acceso directo en el escritorio.
  3. Si ejecutas este archivo .BAT periódicamente, te asegurarás que tu Base de Datos siempre se encuentre en buen estado y que todas las operaciones en ella sean lo más rápidas posibles
  4. Debes ejecutarlo solamente cuando estás seguro que nadie está conectado a la Base de Datos, porque este archivo .BAT desconectará automáticamente a todos quienes estén conectados y eso les podría ocasionar pérdida de sus trabajos
  5. La carpeta BACKUPS debe existir, si no existe obtendrás un mensaje de error y este .BAT no cumplirá su misión
  6. Debes establecer los valores de las variables de entorno (las que empiezan con SET) acordemente a tu situación particular. Las que ves aquí son solamente un ejemplo
  7. Antes de renombrar los archivos (casi al final del .BAT) se cambia a la unidad E:, porque en esa unidad tengo yo mis bases de datos. En tu caso, debes colocar allí la letra que corresponda (C:, D:, E:, F:, la que sea)

Artículo relacionado:

El índice del blog Firebird21