It might be very basic question for you friends, but how to allow multiple users on SQL Server installed on remote windows server 2012 machine.?
right now only two user can work at the same time if third one comes one of two who are active has to allow and get out himself.
we are building new server which will allow multiple user to work on the same time.
My question is once we install SQL server on windows server machine what configuration needs to be done to achieve our goal(Multiple user can work on same time) on server machine as well as what configuration needs to be done on computers of people who will be logging into it.
do we need same number of instance similar to how many people will be working on it? if yes it means that many number of same database on the server and more space will be occupied right?
Thanks.
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'user connections', 777;
GO
RECONFIGURE;
GO
Replace 777 with your limit of connections.
Related
I have a SQL Server database project (sqlproj file) in which I have referenced an assembly containing a user-define aggregate function per https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration-database-objects-user-defined-functions/clr-user-defined-functions?view=sql-server-2017
I was unable to deploy or use my function until I did this:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;
...and also:
EXEC sp_configure 'clr enabled' , '1';
RECONFIGURE;
Along the way, I tried signing the assembly (generated a self-signed cert in a pfx), but could not figure out how to get SQL Server to trust the certificate.
As best I understand it, what I've done is acceptable for a local development deployment, but this is not the right way to deploy to a live environment (or to push to an Azure database service).
I've seen advice which suggests deploying to an older version of SQL Server in order to extract a hash of the assembly to use in a command which will establish trust; this is not useful to me because I only have SQL Server 2017 and have no intention of installing something like 2008 just to extract a hash.
What is the sequence of steps I must perform to successfully deploy my custom assembly with my database and establish trust "the right way", and what exactly does each of those steps accomplish? Part of my problem is a lack of clarity around the need, purpose, side-effects, and "meaning" of each required step.
I have a very strange situation on SQL Server that I cannot fathom out.
Environment : SQL Server 2012 SP3 CU3 running on a 2 node Windows 2008 R2 cluster
In SQL Server Management Studio\Management\Maintenance Plans\ I am unable to create or edit existing plans.
I receive the error:
'Agent XPs' component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Agent XPs' by using sp_configure. For more information about enabling 'Agent XPs', see "Surface Area Configuration" in SQL Server Books Online. (ObjectExplorer)
Checking around that error I expected the following config was going to be required.
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO
-- To enable the feature.
EXEC sp_configure 'Agent XPs', 1;
GO
-- To update the currently configured value for this feature.
RECONFIGURE;
GO
However, I noticed that SQL Agent was already running so I thought I would also check existing config options for 'Agent XPs'
What was interesting was that config_value = 0, run_value = 1 where I was expecting config_value = 1, run_value = 1.
I thought I'd try the sp_configure solution to 'force' the config but when I ran it (step by step), the first RECONFIGURE statement just hung and indeed when it ran I could not even run an sp_who2 to see if it was blocking or being blocked.
The only way I could kill the RECONFIGURE was to close the query window which cancelled it. I therefore am unable to run EXEC sp_configure 'Agent XPs', 1 as the required RECONFIGURE cannot be run.
After a failover of the cluster, the config settings for 'Agent XPs'
remains at config_value = 0, run_value = 1.
Has anyone got any ideas as to how to fix it?
I stumbled across an internet post with a similar issue and that contained a nugget of information that allowed me to ultimately fix the issue.
I documented the case over at SQLServerCentral
https://www.sqlservercentral.com/Forums/1927277/SQL-Server-2012-tells-me-Agent-XPs-component-is-turned-off-but-SQL-Agent-is-running
I am in the midst of evaluating default SQL Server 2008 R2 configuration settings.
I have been asked to run the below script on the production server:
sp_configure 'remote query timeout', 0
sp_configure 'max server memory (MB)', 28000
sp_configure 'remote login timeout', 300
go
reconfigure with override
go
Before proceeding on this, I have been trying to gauge the advantages and disadvantages of each line of SQL code.
Edited on 17-May-2016 14:19 IST:
Few Microsoft links that I have referred are as below:
https://msdn.microsoft.com/en-us/library/ms178067.aspx
https://msdn.microsoft.com/en-IN/library/ms175136.aspx
Edited on 23-May-2016 11:15 IST:
I have set the 'MAX SERVER MEMORY' based on feedback here and further investigation from my end. I have provided my inferences to the customer.
I have also provided my inferences on the other 2 queries based on views and answers provided here.
Thanks to all for your help. I will update this question after inputs from the customer.
Following Query will set the query timeout to 0 , i.e No timeout
sp_configure 'remote query timeout', 0
This value has no effect on queries received by the Database Engine.
To disable the time-out, set the value to 0. A query will wait until
it is canceled.
sp_configure 'max server memory (MB)', 28000
amount of memory (in megabytes) that is managed by the SQL Server
Memory Manager for a SQL Server process used by an instance of SQL
Server.
sp_configure 'remote login timeout', 300
If you have applications that connect remotely to server ,we can set timeout using the above query.
Note :
You can also set the server properties via SSMS (management studio) where you can set the maximum and minimum values rather using the codes as shown in your post.
You can very well try these queries ,but settings that you would like to opt in would depend on hardware and application type you are working on.
I would generally say that these statements are quite idiotic. Yes, seriously.
Line by line:
sp_configure 'remote query timeout', 0
Makes queries run unlimited time before aborting. While I accept there are long running queries, those should be rare (the default timeout of IIRC 30 seconds handles 99.99% of the queries) and the application programmer can set an appropriate timeout in the rare cases he needs it for this particular query.
sp_configure 'max server memory (MB)', 28000
Sets max server memory to 28gb. Well, that is nonsense - the DBA should have set that upon install to a sensible value, so it is not needed unless the dba is incompetent. Whether the roughly 28gb make sense I can not comment.
sp_configure 'remote login timeout', 300
Timeout for remote login 300 seconds. Default of 30 seconds already is plenty. I have serious problems considering a scenario where the server is healthy and does not process logins within less than a handful of seconds.
The only scenario I have seen where this whole batch would make sense is a server dying from overload - which is MOST OFTEN based on some brutal incompetence somewhere. Either the admin (64gb RAM machine configured to only use 2gb for SQL Server for example) or most often the programmers (no indices, ridiculous bad SQL making the server die from overload). Been there, seen that way too often.
Otherwise the timeouts really make little sense.
"Remote query timeout" sets how much time before a remote query times out.
"Remote login timeout" set how much time before a login attempt time out.
The values set here could make sense in certain conditions (slow, high-latency network, for example).
"Max server memory" is different. It's a very useful setting, and it should be set almost always to avoid possible performance problems. What value, it depends how much memory is on the server as whole and which other applications/service are running on it. If it's a dedicated server with 32 GB of memory, this value sounds about right.
None of these could be really tested on the test environment, I'm afraid, unless you have an 1:1 replica of the prod environment.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Enable ‘xp_cmdshell’ SQL Server
When I run xp_cmdshell command in SQL Server 2012, I get the following message:
SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell'
because this component is turned off
as part of the security configuration for this server.
A system administrator can enable the use of 'xp_cmdshell'
by using sp_configure. For more information about enabling 'xp_cmdshell',
search for 'xp_cmdshell' in SQL Server Books Online.
But, in SQL Server 2000 this query is executed successfully.
This has been disabled out of the box starting with SQL Server 2005, when they introduced the Surface Area Configuration Tool, in an effort to make SQL Server more secure by default. That tool has since been retired, but you can still control the behavior using sp_configure. An example is shown on MSDN:
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
GO
-- To update the currently configured value for advanced options.
RECONFIGURE
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1
GO
-- To update the currently configured value for this feature.
RECONFIGURE
GO
(I also blogged about this many years ago.)
The reason is that this is a potential security hole. If you allow SQL Server to execute xp_cmdshell, then they can theoretically send any operating system command there, bypassing any and all security you thought you had. This is especially problematic when the SQL Server service account and/or the proxy account have been elevated to sysadmin or other levels because that's easier than explicitly defining only the exact things they should be able to do.
Rather than enable it and disable it to support command-line interaction, a popular way to expose operating system functionality while still having some control over security is to implement the OS-level functionality you need using SQL-CLR. Here is a good starting point for accessing the file system with CLR (however if you search around you will find much more modern and exhaustive approaches).
This is disable for sql server 2012.
But you can run the following command in sql server 2008..
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
For linked servers, I see how it is possible to change the "remote query timeout" configuration to hint a call to a linked server should complete or rollback within the specific timeout value. This appears to work across the SQL Server engine--is it possible to change the hint within a stored procedure, so that a specific stored procedure could run longer if needs to, but all other non-hinted SPROCs would timeout quicker if they run long?
Linked Query Timeout is discussed here:
http://support.microsoft.com/kb/314530
Example code to set it to timeout in 3 seconds is here:
sp_configure 'remote query timeout', 3
go
reconfigure with override
go
Not really advisable to change it within a stored procedure. remote query timeout is a global server setting when altered with sp_configure, so changing it in a stored procedure affects all remote queries for all linked servers on the server.
Additionally, executing sp_configure requires the ALTER SETTINGS server permission, which typically only sysadmin and serveradmin have. Granting these permissions to a data access account would be a security concern since they could potentially take your server down with sp_configure commands.
What I would suggest is creating a second linked server with a different name that you would use with just this one stored procedure. You can, in SSMS, configure a query timeout for each individual linked server. Adding a second linked server would enable you to query the same server with different linked server client settings. You might need to create a DNS CNAME to accomplish this if you're using plain SQL Server Linked Servers.