Please look into the below error which I am facing. I am trying to create a new job. While configuring the step 1 for this job I am trying to set an SSIS dtsx package under SSIS db. But it doesn't allow me to select my SQL Server Database Engine under the Server drop down. It shows an empty drop down. Please let me know what could be wrong.
When you click the Server drop down, it kicks off a network scan asking any server running the SQL Browser service if they have any SQL Server instances it can talk to. The browser service can be off and SQL Server works just fine, it just means it isn't broadcasting that it is available. Some folks have a misguided belief that, much like hiding under the covers so monsters cannot find you, not advertising that you have a SQL Server instance running you're more "secure."
But the Browser service is running. Ok, then what about firewall, networking rules and potentially user account controls - it's likely that one of those is blocking packets somewhere.
In the job step configuration, you can enter a name for the step. Choose the SQL Server Integration Services Package type, enter the name of the server and select the package.
This article will help you to tackle with SSIS/SQL:
mssqltips
I had to manually enter the SQL Server name inside the Server dropdown shown in the above screenshot to fix the problem.
Related
I try to write a simple sql server agent job to run daily. The sql statement is as follows:
insert into testtable (nt_username, last_batch)
select nt_username, last_batch from master.sys.sysprocesses where nt_username <> ''
The same sql statement works great if I run it in management studio. But it only returns one record something like:
Administrator 2016-07-14 13:07:08.270
when it runs as a sql server agent job. As a result, it is useless. What did I do wrong and how to fix it? What is the correct sql statement for the same result that works as a sql agent job? My sql server is sql 2008 R2 with service pack 2 (10.50.4000) running on windows server 2008.
Thanks.
After some careful examination, it turns out the culprit is that the sql server agent process must be run under a domain account. I encountered the problem because it run under network service account. The weird part is the sql server also runs under the same network service account with no problems. What a headache this is especially when you are in a hurry to just get a thing to work.
Please do not use sysprocesses. It was deprecated when SQL Server 2005 was released, and the sys.sysprocesses "table" you are using is just a compatibility view. The MSDN page for sys.sysprocesses even has a note at the top stating:
This SQL Server 2000 system table is included as a view for backward compatibility. We recommend that you use the current SQL Server system views instead. To find the equivalent system view or views, see Mapping System Tables to System Views (Transact-SQL). This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
You should instead use the new DMV (Dynamic Management Views):
sys.dm_exec_sessions
sys.dm_exec_requests
sys.dm_exec_connections
Please note that a Login might need to be granted the server-level permission of VIEW SERVER STATE in order to see more than their own data for sys.dm_exec_sessions and sys.dm_exec_requests, or see anything at all in sys.dm_exec_connections.
If this permission is needed, then the current database when you run the GRANT statement needs to be master as this is a server-level permission.
How can I hide SQL Server 2008R2 instance? I don't want it to be visible to users across the network.
Is this possible?
Yes, it is possible and pretty easy to set.
In SQL Server Configuration Manager, expand “SQL Server Network Configuration” and then right click “Protocols for < SQL Server Instance >”. Select “Properties”. On the “Flags” tab, in the “Hide Instance” drop down select “Yes” and then click OK to save the changes.
Changes will not take effect until the service is stopped and restarted. Once the database engine service of the instance is restarted, SQL Server Browser Service will not expose this instance of the database engine to client computers.
I am installing TFS2010. There is a separate Application Tier server and Database Tier server. I am using an already existing database, called Tfs_Configuration. When entering the database name/instance name I am able to test it and obtain the green check-mark so TFS can find the database. The version of SQL server I am connecting to is - SQL Server 2008 SP3. But when I run the readiness tests I get the following messages-
First are those two warning causing the error?
Also, I have db_owner rights to the existing database (Tfs_Configuration) that I am connecting to. What other rights do I need? And what can I do to resolve these issues?
The first error suggests you need the sysadmin role which is in fact a SQL Server role which can be enabled by doing the following:http://blog.sqlauthority.com/2008/12/27/sql-server-add-any-user-to-sysadmin-role-add-users-to-system-roles/
Hope that moves you past at least one error.
You need to be Sysadmin of the SQL instance or a role that is able to create new databases, because the installer wants to create an additional database for the DefaultCollection (and the TFS_Warehouse, TFS_Analysis). Therefore it is not enough to be the owner of TFS_Configuration.
I am unable to kill some SQL Server agent jobs. The task state continues to be running and the command stays in KILLED/ROLLBACK. The job executes queries against OSI's PI system via OLEDB linked server and Oracle. The only way I have found so far to kill these jobs is by restarting SQL server (not a preferred method).
I found following article
https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers
Apparently several people have this issue using openquery through a linked server that is not SQL Server. I'm reposting the work-around that BReuter posted on above article:
posted by BReuter on 1/30/2007 at 2:21 PM
*I have experianced the exact behavior and have found a combination of software which stablized our environment.
There were three key ingredients I found:
1) Make sure you do not have ANY linked servers using Microsoft OLEDB Provider for Oracle, instead use Oracle Provider for Oracle(version 9.2.0.4 is what I have in production).
2) Do not allow the linked server to run "in process". This took some research, but it is possible to run the linked server out of the SQL memory space by following the directions below.
3) I'm running SQL 2005 SP1 on W2K3, but I believe the OLEDB Provider is the key and not the OS or DB version.
The default security settings are too tight to run the Oracle OLEDB provider (OraOLEDB) out-of-process. Further, the default settings for MS DTC do not allow network communication.
Control Panel-> Administrative Tools-> Component Services
Drill to Component Services-> Computers
a. Right-click My Computer-> Properties
MSDTC tab -> Security Configuration button (screenshot below)
a. Network DTC Access – checked.
b. Allow Inbound / Outbound – checked.
c. No Authentication Required – This simulates the windows 2000 security settings.
d. Enable XA transactions – the type of transaction implemented by OraOLEDB provider.
Drill to Component Services-> Computers-> My Computer-> DCOM Config
a. Right-click MSDAINITALIZE-> Properties
Security tab (screenshot below)
a. Access Permissions -> Customize.
b. Press “Access Permissions” Edit button.
c. Give the SQL Server Service account “Local Access” permission.
d. Repeat for “Launch and Activation”.*
If they are large transactions, it might be that the server is actually still performing the rollback which might take some time.
This page
http://www.jaygeiger.com/index.php/2015/03/03/how-to-kill-a-frozen-linked-sql-server-connection/
provides a workaround.
It consist in manual TCP connection termination. It's not an ideal solution but it's the best one I know. It's better than having to restart the entire SQL Server.
Btw. I found that link at https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers page mentioned in Ahd's post
for me killing the OLEDB external resources did not worked and i unfortunately had to restart the SQL server instance to fix this issue always
i my cases it have select with OPENQUERY from oracle linked servers or SharePoint lists which simply has a simple error like bad password and it cannot resolve the error and goes and never come back until you restart the service
Transactions that get stuck in KILLED/ROLLBACK can be canceled by killing transactions on local server. If the query is cross-server and you don't want to wait for the rollback, you have to go to the remote server and kill the transaction as well as kill it on the local server.
This applies to any database system.
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.