Dears,
in Sybase ASE warm standby replication, while a standby database is in far distance from the active one, what is the bandwidth required for better performance in transferring and applying transactions to the standby database?
Regards
Related
Is there anyway to identify by how much time we can get a deadlock when we enable Snapshot replication for our subscriber, we have a subscriber considered as Azure SQL Database, and we have 8 databases one of them consists of 200GB in size. Is there any way to identify the downtime for genereating snapshots?
We have a master SAP Sybase database A in country C1 and we need a read only copy of the sybase database B in country C2 (currently hosted in hyper-v). We are currently doing this backup using full and incremental backup. The problem is that it is taking too long to mail the tape and do full database restore at the site B. We have established a VPN connection and the bandwidth is not big. We can accept a few day latency. What are my options besides (using replication server) to do this database synchronisation as corporate situation do not allow spending of extra $.
Our full corporate backup data amounts to 5 TB in size.
Thanks.
Patrick
Without using Replication Server, the simplest solution is probably to use log shipping. This utilizes the transaction log from one database to synchronize another database.
After an initial dump of the Database A has been loaded in Database B, you would setup scheduled transaction log dumps, and load those dumps in Database B. After the initial load, the dump sizes would depend on the database transaction rate, so the more activity in the database, the larger the dumps will be.
A couple of things to note:
This will likely require more transaction log storage space on Database A.
Database B will not be accessible during the transaction loading time.
A good description of this and other options can be found in this SAP article on Business Continuity
Does anybody know how transactional replication have impact to performance of publisher database? I want to use a subscriber as a base for generate on-line reports and statistics (use transactional replication for copy data), but I don't know how it could reduce performance of source database (or not).
The source server: SQL 2005 Standard, VMWare, 4 CPU (16 cores), 16 GB RAM
The destination server: SQL 2005 Standard, VMWare, 1 CPU (4 cores), 8 GB RAM
Well... yes and no. Transactional replication is asynchronous, so it's not as though your performance will slow down merely because there's a publication. However, depending on how much extra horsepower you have to spare on the server right now, the log reader might put you over the top. Also note that the semantics of when a log record can be cleared from the transaction log change with transactional replication, so be careful there.
What is transaction replication used? I seemed to create transaction replication following this tutorial:
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/
And I know when I change some objects i.e any DML or DDL statement, those changes will be reflected to the other server where I did replication. But it's not clear to me why should we use transaction replication. Does SQL server automatically start using the 2nd server where replication was done when the main instance fails? or do we have to manually restore the database from the server where replication was done in case of failure of 1st instance?
Thanks in advance :)
You can use transactional replication to maintain a warm standby SQL server. Transactional replication replicates the data on one server (the publisher) to another server (the subscriber) with less latency than log shipping.
You can implement transactional replication at the database object level such as the table level. Therefore, Microsoft recommends that you use transactional replication when you have less data to protect, and you must have a fast data recovery plan.
This solution is vulnerable to the failure of the publisher and the subscriber at the same time. In such a scenario, you cannot protect your data. In all other scenarios such as the failure of a distributor or a subscriber, it is best to resynchronize the data in the subscriber with the data in the publisher.
You should use transactional replication to maintain a warm standby SQL server only when you do not implement schema changes or you do not implement other changes to your database such as security changes that replication does not support.
Note Replication is not designed for the maintenance of warm standby servers. With replication, you can use replicated data at the subscriber to generate reports. You can also use replication for other general uses without having to perform processing on your relatively busy publisher.
Disadvantages
Schema changes or security changes that are performed at the
publisher after establishing replication will not be available at
the subscriber. The distributor in transactional replication uses an
Open Database Connectivity (ODBC) connection or an OLE Database
(OLEDB) connection to distribute data. However, log shipping uses
the RESTORE TRANSACTION low-level Transact-SQL statement to
distribute the transaction logs. A RESTORE TRANSACTION statement is
much faster than an ODBC connection or an OLEDB connection.
Typically, switching servers erases replication configurations.
Therefore, you have to configure replication two times:
a. When you switch to the subscriber.
b. When you switch back to the publisher.
If a disaster occurs, you must manually switch servers by
redirecting all the applications to the subscriber.
Read more here http://sqlserverdatarecovery.com/transactional_replication.html
I am tasked with setting up a disaster recovery for one of our system. The primary server is in FL and the secondary is in Germany. The application is a global application within my company.
I am not sure if I should use Log shipping or Mirroring. What I have read is that mirroring will have an adverse effect on the performance of my application. Is this true? Does this mean that any time a user modify or save a record that it will take longer to get a positive response.
Thanks
Mirroring can have different performance impacts depending on the operating mode you choose. If you are mirroring you can have three operating modes: High Protection (with and without automatic failover) and High Performance.
Basically, these amount to synchronous and asynchronous mirroring. With High Protection your application will be waiting for the mirroring to finish before considering the transaction complete. In High Performance mode your application will not wait for the mirroring to have been committed. In fact, it is not guaranteed at any point in time that all the most recent transactions will have been saved in the mirror's transaction log.
One of the main factors to consider with mirroring will be the round trip time of your network. Higher latency will impact more heavily on your performance. You will need to weigh the performance cost against your specific recovery (and failover) requirements.
If you haven't already, you should read Database Mirroring in SQL Server 2005 and
Database Mirroring Best Practices and Performance Considerations.
Mirroring would keep both the primary and DR environments in synch 100% of the time and thus eliminate the possibility for data loss. However, as you noted, this has an adverse affect on performance, but may be necessary in situations that cannot tolerate any data loss (ex. financial applications). Shipping logs and applying them to the standby database at the DR site doesn't have the same impact on user response time, but opens up a small period during which data loss could potentially occur.
Mirroring is operate synchronously (wait until the log is committed to DB), usually deploy on good network connection (LAN)
Log shipping is operate asynchronously (will not wait the log is committed to DB), usually deploy over MPLS / VPN or slow network
so for your objective, u should use Log Shipping