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.
Related
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.
In Visual Studio's Server Explorer, I right-clicked Data Connections and selected Create New SQL Server Database.
In the same-named dialog that is then invoked, I entered a ServerName, a New Database Name, accepted the default of Windows authorization, but get this:
I'm pretty sure I installed MS SQL Server when I installed VS (2019). What is causing this error and what do I need to do to fix it?
Am I not allowed to create a Server Name and must use a specific one? If so, what?
UPDATE
I'm also getting problems now with MySql. I recently created MySql Databases (they are displaying on the left -- "movies" and "statesdb" and I've got connections to them, as indicated by the green connector icon), but now trying to create a new Database also fails (after I hit the "Test Connection" button):
UPDATE 2
I still get the same exact err msg after installing SQL Server Express.
And that's even though I do have a bunch of SQLExpress services running now (the only non-new one is the last one):
Do I need to use SQL Server Authentication instead of Windows?
To see if you have sql server installed and it’s running, you can open services.msc and look for SQL Server. The name in between the brackets is the instance name, I.e.: SQLEXPRESS.
To connect to a localhost instance you simply do .\instancename or for SQLEXPRESS: .\SQLEXPRESS
Setup
I'm running an AlwaysOn SQL Server Availability Set (from the Azure Always On SQL Server Availability Set Template), and trying to utilize the two SQL Servers in a scale-out NLB setup (I haven't figured out exactly what virtual appliance to use yet) for SSRS. I've never actually utilized a scale-out set-up for SSRS but it seems relatively straight-forward:
1. Set up one instance of SSRS
2. Create reportserver db
3. Connect to same report server db from a second SSRS instance
4. Accept the join request from SSRS Configuration tool of the first instance
Everything* seems to work fine up until step 4 when the join request doesn't appear (see the screenshot). The part of this that I imagine might be causing some issues is that due to the AlwaysOn Setup I am using an internal load balancer with sql listener for my SSRS connection string, and this can be pointed to either SQL Server instance at any given time based on failover, but I'm not sure how this could be troublesome.
Things I've Tried
The below resulted in: 2nd instance not available to join, despite successful connection to database.
Scaling Out before adding Report Server to AlwaysOn
Scaling Out after adding Report Server to AlwaysOn
Using rskeymgmt Utility from the 1st instance (indicates success but no change on restarting SSRS service)
The below resulted in: Primary scale-out instance changed from one instance to the other.
Restore encryption key from 1st instance to the 2nd instance after connecting to RS database.
None of this seems to work and I'm not sure if this is a bug in SQL Server 2016 or something wrong with my methodology. Any help would be appreciated.
Thanks!
*Note: I ran into some initial problems with loopbacks, but disabled strictnamechecking and allowed the specific dns names through the check (the host name for the load balancer (base and FQDN) and that of the server itself (base and FQDN).
It turns out that Azure SQL Server Templates ship with identical InstallationID's in the report server config file. Altering the GUID in the file resolves the issue.
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 m creating a new login using sql server authentication.
a new login is created.
when i m tring to login with sql server authentication there is an error
Cannot connect to (SERVER NAME) i.e name\sqlexpress
Additional Information:
"A connection was successfully established with the server, but then an error
occurred during the login process. (provider: Shared Memory Provider,
error: 0 - No process is on the other end of the pipe.) (Microsoft SQL
Server, Error: 223)"
I hv already enabled all the protocols running as administrater. set authentication mode both windows and sql sever authentication
There are a number of reasons this error message appears. Try each of the following to see if it solves the problem:
Restart the SQL Service - sometimes configuration changes require a restart to take effect.
Check that Named Pipes and TCP/IP protocls are enabled from the SQL Server Configuration Manager
Use Surface Area Configuration Manager to ensure that remote connections are allowed if trying to connect from a remote machine.
Ensure your firewall (on the client and the server) is not blocking connections
Ensure the account has a default database defined.
Ensure the account is not disabled - if you have set up the account to enforce password policies then too many failed logins may disabled the account.
Double check that you are using the correct password - even to the extent of reseting it.
Here is the solution of this error which solve this issue i would like to answer here because if anybody find this question than it will also finds its answer and its time not wasted.
Click on Start menu > Programs > Microsoft Sql Server > Configuration Tools
Select Sql Server Surface Area Configuration.
Now click on Surface Area configuration for services and connections
On the left pane of pop up window click on Remote Connections and Select Local and Remote connections radio button.
Select Using both TCP/IP and named pipes radio button.
click on apply and ok.