I am a newbie to database administration. I am trying to get things sorted out but as I study more and more about oracle database backup I get more messed up, so I've decided to ask here. Please accept my apologize if I say something ridiculous :p.
Here is my "simple" situation 1:
Assuming I have 2 server rack, one is my Primary Server, another is my Backup Server (Both server sitting in the same site).(Using Oracle 11g), When the Primary Database broke down, the primary database service will point to backup database. Therefore, the backup database must always be updated from primary database, like a mirror. So my questions are:
What backup method suits this situation? Oracle Dataguard? Oracle Stream? Oracle Goldengate?
Can Oracle Active Dataguard achieve this approach?
If Oracle Active Dataguard can achieve this, the redo-log will only be applied when there is a switchover? So if the primary database broke down and the redo-log only starts to apply into the backup database, I'll have some downtime before my production can resume? This production requires 0 downtime.
Please feel free to comment on the database architecture base on the following requirements and feel free to change it if it is not correct.
Requirements:
No downtime. The site is running 24/7.
Auto switchover to backup database without human interaction.
Able to notify administrator after switchover (If the switchover is completely transparent, no one will realize something went wrong with the primary database right?)
Thank you so much.
P/s: Sorry for my horrible english.
As per your requirements, Oracle data guard is the best solution. Oracle goldengate uses replication concept. Oracle data guard is purely for high availability. There are various protection modes exist in data guard. You can set protection mode for minimum data loss. During Active data guard, standby database (here on backup server as per your detail) is also available for querying and executing read only operations like generating reports. This feature is used for decreasing load on production (here primary server). During this stage, your standby database (backup server) is open in read only mode and also accepting changes (redo) from primary database. It means, it is still updating in background and syncing. There is very minimum chance of data loss and minimum downtime during this stage. Using dataguard, you can set automated switchover task too.
In older versions of Oracle (prior to 11g), if we open standby database in read only mode then it does not accept changes from primary database. If primary database will crash in this situation then we need to apply all changes to standby database manually and wait for data synchronization after that we can switch.
You need to study your technical requirements, consider your IT budget for using these features because Oracle dataguard is license product.
Related
I have an application that is in production with its own database for more than 10 years.
I'm currently developing a new application (kind of a reporting application) that only needs read access to the database.
In order not to be too much linked to the database and to be able to use newer DAL (Entity Framework 6 Code First) I decided to start from a new empty database, and I only added the tables and columns I need (different names than the production one).
Now I need some way to update the new database with the production database regularly (would be best if it is -almost- immediate).
I hesitated to ask this question on http://dba.stackexchange.com but I'm not necessarily limited to only using SQL Server for the job (I can develop and run some custom application if needed).
I already made some searches and had those (part-of) solutions :
Using Transactional Replication to create a smaller database (with only the tables/columns I need). But as far as I can see, the fact that I have different table names / columns names will be problematic. So I can use it to create a smaller database that is automatically replicated by SQL Server, but I would still need to replicate this database to my new one (it may avoid my production database to be too much stressed?)
Using triggers to insert/update/delete the rows
Creating some custom job (either a SQL Job or some Windows Service that runs every X minutes) that updates the necessary tables (I have a LastEditDate that is updated by a trigger on my tables, so I can know that a row has been updated since my last replication)
Do you some advice or maybe some other solutions that I didn't foresee?
Thanks
I think that the Transactional replication is the better than using triggers.
Too much resources would be used in source server/database due to the trigger fires by each DML transaction.
Transactional rep could be scheduled as a SQL job and run it few times a day/night or as a part of nightly scheduled job. IT really depends on how busy the source db is...
There is one more thing that you could try - DB mirroring. it depends on your sql server version.
If it were me, I'd use transactional replication, but keep the table/column names the same. If you have some real reason why you need them to change (I honestly can't think of any good ones and a lot of bad ones), wrap each table in a view. At least that way, the view is the documentation of where the data is coming from.
I'm gonna throw this out there and say that I'd use Transaction Log shipping. You can even set the secondary DBs to read-only. There would be some setting up for full recovery mode and transaction log backups but that way you can just automatically restore the transaction logs to the secondary database and be hands-off with it and the secondary database would be as current as your last transaction log backup.
Depending on how current the data needs to be, if you only need it done daily you can set up something that will take your daily backups and then just restore them to the secondary.
In the end, we went for the Trigger solution. We don't have that much changes a day (maybe 500, 1000 top), and it didn't put too much pressure on the current database. Thanks for your advices.
I have a production Server say ServerA I have setup log shipping to ServerB which is left in read-only mode. The purpose of this log shipping is to lower the load on production server for some expensive queries (painful reports).
Now if I have to create some logins using our domain accounts. I cannot do this because the secondary database is in standby mode.
I thought if I create these logins on Primary server it will be copied over to secondary server then the logs are restored there but this isnt the case.
I have done a lot of research online finding a way around to this. I found the following resources for this. I tried every method suggested in this articles but none of them seems to work.
1) Log Shipping in SQL Server 2008 R2 for set BI on replicated database
2) How to transfer logins and passwords between instances of SQL Server
3) Orphaned Users with Database Mirroring and Log Shipping
Has someone experienced the same issue? what did you do? Is there any way around for this issue? Any suggestions any pointer please.
Ali,
Of course I am crafty ...
Check out these articles.
http://technet.microsoft.com/en-us/magazine/2006.05.sqlqa.aspx
http://blogs.msdn.com/b/reedme/archive/2009/04/24/log-shipping-database-snapshots-bummer-dude.aspx
Database mirroring is a better solution since you can create a snapshot and report off that.
However, both mirroring and log shipping have the database in read only state. Therefore, you can not change the orphaned users.
The best way is to make sure your login's on both servers match. Therefore, orphans will not occur.
I your case, you might have to remove log shipping, create the login's on the DR server, drop the database, reseed the DR server with a backup and restart shipping.
In this area, I am not speaking from experience since I always used clustering with a SAN.
Please test this out in a lower environment to work on any gotchas.
My upcoming project will be using Always On (with 1 primary, 1 secondary) = mirroring if synchronous or log shipping if asynchronous. But Always On allows for read only secondaries, which is nice.
Please write back on how you make out. I am curious.
Take care my friend.
J
Recently I had to implement transactional replication to have a live copy of that database on another server for reporting purposes. While configuring replication I realized that a lot of tables didn't have a primary key, so I could not publish all the tables I wanted to.
Second option was to implement merge replication but that would have added a GUID column to all the tables. Since it is a database for a vendor application and vendor has warned us to not "touch" the database structure because any change in the database structure can cause their application to break. So merge replication is not an option anymore.
I have been doing some research on other available options for me in this scenario; the only thing I could find is Log Shipping. I know it will leave my database in Read-Only mode but (to my knowledge) since this is the only option I am left with and it will be strictly used for Reporting purposes only I think I can live with this.
Can anyone suggest a better solution for this? Or is Log Shipping the only option left for me?
It is SQL Server 2008 R2 64-bit DataCenter Edition.
Your other options are:
Database mirroring, and using a snapshot for read-only operations. It can be a pain to manage snapshots.
Upgrading to SQL Server 2012, and make use of Readable Secondaries in Availability Groups. This can be a pain in the wallet.
You mention log shipping but, based on your follow-up comments I don't think it's clear that, every time you restore a log to the log shipped copy, you need to kick out all of the users that may be running reports. This is because you need exclusive access to the database in order to restore the log. This is another case of "you get what you pay for" - you can log ship to Express instances, if you want to (and if your database supports it), but it's not exactly a watertight solution.
I just wanted to know what you guys think about this.
I have an app written in Visual Basic .Net as my front end and and Oracle 11g Standart database as the back-end. So I have like 20 pc's running this app locally. They're all inserting, updating, deleting data on this single database. I want to develop a solution in the case that the server database crashes or cannot stay on line. So i think of having oracle 10g XE on each pc. Thus all the data will be stored in the local db. I think about running a proccess once in a while (ex. every 15 minutes) to send/get the data to/from the main server. What do you think about this strategy?
Oracle does have a mechanism for sharing data between databases, called Replication. Oracle XE supports Basic Replication (read-only and updateable materialized view site only). Obviously it depends on the specifics of your requirements, but from the little you have given us this might be a viable solution for you. Run each POS off its own Oracle XE database with regular synchronisations to the main (master) database.
Each POS has its data in updatable materialized views. That is, it can read and write its own data to the local XE database. These materialized views are part of a replication group which synchronizes their data with a master table in the main database. Going the other way the main database pushes its product data to read-only materialized views in the POS databases. The value of this architecture is that the POS always connect to their local XE databases, and never connect to the master database. This is a lot cleaner than connecting to the central database most of the time and switching to local databases in an emergency.
Unfortunately the documentation is a bit confusing, because it is called Advanced Replication and doesn't really mention "basic replication" at all. But Basic Replication covers most things - Advanced Replication is mainly Writeable Materialized Views and Multi-Master replication, neither of which you need anyway. I'm not saying Replication is easy, because it does cover some tricksy concepts. But using Oracle's built-in functionality has surely got to be better than rolling your own.
Note that your system would still be extremely exposed to the failure of the main database. Your client may think another Oracle license is a bit pricy (I wouldn't disagree). However, in extreme cases, failure to recover a database can kill a company.
This sounds like an horrendous idea. Duplicating data from one database to another is a complex subject. The process you're describing involves 20 duplications !
To be of any use in the event of a crash, you will also need a two-way replication mechanism: the 20 clients will continue to update their local DB. How do you deal with concurrent updates? The merging process alone with 20 databases will cost so much in resources it would have been cheaper to have a tried and tested professional DR (Disaster Recovery) process.
A true standby database on the other hand would be simpler to deploy, simpler to test, simpler to maintain and will cost less in resources. I suggest you don't reinvent the wheel :)
Edit:
By the way if you just want a backup and recovery plan, duplicating the database is NOT the solution. I suggest you read the online documentation about recovery:
Oracle Database Backup and Recovery Basics
Oracle Database Backup and Recovery Advanced User's Guide
I had the "pleasure" of trying to make exactly this sort of solution more robust on a SQL Server based POS system. As Vincent says, it's a complex process, fraught with unforseen nightmare scenarios and difficult to maintain code (e.g., ugly DOS .bat files I had to write). I would have to agree with him that it's a more robust solution to use a standby scenario.
That said, if your client won't spring for another license (and I do see their point) you seem to be stuck doing exactly this sort of thing. It can be done, but let your client know that the homegrown replication system is going to be a costly one, and will likely take quite some time to get the wrinkles worked out. It also probably won't scale well as the number of retail sites increases.
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.