lunes, 28 de abril de 2008

Configurar DNS en SUN SOLARIS 10

Se me presento el problema que despues de instalar solaris 10 en mi VMWARE no podia navegar por internet. No estar rolviendo nombres porque por IPs si podia acceder a las paginas.
¿Cómo solucionarlo?
Veamos el contenido del siguiente articulo:
1) You need to create or edit the file /etc/resolv.conf

# cat resolv.conf
domainname corp.petrobras.biz
nameserver 10.26.42.1
nameserver 10.2.56.33
nameserver 10.2.56.34
search corp.petrobras.biz,engenharia.petrobras.com.br,petrobras.com.br
#
Where :
a) domainname => name of domain
b) nameserver => you can put until 3 DNS servers (IP)
c) search (optional) => used to complete a host name, when you use just the first name to resolve hosts.
Ex: When you put test, the system will search test.corp.petrobras.biz, test.engenharia.petrobras.com.br and so on.

2) You must edit the file /etc/nsswitch.conf and include the word "dns" after "files" in the line shown below . So the system will resolve host using the file /etc/hosts and /etc/resolv.conf in this order.

...
hosts: files dns
...

Good luck

domingo, 20 de abril de 2008

TKPROF y Tracefile

Es necesario usar dos parametros de la base de datos, para realizar el trace de las sesiones:

  • TIMED_STATISTICS : que debe ser TRUE para usar estadisticas.

  • USER_DUMP_DEST : donde se establece el directorio donde el server escribirá los tracefiles.
Existe un parámetro relacionado a este último:
  • MAX_DUMP_FILE_SIZE : que permite establecer el tamaño máximo del tracefile, lo valores válidos para este parámetro son UNLIMITED, o un número seguido de una M o K para establecer el tamaño en Megabytes o KBytes como tamaño máximo a ocupar. De solo tener un número (sin la letra M o K) se considera que está especificándose el número máximo de bloques del SO que el archivo puede ocupar.


¿Cómo habilitarlo?



