Can one install Microsoft's SQL Server Agent, without a database instance?
(The aim is to reduce traffic to the database. I would like to put the server agent to an other server.)
Thanks for the help.
SQL Server Agent needs to store it's data (jobs etc) in the MSDB database. So you will need one.
If your SQL Agent really is causing such a massive amount of I/O that it's use of MSDB is slowing down overall server performance (which I doubt is the case, but everything is possible if you try hard enough), then you have the option to move the MSDB data files to a separate disk. (Not just a separate logical drive on the same disk, but a separate disk entirely).
I expect there are many other performance improvements possible before you get to that point though. Moving TempDB to another physical disk would be a good start point.
My question is similar. How can I make my "instance" the default instance, so I do not have to qualify my sql server with the instance name. Although, this is not the exact same question, I was brought here looking for an answer and others might be as well. This solution allows you to still have multiple instances, yet define the default instance.
To do this you need to change the TCPIP dynamic port of your instance to the default 1433 port value. Details on this simple procedure using the SQL Server Configuration Manager can be found here:
https://kohera.be/blog/sql-server/make-named-instance-look-like-default-instance/
Related
I have an installation which has two SCADA (Intouch) HMIs and I want to save the data in an SQL Server database which will be in another computer. To be as sure as possible that I have an operating database I'm going to set a SQL Server mirroring. So I will have 2 SQL server databases with a distributor. About this I don't have any doubt. To make it easy to understand I've made an image with the architecture of the system.
Architecture.
My doubt is how do I configure the Alarm DB Logger to make it point, automatically, to the secondary database in case that the principal database is down for any unknown failover.
PS: I don't know if it's even possible.
Configure it the database in Automatic failover. The connection are handled automatically in case of a failover. Read on Mirroring EndPoints
The below Links should have more than enough information.
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/role-switching-during-a-database-mirroring-session-sql-server
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/the-database-mirroring-endpoint-sql-server
The AlarmDBLogger reads its configuration from the registry, so you could try the following:
Stop AlarmLogger
Change ServerName in registry [HKLM].[Software].[Wonderware].[AlarmLogger].[SQLServer]
Start AlarmLogger
But what about the two InTouch-nodes? What if one of those fails? You would have to make sure one of them logs alarms, and that they don't log duplicates!
The standard controls and activex for alarms use a specific view in the alarm database. You cannot change that behaviour, but you can script a server change in InTouch or System Platform.
Keep in mind that redundancy needs to be tested, and should only be implemented if 100% uptime is necessary. In many cases you will be creating new problems to solve instead of solving an actual problem.
What are my options for achieving a cold backup server for SQL Server Express instance running a single database?
I have an SQL Server 2008 Express instance in production that currently represents a single point of failure for my application. I have a second physical box sitting at the installation that is currently doing nothing. I want to somehow replicate my database in near real time (a little bit of data loss is acceptable) to the second box. The database is very small and resources are utilized very lightly.
In the case that the production server dies, I would manually reconfigure my application to point to the backup server instead.
Although Express doesn't support log shipping, I am thinking that I could manually script a poor man's version of it, where I use batch files to take the logs and copy them across the network and apply them to the second server at 5 minute intervals.
Does anyone have any advice on whether this is technically achievable, or if there is a better way to do what I am trying to do?
Note that I want to avoid having to pay for the full version of SQL Server and configure mirroring as I think it is an overkill for this application. I understand that other DB platforms may present suitable options (eg. a MySQL Cluster), but for the purposes of this discussion, let's assume we have to stick to SQL Server.
I would also advise for a script based log shipping. After all, this is how log shipping started. All you need is a time based agent to schedule the scripts (ie. Tasks Scheduler), and a smart(er) file copy (robocopy).
I have a server with a default instance and 2 named instances of SQL Server 2005 standard installed. This is a mission critical production server that cannot be restarted during normal business hours.
Will uninstalling the two named instances of SQL Server 2005 require a reboot or put the server in a state that may cause issues with the default instance of SQL Server 2005 until it's rebooted?
This would probably get a better answer at serverfault.com.
I'm not sure how much it would help perf, if SQL isn't getting hit it doesn't do much. You could probably get away with uninstalling, but then again when in surgery bad things happen. I've never killed SQL server uninstalling an instance, but I have killed the client tools. I would take one of the following approaches:
a) First, backup and drop all the databases to reclaim the disk space. Then stop disable the services for the named instances. The binaries will still be there, but they aren't too large and will be sitting idle.
b) Better long-term plan if you can source the hardware is to setup a new de novo box and drop a clean SQL instance over there, then port the live server over. Really not too painful. Then repurpose old box as is fit.
Is there a critical reason why you need to uninstall named instances. Can you just ignore them?
EDIT: the answer is yes you can uninstall via add/remove programs
Rebooting doesn't occur
An article which might apply to your situation:
http://support.microsoft.com/?kbid=915854
I have two database servers running SQL Server 2005 Enterprise that I want to make one of them as mirror database server.
What I need is; to create an exact copy database from primary server on mirror server, so when the primary server was down, we could switch database IP on application to use mirror server.
I have examined "mirror" feature on SQL Server 2005, and based on this article:
http://aspalliance.com/1388_Database_Mirroring_in_Microsoft_SQL_Server_2005.all
The mirror database cannot be accessed directly; however snapshots of the mirror database can be taken for read only purposes. (Prerequisites no. 4)
So how it can be useful when I can't access it when primary server was down?
I've been thinking about creating a regular backup on primary server and restore it on mirror server on hourly basis, but that's quite inefficient (slow) especially if I want an exact copy (since hundreds data's are added once in minute).
Any other suggestion?
EDIT:
Maybe what I mean was a replication thing, not a mirror (thanks JP for commenting)
They are referring to the fact that you can't perform queries on the mirrored copy, but you can get around that limitation by creating a snapshot of the mirrored database. This is often done to create a read-only database copy for reporting uses. You would have full access of the mirror if the primary were to fail, but it will not failover automatically.
Log shipping is another option, which allows you to query (read-only) the standby database without having to create a snapshot.
If I understand your question correctly, you shouldn't have to do that. There are several role switching forms you can use to have your mirror take over as primary. You don't change the IP address at the application level, the cluster itself has a virtual IP address that allows access to the data at any given time (given a reasonable amount of time for the switch over to the mirror from a primary failure). The mirror stays in synch by itself. :) There are good articles here and here on clustering.
Edit: Okay, based on the comments, check out the various options for replication.
Your confusion is common - there's a lot of ways to do disaster recovery planning with SQL Server. I've recorded a 10-minute video tutorial of SQL Server disaster recovery options including log shipping, mirroring, replication and more. If you like that one, we've got a longer one at Quest called Disaster Recovery Techniques but that one requires registration.
Instead of investigating a specific technology here, what you might want to do is tell us what your needs are, and then we can help you find out what option is right for you. The videos will give you an idea of what kinds of information you need to know before selecting a particular solution.
When using only two SQL Servers, you need to do the fail-over manually. The 'backup' database will be usable after you do two things;
Disable mirroring on it
Restore the database with RECOVERY (but without a backup file, this will make the database usable).
Therefore mirroring in this manner does make scense, however it is hard to maintain;
Moving back from the backup database to the primary is a 'pain' as you have to set-up the complete mirroring again using a backup of the redundant server. This is needed to get the primary back up to speed.
My recommendation would be to get a thrid SQL Server into the picture that can act as a witness. The witness will monitor the status of the mirroring databases. Your bonus; you will get automatic failover, and will not have the fail-over (and after fail-over) issues.
If I remeber correct, the witness server can be running SQL Express so no need for the Enterprise version on all three - just the two where the actual mirroring will take place.
Let me know if you need Transact SQL for the commands to fail-over and 'anti-fail-over' in a two server scenario, and I can dig them up.
I am not a DBA by any means, but being a web developer means that I will have to install, setup, and administer databases. In the past, I have just followed the default installation for SQL Server. Over time, I have grown smarter and learned that default installations almost always leave doors open and leak.
So...What are the critical settings that should be thoroughly evaluated when installing SQL Server 2005 for someone of my caliber? or 2008? Or is every setting "critical?"
Any good resources that will guide through a "proper" setup of SQL Server 2005?
Every setting is critical - but the things I always double check are:
Authentication type - Integrated or SQL? If SQL, make sure you put in a very strong sa password.
Service Accounts - think through what you want for the accounts. I generally create a domain user for each service separately, and run them with least priviledges.
database paths. Decide up front where you want your system databases & user databases - its much easier to do that during the install than deciding after the fact.
Though this has mostly gone away with 64-bit, I always make sure that "AWE" is enabled if SQL is the only thing running on the server and it's 32-bit. This way, SQL Server has access to all the memory the server has (up to 3GB in a 4GB server) instead of being restricted to the normal 2GB.
I second the opinion that they're all important, and they all have different purposes, so it's a matter of your environment.
Most settings can be accepted with the default settings. SQL 2005 has been changed to be more secure by default.
Be sure to do the steps to prepare accounts to use.
You might also look at your server hardware and try to separate OS, SQL Binaries, Data and Logs onto separate drives.
http://msdn.microsoft.com/en-us/library/ms143516.aspx - for all the juicy details.
Post install, you should set up dbmail and then set up maintenance plans that notify you on failure of backups or maintenance.
Drive configuration! Where you'll place your log and database files is of absolutely paramount importance in terms of performance
My number one setting to check is the server's collation. This will control the collation of the system databases, and you should ensure that the new server's collation is the same as the old one to avoid collation errors. Ideally your user database will be the same collation.
If the two collations are different, and you compare varchar data from TempDB to varchar data from your user database, you'll need to specify the collation.
Just about every other setting can be changed later, but server collation is one that you're stuck with for keeps. (Technically, you can rebuild the system databases with a new collation, but it's not worth the effort, and still requires you to run Setup again).
The Microsoft documentation in Books on Line and elsewhere is pretty thorough and accurate. I think it's the best documentation that Microsoft does. So I'd be rigorous about "RTM" before anything I would write here, which would be incomplete and inadequately explained in any case by comparison.
That said, the first priority should be Do No Harm. I've seen many more cases where imperfect understanding of the consequences of changing the settings has caused problems, than that the default settings need to be altered. (Note: This advice does not apply to MySQL, whose defaults are pretty random IMHO.)