Block some DDL commands at HDR Secondary Instance
Hello, I have a question regarding HDR i.e Is it possible to block the execution of drop database or drop table SQL Commnads on secondary DB Instance. I mean if someone accidently executes the command drop database or drop table on the primary DB instance then it could not execute on secondary database, so that, there is no down time due to these accidental commands. Regards, Anees
On Wed, Apr 15, 2009 at 06:58, ANEES AHMAD <aanees@i2cinc.com> wrote: > I have a question regarding HDR i.e > Is it possible to block the execution of drop database or drop table SQL > Commnads on secondary DB Instance. > I mean if someone accidently executes the command drop database or drop table > on the primary DB instance then it could not execute on secondary database, so > that, there is no down time due to these accidental commands. No. HDR maintains exact copies of the (logged portions of the) primary database. If the data has gone from the primary, it must go from the secondary too. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." NB: Please do not use this email for correspondence. I don't necessarily read it every week, even. Samuel Goldwyn - "A wide screen just makes a bad film twice as bad." - http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
Hi In HDR, the secondary server does not actually execute the drop database or drop table. When the primary executes those DDLs, those transactions are logged, and when the primary flushes the log buffers to disk, a copy of that log buffer is shipped to the secondary and the secondary simply applies those log records in the log buffer. So what ever is executed on the primary and logged, will be rolled forward by the secondary as is. thanks. Davis. ids-bounces@iiug.org wrote on 04/15/2009 06:58:09 AM: > Hello, > I have a question regarding HDR i.e > Is it possible to block the execution of drop database or drop table SQL > Commnads on secondary DB Instance. > I mean if someone accidently executes the command drop database or drop table > on the primary DB instance then it could not execute on secondary database, so > that, there is no down time due to these accidental commands. > > Regards, > Anees > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
No, but no one but the DBA who owns the database should have DBA or RESOURCE privileges on the database, so no one else should be able to do that except you. Also you can always recover the dropped table or database using an archive (and archecker in the case of a single table). Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Apr 15, 2009 at 9:58 AM, ANEES AHMAD <aanees@i2cinc.com> wrote: > Hello, > I have a question regarding HDR i.e > Is it possible to block the execution of drop database or drop table SQL > Commnads on secondary DB Instance. > I mean if someone accidently executes the command drop database or drop > table > on the primary DB instance then it could not execute on secondary database, > so > that, there is no down time due to these accidental commands. > > Regards, > Anees > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636af0342a64cc10467c0e9d9