Tonight I had run into this issue where all my databases on our production server were in a Recovery Pending state after doing a Windows (server 2016) Update, an update to my Redgate SQL Backup software and restarting the server. Looking at the logs I found that all of the databases were not accessible with an "Access denied" error. So I figured it was something to do with the user under which the MSSQLSERVER service was running. So I explicitly set permissions to the data and log folders for that user and restarted SQL Server service and all is fine again.
HOWEVER, this server has been running for a very long time - and I have not seen this kind of issue where suddenly the user doesn't have access to the data and log folders. SOMETHING had to have removed permissions on those folders. In addition, now when I look at the security tab of those folders, I see that the user I'm using to run the MSSQLSERVER is explicitly defined. But on our staging server, which has the exact same configuration, I DO NOT see the user explicitly defined there, yet the server is running along just fine.
SO - To my question. What the heck happened? Any ideas? Should I be worried that the user account running my MSSQLSERVER service is now explicitly defined in the Security tab of my data and log folders?
Use ALTER DATABASE ... REBUILD LOG ON. First set to Emergency, then rebuild the log, then set online and multi-user. You will get a warning that the database may not be transactionally consistent (and it is true).
Alter Database TestDB Set Emergency;
Go
Alter Database TestDB Rebuild Log On
(Name = N'TestDB_log',
FileName = N'L:\Path\To\LogFile\TestDB_log.ldf')
Go
Alter Database TestDB Set Online, Multi_user;
Go
Related
i am using this T-SQL to repair my TFS suspected database
EXEC sp_resetstatus [TFS_Projects];
ALTER DATABASE [TFS_Projects] SET EMERGENCY
DBCC checkdb([TFS_Projects])
ALTER DATABASE [TFS_Projects] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([TFS_Projects], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [TFS_Projects] SET MULTI_USER
but when i use this T-SQL i will get error
Database 'TFS_Projects' cannot be opened due to inaccessible files or insufficient memory or disk space.
how can i repair my SQL database?
i am using SQL Server 2012
UPDATE 1:
this error will Occurred in line :
DBCC checkdb([TFS_Projects])
UPDATE 2:
i have 20GB free on hard drive that my mdf and ldf on it
UPDATE 3:
i can not chek Autogrow becuase when i right click on db the error will appear
mdf and ldf is not readonly
and i am loged in by windows administartor, and loged in sql server by sa
1) If possible add more hard drive space either by removing of unnecessary files from hard drive or add new hard drive with larger size.
2) Check if the database is set to Autogrow on.
3) Check if the account which is trying to access the database has enough permission to perform operation.
4) Make sure that .mdf and .ldf file are not marked as read only on operating system file system level.
Found here: http://blog.sqlauthority.com/2007/08/02/sql-server-fix-error-945-database-cannot-be-opened-due-to-inaccessible-files-or-insufficient-memory-or-disk-space-see-the-sql-server-error-log-for-details/
i update my answer becuase old answer is dangerous and will damage TFS database!
this answer is from microsoft : http://msdn.microsoft.com/en-us/library/jj620932.aspx
To back up your databases
Launch TFSBackup.exe.
The TFSBackup.exe tool is in the Tools folder where you installed Team Foundation Server. The default location is C:\Program Files\Microsoft Team Foundation Server 12.0\Tools.
In Source SQL Server Instance, enter the name of the SQL Server instance that hosts the TFS databases you want to back up and choose Connect.
In Select databases to backup, choose the databases to back up.
Need help? List of TFS 2010 databases on MSDN; List of TFS 2012 databases on MSDN.
In Backup Databases to, enter the name of a network share that is configured with read/write access for Everyone, or accept the default location in the file system of the SQL Server you connected to in step 2.
Note Note
If you want to overwrite backups stored in this network location, you can choose Overwrite existing database backups at this location.
Choose Backup Now.
The Backup tool reports progress on each database being backed up.
Choose Close.
Restore your data
To restore your TFS data
Launch TFSRestore.exe.
The TFSRestore.exe tool is in the Tools folder where you installed Team Foundation Server. The default location is C:\Program Files\Microsoft Team Foundation Server 12.0\Tools.
In Target SQL Server Instance, enter the SQL Server instance you will use as the data tier and choose Connect.
Choose Add Share and enter the UNC path to the network share that is configured with read/write access to Everyone where you stored the backups of your TFS data. For example, \servername\sharename.
If the backup files are located on the file system of the server that is running TFSRestore.exe, you can use the drop down box to select a local drive.
Note Note
The service account for the instance of SQL Server you identified at the start of this procedure must have read access to this share.
In the left hand navigation pane, choose the network share or local disk you identified in the previous step.
The TFS Restore Tool displays the database backups stored on the file share.
Select the check boxes for the databases you want to restore to the SQL Server you identified at the start of this procedure.
Important note Important
For SharePoint, you must only restore the WSS_Content database. Do not restore the WSS_AdminContent or WSS_Config databases. You want the new SharePoint Foundation versions of these databases, not the ones from the previous version of SharePoint or from a SharePoint installation running on any other server.
Choose Overwrite the existing database(s) and then choose Restore.
The Database Restore Tool restores your data and displays progress reports.
Choose Close.
Probably your database is corrupt either due to an unexpected server restart or filesystem corruption. You can use CheckDB to check for issues & remove the suspect status. However, the best bet is to restore it from a working backup.
Some reasons for when this happens are
Database is corupted
database files are being "opened" or held by some process (operating system, other program(s)...)
Not enough disk space for SQL Server
Insufficient memory (RAM) for SQL Server
Unexpected SQL Server shutdown caused by power failure
How to repair a suspect database
When I type this:
CREATE DATABASE AdventureWorks2012
ON (FILENAME = 'C:\Users\sohm\Desktop\Pohm\AdventureWorks2012_Data.mdf')
FOR ATTACH_REBUILD_LOG ;
I get this:
File activation failure. The physical file name
"C:\Users\sohm\Desktop\AdventureWorks2012_Data_log.ldf" may be incorrect.
Msg 5123, Level 16, State 1, Line 1
CREATE FILE encountered operating system error 5 (Access is denied.) while attempting to
open or create the physical file 'C:\adventuredb\AdventureWorks2012_Data_log.ldf'.
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'AdventureWorks2012'. CREATE DATABASE is aborted.
I know it has to do with permissions. I have the administrator account. I have read a million posts but nothing has worked so far. Also when I try to change the folder containing the mdf file, to full control but it keeps reverting back to read-only.
You should run SSMS as an administrator.
Also it is possible that you might be running query as an 'sa' user(sql server authentication).
Try running the query with windows Authentication.
SHORT VERSION
For allowing MS SQL server 2012 to attach the database files you must grant full access to the mdf and ldf files to:
NT Service\MSSQLSERVER
Full Access
LONG VERSION
SQL Security has been updated a lot in 2012 handling of files.
http://technet.microsoft.com/en-us/library/ms189128.aspx
If you look at the existing attached databases and there security you will probably see that there only are 2 roles allowed with full access. MSSQLSERVER and Administrators, when attached SQL Removes all other roles from the files.
Trying to set the MSSQLSERVER from the fil security Permission will not work.
Looking at your services.msc overview you will in a default install see that NT Service\MSSQLSERVER also runs the SQL server servics.
The service account is not visible, the same issue as with IIS AppPools, a sub group has been created by the system and "hides" the accounts from auto discovery, probably to try and secure the accounts but in my view just obscures the setup.
Regards Jan
Open the SQL Server Management Stdio in Administrator mode(Right click -> Select Run as Administrator. If it asks for User name and password enter your Administrator user name password). Then select Windows Authentication click ok, and now try to attache it will attache without any error.
This has nothing to do with YOUR account. SQL Server is trying to write to that folder under the context of the service account that is running SQL Server. You can see who this is by going to the Services applet and seeing who the instance runs as (probably NT AUTHORITY\SYSTEM or whatever). You can override that or you can place your MDF files in the data folder, which SQL Server already has inherent access to, instead of placing them in this other location on your C:\ drive.
Another way to solve this is to change all the SQL Server services to Local System Account instead of services. Start -> Run ->Services.msc -> Scroll down to SQL Server, you should see five services that start with SQL Server. Right-Click, Properties, Log On, change to Local System Account. Repeat for all the rest of the SQL Server Services and restart them all.
Try This
Go to the folder where you have stored mdf file.
Select file -> Right click -> click on mdf give full permissions to file for logged in user Security.
If still issue persist and it might me because of corrupted transaction logs, you may use tool SQL Database Recovery Tool Repairs to repair your corrupted mdf file.
Figured it out. I went to sql server configuration manager and right clicked SQL Server Service. Then I added my Windows Admin account to run the service and now it works.
The SQL Server instance specified in SSIS service configuration is not
present or is not available. This might occur when there is no default
instance of SQL Server on the computer. For more information, see the
topic "Configuring the Integration Services Service" in Server 2008
Books Online.
Login failed for user 'XXXXX'. (MsDtsSrvr)
After connecting to Intergation Services on the server, I get the above error error message when i try open the MSDB folder under Stored Packages. This is a default instance of SQl server. I've checked the MsDtsSrvr.ini.xml file and all looks fine. The user has access to MSDB system tables. Can anyone recommend any thing else to check?
add the user as a login to the SQL server with sys_admin rights to msdb (taken from last comment in reply to the original question, by davey, #june 19th at 21:54which worked for me - this is the answer)
I have an SSIS package that transfers some tables to CSV files on a network drive; it runs fine from my computer manually. I store it on the server in the MSDB database and execute it from there and it runs fine, but when I create a job that has one step that runs the SSIS package from MSDB it fails saying it can't find the CSV file name.
I spent all day yesterday figuring out this means a permissions issue with whatever logon credentials are being used through the job. The job owner shows to be domain/myuserid and step properties show they are using windows authentication with my username. The problem is, I know I have access to this folder.
The first line of the error log says: "Executed as user: servername\SYSTEM". So I made sure user "SYSTEM" has access to the network folder I want to load the files on, but I still get the same error.
The command line looks like #command=N'/SQL "\SSIS package name" /SERVER servername /CHECKPOINTING OFF /REPORTING E'
edit: I found SQL Server agent job account issue where someone asks who the job is run under and marc_s says "I can't seem to find any definitive answers on that one, really. Since my Jobs typically select and update stuff in the database, I am lead to assume that the "Owner" account will be used by default, unless you specify some other account on a given step"
Which also leads me to believe it is using my logon information that has access
The best practice that we've been able to come up with here is to make a domain account for SSIS and then set up a Proxy in SQL Server that is used to run the SSIS Package in a SQL Job.
I would say that the servername\SYSTEM account is a local account, and therefore won't have access to network folders on other servers.
You probably want to run this as a domain account of some sort, which does have access.
Typically this will be the SQL Server Agent, so check in the Services list, in the control panel, and see what account is running the agent, and if necessary change it to the appropriate account.
This may have knock on consequences though, so be careful what other jobs are running.
I got 3 server.
development (my local development machine)
Test purpose (Beta site).
Production
I got Instances in both SQL server 2005 and 2008.
So, When I want updated data, i take the latest backup from our production server and restore it on the Test or development Server. I got a script that make the changes (restore the file and make some slight changes on the databases.)
My problem is, each time i do this, The SQL server Login (created on the server) I use lose it's Database user mapping. I got to delete it form the restored database and recreate it from the root Security Logins.
Is there a way to include that in my restore script?
I got to delete it form the
restored database and recreate it from
the root Security Logins.
No, you don't need to do this - at least not on SQL Server 2005 and 2008.
What you need to do (like in a script) is this:
USE (your database)
GO
ALTER USER YourUserNo1 WITH LOGIN = YourServerLoginNo1
That associates your user YourUserNo1 in your database (whatever) to the server login called YourServerLoginNo1.
Works pretty nice'n'easy, I'd say! You can even do this as a last step in the restore script (which I'm sure you have to restore those things over and over again)
When restoring our production database to the report server each month, I run:
EXEC sp_change_users_login 'Auto_Fix', 'usernamegoeshere'