I have a database that has lost one of its .ndf files and have been unable to get at the data. The .ndf file in question was added last Thursday and placed in a temporary storage location by a colleague (d'oh!). There is no backup available from this database since prior to this .ndf being created. I have seen numerous solutions to similar problems when the .ndf in question is its own filegroup, but in this case it actually is in a filegroup with an additional file which I want to try and get data from. I am pretty sure what I am trying to do is not possible but there is always a chance right?
The database setup
PRIMARY: Data.mdf -200mb
Data Filegroup 1: Data_1.ndf - 2.9gb
Data_2.ndf - 64gb (newly added file that is now lost - I believe it is just preallocated space)
LOG: Log.ldf - 128mb
When we logged into the VM this morning (hosted in Azure), we were presented with an unexpected shutdown notification from Windows (it seems there was a powerloss/shutdown at 1am) and our application was not reaching the database. Looking in SQL Server Management Studio I could see that it was Recovery Pending status. Trying to bring the db online lead me to an error about Data_2.ndf not being found (located at D:\SQL\Data\Data_2.ndf).
When I accessed the D drive (temporary storage drive) I was presented with a wonderful blank Windows Explorer window - completely blank drive.
I was able to set the Data_2.ndf file offline and bring the database itself online, however I am not able to query any of the data (as all tables were in Data Filegroup 1) due to the filegroup being offline. The other 3 files (mdf, ndf, ldf) are all online.
Is there any way out of this? Any way to perhaps recover any remaining data from Data_1.ndf or is it completely toast?
(This was a hastily stood up development server and there was no backup/recovery strategy for it, as "Azure never crashes" :)).
(Edit:formatting)
You are hosed. Its a miracle you can bring up your database. Are you sure you can retrieve data - have you tried doing selects? You probably will receive more extensive answers on the Database Administrators group.
Related
Background:
I have a medium-sized database (900GB) that needs to be copied onto another server (driven via code, not scheduled). Currently we take a backup (to .bak), move it to a staging server, and restore it to the target server. The target server does not have enough space to hold the backup file, and the restored instance simultaneously, thus the staging server. These transfers (backup to staging, restore from staging) happen over SMB2. The staging server needs to go away due to business requirements, however. It is worth mentioning the target server will be taken offline (and used offline) after the transfer, so I'm not sure the mirroring or replication options are valid.
I have identified two options -- one is to backup the database to the primary server, and open up firewall rules/smb to serve the backup file to the target server over SMB. ("RESTORE FROM \x.x.x.x\blah\db.bak"). Security isn't a fan, though.
The ideal solution (and one that could easily be implemented in every other database I've worked with), is to quiesce the database and transfer the datafiles (in the case of ms-sql, mdf and ldf files). However, upon research I see there is no such functionality available out of the box. I know I can take the database offline to copy the mdf/ldf safely, but that's not an acceptable solution (database must remain online).
I have read LOTS of posts and Microsoft documentation regarding VSS / shadow copy, but I have also read lots of conflicting information about the reliability of using VSS/sqlwriter to copy the mdf/ldf file to the target server, and simply re-attaching the database.
I am looking for documentation or advice (or even backup software that can be programmatically driven via an API) to accomplish this goal of transferring the database without requiring a secondary holding place. Currently I'm researching how to drive this copying process with Powershell, using VSS(vssadmin/vshadow from sdk), but I'm not confident in what I'm reading, and it's not even clear to me if VSS/sqlwriter is a supportable method to copying online LDF/MDF files. Any advice is appreciated.
Thanks,
I am not a database administrator. Our DBA left the organization on bad terms about a month ago and I am a application developer and didn't knew anything about database administration about a week ago, so please bear with me.
We have two servers, Server A (primary server) and Server B (secondary server). Mirroring was configured between A and B.
A was configured to replicate our DB tables to C (reporting server). Replication was configured on between A and C
A went down due to hardware failure (hard drives corrupted); B now is our only server.
A was down so our replication broke between A and C.
B was acting as our principal server now. Note that we were already low on disk space (different configurations of both servers), unusual behavior was observed that the disk space was being filled up so quickly.When the disk space was full the error encountered was “the transaction log for database ‘DBName’ is full due to ‘REPLICATION’.”
Note that the replication between B and C was not configured.
We faced a downtime of 18 hours
During that downtime started replacing hard drives of A and reconfigured it from scratch (windows server installation, SQL server installation)
We then copied the .mdf and .ldf files from B to our fresh A and restored them.
We are now on our A (primary) back again.
We bought a new server (D) to make work as our secondary server and restored the latest back up (DBName.bak) of fresh working A and the latest transaction log file backup (DBName.trn) taken after the full database backup. This was done to configure mirroring between A and D successfully.
We configured mirroring between A (primary) and D (secondary) successfully.
Now we are trying to configure replication between A (reporting) and C (reporting server) for that we need to make sure that our transnational log backup job is running which takes the backup and then shrinks the ldf files, the job runs after every 15 mins.This job is not running successfully. We notice an error with message ID 9003
Error :
The log scan number (7796674:12164:1) passed to log scan in database ' DBName ' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication, re-create the publication. Otherwise, restore from backup if the problem results in a failure during startup
We have read several blogs and articles proposing different solutions but the scenario doesn’t match to mine. I am confused to apply any of those solutions.
Currently we don’t have any replication configured. So the best solution a could read out of blogs were to apply sp_repldone which will remove or mark all the pending replication transactions as replicated from the transactions log files.
Given the above scenario should we be applying the above solution.
I have uploaded the MS-Access database at a shared drive location in a Windows folder. For couple of days, the database works fine and then it automatically starts creating backup copies of the database every time users try to use the database. While the backup copies are created the size of parent database gets reduced from 10 Mb to 150-200 Kb.
When users try to open the database, they get the message -"Unrecognized database format '\10.10.5.7\Database\DB-R.accdb'
Any suggestions!!
Online searches show this could be related to:
1. 64bit of Access vs 32bit version
2. The version of access you are running, if it is not patched
See related question:
Simular Stackoverflow Question
When a database in the Treeview of SQL Server Management Studio is right-clicked and is taken offline and then the Delete option is chosen, is all space allocated to the database released back to the o/s file system pool?
If you take the database offline before deleting it, data files will not be deleted from disk. Please see this section of the books online.
http://msdn.microsoft.com/en-us/library/ms178613.aspx
Dropping a database deletes the database from an instance of SQL
Server and deletes the physical disk files used by the database. If
the database or any one of its files is offline when it is dropped,
the disk files are not deleted. These files can be deleted manually by
using Windows Explorer. To remove a database from the current server
without deleting the files from the file system, use sp_detach_db.
Yes and no. As long as all of the database files related to the database are deleted (happens when the delete option is chosen) then yes, that space is now freed back to the OS. However there is some data related to the database in the system databases. The best example is the backup history (which you can choose to delete when you drop the database as well). This doesn't seem like much but the data on several years worth of backups can add up. Particularly if you are doing transaction log backups say every 5 minutes.
Also of course your backup files will still exist and take up space on the drives.
The transaction log file for the ReportServerTempDB database (database installed with Reporting Services) is has grown to over 100GB. And I'm not sure why.
Here are the file sizes:
D:\SQLDatabases\ReportServer.mdf - 0.7GB
G:\SQLDatabases\ReportServer.ldf - 1.8GB
E:\SQLDatabases\ReportServerTempDB.mdf - 5GB
G:\SQLDatabases\ReportServerTempDB.ldf - 107.6GB
Recovery mode for all these database is SIMPLE.
We are using SQL Server 2008 R2 Standard Edition.
EDIT: Something that is unique to the reporting services databases:
The collation for these databases is Latin1_General_CI_AS_KS_WS. But for all other database it is Latin1_General_CI_AS.
I don't want to just shink the log files and carry on, because they might just grow again. And I can't see why they should be so large.
Does anyone know what could cause the log file (and the data file) for the ReportServerTempDB database to grow so much
And what I should do about it?
Could this indicate a problem with our Report Server?
You are sure that your temp DB is on recovery model - simple as well?
At least you can shrink the database so you get your disk space back using SHRINK DBCC, check this link for more details: http://msdn.microsoft.com/en-us//library/ms190488.aspx
We had renamed SSRS, but the cleanup / archive procs were still trying to cleanup the old database names. When we changed that, out problem stopped.