sin mensaje de "tablespace altered" (Oracle 9i)

estuve ejecutando ahora la siguiente instrucción para crear mas datafiles... pero no obtuve ningún mensaje...

SQL> ALTER TABLESPACE TS_DATA_G ADD DATAFILE '/oracle/oradata/DB/index/TS_DATA_G_04.dbf' SIZE 1000M AUTOEXTEND OFF;

... y la confirmación de tablespace altered??? OK, chequeo el siguiente query que tengo para minitorear espacio... y nada... no se ve ningún cambio en el tablespace...

SQL> Select A.Tablespace_Name, Total, Libre, Round(Libre/Total,2)*100 Porc_Libre, to_char(SYSDATE,'dd/MM/yyyy HH24:mi:ss') curTimeFrom (Select Tablespace_Name, Sum(Bytes)/(1024*1024) Total From DBA_DATA_FILES Group By Tablespace_Name ) A, (Select Tablespace_Name, Sum(Bytes)/(1024*1024) lIBRE From DBA_FREE_SPACE Group By Tablespace_Name ) BWhere A.Tablespace_Name = B.Tablespace_Name

el tamaña es el mísmo que tenía antes...
chequeamos si se creó el datafile y....

SQL> r 1 SELECT name, bytes/1024/1024 Tam_Mb 2* FROM v$datafile

no aparecio!!... nada, por último chequeamos el alert.log y nada... la instrucción no aparece... pues nada... ejecutemosla de nuevo... el resultado...

SQL> ALTER TABLESPACE TS_DATA_G ADD DATAFILE '/oracle/oradata/DB/index/TS_DATA_G_04.dbf' SIZE 1000M AUTOEXTEND OFF;
Tablespace altered.

??? bueno... guardemoslo en los archivos X... jejeje

¿Que está mal con esta instrucción? (Oracle 9i)

estoy tratando de agregar un nuevo datafile a mi base de datos con la siguiente instrucción, pero me da un mensaje de error al momento de ejecutar:

ALTER TABLESPACE TS_DATA_M ADD DATAFILE '/oracle/oradata/DB/index/TS_DATA_M_01.dbf' AUTOEXTEND OFF SIZE 1000 M *ERROR at line 1:ORA-00933: SQL command not properly ended

en www.ss64.com la sintaxis me decia:

ALTER TABLESPACE
Change the properties of a tablespace.
Syntax:
ALTER TABLESPACE tablespace_name option
options: The option used with this command can be any one of the following
ADD {TEMPFILEDATAFILE} 'filespec' [AUTOEXTEND OFF] SIZE int {KM}

Entonces que está mal??... despues de 30 minutos reviso la documentación de oracle en la página:
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_33a.htm#2093898
o sorpresa... mirando los ejemplos de sentencias observo que el orden de las clausulas AUTOEXTEND Y SIZE están al revés. Cambio el orden de las clausulas así, y el resultado es el siguiente:

ALTER TABLESPACE TS_DATA_M ADD DATAFILE '/oracle/oradata/DB/index/TS_DATA_M_03.dbf' SIZE 1000M AUTOEXTEND OFF
Tablespace altered.

por fin!!... bueno, ya saben... como pueden perder el tiempo en pequeñeces... espero recuerden el dato y no les pase.

Esquemas de contingencia para SQL Server. I Parte.

Una de las primeras labores encargadas como DBA en la empresa donde me encuentro laborando ha sido la implantación de un esquema de contingencia para asegurar una perdida mínima de datos al momento de una posible caida.

Generalmente se pensaria en implementar LogShipping... en un ambiente normal... pero en ambientes que tienen una álta restricción de puertos podemos vernos envueltos en una situación de 'escanear puertos' para concluir que puertos debe usar el LoShipping. En las siguientes entregas observaran un método de 'LogShipping Casero' que puede usar 2 técnicas: copia de archivos por Red y aplicación de Transaction Logs ó Lectura de Transactión Logs por medio de una unidad de red y aplicación directa en el servidor de contingencia.

Pero bueno... me fui a fondo con el tema. Primero un poco de fundamentos para ver de que estamos hablando y que me estaban pidiendo como DBA.

En la actualidad me encuentro administrando bases de datos SQL Server 2000 2005 y Oracle 9i (Próximamente 10g en RAC.... alguien tiene un manual para dummies... =( ). Para bases de datos Oracle como SQL Server existe un esquema de contingencia basado en copiar log de transacciones o archives en el caso de Oracle... el concepto es el mismo... el motor de base de datos lleva un registro de las operaciones realizadas sobre las bases de datos y son almacenadas en un log que en el caso de SQL Server es un archivo transaction log y en el caso de Oracle son los archivos archive que son vaciados de los redo logs. Bueno, la idea con la contingencia es aplicar estos archivos de log de transacciones en una base de datos alterna. Obviamente estabas bases de datos tienen que ser extraidas de la base de datos original... es decir, le debemos sacar un backup a la base de datos a la cual le vamos a implantar una contingencia.

Para organizar el tema realizaremos un checklist de lo que tenemos que hacer... a ver si vamos desenredando todo esto:

1. Tener un servidor al cual le queremos sacar contingencia (jejeje)
2. Preparar el servidor de producción para que pueda retroalimentar la contingencia (no me digan que la base de datos esta en modo recovery simple...)
   
3. Contar con un servidor que nos sirva de contingencia e idealmente en el caso de SQL Server que tenga el mismo Service Pack.
4. Sacar un full backup de la base de datos del ambiente de producción.
5. Restaurar el full backup en modo read only.
6. Definir frecuencia de actualización de contingencia.
7. Implantar scripts de aplicaciòn de transaction log en contingencia.
8. Monitoreo de nuestra contingencia.

Bueno, como el blog está empezando realmente es con ésta publicación no habran muchas lecturas antes de la siguiente publicación. Espero esto les sirva. si alguien me puede colaborar con lo del logo de creattive commons y todo esto les agradezco...

Espero la próxima entrega sea en 8 dias. Bye.

Para obtener la lista de usuarios con privilegios de adminstraciòn en SQL Server 2000 se usa la vista sysxlogins. Pero no he obtenido su equivalente en SQL Server 2005.