SQLVDI error when backing up to Azure Storage BLOB - sql

I'm running a patched SQL 2014 trying to backup a database to one of our Azure Storage BLOBs, using:
BACKUP DATABASE [DB]
TO URL = N'https://storage.blob.core.windows.net/server-mssqlserver/DB.bak'
WITH CREDENTIAL = N'AzureCredential'
,NOFORMAT
,NOINIT
,NAME = N'DBA_DB-Full Database Backup'
,NOSKIP
,NOREWIND
,NOUNLOAD
,COMPRESSION
,STATS = 5
GO
but the query throws the following error:
Msg 3292, Level 16, State 9, Line 1
A failure occurred while attempting to execute Backup or Restore with a URL device specified. Consult the Windows Event Log for details.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
Checking the server's Event Logs shows the actual error as:
SQLVDI: Loc=IdentifySQLServer. Desc=MSSQLSERVER. ErrorCode=(5)Access is denied.
. Process=4668. Thread=6596. Client. Instance=MSSQLSERVER. VD=.
I have made sure that the SQL Server Agent service's account has the Create global objects policy, and also made sure the SQL VSS Writer service is running under the Local System account. The error keeps happening!
Is there something I can do to fix it, or just log some more detailed error messages than the "SQLVDI: Loc=IdentifySQLServer" one above?

Crikey, this is one of those "no idea how I fixed it" things.
Before I went to lunch, I could reliably generate the error in question by running the provided T-SQL, yet when I came back from lunch the BACKUP command completed fine!
The main thing I remember changing was on the Azure side, where I created a SAS (Shared Access Signature).
This is supposedly not required for SQL 2014 as it uses an actual Azure Credential to connect to the storage instead. I actually created the SAS for an instance of SQL Server 2016 that I want backing up to the same container, and that may have opened the access pathway to the container for SQL Server 2014 too!
Many thanks to Sean Gallardy for recommending ProcMon, which showed a whole ton more error log information than the "ErrorCode=(5)Access is denied" message did.

Related

SQL Server & RStudio - SQL Connection Almost Working

