Tag Info

New answers tagged

0

Put the distributor in a virtual machine, and use the hypervisor's high availability tools. This lets you survive host hardware failure. OS problems will still cause issues, though, so for an additional level of protection, you can run clusters inside virtualization.


1

is there a risk that something can get corrupted regrading data and availability group listener No, tempdb is recreated when SQL server restarts. If your tempdb is large, Make sure to enable instant file initialization for data files only. The instructions are fine and follow the comment that I put in.(will add it in answer later)


2

Firstly I should say great question usr. Sean, Robert and Max have both correctly stated that due to the re-negotiation between the Primary and Secondary, that the correct LSN is always resolved so that there is not possibility of any discrepancy in that scenario. In response to the discussion with Shanky, in Synchronous mode, the Commit first has to occur ...


1

There is no other way to enable service broker except taking that database out of AlwaysON Availability group, enabling service broker and then joining it back. If you know that your source database has service broker enabled, then when you restore the database, use RESTORE .. with ENABLE_BROKER, so that you dont have to go with such trouble again. If you ...


0

You can restore transaction logs on top of a copy-only full backup--this means that you can use a copy-only backup from the secondary replica along with transaction logs, and accomplish point-in-time recovery. However, if you are only performing copy-only backups on the secondary replica, you won't have a "real" backup to reset the differential bitmap on ...


2

No. Full recovery model is a prerequisite of AlwaysOn Availability groups as per the check list here, and minimally logged operations are only available under Simple or Bulk Logged recovery. Quote from the Data Loading Performance Guide: Minimally logged operations are available only if your database is in bulk-logged or simple recovery mode. Re ...


1

Converting my comment to answer : You can use SQLCMD.exe -S <AG listener> -D <AG database> -E. You may want to specify AGlistener,port_no to see if you can connect to the listener.


0

You are just not catching it at the right times, there are lots of operations that will use the transaction log. When do you do maintenance if any (defragment indexes, CHECKDB, etc.)? These all use the transaction log. Do you have any jobs that load/modify data at night? These operations can use the transaction log as well. As Jon Siegel suggested, use ...


2

Assuming these are not contained databases, you need to worry about the logins (server level), not the users (database level). Contained users will be transferred automatically without difficulty. Manually creating a login with the same name on the other server is not good enough - the SID will not match. Robert Davis has written a post that describes how ...


0

If your not planning on going the contained database route you may want to consider running the procedure sp_helprev_login and in the output find the account you are needing and copying the create user information and run it on the other nodes of the AG.


1

The first attempt would be to try to get either the primary replica back online, or to get the synchronized secondary replica online to ensure that there is no data loss. But provided this is a true disaster recovery scenario (as your original question implies), then it would seem as though your actual cluster (WSFC) has failed. With the database entering ...


1

An alternative you haven't considered is DNS. Obviously changing the connection string is easiest, but if that is a problem for some reason, you could leave the connection strings alone and remap using DNS. More importantly, think about these questions: Why do you need to rename the server/cluster? Is the rename essential to business processes, or is it ...



Top 50 recent answers are included