Last night we migrated to a brand new server and moved all our data from SQL 2000 to SQL 2008 R2.
Everything worked out fine except any jobs that have steps where a linked server is referenced are failing and we can't figure out why.
If I log in as 'sa' and browse the linked servers I can expand and browse the objects, etc. I can also run the jobs' code in a query window logged in as 'sa' with no problems.
However when I run the job I get the following:
Execute of job 'ARUpdate' failed. See the history log for details.
History log:
The job failed. The Job was invoked by User sa. The last step to run was step 1 (Step 1).
Executed as user NT AUTHORITY\SYSTEM. Login failed for user 'ANSAC_NT\ANSAC-SQL$'
[SQLSTATE 28000] (Error 18456). The step failed
Sql Severity: 14
Sql Message ID: 18456
Any ideas as to why this is happening? I assume it's something with the sa account?
Happens even if I recreate the job from scratch logged in as sa or with a new sysadmin account created.
Note: we ported over the logins from 2000-2008 as well if that helps.
Thanks!
Related
For the past week, multiple SSIS packages running on SQL Server Agent that load data into Snowflake have started returning the follow message randomly.
"Failed to acquire connection "snowflake". Connection may not be configured correctly or you may not have the right permissions on this connection."
We are seeing this message across multiple jobs and each of the jobs is loading multiple tables and its not happening on each call to Snowflake within the projects, but just on one or two tasks in jobs that have 100s.
We are using the 2.20.2 drivers from Snowflake
We have ran the jobs while WireShark was capturing network traffic and were received by the network team. They didn't have much luck because the ACK messages were not being shown.
We also ran Process Monitor while the jobs ran and we did not find anything that alluded to any issues
We also dug though the logs from the Snowflake driver and found the calls right before and right after, but no messages for the task that failed. Since those logs bounce around on which file they are sending to, its a bit hard to track sequential actions when multiple task on a job are running together.
We also installed SnowCD and ran it and it returned a full success message.
The user that runs the jobs on SQL Server Agent is an Admin on the server and has SysAdmin rights on the Sql Sever instance.
The warehouse the drivers are connected to are a size Large with a max of 3 clusters (was at 1 when the issue started, but upped it to 3 to see if that helped)
Jobs are running on Windows Server 2016 DataCenter in Azure
SQL Server instance is Sql Sever 2016 13.0.4604.0
We cannot figure out why we are suddenly and randomly using connection to Snowflake.
Some ideas to help get these packages working:
Add a retry to the tasks that are failing. The task would move onto the next step only upon success:
https://www.mssqltips.com/sqlservertip/5625/how-to-retry-sql-server-integration-services-ssis-control-flow-tasks/
You can also combine the truncate and insert into one step using the insert overwrite into command which will allow your package to run quicker and have one less task for failure:
https://docs.snowflake.net/manuals/sql-reference/sql/insert.html#insert-using-overwrite
Once the SSIS packages are consistently completing, you can analyze the logs at the point of failure to see if there is any pattern to help you identify the root cause.
I am using SQL Server 2014 on a Windows 2012 server. I have several database instances on the server.
One of the instances has an error in the log every day at 2 AM.
Login failed for user MyDomain\SQLAgentAccount.
Reason: Could not find a login matching the name provided.
[CLIENT: ].
Error: 18456, Severity: 14, State: 5
This is the service account used for SQL Server Agent. The Agent service is running and all jobs run successfully. I was able to trace it back to see that it is coming from PowerShell.
If I add the account explicitly, the error goes away. But I did not need to do that on the other instances and don't think it would be best practices to do so here.
Job runs from SQL Server 2008 64 bit
Job step kicks off a SSIS package which runs successfully in BIDS. SSIS package copies data from an Oracle server to a database in SQL Server
The login for the connection manager for the Oracle database is different than the login used to create the SQL Agent job. I doubt this is the issue because I have another job which does the exact same thing with same parameters as this job and SSIS package the only difference is the Job that works connects to a different Oracle database.
The SSIS package is copying over the data nightly, record counts in source (Oracle) and destination (SQL Server) match but the error I get when I view the history is:
X - The job failed. The Job was invoked by.....
Selected row details:
Date 5/31/2013 12:00:00 AM
Log Job History (DailyPull)
Step ID 0
Server SQL00
Job Name DailyPull
Step Name (Job outcome)
Duration 00:34:28
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
The job failed. The Job was invoked by Schedule 20 (DailyPullSchedule). The last step to run was step 1 (DailyPull).
Here is what worked for me:
The problem happened when we changed the account other than who created it and used a proxy for the new account.
copy the package to another folder
changed the Name for the 'CreatorComputerName'
changed the 'CreatorName' to the new account (our new account has a sys admin right)
save and reload the package in the job.
Success!
I have an SSIS package which contains an Analysis Services Processing Task.
This package is kicked off by a SQL Server Job in SQL Server 2008 R2.
If I run this job myself or process the cube manually everything is fine.
However if I schedule the job and let the SQL server agent run it then the Analysis Services Processing task fails stating Errors in the OLAP storage engine and that an error occurred while processing the one of the measure groups.
Has anyone else every seen anything like this?
The SQL Server Agent service account may not have sufficient permissions. You can validate this by doing any of the following:
Add the service account to the Administrators group on the analysis services server to validate this issue. Let the job run as scheduled.
Create a proxy that runs under your credentials and set the job to execute under the proxy. Let the job run as scheduled.
Change the SQL Server Agent to use your credentials. Let the job run as scheduled.
If the job completes successfully after making any of the above changes, then you have a permission issue that you need to resolve.
So after months of looking at this I finally realised the answer; of course it's a simple one.
The SSIS job I had created was processing the Cube only, while every time I processed manually in management studio I was processing the whole SSAS database.
I've now changed the SSIS package to process the whole database and everything seems to be working correctly.
when This Error Generate :
reporting services catalog database file existence failed sql server 2008 r2
================================================================================
This issue occurs because the databases for the SQL Server 2008 Reporting Services instance that you want to install already exist on the computer with following path.
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA
Manually Remove .MDF and .LDF files of Report from above path and Re-run Setup.
In my case I found the solution in other way. First of all I login into analysus services using SQL management studio.Second of all I searched into databases folder the name of my project, after I open that and double clic in Roles folder, clic in new role, in this window I selected Membership in the left pane, clic in add button and search the NT AUTHORITY\Service, clic in Ok button and finally restart Sql analysis services. I tried to run my job and It works.
At the start of the year I pushed to setting up TFS for a more structured approach to things (before, everyone would change things as they went, obviously A Bad Thing). I set up a very basic single server TFS 2010 installation. The TFS databases resided on one of our Dev servers (SQL 2008).
Everything went well until:
We uninstalled SQL 2008, installed SQL 2008 R2 and reattached the databases. Since then TFS has been impossible:
The clients (SQL Mgt Studio and VS2008/2010) could no longer connect (error 404 not found)
http://localhost:8080/tfs/ gave:
"Team Foundation services are not available from the server.
Technical information (for administrator):
The request could not be processed because the application is not configured correctly. No service host is available for the request."
Team Foundation Admin Console finds the collections, everything SEEMS ok.
In an effort to jumpstart things:
I restarted the website and it's application pool
I rebooted the server
No effect.
Then I stopped the collection (that worked) to re-enter the database information, save it and start the collection again. However, it kept hanging on the save. I tried to detach the collection, but that didn't do anything. So now I have a stopped collection with the following activities:
Prepare Collection (Success)
Create Collection (Success)
Servicing Collection (Queued)
Detach Collection (Queued) (3 times, since I tried this a couple of time)
and nothing is budging.
I have all source in my local folder, so in extremis I can delete and uninstall the whole thing and start over, but... I rather not.
Any way to unblock this?
ok, This was solved by re-adding the TFS machine account to the new SQL Server installation using
EXEC master.dbo.sp_grantlogin #loginame = N'DOMAIN\MACHINE$'
as detailed here. From then on all tasks proceeded as they should..
What tipped me off was the following error in the Application Log:
TF53010: The following error has
occurred in a Team Foundation
component or extension: Date (UTC):
22/06/2011 18:07:22 Machine: AZT-TS-02
Application Domain: TfsJobAgent.exe
Assembly:
Microsoft.TeamFoundation.Framework.Server,
Version=10.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a;
v2.0.50727 Service Host: Process
Details: Process Name: TFSJobAgent
Process Id: 2980 Thread Id: 3804
Account name: NT AUTHORITY\NETWORK
SERVICE
Detailed Message: There was an error
during job agent execution. The
operation will be retried. Similar
errors in the next five minutes may
not be logged. Exception Message:
TF246017: Team Foundation Server could
not connect to the database. Verify
that the server that is hosting the
database is operational, and that
network problems are not blocking
communication with the server. (type
DatabaseConnectionException)
Good times,
Try running the following command:
TFSConfig registerDB /DatabaseName:Tfs_Configuration /SQLInstance:SERVERNAME /Continue
RegisterDB updates the name of the server that hosts the configuration database and in this case should resolve your DB issues. Another command you could try is RemapDBs.
Make sure you "Run As Admin" for these commands or they of course will not work.
I am guessing what is going on is attaching isn't going to be enough because TFS internal mappings no longer understands where your SQL Server db is.
Hope that helps.