I am having some difficulty in determining how best to implement the different parts of reporting services.
Our company has just bought a new slew of servers and a shared SAN to support our growing infrastructure.
Our servers are running VMware and we have several virtual machines each with their own tasks load balanced across the set of physical machines. We currently have an application server which runs terminal services, and a SQL box which runs 2005 to hold our data, as well as several others for other purposes unrelated to our database.
My question is:
What would be the ideal installation of reporting services in a virtual environment? We will still be dealing with the same amount of resources if we install everything on our current SQL box, or slice up the installation into several virtual machines. Slicing the configuration into distinct machines would help load balancing, but slicing it up will also require more licenses.
My current thought was to install the report server database on the same box that currently has our sql databases and install the report server service on another box to keep iis off the sql box with our operational data.
How difficult would it be to migrate from one configuration to another, or would i be pretty much locking myself into something once a decision is made?
Editing: Adding my options
The different configurations i can think of
A) benefit : easiest to set up. downside : scale out requires migrating back end
1. SQL Data Box holding our production data
2. Reporing Services DB, Reporting Services Service, and IIS
B) benefit : supports scale out without migrating back end
1. SQL Data Box holding our production data, and Reporting Services DB
2. Reporting Services Service, and IIS
C) benefit : best for load balancing virtual machines across hardware, supports scale out without changes. downside : most expensive for licenses
1. SQL Data Box holding our production data
2. Reporting Services DB
3. Reporting Services Service, and IIS
D) benefit : cheapest for Licenses. downside : lots
1. Everything on one box
So options A or B are my front-runners, with B having no drawbacks i can think of, but not sure what kind of load reporting services has on it's database if that would be a noticeable impact as the production data box will be being queried for the raw data as well. Option A would allow me to slice off a new virtual server and play with it while developing and keeping everything off our production box and we could then change our data sources to point to the production box and roll it out.
I'm still not sure what the best option is, so if anyone else has opinions they would be welcomed.
Thanks again, Wesley
I have never done it but this article tells you how to do the remote install which is pretty common.
This article tells you how to move the database to another machine. Presumably this would allow you to migrate between both methods.
Personally I would try to pick the option you are hoping to stick with because in my experience with microsoft, installation instructions are more reliable than migration instructions.
Related
I have an ASP.NET Web Application that is connected to a Database that is installed in several clients in production environment.
Some of those clients manage critical information (in other schemas, not accesible for the Web App, like people's money) so the access to execute scripts directly in the database to fix things in my Web App, if it's needed, requires time and also approbation, sometimes it takes weeks..
As some of my clients have a volatile reallity, my Web App has to manage a lot of changes in some short periods of time, that means script executions in the database to alter data or schema, and that means time waste !
Long story short, my question is, is it a good practice to implement a page, only for administrator users, that executes a raw query directly to database?
Think in the scenario where security issue is managed properly.
Something like: Sql Pad where you cannot see the entire database system, just the query and the result as the target database is only one.
No. It's a terrible idea. The security issue is probably not manageable - a web page that's available on the public internet which grants schema modification rights to the logged in user is a horrible security risk. Even if you can't get to another schema, you can easily bring the server to its knees by writing simple SQL which consumers all CPU, memory or disk space.
It's also terrible because you lose any track of what changes were installed in which environment.
If the IT department won't approve your scripts when run from management studio they certainly won't let you loose on your own via a web interface.
I've always solved this problem via automated deployment scripts - execute the schema changes etc. as a part of installing the new version of the web application. That way, you can do things like back up the database before running your changes, keep track of versioning and control access.
Hello I am looking for a little Direction / Guidance. I have built an application in vb.net using visual studio for my company that manages people and equipment. This application is installed on multiple computers in the office and updates a Microsoft Access Database which resides on one of our local Network Servers in the Building. What my goal for this is to have the application access the database from any location in or out of the network. I originally built this around an Access Database because it seemed the easiest at the time, I would like to re-create this in an SQL Database but am unsure how to and or what I need to do so I have this access with the application. I am confused to how the SQL database would work with the remote access I guess.. Do I need to have an SQL Engine installed on the Server or can I have the Database file just sitting there and access it through the IP with Username and Passwords? Should I purchase server space somewhere else and go that route? Is there any links or information anyone could direct me to, I have been reading about this for days but am not getting anywhere.. Just looking for some black and white answers to steer me in the right direction!!
Thanks Everyone!
I would recommend Azure. This article describes the process for migrating from Access to Azure:
Migrating Access Databases to SQL Server/Azure SQL DB (AccessToSQL)
All major SQL RDBMS client/server systems are built around the premise that clients will he accessing the relational database management services over a network (almost always over TCP/IP for anything developed or updated within the last couple of decades).
For the nodes (clients) on your local area network this should be relatively straightforward.
For remote access I strongly recommend requiring that they access your network through a quality VPN which has been professionally configured (and, preferably, is being professionally maintained).
As for the question of locally owned equipment vs. a virtually private server (VPS) that's mostly a cost consideration with tradeoffs on reliability of access, reliability of the hardware and storage, reliability and capacity of the backup systems, and the personnel costs and availability.
A well managed VPS offering can get you past all the preliminary hurdles to the point where you can focus on your development right away. The long term decisions about Tue production environment are best deferred until you have some functionality prototyped.
We are currently migrating our whole IT systems (application server, web server, DBMS etc.) to a new datacenter. The systems used before have been spread out across several datacenters in Europe and one of the goals for this migration was to have it all in one place, in one private cloud. After an initial migration of the productive systems on a particular day, we are right now reconfiguring the whole systems, going to be testing them thoroughly. Afterwards we will have to bring the newly migrated, configured and tested systems to the latest version and will use the new system.
The systems so far have been using several large SQL Server 2008 databases, transferring them to the new datacenter has been quite painful, and had to be done via harddrive, since the outgoing network connection from that old location is only 10 Mbit. So I don't want to use a brute force approach to redo the whole way through using a harddrive, so transport the whole databases, I'd rather like to use database tools to get the job done.
I've heard of several technologies applicable for this, varying from SQL Server Replication to the Sync Framework, but I would like to know which of them would be the best for a one time synchronization of such larger databases, having especially in mind the rather slow outgoing network connection and a forced disconnect every 24 hours at that old Location.
I'd still go for Sync Framework, but the more I read about it, it seems to be rather targeted for scenarios where you want to implement periodic updates between several databases, so I'm unsure if I overlooked a rather simple and easier solution for this synchronization.
Im looking at developing a simple ecommerce platform and need to replicate product and customer data to the web host over the internet so the website can run disconnected. The two options i can think of at present are using enterprise messaging and database replication.
Im leaning towards database replication over enterprise messaging as enterprise messaging would require additional developer resource to write all the plumbing code. Anyone have any success using sql server one way replication over unreliable wan links through the internet?
I'm sorry I missed this... NitroAccelerator from Nitrosphere.com is built exactly to speed up replication over the internet. It compresses the TDS packets very efficiently and results in 80-90% improvement in replication times.
In the last company I worked for we had full merge replication for some of our customers.
There were 2 scenarios
Merge Replication for hanadheld devices
Some of our customers had PDAs and they subscribed to some published tables of our main database. They were disconnected for large periods and merge replication worked fine and updated changes on both sides when the connection was restored
Full site to site Merge Replications
This was used for customers that had remote offices but required a fully synchronized local database for performance reasons. In most cases the VPN was extremely poor and we did have some instances of the VPN being down for a week and on restoration replication synchronized both database without an issue.
In both cases replication seems to be very fault tolerant and performed very well.
In your case its one way replication so there should not be no merge conflicts to deal with making the situation easier.
There is a learning curve with replication but as a technology it works very well I found even over poor connections.
Liam
I am trying to find out what my options are for SQL Server hosting. The reason I am asking is because it always seems to be a problem getting the right kind of hosting for SQL Server. I mostly need a few small databases(<3Mb) for testing or to temporary store some data for clients when I am working on their website.
I could just pay 60-80 euro for a database each time I guess but that seems really expensive for a database with limited data and almost no bandwidth usage.
It can be really frustrating sometimes and it feels like I am always giving up some development "freedom" when I want to work with SQL Server. On the other hand it works so well with Asp.net so maybe that's the price I have to pay for using SQL Server.
So I was wondering how other people deal with this?
If you are truly a web company, I'd strongly suggest that you consider investing in a dedicated server. If this is just for fun/experimentation, of course, then this may well be too expensive.
When I started out, I leased a server with both IIS and SQL Server already installed (managed by MaximumASP, btw) and then added Databases and Sites to the server as needed. I believe that you can even do this with "Virtual" dedicated servers to keep costs fairly low (e.g. < $100 / month). Growth, of course, will push you to more sophisticated configurations like it did for me (e.g. dedicated SQL Servers, multiple server web farm, etc.). But if you don't start out with a solid foundation, you'll never get the growth.
SQL Azure.
Presuming your apps will play well with Sql Express, get a small virtual box for client QA and profit.