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.
Related
I need to log the last time the user signed in using my node.js server. I am looking into three options. The persistence requirement is not super high, meaning that the margin of error of this record being recorded is open.
Use SQL DB and whenever the user logs in it modifies their profile account.
Record it in a server text file. So whenever the user logs on, this file will be opened and updated. The opening, recording and closing of the file will all be done asynchronously.
I'm thinking that the second option is the better on because I'm using SQL for many other operations so I prefer to not interrupting my DB as much as possible.
One concern I have for the second option is the performance hit on the server that will be caused by the frequently read and write to a local text file.
I'm curious what other people who have gone through this path thought about my thought process. Any opinions or tips are highly welcomed. Thank you.
Normally you should use a SQL database, it is a much more better way than the plain text.
The main problem with a text file is that when you log in, you can simply append a line (but what about a couple of user loggin in at the same moment ? You have not any warranty that all the access are logged), but when you want to extact the last login for a user, you should read (and then load) all the file from the start (or the end), which can cause a really worst problem than the access to the DB.
Naturally you can work out all the problems with a text file, but then you have written a lot of code to avoid a simple update query.
I don't think that, with the information you give, you should be worried about the performance of a database access in this case.
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.
We have an ERP Program used to create and manage stock / orders. Somehow an order has vanished - this should not be possible. It should be possible to cancel an unwanted order, but never delete it completely.
The order in question was created, printed and sent to a customer - and then disappeared. I know the Primary key and Table info, and want to search the log to see if this was somehow deleted, or perhaps there was a rollback.
How can I translate/search the log in this way?
Please note: I did not write this program, and its not my job to fix it.
I just need to diagnose the issue and contact the SW Vendor, if required, and have them fix it. As such I cannot post any code.
With so little information it is hard to give a definitive answer.
I'd start by searching the regular logs. If you have some kind of audit trail mechanism that would be a great help!
If a search through the regular logs doesn't find you the answer then I would:
Get a copy of the database
Go through the REDO logs using the appropriate DBA tools. Since I'm not an sqlanywhere DBA I would get help from one.
When I found the place in time where the order was deleted I would find any other information I could get. The user that did the commit or users that where logged on at the time (I don't know exactly what kind of information you can get here). Also, go back to the other logs you may have and check around that time stamp.
To learn exactly how to go through the redo logs of an SQL Anywhere database you should first try your google luck and then ask in Database Administrators.
Solved!!!!
The Sybase Central tool has an option (which I couldn't find in the manual and missed the first time I looked), which can translate a log file into a series of statements and create a *.SQL file.
Tools -> SQL Anywhere -> Translate Log File -> Follow wizard (which hopefully for you is in a language that you speak, for me it was not).
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 ?
I have almost exactly this problem. I say, almost exactly because the answer that worked for this gentleman did nothing whatsoever for me. I can open my own database and see all of the lovely RS data sitting there staring at me but the actual Reporting Services installation still can't. This all came about because of precisely what he said. We accidentally left the password policy on on the Reporting Services account and it expired. When I changed it the whole thing went kaputt. I'm still getting the "key cannot be used in current state" error message even after dropping all encrypted data from the RS installation. I have no access to the Report Manager to reset encrypted information. Has anyone got any suggestions?
EDIT: In continuing my research I found this suggestion. It's not that.
Well... here's the thing.
I eventually tried creating a whole new user to take charge of the SSRS operations. I also remembered to update those details on our live data server. (I did this first and it failed to work as it was still telling me the key could not be used then.)
I guess that there must be something that prevents the reassignment of the SSRS gofer account's password. The new user is set up identically and works perfectly. So that's what cleared it up for me but I'm a little irritated that I still don't know exactly why...