miércoles, 5 de febrero de 2014

script de bash para reiniciar tomcat

Hola amigos, en las tareas del dia a dia me encontré con el tema de tener que reiniciar un servidor tomcat de manera automatica, la solicion fue buscar un script de bash que  realizara la tarea.

me he encontrado este script muy interesante y con bastantes validaciones les dejo la url:

http://java360.blogspot.com/2012/03/restart-tomcat-via-shell-script-using.html

por si acaso copio el contenido porque puede que despues no se encuentre disponible...


#!/bin/bash
#Important!! Script Must be run as root(you can ignore this if your tomcat does not need root
PATH=$PATH:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/ant/bin:/opt/java/
export PATH
NOW=$(date +"%Y%m-%dT%H%M")

if [ "$(id -u)" != "0" ];
then
echo "This script must be run as root" 1>&2
exit 1
fi

echo `date` ":=================================" >> /tmp/tomcat-restart.log
echo `date` ":Tomcat restart script initiated!!" >> /tmp/tomcat-restart.log
echo `date` ":=================================" >> /tmp/tomcat-restart.log

if [ `ps -ef | egrep 'tomcat6' | egrep -v egrep | wc -l` -gt 0 ];
then
echo `date` ":Tomcat is running" >> /tmp/tomcat-restart.log

kill -3 `ps ax | grep tomcat6 | grep -v grep | awk '{print $1}'`
/opt/tomcat/bin/catalina.sh stop
echo `date` ":Tomcat has shutdown" >> /tmp/tomcat-restart.log

if [ `ps -ef | egrep 'tomcat6' | egrep -v egrep | wc -l` -gt 0 ];
then
kill -9 `ps ax | grep tomcat6 | grep -v grep | awk '{print $1}'`
fi

#echo "Restarting tomcat !!!!!" >> /tmp/tomcat-restart.log
#/opt/tomcat/bin/catalina.sh start
#else
#echo "Tomcat not found running" >> /tmp/tomcat-restart.log
#echo "Restarting tomcat !!!!!" >> /tmp/tomcat-restart.log
#/opt/tomcat/bin/catalina.sh start
fi

echo `date` "Sleep started" >> /tmp/tomcat-restart.log
sleep 30
echo `date` "Sleep End" >> /tmp/tomcat-restart.log

if [ `ps -ef | egrep 'tomcat6' | egrep -v egrep | wc -l` -eq 0 ];
then
/opt/tomcat/bin/catalina.sh start
echo `date` "Tomcat restarted." >> /tmp/tomcat-restart.log
fi


bendito error generico ORA-00600

copio la informacion que seguí paso a paso de esta URL: http://oraclemamukutti.blogspot.com/2011/06/ora-00600-13013-5001.html

por si acaso se llegan a encontrar con el tema que no saben donde ubicar los archivos de log que tienen el error, se puede usar:
select value from v$parameter where name = 'USER_DUMP_DEST'
por otro lado si desean una ubicacion en donde se puede localizar, les dejo esta ruta:

/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_4303.trc

y dentro de ese archivo se debe buscar la cadena: mismatch



Ora - 00600 [13013], [5001]

I experience an Ora-00600 error. Let's look what is the error and the way to resolve it.

Error received
--------------

ORA-00600: internal error code, arguments: [13013], [5001], [4722], [29361923], [9], [29361923], [17], []

Let's look into details of how to solve this issue.

Section 1> What information needs to be Collected
ORA-600 [13013] [a] [b] [c] [d] [e] [f]

This format relates to Oracle Server 8.0.3 to 10.1

Arg [a] Passcount
Arg [b] Data Object number
Arg [c] Tablespace Relative DBA of block containing the row to be updated
Arg [d] Row Slot number
Arg [e] Relative DBA of block being updated (should be same as [c])
Arg [f] Code

The Second argument would give the information about the data object id.
This would give information about the object involved.

SQL> Select object_name,object_type,owner from dba_objects where data_object_id=;

Once the Object is identified run the following :
The below command check if the table has corruption or not .

SQL> Analzye table . validate structure online;

If this goes fine table doesnot have corruption. For next command.
If the above command fails with ORA-1498 go to Section 3

The below command check if table/index has corruption or not

SQL> Analzye table . validate structure cascade online;

If the above command errors out with ora-1499 it indicates a corruption in index.
Go to section 2 for resolution

