Hello I am trying to create a new plan on SQL server to backup all my database.
My goal is to backup them to a network drive thus if I do have some trouble with my server, I will be able to restore databases to other server thanks to backup present in the network drive.
When my plan is executed, I do have some error so I try to execute manually the relative query.
After some investigation, it seems even net use command doesn't work (whereas it is working and I do it from cmd)
EXEC XP_CMDSHELL 'net use Z: \\ServerName\loggin/user:loggin password'
error is
System error 1450 has occurred. Insufficient system resources exist to complete the requested service.
Beside, I do have another server where it is working so I suppose some configuration missing but can't find them
as my network drive is also accessible via FTP, I chose this way to make the job : create a batch file that run winscp and use this batch file in a SQL agent job . I need to add right to batch file to SQL Server agent account. I also need to define a credential and a proxy to be used in the job.
Related
I have a developer pc "A". And I have a SQL Server "B".
My SQL Server is a Microsoft SQL Server 2019.
On server B, I have a database with a stored procedure, which bulk loads data from a text file (using the BULK INSERT command).
I have now created an SSIS project on server A, which calls the stored procedure on server B using the "Execute SQL Task". The connection on the task is pointing at the database on server B. I have tried using the OLE DB connection and ADO.
When I place my text file on server B and reference the file like D:\myFolder\myFile.txt, everything works fine.
When I place my text file on server A and references the file like \\\A\myShare\myFile.txt it fails. The error I get is:
[Execute SQL Task] Error: Executing the query "exec BulkInsert
'\\A\myShare\myFile.txt'" failed with the following error: "Cannot
bulk load because the file "\\A\myShare\myFile.txt" could not be
opened. Operating system error code 5(Access is denied.).". Possible
failure reasons: Problems with the query, "ResultSet" property not set
correctly, parameters not set correctly, or connection not established
correctly.
I have tried logging on to server B and via a File Explorer open the file using the above path. It works fine. And yes, I am logged in as the same user on both servers A and B.
I have also tried giving "Everyone" read/write access to the share, but still the same poor result.
I am only interested in knowing how to fix this problem, using the stored procedure call - I do not wish to rebuild its functionality in SSIS (the stored procedure is maintained by an external company and they may change it at their will, but we agree on how I can call it).
According to what I read from Microsoft, it should not be a problem, call BULK INSERT using a UNC path.
According to what I read from Microsoft, it should not be a problem, call BULK INSERT using a UNC path.
This is true, UNC paths are supported by the BULK INSERT command.
Based on the Microsoft documentation, BULK INSERT has three main requirements:
The server must have permission to access both the file and the destination database.
The server runs the Bulk Insert task. Therefore, any format file that the task uses must be located on the server.
The source file that the Bulk Insert task loads can be on the same server as the SQL Server database into which data is inserted, or on a remote server. If the file is on a remote server, you must specify the file name using the Universal Naming Convention (UNC) name in the path.
The first requirement means that you should grant the SQL Server Service account to access the UNC path, not the Windows account you are logging in with.
You should refer to the following articles to find the SQL Server service account name:
Configure File System Permissions for Database Engine Access
How to Find Service Account for SQL Server and SQL Server Agent?
Besides, you can learn more about SQL Server service accounts and permissions in the following documentation:
Configure Windows Service Accounts and Permissions
Alternative - Mapping network drive
As an alternative, you can try mapping the network drive within SQL Server. You can check the following articles for more information:
Make Network Path Visible For SQL Server Backup and Restore in SSMS
How to Map Network Drive as Fixed Drive?
I am using .mdf file for connectivity, when I select it it generates error:
Failed to generate user instance in SQL Server due to failure in starting the process for the user instance
I have attached image to make it clear to you.
http://i.stack.imgur.com/B1ae2.png
Can anyone answer my question.
Thank you!!
Try following steps :
Stop all user instance processes of SQL Server running under your local account (open up task manager and look for sqlsrv.exe process and end it)
Delete all files in the %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Data\SQLEXPRESS folder
F5 again
The problem is known issue. SQL Server Express cannot create a user instance using the set of engine files in your local app data folder, deleting them should allow SQL Server to recreate them with the correct credentials for you to F5 successfully.
I am trying to move all .zip in a specific folder to another folder. the source folder is located on another server, currently i am using
EXECUTE xp_cmdshell 'copy \\server1\e$\ETL\*.zip \\server2\e$\ETL\'
GO
Which is working if I am logged into both server, but the goal is to automate this process VIA sql server job agent. I have tried
EXECUTE sp_xp_cmdshell_proxy_account 'domain\useracc','pass'
GO
EXECUTE xp_cmdshell 'copy \\server1\e$\ETL\*.zip \\server2\e$\ETL\'
GO
but I am receiving the following error;
An error occurred during the execution of sp_xp_cmdshell_proxy_account. Possible reasons: the provided account was invalid or the '##xp_cmdshell_proxy_account##' credential could not be created. Error code: '0'.
And also not sure if this is my solution. Please help with how I can achieve this. The file names on server1 change name and quantity everyday.
I would strongly advise...Do not use xp_cmdshell. It opens up large security wholes in your surface area and makes you vulnerable to attack. xp_cmdshell should be disabled!
Instead, if you want to automate this with server agent you have 2 options. My preference would be to write a simple SSIS package with a file system task and schedule this package with server agent. SSIS is underutilized for this kind of task but is actually pretty good at it.
Alternatively re-write your script to use Server Agent CmdExec job steps. This does not require xp_cmdshell to be enabled and reduces the attack surface.
I Found that the following worked for me;
In the command prompt, type services.msc, this would open the list of all services on the server.
In the list of services, look for SQL Server Agent, Right Click -> Properties. Go to Logon Tab
Change the logon to a user with access on both servers. then re-write your script to use Server Agent CmdExec job steps(Thank you Pete Carter)
I have a SQL Server Job running on server X.
Now I have to delete the existing AS(Analysis Services) backup files on server Y and create a fresh backup again. I wrote the required code in a batch file and saved it on hard drive of server X. I am executing this batch file using an execute process task in SSIS.
This SSIS package which is on server X will be run through a SQL Server Job at a particular time in every week.
This batch file executes successfully if I run the package manually, but it's failing if I run through a scheduled job! I tried this many times but in vain.
Error message says that "Access Denied" for deleting the files on server Y.
Any help would be appreciated!
When you manually execute the batch file, your credentials are presented to server Y, they are accepted and the OS deletes the file as requested.
When the SQL Agent run the same file, the SQL Agent service account's credentials are presented to server Y. Either they are being rejected by the server-it's not authorized to even look at the box or it can read and list the files on \ServerY\SomeShare but ultimately it is not able to delete a file.
Resolution
Option 1) On Server Y, add the account that corresponds to Server X's SQL Agent Service Account with sufficient privileges to see the folder where the AS backup is and delete the backup.
Option 2) Create a credential and a proxy on Server X that has the above permissions on Server Y and then execute the SSIS package as that user, assuming of course the credential has all the other permissions Server X's Agent account does.
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.