Puede habilitarse de las siguientes maneras:

  1. SQL*Plus: SQL> alter session set sql_trace true;

  2. PL/SQL: dbms_session.set_sql_trace(TRUE);

  3. DBA: SQL> execute sys.dbms_system.set_sql_trace_in_session(sid,serial#,TRUE); donde sid y serial# provienen de la consulta Select username, sid, serial#, machine from v$session;

  4. PRO*C: EXEC SQL ALTER SESSION SET SQL_TRACE TRUE;


¿Cómo leo los tracefiles?



Usando TKPROF puedo leer los tracefiles generando a partir de ellos un archivo de texto con el detalle. La sintaxis del comando es la siguiente



TKPROF tracefile exportfile [explain=username/password] [table= …] [print= ] [insert= ] [sys= ] [record=..] [sort= ]



Y un ejemplo,

tkprof ora_12345.trc output.txt explain=scott/tiger

Fuentes:

martes, 15 de abril de 2008

Aplicaciones J2EE - iSQLPlus

He instalado el dbms Oracle 11g en la maquina virtual y estas son las direcciones desde las que se puede acceder al iSqlPlus.

Se han desplegado las siguientes aplicaciones J2EE y se puede acceder a ellas en las siguientes direcciones URL.

URL de iSQL*Plus:
http://VMWARE-ORACLE:5560/isqlplus

URL de DBA de iSQL*Plus:
http://VMWARE-ORACLE:5560/isqlplus/dba

URL Enterprise Manager 10g Database Control

lunes, 14 de abril de 2008

EXCELENTE BLOG con las tareas de un DBA

http://delfinonunez.wordpress.com/page/4/


Monitoreo de espacio en tablespace


20 Julio, 2006 by delfinonunez

Una de las tareas de un DBA es monitorear el espacio de la base de datos, debido a que esto consume mucho tiempo cuando se tienen varias DB’s es bueno automatizar tareas repetitivas y tediosas. Una manera de realizar la automatización del monitoreo de DB’s en UNIX es por medio del crontab, el siguiente es un ejemplo de como usar el crontab para monitorear los tablespaces.



  • Los siguientes scripts permiten obtener el espacio utilizado y libre de los tablespaces, uno lo obtiene en base el porcentaje libre de espacio y el otro obtiene el espacio en base a los MB libres. Estos scripts reciben dos parametros: &1 .- es el directorio y archivo donde se va a crear el reporte(spool) y &2 que es el limite ya sea porcentaje (99) o Mb(99999).


tablespace_size_pct.sql



SET line 132
SET pages 50
SET pause OFF
SET feedback OFF
SET echo OFF
SET verify OFF

COLUMN c1 heading "Tablespace|Name"
COLUMN c2 heading "File|Count"
COLUMN c3 heading "Allocated|in MB"
COLUMN c4 heading "Used|in MB"
COLUMN c5 heading "%|free" format 99.99
COLUMN c6 heading "Free|in MB"
COLUMN c7 heading "%|used" format 99.99

spool &1;

SELECT c1,ROUND(c3,2) c3,ROUND(c4,2) c4,ROUND(c6,2) c6,ROUND(c7,2) c7,ROUND(c5,2) c5,c2
FROM(
SELECT NVL (b.tablespace_name, NVL (a.tablespace_name, 'UNKOWN')) c1,
mbytes_alloc c3, mbytes_alloc - NVL (mbytes_free, 0) c4,
NVL (mbytes_free, 0) c6,
((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100 c7,
100
- (((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100) c5,
b.files c2
FROM (SELECT SUM (BYTES) / 1024 / 1024 mbytes_free, tablespace_name
FROM SYS.dba_free_space
GROUP BY tablespace_name) a,
(SELECT SUM (BYTES) / 1024 / 1024 mbytes_alloc, tablespace_name,
COUNT (file_name) files
FROM SYS.dba_data_files
GROUP BY tablespace_name) b
WHERE a.tablespace_name(+) = b.tablespace_name
UNION ALL
SELECT f.tablespace_name,
SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2)
) "total MB",
SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) "Used MB",
SUM (ROUND ( ((f.bytes_free + f.bytes_used) - NVL (p.bytes_used, 0)
)
/ 1024
/ 1024,
2
)
) "Free MB",
(SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
100
- (SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
COUNT (d.file_name)
FROM SYS.v_$temp_space_header f,
dba_temp_files d,
SYS.v_$temp_extent_pool p
WHERE f.tablespace_name(+) = d.tablespace_name AND f.file_id(+) = d.file_id
AND p.file_id(+) = d.file_id
GROUP BY f.tablespace_name)
WHERE C1 NOT IN('USERS')
AND C7 >= &2
ORDER BY c6 ASC;

spool off;
exit;

tablespace_size_spc.sql



SET line 132
SET pages 50
SET pause OFF
SET feedback OFF
SET echo OFF
SET verify OFF

COLUMN c1 heading "Tablespace|Name"
COLUMN c2 heading "File|Count"
COLUMN c3 heading "Allocated|in MB"
COLUMN c4 heading "Used|in MB"
COLUMN c5 heading "%|free" format 99.99
COLUMN c6 heading "Free|in MB"
COLUMN c7 heading "%|used" format 99.99

spool &1;

SELECT c1,ROUND(c3,2) c3,ROUND(c4,2) c4,ROUND(c6,2) c6,ROUND(c7,2) c7,ROUND(c5,2) c5,c2
FROM(
SELECT NVL (b.tablespace_name, NVL (a.tablespace_name, 'UNKOWN')) c1,
mbytes_alloc c3, mbytes_alloc - NVL (mbytes_free, 0) c4,
NVL (mbytes_free, 0) c6,
((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100 c7,
100
- (((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100) c5,
b.files c2
FROM (SELECT SUM (BYTES) / 1024 / 1024 mbytes_free, tablespace_name
FROM SYS.dba_free_space
GROUP BY tablespace_name) a,
(SELECT SUM (BYTES) / 1024 / 1024 mbytes_alloc, tablespace_name,
COUNT (file_name) files
FROM SYS.dba_data_files
GROUP BY tablespace_name) b
WHERE a.tablespace_name(+) = b.tablespace_name
UNION ALL
SELECT f.tablespace_name,
SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2)
) "total MB",
SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) "Used MB",
SUM (ROUND ( ((f.bytes_free + f.bytes_used) - NVL (p.bytes_used, 0)
)
/ 1024
/ 1024,
2
)
) "Free MB",
(SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
100
- (SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
COUNT (d.file_name)
FROM SYS.v_$temp_space_header f,
dba_temp_files d,
SYS.v_$temp_extent_pool p
WHERE f.tablespace_name(+) = d.tablespace_name AND f.file_id(+) = d.file_id
AND p.file_id(+) = d.file_id
GROUP BY f.tablespace_name)
WHERE C1 NOT IN('USERS')
AND C6 <= &2
ORDER BY c6 ASC;

SPOOL OFF;
exit;


  • Con el siguiente script podemos ejecutar los SQL scripts anteriores dependiendo los parametros que le enviemos. La forma de ejecutar el script es la siguiente:

    • Para reportar en base al espacio, despues del parametro -d debe seguir el nombre de la instancia (SID), despues del parametro -s sigue la cantidad minima que puede tener libre un tablespace:

      • tbs_monitor.ksh -d DEVELOPMENT -s 500

        Connected.
        Instance: DEVELOPMENT
        Tablespaces with usage < 500 MB.

        Tablespace Allocated Used Free % % File
        Name in MB in MB in MB used free Count
        ------------------------------ ---------- ---------- ---------- ------ ------ ----------
        SYSTEM 600 403.13 196.88 67.19 32.81 1
        IDX1 11741 11363 378 96.78 3.22 3




    • Para reportar en base al porcentaje, en lugar de utilizar el parametro -s se utiliza el parametro -p seguido del porcentaje maximo que puede tener un tablespace:

      • tbs_monitor.ksh -d DEVELOPMENT -p 80




    • Connected.
      Instance: DEVELOPMENT
      Tablespaces with usage >= 80%.

      Tablespace Allocated Used Free % % File
      Name in MB in MB in MB used free Count
      ------------------------------ ---------- ---------- ---------- ------ ------ ----------
      IDX1 11741 11363 378 96.78 3.22 3
      IDX2 3201 2696 505 84.22 15.78 2
      IDX5 18385 17394 991 94.61 5.39 3
      DATA02 13312 11520.13 1791.88 86.54 13.46 2
      DATA03 33797 31709.13 2087.88 93.82 6.18 4
      DATA01 56629 46606.38 10022.63 82.30 17.70 7





Basic RMAN Backup

Lets do a real simple backup using RMAN that writes it's output to a local file instead of the tape subsystem just to see how it works. In this case, we've got our database (SID: cuddle) up and running.

[oracle@vixen oracle]$ echo $ORACLE_SID
cuddle
[oracle@vixen oracle]$ rman nocatalog target /
Recovery Manager: Release 10.1.0.2.0 - 64bit Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
connected to target database: CUDDLE (DBID=251015092)
using target database controlfile instead of recovery catalog
RMAN> backup database;
Starting backup at 02-NOV-04
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=162 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u02/oradata/cuddle/system01.dbf
input datafile fno=00003 name=/u02/oradata/cuddle/sysaux01.dbf
input datafile fno=00002 name=/u02/oradata/cuddle/undotbs01.dbf
input datafile fno=00004 name=/u02/oradata/cuddle/users01.dbf
channel ORA_DISK_1: starting piece 1 at 02-NOV-04
channel ORA_DISK_1: finished piece 1 at 02-NOV-04
piece handle=/u01/app/oracle/product/10.1.0/db_1/dbs/05g438u6_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 02-NOV-04
channel ORA_DISK_1: finished piece 1 at 02-NOV-04
piece handle=/u01/app/oracle/product/10.1.0/db_1/dbs/06g4391f_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 02-NOV-04
RMAN> quit
Recovery Manager complete.
[oracle@vixen oracle]$


This is the most basic backup you can do with RMAN. We didn't tell RMAN how or where to backup the database, just simply to do it.
The rman command is passed 2 arguments: the first "nocatalog" tells RMAN that we aren't using a recovery catalog database and the second "target /" is similar to a SQL*Plus connect statement, with information that RMAN requires to connect to the target database. The target is the database we wish to backup.
Notice that RMAN returns some interesting information prior to giving us a prompt. It confirms that RMAN is connected to the target and lists that target. The DBID seen after the target database SID can be very important for later recoveries and it is recommend that you write it down somewhere for future use. RMAN then confirms that because we aren't using a recovery catalog to store backup metadata that it will instead store the data in the target databases control files.
The RMAN command backup database; sends RMAN on its merry way backing up the database. Notice that we didn't tell it where or how to backup the data. By default the backup peices will be placed in the $ORACLE_HOME/dbs directory. This can get very messy since your system PFILES are in there too, and therefore we recommend that you don't use this location for your normal backups.
Two backup peices were created. The first contains the datafiles holding the tablespaces including the undo tablespace. The second backup peice contains the current SPFILE and curent controlfile.
Lets stop and think carefully for just a moment. Now, we've opted to use ARCHIVELOG mode which means we can do hot backups. However, we didn't want the hassle and administrative overhead of maintaining a recovery catalog. So here is the rub: recall that you need a PFILE/SPFILE to start an instance and you need the controlfile to point to all the files to be mounted. If the database were completely destroyed we would certainly need both the SPFILE and the Controlfile to access the backup peices made by RMAN.... but they are inside the backup we just made! Nice little loop of confusion huh? We'll talk about this later, but for now just keep it in mind.

Fuentes:

RMAN - ¿Qué es un SCN?

An SCN in Oracle is nothing more than Oracle's clock: a chronology of changes.

It is this chronology that affords Oracle the ability to perform recovery with exact precision.

There are many types of events that trigger many types of checkpoints. But, for the sake of this discussion consider the global checkpoint triggered by a log switch. Upon this triggering event Oracle "notes" the current SCN. This is the SCN that will be written to the data file headers and their corresponding control file entries once Oracle has written ALL blocks up to and including that SCN to said files. At that point Oracle can assert with 100% certitude that the data file(s) are consistent with respect to that SCN - or simply that change-point in time. This doesn't mean all of the data written is committed or that there aren't blocks in the data files with higher SCNs by the time the checkpoint completes. It only means that Oracle can guarantee all changes, up to and including the checkpoint SCN, are written to the files.

Fuentes:

Using RMAN

SysAdmin's have a definate love/hate relationship with RMAN. Many of us not so jokingly refer to it as the "Recovery Mangler". You love it because its fairly simple and is the only sure-fire way to perform online backups. You hate it because it's often cryptic, and either works or doesn't. Because RMAN couples closely with a backup infastructure there is alot of finger pointing when problems arise between "It's an RMAN issue!" and "No, it's a NetBackup issue!". RMAN causes DBAs and UNIX admins to get too close for comfort and niether generally understands the wholistic view of the interaction properly.

So, why would a sysadmin like RMAN?

  • RMAN can perform online (hot) backups
  • RMAN can allow for partial or complete recovery
  • No fear of incomplete backups
  • DBA initiated backups and recovery without the interaction of the SA
  • Intigration with existing backup infistructure

The problem with backing up Oracle using traditional methods is similar to the problems with backing up filesystems, unless you shutdown the database and perform a cold backup there is no way to know that all the transactions and changes have been written to datafiles. The SGA maintans a huge amount of data in active memory which can cause a problem. It's alittle like editing a configuration file on the system and then halting the system and wondering where your changes went. In order to ensure consistance of the database we need a hot backup method. If we restore a filesystem backup of the database that was taken while Oracle was running we run the risk of lossing database changes at best or having a corrupt database at worst.

Fuentes:

FULL backups in RMAN

INCREMENTAL vs. FULL backups in RMAN

Oracle has made it easy for people to not understand these backups in RMAN.

If you're not using 10g and "true incrementals", just use full. Older versions of RMAN were not much faster because it had to do just as much reading as a full backup (read the whole datafile, backup anything that's changed). They were ONLY designed to save disk/tape speed and/or bandwidth to disk/tape. They certainly didn't speed up recovery.

In 10g, they've FINALLY introduced a "change tracking file" and many other enhancements like incrementally Updated Backups.

So, RMAN started out as a ham fisted tool that caused problems for a lot of people (but did help many who dedicated themselves to it), but has now become much more of an asset to the DBA.

I use RMAN and I am glad I do. But I also use 10g. I still have problems recommending it to people on older versions.

Read through the product docs and you can see what it offers (you'll notice RMAN doesn't have to put your tablespaces in backup mode). It also seems to be a lot easier to use nowadays, but maybe I've just gotten used to it.

Like anything in Oracle, there are lot's of powerful tools and features for you to exploit if you know WHY to. Don't be one of those poor saps that tries to use every feature or tool just hoping that it's the proper way of doing it.


Fuentes:

domingo, 13 de abril de 2008

Flash Recovery Area.

Con la caída del costo de los discos en el mercado, los backups a disco es a menudo mas factible y funcionalmente ventajosos que los tradicionales backups a cinta. Primero, el backup a disco, elimina las restricciones de performance de la escritura en cinta , y segundo, el "time-to-recover" se reduce mediante la eliminación de la necesidad de localizar la cinta y buscar en ella la ubicación correcta desde donde iniciar la operación.

Aprovechando esta tendencia del mercado, RMAN simplifica enormemente los backup basados en soporte de disco con la "Flash Recovery Area". La "Flash Recovery Area" es una única ubicación de storage en un filesystem o en un grupo de discos ASM (Automatic Storage Management) que organiza todos los archivos de recovery y actividades relacionados, para una base de datos Oracle.

Todos los archivos que son necesarios para un recovery completo de una base de datos ante un media failure residen en la Flash Recovery Area, INCLUYENDO control files, archived log files, copias de los data file , y los backups de RMAN.

Que diferencia la Flash Recovery Area de simplemente mantener backups en disco, es un conjunto de características para una administración pro-activa de backups. Por ejemplo, los backups obsoletos y archived logs que quedan fuera de la política de retención de RMAN o ya han sido almacenados a CINTA son automáticamente removidos cuando no hay espacio en disco para crear nuevos archivos. La flash recovery area informa al administrador cuando su consumo de espacio en disco está próximo a su quota definida y no hay mas archivos para eliminar. . El administrador puede entonces accionar para adicionar mas espacio al disco, , hacer backup de archivos a un tercer storage, cambiar la política de retención de RMAN, o simplemente borrar archivos. La Flash Recovery Area es administrada y configurada usando el Enterprise Manager o mediante la línea de comando.

Fuente: http://www.oracle.com/technology/deploy/availability/pdf/rman_10g_fov.pdf

Oracle Recovery Manager (RMAN)

A complete high availability and disaster recovery strategy requires dependable data backup, restore, and recovery procedures. Oracle Recovery Manager (RMAN), a command-line and Enterprise Manager-based tool, is the Oracle-preferred method for efficiently backing up and recovering your Oracle database. It provides a common interface for backup tasks across different host operating systems, and offers features not available through user-managed methods, such as parallelization of backup/recovery data streams, backup files retention policy, and detailed history of all backups. The RMAN environment consists of the utilities and databases that play a role in backing up your data. At a minimum, the environment for RMAN must include the following:

  • The target database to be backed up
  • The RMAN client, which interprets backup and recovery commands, directs server sessions to execute those commands, and records your backup and recovery activity in the target database control file.

Some environments will also use these optional components:

  • A flash recovery area, a disk location in which the database can store and manage files related to backup and recovery
  • Media management software, required for RMAN to interface with backup devices such as tape drives
  • A recovery catalog database, a separate database schema used to record RMAN activity against one or more target databases

New Features in Oracle Database 10g Release 2
Backup Set Encryption

Backup security is vital to the well-being of any company. Backups should only be able to be opened and read by their creators. With Oracle Database 10gR2, backup sets made to disk can now be encrypted, for the whole database or particular tablespaces, using the new CONFIGURE ENCRYPTION FOR [DATABASE TABLESPACE …] option.

Unused Block Compression

With unused block compression (enabled by default), only the currently used blocks are read and written during a full backup. This speeds up backups and reduces backup size. In previous releases, blocks that are currently unused, but had been used at some point in the past, were required to continue to be backed up. Also, blocks that have never been used are never backed up.
Dynamic Channel Allocation for RAC Environments

By configuring the PARALLELISM parameter, RMAN will dynamically allocate the specified number of channels across all active RAC nodes, to perform the backup or restore operation. RMAN utilizes Oracle Clusterware (formerly known as Cluster Ready Services) to allocate channels to the least loaded nodes, to perform the operations. In this way, the overall backup or restore workload can be distributed across the RAC nodes more efficiently.
Enterprise Manager Enhancements Oracle Enterprise Manager, a single, integrated solution for administering and monitoring systems and applications based on the Oracle technology stack, is further enhanced for managing and monitoring backup jobs.
Database Control allows DBAs to view all backup jobs by date range and backup type (e.g. full, datafile, archive log), along with their status (e.g. "completed", "completed with warnings"), input and output sizes, and output rate. Each backup job can be further drilled down to review input files and output backup sets/image copies, their sizes, and compression ratio (if enabled).Grid Control offers several enhancements to manage backups across the enterprise. Backup jobs can be viewed across all target databases, and a failed job can be easily restarted without having to resubmit the job again. In case a backup job fails, the DBA can be notified immediately via email. In addition, user-defined RMAN scripts can be created as jobs and applied to any number of target databases. The recovery wizard has also been enhanced to allow restore and recovery to a different Oracle home, in the event that the original Oracle home or database is lost.

martes, 1 de abril de 2008

Los primeros desafios

Estoy teniendo mis primeros inconvenientes para hacer la instalacion de ORACLE en la instancia de VMWARE.

Una de las primeras trabas para continuar con la instalacion a sido la instalacion de las VMWARE Tools.

El mensaje de error es

"Error: can't create transaction lock on /var/lock/rpm/transaction"

Y la forma de solucionarlo es ejecutar lo siguiente como Root.

mkdir /var/local/rpm

Para luego hacer lo siguiente (primero como usr normal y luego como root porque daba un error de permisos):

[oracle@localhost tmp]$ cp /media/cdrecorder/VMwareTools-6.0.0-45731.i386.rpm /tmp
cp: cannot create regular file `/tmp/VMwareTools-6.0.0-45731.i386.rpm': Permission denied
[oracle@localhost tmp]$ su
Password:
[root@localhost tmp]# cp /media/cdrecorder/VMwareTools-6.0.0-45731.i386.rpm /tmpcp: overwrite `/tmp/VMwareTools-6.0.0-45731.i386.rpm'? y
[root@localhost tmp]# rpm -Uhv /tmp/VMwareTools-6.0.0-45731.i386.rpm
Preparing... ########################################### [100%]
package VMwareTools-7238-45731 is already installed
[root@localhost tmp]#


Despues seguiré posteando errores...