I have a MS SQL 2012 Enterprise server (publisher & distributor) on a desktop PC which is constantly online (public static IP address) and it needs to do a transactional replication on tablet devices that also contain MS SQL 2012 (Express). Since tablets don't use static IP addresses I'm worried will this work?
I thought on using push subscription, but if tablets change their IP's constantly will this work? Or, should I do pull subscription? Or both will be fine?
The IP address won't be an issue as long as DNS is constantly updated to resolve the correct name/IP. I've done this previously with fixed devices (desktop PC's). you may have to bump down the TTL's on those machine names to something pretty low if they reconnect frequently with new IP's.
My .02, I would probably advise against creating a push model at the server because of the dynamic nature of the roaming client. You might want to create the publication at the server side and use a pull style method. If the clients are constantly connecting and disconnecting it will most likely aggravate the distribution agent. If you do use Push you'll want to really consider the frequency of how you build the snapshots and how you handle initializations and expirations.
MSDN suggests the following use cases;
http://msdn.microsoft.com/en-us/library/ms151170.aspx
Related
I have an SQL Server located in the US, I've written a program that connects to a database on the server and takes the data from the server. The users of the program are spread around the world. The majority of them can easily use the program (i.e. the connection is successfully established).
But some of the users who try to run the program from inside their office building can't connect to the server because of their companies' firewalls. Since the number and location of the users is not known (the application is distributed for free with no notifications to me), customizing every firewall isn't really an option (even though it helped when I was able to do this).
I believe there should be an option like a kind of "certificate" that has to be embedded in my program and has to be registered somewhere on a user's machine that would allow establishing the connection. Or anything of that sort. Unfortunately, I haven't found anything specific in the Internet. Most probably because I googled wrong words or so.
Any help or advice is very much appreciated!
If a firewall (or other security device) is blocking, then there is no magic bullet. You need to avoid directly talking to SQL Server.
Even if you changed the port, many of those company workers will be limited to HTTP(S) access, and then only via a proxy.
So you need to talk HTTP to an API you provide, and the implementation of that API then talks (under your control) to the database.
This has the enormous advantage of giving you an extra layer protecting the integrity of the data in the database.
To build a connection you need firewall at client's place to allow access to the ip where your sql server present.
You can give a custom message to the users to allow access to the IP address of the SQL server, but it is not safe to do so due to security concerns.
Instead you can make a third application to take requests from clients and forward it to your sql server. Like some web service. Host this application on public IP and inform the clients that they need to open the IP in their firewall to run the program. It will ensure security as well as your problem will be solved.
I have two windows server 2012 data-center R2 VMs with SQL Server standard 2012 running. I installed my both application and the db server on each of VMs. Both VMs reside within the same cloud service.
Also I setup load balancing between two VMs through port:80. Now it's a matter of mirroring the databases. I tried to setup SQL Mirroring but no luck so far. I'm not sure how these two VMs communicate with each other via the same port 5022.
Also I've done some reading but still I'm not sure what is the possible way of doing this. I definitely need a help now.
Questions:
a) Do I need to set up a virtual network in order to mirror databases?
b) Can I mirror databases resides within the same virtual network?
c) If my assumptions above are incorrect, what is the best way forward on this?
Thanks in advance!!
UPDATE: I managed to setup Principle server in VM1 and both Mirror & Witness servers in VM2 (If you have resources best way to have them in separated VMs). Both VMs reside within same Virtual Network and same cloud service.
So when the Principle is not available, Witness automatically set the Mirror to Principle and it's no longer in the recovery state.
If you're planning to have both Witness & Mirror SQL instances within the same server, Make sure you use a different Port for Witness server.
eg.
- Principle : 5022
- Mirror : 5022
- Witness : 5023
They can be in same Cloud Service and placing them into the same CS will make life simpler, because of no need to deal with public endpoints. In fact Cloud Service is just a container for VMs and/or Roles that's also associated with an implicitly created network (thus you need an endpoint to access it from outside).
It is also recommended to put VMs into the same Availability Set, in this case Azure will try to do not shutdown all the VMs at the same time.
The simplest way to setup DBM is to use certificates. You can see example here.
Note: don't forget to setup witness if you need an automatic failover.
In order for two Azure VM's to talk they need to be set up in the same affinity group.
A virtual network is a specialized affinity group, where you are able to control the IPs.
Once the virtual network is set up, you should have no problem setting up replication for your database.
We're getting ready to build a new platform for our current system. Currently we install sql server express locally to all our clients and all their data is stored there. While the process works pretty good, it's still a pain to add columns/tables etc. We also want to have our data available outside of the local install. So we're moving to a central web based sql database and creating a web based application. Our new application will be a Silverlight 5, wcf ria services, mvvm, entity framework application
We've decided that either a web hosted sql server database or sql azure database are the way to go. However, I have no idea why I would choose one over the other. The limitations of azure don't seem to apply to us, but our application will be run on our current shared web host. Is it better to host the application on the same server as the database? Do we even know with shared web hosting that the server is on the same location as the app? There's also the marketing advantage of being 'in the cloud' which our clients love when we drop that word (they have no idea about anything technical, it's just a buzzword for them). I'm not too worried about the cost as I think both will ultimately be about the equivalent of each other.
I feel like I may be completely overthinking this and either will work, however I'd like to try and get the best solution for us and don't want to choose without getting some feedback.
In case it helps, our application is mostly dashboard/informational data. Mostly financial and trending data. It's almost entirely read only. Sometimes the data can get fairly large and we would be sending upwards of 50,000 rows of data to the application.
Thanks for any help/insight you can provide for me!
The main concerns I would have with using a SQL Azure DB from an application on your current shared web host would be
The effect of network latency: Depending on location, every time you do a DB round trip from your application to the SQL Azure DB you will incur a 50-100ms delay. If your application does lots of round trips, this will mount up. Often, if an application has been designed to work with a DB on the LAN (you use of local client DBs suggests this) the they tend to get "chatty" since network delays are very small on the LAN. You may find your application slows down significantly.
Security: You will have to open up the SQL Azure firewall to the IP address(es) that your application presents when querying. Depending on your host, it may be that this IP address is shared between several tenants. This would be a vulnerability.
If neither of these is a problem, then SQL Azure will provide a much lower management overhead (e.g. no need to patch etc.) and will give you very high reliability, especially in terms of the risk of data loss.
I am upsizing an MS Access 2003 app to a SQL Server backend. On my dev machine, SQL Server is local, so the performance is quite good. I want to test the performance with a remote SQL Server so I can account for the effects of network latency when I am redesigning the app. I am expecting that some of the queries that seem fast now will run quite slowly once deployed to production.
How can I slow down (or simulate the speed of a remote) SQL Server without using a virtual machine, or relocating SQL to another computer? Is there some kind of proxy or Windows utility that would do this for me?
I have not used it myself, but here's another SO question:
Network tools that simulate slow network connection
In one of the comments SQL Server has been mentioned explicitly.
You may be operating under a misconception. MS-Access supports so-called "heterogeneous joins" (i.e. tables from a variety of back-ends may be included in the same query, e.g. combining data from Oracle and SQLServer and Access and an Excel spreadsheet). To support this feature, Access applies the WHERE clause filter at the client except in situations where there's a "pass-through" query against an intelligent back-end. In SQL Server, the filtering occurs in the engine running on the server, so SQL Server typically sends much smaller datasets to the client.
The answer to your question also depends on what you mean by "remote". If you pit Access and SQL Server against each other on the same network, SQL Server running on the server will consume only a small fraction of the bandwidth that Access does, if the Access MDB file resides on a file server. (Of course if the MDB resides on the local PC, no network bandwidth is consumed.) If you're comparing Access on a LAN versus SQL Server over broadband via the cloud, then you're comparing a nominal 100 mbit/sec pipe against DSL or cable bandwidth, i.e. against perhaps 20 mbit/sec nominal for high-speed cable, a fifth of the bandwidth at best, probably much less.
So you have to be more specific about what you're trying to compare.
Are you comparing Access clients on the local PC consuming an Access MDB residing on the file server against some other kind of client consuming data from a SQL Server residing on another server on the same network? Are you going to continue to use Access as the client? Will your queries be pass-through?
There is a software application for Windows that does that (simulates a low bandwidth, latency and losses if necessary). It not free though. The trial version has a 30-sec emulation limit. Here is the home page of that product: http://softperfect.com/products/connectionemulator/
#RedFilter: You should indicate which version of Access you are using. This document from 2006 shows that the story of what Access brings down to the client across the wire is more complicated than whether the query contains "Access-specific keywords".
http://msdn.microsoft.com/en-us/library/bb188204(SQL.90).aspx
But Access may be getting more and more sophisticated about using server resources with each newer version.
I'll stand by my simple advice: if you want to minimize bandwidth consumption, while still using Access as the GUI, pass-through queries do best, because then it is you, not Access, who will control the amount of data that comes down the wire.
I still think your initial question/approach is misguided: if your Access MDB file was located on the LAN in the first place (was it?) you don't need to simulate the effects of network latency. You need to sniff the SQL statements Access generates, rather than introducing some arbitrary and constant "network latency" factor. To compare an Access GUI using an MDB located on a LAN server against an upsized Access GUI going against a SQL Server back-end, you need to assess what data Access brings down across the wire to the client from the back-end server. Even "upsized" Access can be a hog at the bandwidth trough unless you use pass-through queries. But a properly written client for a SQL-Server back-end will always be far more parsimonious with network bandwidth than Access going against an MDB located on a LAN server, ceteris paribus.
I am trying to get our DBA's to enable DTC on a cluster of SQL Server 2005. Unfortunately they keep refusing. Their argument that they would need to set up a dedicated host for DTC (Could take months!!) as it is not a matter of ticking a few boxes. Is this true? How intrusive is DTC on a shared environment such as a SQL farm. Do I have an argument against this?
Thanks
Had to tone down the original response your 'DBA' team deserve!
In response to your questions:
Dedicated server - Not at all. Everywhere I've worked with clusters, the DTC service is installed when the cluster is commissioned. Typically it sits in its own resource group or within the cluster group. If in its own group its usually sits on whichever server is hosting the cluster group.
Intrusive? - Absolutely not. It should be installed when the cluster is created, as per MS best practice.
Do you have an argument? - You most certainly do. The links below should cover the why and how for getting it installed:
MSDTC and SQL on a Cluster
Clustered SQL Server do's, dont's and basic warnings
DTC needs to be enabled and running on both sides of the connection. In my organization, it took some research to figure out which four boxes to check and then some hand-holding to get those boxes checked on all db servers, all app servers and most laptops. There's still a couple of hold-out developer laptops... but they're ok as long as they don't write. :)
You should have some driving scenario (such as an atomic multiple database write) to hit the DBA's over the head with. Give them some time to guess at alternatives... then let them know that DTC is the only hammer for this kind of nail.
I'm unsure of the implications of DTC on a SQL farm. I imagine the whole farm could get involved in the transaction if it involves enough data... which can't be a good thing.