24. January 2009 by admin.

PREMIOS CLOUG 2009

Ayudenos a premiar a los mejore professionales y empresas Oracle del ano 2008 durante CLOUG 2009.

Para esto, necesitamos su apoyo respondiendo las siguientes encuentas:

• Provedor del Ano
• Instructor del Ano
• Consultor del Ano
• Empresa de Servicios del Ano
• Professional Oracle del Ano
• Desarrollador del Ano
• DBA del Ano
• Mejor Blog Oracle Chileno del Ano
• Proyecto Oracle del Ano

Muchas Gracias por su participacion, para premiar a lo mejor de lo mejor en Chile.

 CLOUG 2009

Posted in News | Print | No Comments »

17. January 2009 by antilope.

Hola,

tengo un problema. Estoy conectado a una instancia de una base de datos mediante isqplus con un determinado usuario. Si intento conectarme desde otra ventana de navegador con un usuario distinto a la misma instancia, el primer usuario se “machaca” con el segundo. A partir de ese momento los dos usuarios son el mismo. ¿Cómo se puede solucionar?¿Cómo puedo tener distintos usuarios conectados simultáneamente a la misma instancia?

Muchas gracias

Posted in Consultas | Print | 4 Comments »

14. January 2009 by admin.

El primer CPU del 2009 ya se encuentra disponible, fue oficialmente liberado el 13 de Enero del 2009. Como siempre Oracle  recomienda fuertemente la aplicacion de estos parches lo mas pronto possible. 

Favor de utilizar el siguiente link para obtener mas informacion sobre este CPU como productos y componentes afectados por ejemplo:

http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujan2009.html

 Muchos Saludos,

Francisco Munoz Alvarez

Posted in News | Print | 1 Comment »

12. January 2009 by admin.

Comiésemos este año nuevo con una nueva mentalidad, o una resolución de año nuevo si quieres pensarlo de ese modo, dejemos de ser reactivos y empecemos a ser proactivos. Ser proactivo va a ayudarlo a reducir sus costos en administración de base de datos,  incrementar tu nivel de eficiencia, ayudarte a cumplir más fácilmente los SLA’s y lo que es mejor salvar tus horas de sueño cuando estés de turno.

¿Porque chequear los problemas solamente cuando estos ya son críticos, o cuando ya es muy tarde y la base de datos ya está abajo o congelada,  o lo que es peor,  cuando los usuarios ya están gritando?

Ser proactivo es la mejor manera de mantener tu base de datos saludable y de mostrarle a tu empresa o tus clientes que tu realmente te preocupas por ellos.

No sé porque, pero muchos DBA’s gastan la mayoría de su tiempo siendo bomberos solamente (puro apagando incendios) arreglando problemas o trabajando en requerimientos de los usuarios. Este tipo de mentalidad o comportamiento va solamente traer como resultado, miles de dólares en horas extras (si es que te las pagan), varias horas sin sistema para los usuarios, baja performance de las aplicaciones y lo que es peor de todo, varios usuarios insatisfechos que pensaran que tú no tienes el conocimiento necesario para estar a cargo de su data.

Mencionemos un pequeño ejemplo, tienes configurado el alarma del área de archive logs en que se dispare cuando este en un 95% lleno, y esto ocurre en la mitad de la noche, algunos DBA’s van a tomar este alerta seriamente y lo arreglaran de inmediato, otros esperaran hasta el día siguiente para resolverlo ya que o están muy cansados y dormidos, o no tienen en ese momento acceso a internet para resolverlo. Hubiera sido mucho mejor y más fácil si en vez del alerta estar configurado en un nivel crítico solamente, haberlo puesto con un monto mas proactivo como por ejemplo un 75% o un 85%, o lo que hubiera sido aun mejor, haber mirado la salud de tu DB antes de haberte ido del trabajo para detectar y resolver cualquier posible problema antes que fuera un problema real o para planear como solucionarlo a tiempo antes de que te despierten en la mitad de la noche o te interrumpan durante el fin de semana (Acuérdate siempre que tu tiempo personal y familiar es lo más importante que tienes y siempre debes de trabajar en pro de protegerlo y cuidarlo). A mí personalmente siempre me gusta recomendar a los DBA’s que corran 2 checklists diarios, uno a principio de su jornada laboral y otro al final de esta.

Yo conozco a muchos DBA’s que reclaman todo el tiempo que no tienen vida, ya que se vuelven locos cuando están de turno por el volumen de llamados y de las interrupciones que ocurren durante los fines de semana y noches. Pero esto solamente les ocurre porque ponen su atención y tiempo en solucionar los síntomas y no los problemas de raíz o si no es posible, en tomar medidas proactivas para protegerse.

