We have a SQL Server VM with a SQL Server instance running on it. Can we install other software on it including the application server on this SQL Server VM? And can we use it as a jump server to connect other SQL Server databases and managed instances?
I have a SQL Server VM with many other software installed on it and it is being used as a jump server. Want to know if we can continue with it or shall not be used for other purposes.
Want to know the cons of this approach.
Thanks & Regards
This is considered a bad practice.
Reasons:
You are using resources (CPU/Memory/IO/Network) from your (expensive) SQL Server
Your SQL Server license is paid by core, so if you would need to scale because of the other applications, this would impact your SQL server licensing cost.
SQL Server will consume the amount of memory that is configured, so if you set it to 90% of that server, your app server won't have any memory to use.
Troubleshooting will become harder because of shared resources.
Security: You'll open more ports then the SQL server ports increasing the attack surface
SQL server also has a specific set of best practices for the host. Eg: Disk Sector size, ...
If you enable lock pages in memory together with apps running on the same server, you are going to have a bad time.
...
So host your applications on a different server preferably in a different subnet for security reasons.
Create a seperate jump box, because remote sessions will always impact performance, even if they are idle.
Related
I have an IaaS SQL Server in which internet is disabled.
We plan to set up ADF integration run time on the database server itself rather than creating a new server just for IR.
In order to set up, we need to install .net framework and internet should be available in that VM.
So do we feel that installing .net framework and enabling internet in IaaS SQL Server is a security risk for the database server and we need to go ahead with a new gateway server or is the above idea great for cost saving and less maintenance purpose
Enabling outbound internet access on a SQL Server is not a security risk, per se. But using a separate server for the Self-Hosted Integration Runtim (SHIR) is generally recommended over installing it on your SQL Server directly because
The SQL Server is isolated from the performance impact of the SHIR
A single SHIR can provide access to multiple data sources.
You can individually size and scale the SQL Server and the SHIR, and the SHIR doesn't need a SQL Server license. So it may not cost any more to run them seperately.
I'm currently working on a project proposal which would require moving multiple Access databases into a new MS SQL Server database. The idea is to keep the front end program as MS Access so that the users are familiar with the process of inputting data and creating reports.
However, things get complicated in that the internet in the areas where the survey will be collected has poor connectivity and will be out from time to time. I had thought of a few ways of solving this issue but all of them are cumbersome:
1) Having a PC with a router that stores the SQL Server database in offline mode and the data entry PCs connect to the PC with the offline database through the router. The PC with the SQL Server database can then backup the db on the server when it has an internet connection.
2) Adding the data to MS Access databases that can then be merged with the SQL Server at specified increments (this would probably cause some issues).
We've done option 1 before for similar projects but never for connecting to an SQL Server database in offline mode. However, it seems feasible.
My question is: Does anyone know of a way of using Access as a front end application for SQL Server and being able to update data during times without internet connectivity? The SQL Server database would automatically assign primary keys, so, duplicate unique values shouldn't be an issue while syncing the data.
Thanks for your help. I've been having a hard time finding an answer on Google and syncing to databases is complicated at the best of times. I'm really just looking for a starting point to see if there are easier ways of accomplishing this.
I would run a the free editon of SQL express on all laptops. So the Access database would be the front end to the local edition of SQL express. SQL express can be a subscriber to the "main" sql database. You thus use SQL replication to sync those local editions of SQL server to the master server. Of course the main SQL server can't be the free edition of SQL server. So to publish the database for replication, you can't use the free edition, but those free editions can certainly be used as subscribers.
This approach would eliminate the need to build or write special software for the Access application. You thus do a traditional migration of the access back end (data tables) to sql server, and then simply run the Access application local with sql express installed on each laptop. You then fire off a sync to the main edition of sql server when such laptops are back at the office.
The other possible would be to adopt and use the net sync framework. This would also allow sync, and would eliminate the need to run sql expess on each machine. I think the least amount of effort is to sync the local editions of sql express with the main editon of SQL server running at the office (but that office edition of SQL server can't be a free edition).
We are working for a client with an asp.net/SQL server application which has been using a SQL Server 2005 system till now. The client has decided to upgrade the database to SQL Server 2008 R2 and has procured a powerful server machine with 16 processors with enough RAM and installed Windows Server 2008 64 bit on the system. Now we are tasked with the installation of SQL Server 2008 on the system followed by migration of the existing DB from the SQL 2005 box. Now I am not a SQL Server DBA nor am I a System Administrator by role. Hence, in spite of reading up a lot of the literature on the net, I am not quite able to make sense of it all or put it in the right order of execution. Can somebody explain me the following items, preferably in terms of bullet lists:
What are the points of consideration during installation of SQL Server 2008, specifically in terms of
Configuring memory usage
Configuring the SQL Server to take advantage of the multiple processors available
Other factors to configure to enable SQL Server 2008 features for performance and scalability
Other points, if any, for configuring the Windows Server 2008 with respect to SQL Server 2008
Note: We will only use the Database Engine services in SQL Server. The applications does not use SSIS, SSRS, etc.
SQL Server will take advantage of whatever processors are available. Processors will be shared between sessions - if all of the work is being done by a single session, then it will all occur on the same processor (to the best of my knowledge - this requires citation).
Memory usage is dynamic by default, meaning that there is no restrication on memory usage. You can limit the memory usage used by the server (right-click on the connection in SSMS and select properties) if needed. This is generally used if the instance is part of a server performing other tasks, such as running other database instances, web service tasks, etc.
SQL server is pretty good it sorting itself out according to its environment. If you are in a position that you need to create a server farm and distribute data and processing between different machines, this is a whole new topic, discussed at length on MSDN and the StackExchange forums.
I am configuring a new environment to run several intranet web applications. I have 2 servers, one will be the SQL Server 2008 server, and the other will be the IIS server. I also need to install SQL Server Reporting Services. I am not sure whether it would be better to run reporting services on the database server, or web server. Is there a best practice for this situation?
Depends...
The reporting services rendering is fairly processor intensive so you need to keep that in mind. Typically if I'm designing a system with heavy load or throughput requirements I place the reporting services instance on its own server. The best practice is really dependent on the complexity of your system.
If a third server is not an option and the two servers you already have are similarly speced I would probably place it on the one with the lowest processor load. If you place the reporting server on the web server make sure that Reporting services uses your dedicated database server for the reporting services meta-data so that you don't have to install the RDBMS on both machines.
You need to keep in mind that if you don't place the reporting server on the same box as SQL server you will need another SQL Server license. The product is only "free" if it is installed on the same machine as SQL.
I would run installer on your web server so that the web service components of Reporting Services are installed there.
It is also benificial to configure reporting services with it's own application domain in IIS so that you can tweak the configurations independant of say your other web applications.
When you run through setup using the Reporting Services Configuration Tool, set up the database on your non web server (i.e. dedicated db server). This way all your data processing is handled on one server and all your web processing/data rendering is handled on another.
Hope this is clear and of use but please feel free to pose further questions.
Cheers,John
What ports or modes of communication do you need to open up for SQL Server 2005 Transactional Replication? Main and slave are geographically separated.
Make sure you enable encryption, otherwise your replicated data could be sniffed by any one in between. The better solution would be to set up a VPN between your two locations to off load the encryption from SQL Server and also provide better security.
I believe TCP Port 1433 is typical although it can be defined by the publisher
Here is a decent article on this.
(Not an Answer)
I regretted using SQL Replication back during the SQL Server 7 days. From what I've seen of SQL Server 2005, The tools have become more unusable.
If I were in your position, I would look at some form of Transaction server that supports replication and set it up as a middle tier between your application and your database(s).