What is the difference between Connection, instances, and sessions in the SQL server? I tried to find the differences but one and others are interrelated.
Connection: It is the number of instances connected to the database.
Sessions: A session run queries.
Instance: It is a copy of the sqlservr.exe executable that runs as an operating system.
Any explanation with examples would be helpful.
A connection refers to the layer-4 (TCP or Named Pipes or Shared Memory or etc...) connection between a client and the server.
A session is the "logical" unit of a client connection and uniquely identifies a client. A session can have multiple active commands and is the entity which "holds" locks on an object. Sessions are normally 1:1 with connections (the exception that comes to mind is the Context Connection.)
An instance is the SQL Server process running on a server which provides the SQL Interface to the databases. It frequently listens on TCP ports to accept connections from clients to create new sessions.
Related
For my project that is being developed in .NET Core 2.2, i'm trying to implement a Connection Pool of SQL Server Database connections. So that whenever the business entity will need to connect any of the database, it will just pull the connections from Connection pool and use. Also need to keep the connections in the connection pool alive. All the databases are in the Azure.
Can you please guide me or provide me an example, how to implement the connection pool in C# code?
Whether the Connection pool can be implemented using any standard library?
Specify the Min Pool Size= connection string keyword with System.Data.SqlClient or Microsoft.Data.SqlClient to indicate in initial number of pooled connections. These physical connections will remain open in the pool when not in use.
Connections are normally acquired on demand and closed automatically when not used for several minutes so this setting is generally used only for specialized cases. See SQL Server Connection Pooling (ADO.NET).
From here:
When SQL Server clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named pipe of the requested instance.
Apparently when UDL or SSMS used for connecting remotely to SQL Server instance name, the query for resolving the instance name's port number store's somewhere in client machine.
I tested this by two client machines. When the 1434 UDP port was open first machine could connect to SQL Server instance name. Then I closed the port and tried again with that machine. The first client still could connect without the port being open. Then I tried with second machine but it couldn't connect.
I just wondering how and where this caching takes place?
Client APIs like SqlClient use connection pooling by default to avoid the overhead of name resolution, physical network connection, and authentication every time a connection is opened. When the initial connection is closed, the connection is added to a connection pool where it can be reused the next time another connection with the same attributes is opened. The client API in that case simply retrieves and unused connection from the pool avoiding the significant overhead of establishing the physical connection.
With a named instance, connection pooling also avoids the need to query the SQL Server Browser service every time a connection is opened so this explains your observations. I suspect if you exit and re-launch the application after blocking UDP port 1434, the SQL connection for the named instance will fail due to the failed SQL Server Browser data gram query during the initial connection open.
I am creating a new version of my Datasnap server for Firemonkey apps to connect to in Delphi 10.2 Tokyo.
My main issue is that the Datasnap server must be able to connect to multiple Firebird databases. The apps will give a parameter to the server so it knows which one to use.
For know I use an .INI file for administrating my Firebird databases. On creation of the server it reads all the locations of the database files and settings.
What is the best way to safely connect to the databases in your opinion?
I've had a few ideas my self:
On device connect create new connection component and then connect to
database that the app has set in parameter. After the device disconnects close the connection and free the component from memory.
After reading the INI file create the connection components and put them in a list. Then when a device connects search for the connection with the parameter the app sends and then open the database connection. Then after the device disconnects close the connection.
Create new TDSServer per database with a set database connection and add to
list. When device connects search for the server it needs to use with the parameter the app sends. No further database connection handling is necessary.
Only opening the connection and closing.
Or something else entirely? Maybe multi-threading?
Remarks
If a new database is added to the INI file the server is restarted so it reads all settings again. So no need for accounting for new databases runtime.
I do also want to use database transactions arround calling different methods in the server. The apps send when to start/commit/rollback the transaction.
I have an OLTP server that I am thinking of setting up transactional replication for in order to support OLAP Reporting.
I have a server named Yoda that we are using for our OLTP and one named Chewie for our OLAP server (Both are VM servers). I know I can setup transaction replication on them easily. However, in thinking of network IO and performance and talking it over with the network admin we were thinking of adding a 2nd nick card to both servers and running the replication commands across there.
So they would have something similar to below:
Yoda: 192.168.XX.51:1433 (Main OLTP Transactions)
192.168.XX.52:874 (Replication Transactions)
Chewie: 192.168.XX.21:1433 (Usual SQL Agent Transaction)
192.168.XX.22:874 (Replication Transaction)
In Microsoft forums I was told that this could be done using Routes. However, I am new to routes in SQL Server so I am not sure where to begin. How would I create one that I can tie to Transaction Replication?
A Windows server may have multiple IP addresses, either on one or across multiple NICs.
After a second IP has been assigned to the host, configure SQL Server to listen to that IP/port using SQL Server Network Configuration.
Here you may modify the port to listen to, but probably unnecessary to use different ports when using multiple IPs. Each IP can be listening to port 1433.
You may create additional CNAMES or aliases to reach the database instance with different host names.
Creating a Valid Connection String Using TCP/IP
SQL Server also support aliases.
During app loading a single user will add 10 connections to the pool. Then if I load another user I will have a total of 20 connections.
Why are new connections being added to the pool instead of reusing connections? I can see that that there are connections available that haven't been used in minutes yet it still opens new connections.
Its the same connection string
I ran SQL Sever Profiler I can see sp_reset_connection being called after every call.
Any help would be appreciated.
If the connections are coming from a different machine, the connections can't be pooled. A connection required both endpoints to be a connection. If you are using connection pooling correctly, applications instantiate a connection (from the pool), use the connection, then drop it as soon as exchange is complete.
If you a writing a single-threaded desktop app, another common and simple strategy is to open a connection, and just leave that connection open as long as the application is running.
You can control how many connections are created, etc. see MS article for more details related to connection pooling.
IIRC, connection pools are not shared unless the connection string is identical either.