Ser proactivo no solamente lo ayudara a obtener una mejor calidad de vida, también lo ayudara a detectar puntos de mejora en: performance, seguridad o quién sabe, simplemente evitar un posible desastre futuro antes que cualquier otra persona lo haya detectado.

Aquí podrás encontrar un script de checklist que podrás usar como ejemplo para ayudarte a hacer tu vida un poco mas fácil (Este no es mi script completo, pero muy bueno para empezar). Este script es una compilación de varios scripts de checklist y tu podras modificar facilmente  las variables (thresholds) segun tus necesidades, pero eso si, acuerdese siempre de tener una baseline con que compararlo.

Como mencionado antes, este script no solamente lo ayudara a Ud. A detectar problemas actuales o futuros, pero también lo ayudara a detectar futuros requerimientos de tuning también.

Aquí está un ejemplo de lo que sería la primera parte del reporte generado por el script:

– ———————————————————————– –
– Oracle Instance Information
– ———————————————————————– –
Cpu_Count                                    4   |      Host_Name              OLIVER
Instance_Name                        prod   |      Database_Status      ACTIVE
Status                                     OPEN   |     Startup_Time          10-01-2009 19:50
Version                            11.1.0.7.0   |      Instance_Role          PRIMARY_INSTANCE
Database Space (Mb)           36604    |      SGA (Mb)                 511
Nb. Datafiles                               43    |     Nb. Tempfiles           1

Archive destination LOCATION=E:\oracle\oradata\prod\archive
Database log mode ARCHIVELOG
Background Dump Dest d:\oracle\diag\rdbms\prod\prod\trace
Spfile D:\ORACLE\PRODUCT\11.1\PROD\DATABASE\SPFILEPROD.ORA
Redo size (Kb) 102400

– ———————————————————————– –
– Instance CheckList –
– ———————————————————————– –
Instance Status                                  OK    |      Listener Status      OK
– ———————————————————————– –
– Performance Memory CheckList –
– ———————————————————————– –
Total Sessions < 700                           OK - 19
Active sessions number <15                 OK - 9
Data Buffer Hit Ratio > 80                   OK - 97
L.Buffer Reload Pin Ratio > 99           OK - 99
Row Cache Miss Ratio < 0.015            NO - 1.351
Dict.Buffer Hit Ratio > 80                    OK - 99
Log Buffer Waits = 0                            NO - 110
Log Buffer Retries < 0.0010                 OK - 0
Switch number (Daily Avg) < 5            OK - 1
Jobs Broken = 0                                   OK 0
Shared_Pool Failure = 0                     OK - 0
– ———————————————————————– –
– Storage CheckList                                            –
– ———————————————————————– –
Dba_Tablespaces Status                     OK   |       V$Log Status             OK
V$Datafile Status                                OK   |       V$Tempfile Status   OK
V$Recover_File                                  OK   |       V$Recovery_Log      OK
Tablespace in Backup Mode = 0        OK - 0
Tablespace < 95%                              OK- 0
Objects Invalid = 0                              NO - 147
Indexes unusable = 0                          OK - 0
Trigger Disabled = 0                            NO- 5
Constraint Disabled = 0                       NO - 2
Objects close max extents = 0             OK - 0
Objects can not extent = 0                  NO - 552
User Objects on Systems = 0               NO - 26
FK Without Index = 0                          NO - 138
– ———————————————————————– –
– Datagard CheckList                                          –
– ———————————————————————– –
Datagard Errors = 0                             OK- 0
Datagard Gap = 0                               OK - 0
Archives not Aplied < 5                       OK - 2
– ———————————————————————- –
– Installed options :
– ———————————————————————- –
- Objects option
- Connection multiplexing option
- Connection pooling option
- Database queuing option
- Incremental backup and recovery option
- Instead-of triggers option
- Parallel load option
- Proxy authentication/authorization option
- Plan Stability option
- Coalesce Index option
- Transparent Application Failover option
- Sample Scan option
- Java option
- OLAP Window Functions option

Ud. También podrá encontrar varios productos que lo podrán ayudar a monitorear y configurar sus alertas de una forma proactiva, tales como: Grid Control (Oracle), Enterprise Manager (Oracle), Insider (FourthElephant), Spotlight (Quest), entre muchos otros más disponibles en el mercado y también caso sea su preferencia, utilizar sus propios scripts para esta finalidad. La idea es siempre usarlos de una forma proactiva, nunca reactiva.

Por eso cambiemos nuestra mentalidad y dejemos de ser bomberos para comenzar a ser realmente héroes.

Mucha suerte,

Francisco Muñoz Alvarez

Posted in Monitoreo, Tuning, Experiencia, Tutoriales, Scripts | Print | 4 Comments »