Run dbverify on the datafile reported in the error
Arg [c] in the ora-0600[13011] would give the Relative DBA

For example
ORA-00600: internal error code, arguments: [13013], [5001], [57353], [155254965], [261], [151062605], [17], []

Arg [c] --> rdba-->155254965
Use this value and find the file and block number for this dba(data block address)

SQL> select dbms_utility.data_block_address_file(155254965) Rfile# ,dbms_utility.data_block_address_block(155254965) "Block#" from dual;

RFILE# Block#
---------- ----------
37 65717

You can run dbveirfy on datafile with rfile#=37

SQL> Select name from v$datafile where rfile#=37;

$ dbv file= blocksize=

Section 2 > How to resolve if an Index is corrupted.

You would need to drop and recreate the index
Ensure before dropping the Index 

SQL> Spool /tmp/createindex.sql
SQL> Set long 100000000
SQL> Select dbms_metadata.get_ddl('INDEX','',<'user name>') from dual; 
SQL> Spool off

To Identify the index please do the following

Analyze table with "validate structure cascade" fails with ORA-1499 and the trace file contains message "Table/Index row count mismatch". Example:

SQL> analyze table test validate structure cascade;
analyze table test validate structure cascade
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
 

The associated trace file contains:
Table/Index row count mismatch 
table 6559 : index 10000, 0 
Index root = tsn: 6 rdba: 0x01400091

It means: A table scan returned 6559 rows and an index scan returned 10000 rows. 
"Index root" is the segment header information for the index: 
rdba: 0x01400091 is the Index segment header relative data block address. It is decimal 20971665 which is Rfile#=5 Block#=145 :

SQL> select dbms_utility.data_block_address_file(20971665)  "Rfile#"   
2          ,dbms_utility.data_block_address_block(20971665) "Block#"   
from dual;   

Rfile#     Block#   
---------- ----------   
5          145  

Running the next query can identify the associated index:
QUERY 1:  

SQL> select owner, segment_name, segment_type  
2    from  dba_segments  
3    where header_file = 5  
4      and header_block = 145;  

OWNER    SEGMENT_NAME    SEGMENT_TYPE  
-------- --------------- ------------------  
SCOTT    I_TEST          INDEX 


Section 3> How to resolve if table is corrupted

Option a> Backup is available

Ora-1498 would be reported on the table.

The trace file from Ora-1498 would contain following information

Example

Block Checking: DBA = 1066265208, Block Type = KTB-managed data block ---> 
file 254,block 911992 
data header at 0xc00000010118e07c 
kdbchk: avsp(816) > tosp(812) 
Block header dump: 0x3f8dea78 
Object id on Block? Y 
seg/obj: 0x155b452 csc: 0x05.7b2b4ee6 itc: 3 flg: E typ: 1 - DATA 
brn: 0 bdba: 0x3f8dde0c ver: 0x01 
inc: 0 exflg: 0 

Note the DBA value reported in the trace file DBA = 1066265208
Convert this to find the file number and block number having issue

Sql> Select dbms_utility.data_block_address_file('1066265208') from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE('1066265208') 
-------------------------------------------------- 
254

Sql> Select dbms_utility.data_block_address_block('1066265208') from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK('1066265208') 
--------------------------------------------------- 
911992


Run dbverify on the datafile containing the table

$ dbv file= blocksize=

Corruption would be reported on the block.

If you have an Rman backup do a Rman block recovery (Take the file number and block number affected from the trace file)

Rman> Blockrecover datafile block ;

Or

If you have a user managed backup you can do an restore and recovery from good copy of the problematic datafile
Option b> Backup is not available

If no backups are available then use event 10231 at session level to create a salvage table

SQL> Alter session set events '10231 trace name context forever, level 10'; 
SQL> Create table .salvage_table as select * from ;

Rename the Original table to old.

Rename salvage table to Original table name

How to resolve when Smon terminates the instance due to Ora-00600[13013]

If Smon is terminating the instance then.

Set event 10513 and startup the database
event="10513 trace name context forever, level 2" 

SQL> Startup mount;
SQL> Show parameter event
SQL> Alter datatabase open;

Identify the object involved using information from Section 1.

How to resolve the issue if the object involved belongs to system tablespace

System objects are very important.
Please open a Service request with Oracle support if system tables are involved.