ORA-27086: skgfglk: unable to lock file - already in use

Question

Hi,
I advance I appreciate your time for assistance.
Thu Sep 30 23:07:08 2010
Errors in file /opt/app/oracle/admin/EDITDATA/bdump/editdata_dbw0_21124.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/opt/app/oracle/oradata/EDITDATA/users01.dbf'
ORA-27086: skgfglk: unable to lock file - already in use
Linux Error: 11: Resource temporarily unavailable
I am getting this error for last 2-3 days. I need to start up the database manually.
Daily there is crontab schedule which will take the cold backup and startup the database. When I am checking daily morning. DBt is going into MOUNT stage instead of OPEN stage. I have check the script every thing is fine.
Note: This is happening intermetendly. Also is error is happening with different datafiles each time.
Regards

Answer 1

user818118 wrote:
This is the cold_backup Script ...
1) First, it will shutdown the db.
2) Copy all the crb files to the backup location.CRB files? Do you mean data files, control files and spfile/pfile?
3) Startup the db.
4) ZIp the files.
5) Deletes the old uncompress files.Any special reason why you use this approach? It may in fact be slower than zipping and compressing on the fly.
For example, 10GB of data files need to be be backed up. You can follow the above approach and make a 10GB copy. Then read that copied 10GB (20GB in total read at this stage) and then compress it (CPU resources needed) and then write 5GB of compressed data (assuming a 50% compression ratio was achieved).
Now compare this with reading 10GB, compressing it (CPU resources needed) and then writing 5GB. Not only is this significantly less I/O to do, but less physical space is needed too.
As for your problem - you can add some debugging code into the cold backup script to show whether any processes are using any of the Oracle datafiles prior to starting the Oracle instance. If so, then doing a process listing of the "guilty" process to determine who it is.
Also keep in mind that you also need clean starts and exits from shell scripts... in other words, what happens if a 2nd copy of the cold backup is started? Or when a previous run failed and is stuck as a background process?
In my experience, this is often the cause of the problem you're seeing - the database is started up, but the cold backup has a rogue process (remnant of some script failure) that still locks Oracle datafiles.