I had installed Oracle 11g on windows 07,everything was working fine.But today it is giving me an error saaying ORA-01033: ORACLE initialization or shutdown in progress . I followed the steps mentioned in the different communities but unable to solve the error. After connecting as sqlplus sys/sys as sysdba. and executing below statement,i got following error. How to solve this error?
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 9: 'C:\APP\MKHATAL\ORADATA\ORCL\VELODBDATA.DBF'
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: 'C:\APP\MKHATAL\ORADATA\ORCL\VELODBDATA.DBF'
Thanks in advance!!
First, check your ALERT.LOG file typically located in D:\app\oracle\diag\rdbms\DBNAME\SID\trace\.
The latest entries in your ALERT.LOG should give you an indication on what is going on. Is the database starting? Shutting down?
Should the database be stuck in the shutdown process, you can try to kill the oracle.exe process and then restart the database via Windows Service.
Often, when the database seems to hang on startup, it is actually applying REDO to get a consistent state, so pay close attention on what the ALERT.LOG tells you.
There's more info needed to be able to solve similar issues. Questions like these are interesting to get answered:
To what level can you start the database ? None, nomount, mount or
open (exclude the last one in this case)
What does the ALERT.LOG file show ? This from the moment the first
issue is suspected to be around
An obvious question is just : what happened ? What action were you
doing when you saw the first error message ?
Can you shutdown the database ? If yes, which methods : normal,
immediate or abort only ? Know that stopping the database with ABORT
option may make problems bigger as they are already.
Did you try rebooting the server ? This is particularly an issue on
Windows, which is your case.
Depending on how you stopped the database, do you have a cold backup
?
Depending on RMAN still working : can you take a backup ? The RECOVERY you were trying is not bad, but it could be interesting to know what is happening on OS level with that file; Is it there ? If yes, is it locked or not ? Does the OS think it's a valid file ?
Related
I have two Access databases that I'm opening on the same computer. In one, running this in the immediate window works as expected (opens Notepad):
Shell "notepad.exe"
In the other, I get this error instead:
Run-time error '5': Invalid procedure call or argument
I have not been able to come up with any shell command that will run successfully in that second database. No matter what, I get that error.
What is going on here? Could there be a security setting coming into play? Or perhaps one is an older version?
Edit - More Info
When I go to the definition of Shell in the malfunctioning database, it goes to VBA.Interaction.Shell.
I get the correct IntelliSense tooltip for Shell.
I tried VBA.Shell "notepad.exe" and VBA.Interaction.Shell "notepad.exe" without success (same error).
Here are the references that are checked in both databases:
Decompiling did not help.
The culprit was our anti-virus software! UGH!
Why did it work in one database and not the other then? I'm told that years ago, anti-virus exceptions were made for my computer for the one database but not the other.
I recommend that any others who encounter this problem check their anti-virus logs/policies. Also, running the database from another computer with different policies in place might shed some light on the issue faster. In this case, when I used remote desktop to log into a server, I was able to call shell successfully.
My problem is like this: I had a copy of SqlServer 2012 installed on my machine. It's been there for over 3 years without any glitches at all. Just 4-5 days ago, a problem sprouted up. When I started Management Studio it told me that
msdb got corrupted so it cannot be opened.
The complete message is something like this:
Cannot display policy health state at the server level, becuase the user doesn't have permission. Permission to the database msdb is required for this feature to work correctly.
So what could be wrong here? What sudden changes/anomalies could have crept in that has made this unstable? Someone told me it could be due to a wide range of possibilities. The reason could be anything. Even some nuget packages affect the database. Initially I though this could have been an issue with login, permissions etc. So I tried to run as administrator also. No, it did not cure this problem. If you try to create a new database it simply tells me, that I can't do it. The message is something like this:
An exception occurred while executing a T-SQL statement or batch.[Microsoft.SqlServer.ConnectionInfo]. Database msdb cannot be opened. It has been marked as SUSPECT by recovery. [Microsoft Sql Server, Error:926]
How do I recover from this? Can you provide me some guidance? Or a clue where precisely to look for the hints of problem? All my work is stalled. Any kind of assistance in recovering my ailing sqlserver installation will be humbly received.
So, I'm requesting you all to show me the way.
Thanks in anticipation.
I fixed mine with Solution C from the following website. my MSDB was corrupt and not loading so I stopped the services and replaced it with the files from the template in the SQL Server directory.
https://www.mssqltips.com/sqlservertip/3191/how-to-recover-a-suspect-msdb-database-in-sql-server/
"The templates are saved in "C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn\Templates" (the path varies by version and install choices, this is the default for SQL Server 2012). By shutting down the instance and replacing the bad MSDB data (msdbdata.mdf) and transaction log (msdblog.ldf) files with the template files I was able to restart the instance without error!" (just incase the website link doesn't work I have quoted it here).
Fissh
If your MSDB is corrupted, restore from your most recent backup. That's the safest thing to do and that's why we have backups to begin with.
If you do not have a backup of MSDB, you have a couple of options.
Recreate it. Detailed instructions here: https://msdn.microsoft.com/en-us/library/dd207003(v=sql.110).aspx#CreateMSDB. This is the best way to ensure you get a clean, functional MSDB and is the fastest way to get up and running again. IMPORTANT: Doing this means you lose all jobs, backup history, etc... that is stored in MSDB. Remember to recreate all maintenance jobs after you're done else you're just waiting for the next thing to fall over (e.g. transaction log backups no longer run, tlogs grow till you run out of disk space - now you can't run any queries that will commit transactions).
DBCC CHECKDB WITH Repair_allow_data_loss is another option which you'll probably find if you google/bing the issue. This might work but it is not recommended. The problem is you don't really know what will be lost. It works by deleting what it can't read then fix the links to get the database physically functional again. Once that's done, you'll have to go back and figure out what remains and is still functional. That is tedious and error prone. Besides, if you're gonna do this very thorough manual check to ensure all your jobs are intact, you're better off just re-creating them on a new, clean MSDB.
I recently made some changes to a working publication under Merge replication which seem to have broken synchronization for the subscriber.
The error message I'm getting is:
The schema script 'ftdb_arcmessagefac64b65_76.sch' could not be propagated
to the subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)
Get help: http://help/MSSQL_REPL-2147201001
The process could not read file 'D:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\ReplData\unc\xxx\20120701000581\xxxx.sch' due to OS error 3. (Source: MSSQL_REPL, Error number: MSSQL_REPL0)
Get help: http://help/MSSQL_REPL0
I've looked in the unc directory, and there's no directory 20120701000581, but there's a directory 20120706110881 from when the snapshot of the publication was updated.
I've tried reinitializing the subscription and recreating the snapshot, but the process still fails expecting the 20120701000581.
I haven't tried deleting and recreating the subscription yet, as I would rather get to the bottom of the issue before trying this. Can someone explain what may be happening and how to fix this?
this happen because subscriber cant locate snaps so you can share snaps folder in your network using UNC
http://msdn.microsoft.com/en-us/library/ms151151.aspx
After some further investigation, it appeared that I was able to make some changes to the article properties in the subscription and once the snapshot was rebuilt the subscription resynchronization ran successfully.
View snapshot agent status-> Monitor-> Right Click on Error Subscription and choose Reinitialize.
Good luck
Current situation:
Delete command executed on production database SQL Server
Rows are not available in last backup
Recovery mode: simple
According to windows, the log file was last modified a day ago. Which if true raises the question: where are the transactions of today if they are not yet written to the log files. Are they still in the buffer??
Question:
Is there a possible way to recover the deleted data?
Is there a way to read what's in the buffer?
Thanks in advance!
No
No
You may attempt to recover the data using a 3rd party log file reader but it probably won't work.
The choice of "Simple" recovery defines your RPO as "last full backup".
Of course my boss is out the day something goes wrong. It's just me, an inexperienced little student here, trying to get our website back up and running. All alone.
The oracle database our site pulls data from won't let me connect (throwing the error on our site), giving me the error: ORA-00257. In full:
ORA-00257: archiver error. Connect internal only, until freed.
Cause: The archiver process received an error while trying to archive a redo log. If the problem is not resolved soon, the database will stop executing transactions. The most likely cause of this message is the destination device is out of space to store the redo log file.
Action: Check archiver trace file for a detailed description of the problem. Also verify that the device specified in the initialization parameter ARCHIVE_LOG_DEST is set up properly for archiving.
All I have is the username and password into the database. And of course the Oracle SQL Developer client.
My question is: am I equipped to fix this problem? If so, how? If it's fixable (by me), and someone can explain it, can they explain it very, very slowly and painstakingly?
If anyone can help, even if it's just to say, "You're doomed!" ...thank you in advance.
You've probably used up all of the space on the disk/partition where the archive logs are being written. Your DBA or DBA-standin should be involved at this point, because losing these logs will affect your ability to recover the database - Oracle is helping you by refusing transactions to make sure the database can be recovered if that is necessary.