Qmail ya es de código libre
Una de las quejas principales a la hora de adoptar qmail como nuestro gestor de correo era que su autor, D.J. Bernstein no permitía la modificación del código y eso impedía la evolución de esta sólida solución de tratamiento de correo ( también había quien decía que qmail estaba tan bien que no hacían falta modificaciones... ). A partir de ya, D.J. Bernstein a puesto a disposición pública el código de qmail, tal y como anuncia en http://cr.yp.to/qmail/dist.html . La comunidad de usuarios avanzados de qmail ya se está moviendo para dar de alta el proyecto qmail en sourceforge.
Oracle 11g and Ubuntu 7.10 on the road
Tan fácil como seguir esta receta
Al cabo de 2 horas:
SQL> select INSTANCE_NAME,HOST_NAME,PLATFORM_ID,
PLATFORM_NAME,VERSION,DATABASE_STATUS
from v$instance,v$database;
INSTANCE_NAME
----------------
HOST_NAME PLATFORM_ID
---------------------------------------------------------------- -----------
PLATFORM_NAME
--------------------------------------------------------------------------------
VERSION DATABASE_STATUS
----------------- -----------------
dbm11g
nebuchadnezzar 10
Linux IA (32-bit)
11.1.0.6.0 ACTIVE
SQL> !cat /etc/issue
Ubuntu 7.10 \n \l
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL>
Blogger robots had a bad day, and considered this blog as spam blog, blocking it ¿? After some days of wait, it's availabe again
"
Hello,
Your blog has been reviewed, verified, and cleared for regular use so that
it will no longer appear as potential spam. If you sign out of Blogger and
sign back in again, you should be able to post as normal. Thanks for your
patience, and we apologize for any inconvenience this has caused.
Sincerely,
The Blogger Team
"
Integrating bacula and Oracle RMAN. Open draft
The idea is to define the pieces ( and combinations of them ), scenarios, tools and procedures to integrate the bacula backup solution with the Oracle Rman utility. Please, feel free to collaborate on this draft, use the comments and I will update the post with your contribution and credit. Once we'll have a good base, I will begin to develop the solution ( more hands are wellcome :D ).
Oracle releases
9i and 10g . When something described below will be only applicable for one of this releases will be informed accordingly.
Assumptions
Rman will not be able to talk 'directly' to tape device using bacula. The primary destination of rman backup pieces will be disk ( see below Rman backup set to disk point )
Pieces and scenarios
- Rman binaries
The rman binaries can be located at the same host where resides the databases to be protected or in a different host than the databases to be protected ( could be the same host as the bacula director ).
In any case, bacula must be able to execute scripts on the host where rman binaries are installed. Personally I think that running rman in the same host where is running bacula seems a good approach, 'cause we can store rman backup result locally in the machine where bacula is running and from there, directly to tape. I'm trying to minimize the recover period and at same time, a good availability in case of restore ( we can hold on disk always the last rman backup done )
- Rman catalog
rman backup catalog stored in the database control file to be backed up. Control files will grow ( and depending on retention, can grow a lot ). Rman takes care to backup controlfiles.
rman backup catalog stored in dedicated oracle database. Here an inexpensive linux machine with Oracle XE can fit very well, being able to use an Oracle database as rman catalog at no extra cost ( 4 GB of user data gives a lot of space for rman catalog data ). An extra bacula backup job must be done to backup this new database/host after all other rman backups has been done. Take in mind that is possible to catalog an rman backup.
- Rman backup set to disk
We can storage the rman backup set in local storage where rman is executed, or in remote storage disk via network protocols ( nfs, iscsi... ). IMMO we need to minimize the data 'migration' between hosts to provide a good backup timing.
- Types of backups
The idea is to create a set of jobs on both bacula and rman to Full, incremental and cumulative. Both rman and bacula support them and we can call the aproppiate rman script depending on the backup type to perform. Join retention policies.
- Type of database
Oracle monoinstance. Can be some databases in a multihomed host.
Oracle RAC
Oracle Dataguard ( as product or as concept ). We can make a backup of the standby database and if we are using rman catalog, we can clean archivelogs from both instances.
- Database mode
Archivelog or no archivelog. In archivelog we can create rman policies to backup to disk archivelogs several times a day, and delete the archives that have been at least N times backed up, to mantain under control the space in the archivelog destinations. For the 'at least N times backed up' we need to assure that archivelogs backed up has been moved to tape. We can take a look to the rman instructions to manage valid backups inside is own catalog.
In no archivelog mode, we can use rman but database will must just to be mounted.
- Bacula
Pre jobs and after jobs scripts using bacula environment variables to merge with rman scripts ( coherence and reference for the admin ).
- rman backup optimizations
Avoid to backup Oracle databases with the begin/end backup, this freezes the datafiles headers but oracle writes database blocks into them and then you're copying the files in inconsistent state. For this cause Oracle writes the entire block to the redo files when it tries to write a block of a tablespace that is maked as 'backup' ( if is a intensive writing database you will have a lot of switchlogs and archiving load ) Prior to 10G, it's necessary to put each tablespace in backup mode, in 10G we can use 'alter database begin backup' that do the job for us ( then we don't need to take care about new datafiles added over time ).Of course, we need to backup control files and other important Oracle files 'manually'.
Another point against this type of backup, If you have created a datafile of 2 GB but never used more than 25% of it you're backing up 2GB ( the entire file ).
Rman takes care of what datafiles/controlfiles/archives and parameter file to backup.
In 9i rman only reads blocks from datafiles under high-watermark ( in the previous example about the 2 Gb datafile and the 25% used, rman only will backup the 25% of the file )
In 10g rman is able to backup ONLY the used blocks, not the empty ones, even if them are under the high-watermark.
On RAC environments we can instruct rman to use a connection channel for each node in the cluster, paralleling the backup/restore process, but in 9i if one of this channels goes down, the backup/recover process gets broken. In 10g rman can manage this and use only the surviving nodes.
In 10g rman can compress the result 'on fly' ( with the ability to backup only used blocks and the compression method, we end with very little backed up data )
In 10g we can use a new feature called 'Block Change Tracking' where we instruct Oracle about a special file where it tracks the changed blocks ( only once, not each time the same block changes ), this tracking is used by rman to backup only the changed blocks without needing to read each datafile in the search of them. This tracking can be reseted when necessary ( when performing full backups, for example ).
The temporary datafiles from locally managed temporary tablespaces are not backed up. In 9i, after restore the dba must recreate them. In 10g rman is able to recreate this datafiles accordingly.
Oracle está desarrollando un nuevo filesystem para GNU/Linux
Btrfs, así se llama un nuevo filesystem que está desarrollando Oracle bajo licencia GPL. Aún está en fase muy temprana de desarrollo y es poco funcional, lo que se supone que cambiará según se vaya adelantando el desarrollo. Esta es una lista de las características que ofrecerá cuando se considere estable y entre en producción:
- Almacenamiento para ficheros muy grandes (264 tamaño maximo fichero)
- Eficiencia en el almacenamiento de ficheros pequeños
- Eficiencia en el almacenamiento con directorios indexados
- Asignación dinámica de i-nodos
- Snapshots modificables (!)
- Subvolúmenes (!)
- Mirroring y striping a nivel de objeto (!)
- Checksums en datos y metadatos
- Fuerte integracion con el mapeador de devices para soporte de múltiples devices
- Verificación del filesystem en caliente
- Verificación muy rápida del filesystem en frío
- Backups incrementales eficientes (!) y mirroring de FS
Quizá sea una especie de mix para acercar ASM a un filesystem de Linux, me hace pensar eso lo de 'subvolúmenes' y lo de mirroring y striping a nivel de objeto ( eso me hace babear! ). Si no me equivoco, el striping a nivel de objeto + el soporte de multiples devices + la asignación dinámica de inodos permitiría que el propio sistema fuera capaz de detectar objetos que son accedidos constantemente y moverlos de manera que se reparta la carga de I/O en varios devices, en caliente y de forma transparente.
Lo de backups incrementales eficientes también tiene su punto, ya que si el filesystem es capaz de decirnos a priori que es lo que se ha modificado - y si eso significa que marcará ( ¿bitmaps? ) solo los bloques que hayan cambiado, no todo el fichero - tendremos una mejora espectacular en los tiempos de backup.
Si todo lo anterior es cierto, me da la sensación que tendremos un filesystem con pinceladas de lo que ya tenemos en base de datos Oracle : gestión local/automática de espacio, Subvolumenes + multidevice + strip de objetos ( conceptos de tablespaces y de ASM ?), backups 'detallistas' ( conceptos de RMAN? )
Fuentes: Home del proyecto Btrfs
Voy a preguntarles a ver si me dan más info sobre esas features, ya iré contando ( sobre todo preguntaré que coñ* significa Btr )
Impresiones de usuarios de DELL con Ubuntu preinstalado
Ya hay reportes de usuarios que se han decidido por la compra de una computadora DELL con Ubuntu preinstalado ( Fuente : theinquirer )
http://ubuntuforums.org/showthread.php?p=2764621#post2764621
Hay que hacer notar que Dell ofrece 2 soluciones basadas en software libre, Ubuntu y FreeDos
http://www.dell.com/content/topics/global.aspx/alliances/en/linux?c=us&cs=555&l=en&s=biz
oracm fails on Red Hat 4
( sorry for my English, is not my first language. Sometimes is bad, sometimes is worse :P )
I've seen several people having this problem - as I had before -, here comes one explanation and a workaround
Oracle RAC 9iR2 Cluster Manager ( oracm ) installed on RedHat 4 x86_64 ( AMD64 / EM64T ). Starting oracm on first node shows only one oracm process and starting oracm on the second one dumps both oracm process on each node tracing dumps on $ORACLE_HOME/oracm/log/cm.log and the process dies.
Cause
oracm and all other oracle binaries for GNU/Linux on 9i uses the 'old kernel API' ( 2.4 series ) and now 2.6 kernels offers new improvements ( glibc, modules, etc... ) then the start up oracm script - $ORACLE_HOME/oracm/bin/ocmstart.sh - contains a verification condition to apply corrections in the execution environment to force the use of the correct libraries and avoid malfunctions on executables that only understand the old way:
$ORACLE_HOME/oracm/bin/ocmstart.sh verification:"(...)
#
# 3. Startup
#
#check if RH3.0, then set LD_ASSUME_KERNEL for starting CM.
if [ -e /etc/redhat-release ]
then
version=`rpm -qf /etc/redhat-release --queryformat "%{VERSION}\n"`
if [ $version == 3AS -o $version == 3ES ]
then
LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL
fi
fi
(...)
"
that's OK if we are running RedHat 3 but under RedHat 4 this condition returns false miserably :), then the LD_ASSUME_KERNEL correction is not applied and oracm crashes when trying to create new threads.
Possible Solution
You can modify the condition to return TRUE on RedHat 3 or RedHat 4 or simply, 'cause you know where are you running, force the declaration of LD_ASSUME_KERNEL=2.4.19 at the beginning of the ocmstart.sh script ( on all nodes )"
(...)
#
# 1. Configuration
#
export LD_ASSUME_KERNEL=2.4.19
if test -z "$ORACLE_HOME"
then
echo 'ocmstart.sh: Error: environment variable ORACLE_HOME is not set'
(...)
"
Remember that you've modified this script manually and check the content after application of any patch related to Oracle Cluster Manager. Some of them could overwrite this script and the forced export LD_ASSUME_KERNEL=2.4.19 should be inserted again
After this changes you will be able to start oracm correctly on all nodes and see how each one is registered on the cluster software layer
Good explanations about LD_ASSUME_KERNEL
http://developer.novell.com/wiki/index.php/LD_ASSUME_KERNEL
http://people.redhat.com/drepper/assumekernel.html
