From your description:
When I do a db_verify I get the same LSN error.
When I do a db_recover it seems to work since the db_verify then succeeds and i am able to db_dump.
Put when start again my application I get the same LSN error again.
if your database was in a known good state after the recovery, and you get the error after you start your application, then it is possible there is something in the application that is stomping on the log records before they are written out to disk. There could be some buffer over flow or something else in that space. The best way to recover is to use catastrophic recovery and apply logs up to the point where lsn is corrupted.
This is a fairly complicated problem and it is going to be very difficult to debug over the forum. Do you have a support contract with Oracle? If so, have you filed an SR? You have already listed the common cause for this error and ruled that out. Other than the common case, this comes up when there has been some data corruption of which a common one there is corrupt sectors on a disk.
Thanks for the reply, I just now noticed it.
This does seem like a complicated problem yet unfortunately we do not have a support contract.
I do not think it was caused by a hardware failure since we are running on virtual machine.
The possibility of a buffer over flow would be much more likely, although I can't see how this could the LSNs of the DB and logs to be mismatching.
(Could log_archive have caused anything if the env was open by another process?)
One thing maybe easier to answer is the report from the db_verify tool.
Why does it not detect the LSN mismatch after the db_recover was run?
The output of db_printlog shows that the DB LSN is ahead of the log file so why does db_verify return success?
purpose of db_verify is to verify the integrity of the database files themselves.
It checks for many different things dealing with the structural integrity of
the files themselves. There is also another tool to verify the integrity
of the log files. I would recommend you run db_log_verify and see
what that gives you. It seems that you log file may have gotten
corrupted. You can dump the data in the db after it is recovered
and then rebuild a new db from scratch, then load it with the
data the dumped. Recovery has to touch both the database files
and the log files because it needs to handle roll forward/backward
issues. We have 2 verify tools each focused in on their specific
area, one for logs and one for db.