I've been running into an issue in R Studio with a SQL connection.
We've had an on-prem SQL Server that's been upgraded over the years, and a colleague that set it up no longer is with the organization.
We also have an Azure Server that's loaded with a SQL Server as well that was much more recently set up before they departed.
We have a GUI program we're currently developing, and one of the early steps is a SQL Login connection for the user where the variable is declared (db_user) and changes with their login and passes the password correctly within system variables defined in .Renviron as posted on RStudio's site for references.
Our initial connection string looks like this, and this is the line of code that starts the connection and where I believe the issue may lie first:
db_conn_onprem <- DBI::dbConnect(odbc::odbc(),
Driver = "SQL Server",
Server = Sys.getenv("server"),
Database = Sys.getenv("database"),
UID = Sys.getenv("db_user"),
PWD = Sys.getenv("PWD")
Whenever the Azure connection succeeds, it connects as dbo#Azure\Azure vs On-Prem's guest#Server\Server.
(I can't post in-line screenshots yet)
On-Prem Connection Screenshot: https://i.ibb.co/PmbGt5y/RStudio-SQL.png
Azure Connection Screenshot: https://i.ibb.co/WFY3FqZ/azure1.png
I feel this is something dbo-related since that's where the connection drops.
(variable names anonymized)
Now for the issue:
Whenever we attempt to run a series of queries, our on-prem errors out with this:
Error: nanodbc/nanodbc.cpp:1655: 42000: [Microsoft][SQL Server][SQL Server]Cannot execute as the server principal because the principal "db_user" does not exist, this type of principal cannot be impersonated, or you do not have permission.
<SQL> 'EXECUTE AS LOGIN = 'db_user' SELECT name FROM master.sys.sysdatabases WHERE dbid > 4 AND HAS_DBACCESS(name) = 1 ORDER BY name ASC'
However, run the exact same procedure on the SQL Server in Azure with relatively no major configuration, and it succeeds.
Here's the SQL Code we run:
EXECUTE AS LOGIN = 'db_user' SELECT name
FROM master.sys.sysdatabases
WHERE dbid > 4
AND HAS_DBACCESS(name) = 1
ORDER BY name ASC
I feel like I've exhausted my resources for this, first I thought it was the initial R code or possibly SQL Drivers, however I don't believe that to be the issue since the SQL driver pulls a list of names in R Studio in the Connections context menu, but bounces back the error when attempting to complete the query.
Whenever I'm searching errors for references for this error, I see
Cannot execute as the server principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
Listed as the most commonly related error for the one I'm experiencing, however I've tried a number of those (From blank DB ownerships to unrelated solutions), but I've mostly hit a wall here.
Any assistance would be greatly appreciated.
I feel this is something dbo-related since that's where the connection drops, but I have no clue where to continue going on this issue.
Yep.
This
EXECUTE AS LOGIN = 'db_user'
requires impersonate permission for the login. Which the error message is clearly telling you. It's unclear why you want to impersonate that login instead of simply connecting as the login to begin with.

SQL Server creating external data source

I'm trying to create external data source in SQL Server 2019. From one SQL Server instance to another.
I have done everything like in documentation (https://learn.microsoft.com/en-us/sql/relational-databases/polybase/polybase-configure-sql-server?view=sql-server-ver15).
To create external data source i use following command:
CREATE EXTERNAL DATA SOURCE SQLServerInstance
WITH ( LOCATION = 'sqlserver://SQL2:port',
PUSHDOWN = ON,
CREDENTIAL = MyCredentials);
But i keep getting following error:
Msg 46721, Level 20, State 1, Line 1
Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.
What can I do to fix this?
Are you running the DDL from a local Windows account (i.e., non-domain joined machine)? There is a regression in SQL Server 2019 where you will get this error when trying to use PolyBase. We are in the process of fixing the issue in an upcoming CU.

Run MS SQL server script on startup

I am trying to run an SQL script when I start (or restart) my windows 2012 R2 server instance (Google Cloud Server). I am doing so using an SQL script, a Batch-file and the task-scheduler.
For the sake of testing I have created a simple SQL-script that adds a datestamp to a table:
USE <Databasename>
GO
INSERT INTO testingTable(time_Stamp)
VALUES (GETDATE())
SELECT * FROM testingTable
(where Databasename obviously contains the name of the specific database)
The batch-file looks as follows:
sqlcmd -S <servername> -i "C:\Temp\testQuery.sql" > C:\Temp\output.txt
I am outputting everything to a text-file. When I run the Batch-file the output looks fine: it prints a list with all the times I have run this SQL-query and saves it in the text-file.
I have scheduled this task to run on startup (following the steps here: https://www.sevenforums.com/tutorials/67503-task-create-run-program-startup-log.html). I have tried a whole range of settings here but nothing seems to work, including the exact settings as highlighted in the forum.
When I now restart the server the output file shows the following error message:
Msg 904, Level 16, State 3, Server <servername>, Line 1
Database 7 cannot be autostarted during server shutdown or startup.
Msg 208, Level 16, State 1, Server <servername>, Line 2
Invalid object name 'testingTable'.
It seems like MS SQL does not allow scripts to be run before you log-in to one of the user accounts.
The problem really is that the actual SQL tasks that I want to run have to be run very early in the morning such that they are done when everyone arrives at the office. I have managed to automate the startup of the server using VMPower, but I can not automate logging in to one of the accounts.
I was hoping someone could give me some feedback on how to resolve this issue. Preferably I would want my current setup to work, but if anyone has an idea on how to automate logging in to an account on an existing google cloud server instance that would be really helpful as well.
Thank you,
Joost
SQL Server offers the system stored procedure sp_procoption which can be used to designate one or more stored procedures to automatically execute when the SQL Server service is started.
For instance, you may have an expensive query in your database which takes some time to run at first execution. Using sp_procoption, you could run this query at server startup to pre-compile the execution plan so one of your users does not become the unfortunate soul of being first to run this particular query. I've used this feature to set up the automatic execution of a Profiler server side trace which I've scripted. The scripted trace was made part of a stored procedure that was set to auto execute at server start up.
exec sp_procoption #ProcName = ['stored procedure name'],
#OptionName = 'STARTUP',
#OptionValue = [on|off]
Read more: Automatically Running Stored Procedures at SQL Server Startup.
Docker
For solution to MSSQL Docker image, see: SQL Server Docker container is stopping after setup.

MDF File not Opening in SQL Server

My database file of SQL Server 2012 cannot be opened, it causes the following error.
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:903; actual 0:0). It occurred during a read of page (1:903) in database ID 6 at offset 0x0000000070e000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\inventoryDB.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
I also checked it by using
DBCC CHECKDB(inventoryDB, REPAIR_ALLOW_DATA_LOSS)
But the result is given below
DBCC results for 'inventoryDB'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'inventoryDB'.
Is any possibilities to recover my data from that database file? I am also done many methods in many of the sites. But it not working and shows same error messages.
Do you have any mdf backup after this error occurred? If yes, you should try to create a table and restore from it using your backup.
Or try reading this article:
https://support.microsoft.com/en-ph/kb/2152734
See if it helps with your error.
You've got corruption in your DB. Either the DB was corrupt before you tried working it and you didn't notice, or it was damaged in the work.
Here. We have few options.
Solution one - If you have a backup file, You can restore your database.
Solution two - If you do not have a backup file, you can use DBCC CHECKDB to repair it. (Resource : https://www.stellarinfo.com/blog/how-to-repair-sql-database-using-dbcc-checkdb-command/)
Thanks :)

Import Excel 2010 to Sql Server 2008

I am using Excel 2010 and sql server 2008 to import the data from excel to sql server. But am unsuccessful. Can you please check the way i am doing ?
sp_CONFIGURE 'show advanced options',1
RECONFIGURE
GO
sp_CONFIGURE 'optimize for ad hoc workloads',1
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0','Excel 12.0;Database=C:\Users\anayak\AppData\Roaming\Microsoft\Templates\Book1.xlsx; HDR=YES;IMEX=1','SELECT * FROM [sheet1$]');
where i am getting this error
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Unspecified error".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
I installed the Microsoft Access Database Engine 2010 Redistributable for Microsoft.ACE.OLEDB.12.0.
But when i use the command "ODBCAD32.EXE" to check the version of my excel then i am getting 14.00.4760.1000.
Then i tried my connection string to -
SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.14.0','Excel 14.0;Database=C:\Users\anayak\AppData\Roaming\Microsoft\Templates\Book1.xlsx; HDR=YES;IMEX=1','SELECT * FROM [sheet1$]');
but again it didnt work.
Can you please suggest what i am doing wrong here ?
Thanks.
Re: 7303 error
Distributed Queries in SQL Server, data from XLS
So your main error is likely this;
OLE DB provider "MICROSOFT.JET.OLEDB.4.0" for linked server "(null)" returned message "Unspecified error".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "MICROSOFT.JET.OLEDB.4.0" for linked server "(null)".
I would check some permissions.
Check the permissions on the Temp folder
This is needed because the provider uses the temp folder while retrieving the data. The folder can be one of the below based on whether you use a local system account or network domain account.
For network accounts, folder is
\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp
and for local system account its \Windows\ServiceProfiles\LocalService\AppData\Local\Temp
Right click on this folder and give it read write access to the account (or group) executing the code. That solved the error for me.
Also
http://blogs.msdn.com/b/spike/archive/2008/07/23/ole-db-provider-microsoft-jet-oledb-4-0-for-linked-server-null-returned-message-unspecified-error.aspx
This is because the SQL Server Service is trying to write the temp DSN to the temp folder for the login that started the service, in this case the Admin/Admin login.
The temp folder is something like: C:\Documents and Settings\Admin\Local Settings\Temp
.15 As mentioned, the OleDbProvider will always execute in the context of the user who initialized it, in this case User/User.
.16 User/User has no rights on this folder (C:\Documents and Settings\Admin\Local Settings\Temp).
If running FileMon when the SQL is executed, we can see the following:
(Actually, try using Process Monitor - http://technet.microsoft.com/en-us/sysinternals/bb896645)
sqlservr.exe:000 QUERY INFORMATION C:\DOCUME~1\Admini~1\LOCALS~1\Temp ACCESS DENIED Attributes: Error
So to summarize so far:
The SQL Server service is started as Admin/Admin, when the select is made, the OleDb provider is invoked by User/User.
Now the OleDb provider attempts to create a temporary DSN in the temp directory. This will be the temp directory for the SQL Server service (Admin/Admin)
but the user (in this case User/User) does not have write permissions on this folder. And the error occurs.
There are two ways to resolve this.
Option 1:
Log out of the machine and log in as the account that starts the SQL Server Service (in this case Admin/Admin) then start a command prompt
and type “set t” (no quotes), this will show something like:
TEMP=C:\DOCUME~1\Admin\LOCALS~1\Temp
TMP=C:\DOCUME~1\Admin\LOCALS~1\Temp
these are the environment variables set for %TEMP% and %TMP%, so go to that folder and right click and select Properties -> Security,
then add the user, in this case User/User, note that the default for the user is Read&Execute/List Folder Content/Read, this not enough, you have to select Write as well.
Log out, and log in again as User/User and rerun the command from SSMS. This time it should work.
Option 2:
Log on as Admin and change the TEMP and TMP variable to, for example, C:\Temp, basically this moves the Temp directory out of the Documents and Settings folder.
However, you must restart the SQL server for this to take effect.
So basically, what happens is that when SQL Server starts, it uses the Temp folder of the startup account (Admin/Admin) but the MICROSOFT.JET.OLEDB.4.0 will always execute
as the user who calls the SQL command (User/User) and this will fail unless this user does not have Write access to that temp folder.
Without knowing all setups out there, perhaps option 2 is the preferred solution since with option 1, you will have to add ALL the users that will invoke the provider which may not be practical.
Also, when changing the startup account for the SQL Server service, then the TEMP directory for that account will be used, and you will see the error again until you, again, give write permissions for all the users on this TEMP folder...or a user group (preferred).