Sybase Prod issues..

Tempdb full

–Check the error log if it is the data segment or the log segment that is full
–If it is the log segment, do the following sequentially:
Try to truncate the log
dump tran tempdb with truncate_only
dump tran tempdb with no_log
Check the spid causing the log to get full
select * from master..syslogshold where dbid = 2
Or use d_dbdba002, for the tables syslocks_copy, sysprocesses_copy, syslogshold_copy to check the process that has caused tempdb to get full
Check with the user about the spid identified and kill the spid after confirmation with the application contact
Try to abort the transaction using lct_admin
Select lct_admin("abort",spid)
spid in the syntax is that of the process that initiated the transaction. This also terminates any other suspended transactions in the log that belong to the specified process. Ensure that this is notified to the user and user approval is taken prior to executing this command
Retry executing the dump tran commands
Alter the tempdb on the device that has space

If there is no space on any of the existing devices then create a database device in the location : /app/sybase//tempdb
Check for the name of the last tempdb device created on this server
-Create the new device in the sequential order as per the name in the server
In worst case scenario where no space is available anywhere in the server, extend the tempdb on any device with free space available as the tempdb can be shrunk during a subsequent restart of the server by making changes to the sysusages table

Blocking process

–Execute the following query to check the process that is blocking:
select spid, suser_name(suid), db_name(dbid), blocked from sysprocesses where blocked > 0
Check the physical io for the process:
sp_whodo ‘blocking process’
select spid, suser_name(suid), db_name(dbid), physical_io, memusage from sysprocesses where spid = BlockingSpid
sp_lock ‘BlockingSpid’

Open tran issue..

–Execute the following query to check the process that is open:
select db_name(dbid), spid, starttime, name from master..syslogshold where dbid = db_id('dbname') order by starttime
Check the physical io for the Open Transaction:
sp_whodo ‘OpenTranSpid’
select spid, suser_name(suid), db_name(dbid), physical_io, memusage from sysprocesses where spid =OpenTranSpid
sp_lock ‘OpenTranSpid’

LogSuspend issue..

Check the spid causing the log to get full
select db_name(dbid), spid, starttime, name from master..syslogshold where dbid = db_id('dbname')
Check with the user if the spid has been identified and kill the spid after confirmation with the application contact
If the spid belongs to the truncation point for a replicate database check if there is an issue with replication. If so, correct the problem with replication
Check if the transaction log can be dumped:
Execute the ncycle job for dumping the transaction
Execute dump tran dbname with truncate_only (This will invalidate the future tran dumps)
Execute dump tran dbname with no_log (This will invalidate the future trans dumps)
Check for an existing device where the database can be extended and extend the database
Alter the database on the device that has space
Ensure that the database does not have a data fragment on that device already

Try to abort the transaction using lct_admin
Select lct_admin("abort",spid)
Performance issues..

–Log into the server and check the following:
Check if there are any known issues with that server/region (outages etc.)
Execute sp_monitor and check for CPU utilization
Check if there is blocking
Check if there are issues with the tempdb
Check if there are any open transactions
Ask the application user, if he is aware of the process that is causing the problem
If yes, get the query plan of the process
Look out for table scans, deferred modifications. If you find any, suggest using indexes for the query
If the query is using the correct indexes, check from when has the issue been recurring. If it is a recent issue, check for the following:
Was update statistics successfully executed
Did the index rebuild job complete successfully

If the application user is not aware as to what process is causing the problem, execute the following query:
select spid,status,hostname,program_name,hostprocess,cmd, cpu,physical_io from sysprocesses where status like 'runn%'
Generally the spid showing cpu and physical_io as 0 is the prime candidate to be killed
How to use VCS Commands

Login to the host as sybase to start the servers...
1) STATUS
/opt/VRTSvcs/bin/hastatus -sum grep

) SHUTDOWN
/opt/VRTSvcs/bin/hagrp -offline sg_dbservername -sys lns66h-6001e
3) START
/opt/VRTSvcs/bin/hagrp -online sg_dbservername -sys lns66h-6001e