From derby-dev-return-97772-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue Sep 11 12:15:39 2012 Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1752DD206 for ; Tue, 11 Sep 2012 12:15:39 +0000 (UTC) Received: (qmail 90663 invoked by uid 500); 11 Sep 2012 12:15:38 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 90497 invoked by uid 500); 11 Sep 2012 12:15:37 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 90450 invoked by uid 99); 11 Sep 2012 12:15:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2012 12:15:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.32.180.13] (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.13) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2012 12:15:29 +0000 Received: from mail107-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 12:15:08 +0000 Received: from mail107-va3 (localhost [127.0.0.1]) by mail107-va3-R.bigfish.com (Postfix) with ESMTP id DBC9B1601F8 for ; Tue, 11 Sep 2012 12:15:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:74.62.37.82;KIP:(null);UIP:(null);IPV:NLI;H:CPHUB1.canoga.com;RD:rrcs-74-62-37-82.west.biz.rr.com;EFVD:NLI X-SpamScore: -8 X-BigFish: VPS-8(zz98dI9371Ic85fh179dNzz1202h1d1ahzz17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3 (MessageSwitch) id 1347365695928712_18859; Tue, 11 Sep 2012 12:14:55 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.253]) by mail107-va3.bigfish.com (Postfix) with ESMTP id DF08020043 for ; Tue, 11 Sep 2012 12:14:55 +0000 (UTC) Received: from CPHUB1.canoga.com (74.62.37.82) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 12:14:54 +0000 Received: from vserver1.canoga.com ([169.254.2.223]) by CPHUB1.canoga.com ([172.16.1.93]) with mapi; Tue, 11 Sep 2012 05:17:12 -0700 From: "Bergquist, Brett" To: "derby-dev@db.apache.org" Date: Tue, 11 Sep 2012 05:14:33 -0700 Subject: RE: Had a problem with SYSCS_FREEZE_DATABASE and am wondering is something can be done make this more robust Thread-Topic: Had a problem with SYSCS_FREEZE_DATABASE and am wondering is something can be done make this more robust Thread-Index: Ac2PpEwcw8UsfTNrQ0+RigpgSRP/xwAcQv1Q Message-ID: <97EB699F861AD841B5908C7CA9C956560237709B5AD6@VSERVER1.canoga.com> References: <97EB699F861AD841B5908C7CA9C956560237709B5A28@VSERVER1.canoga.com> <504E6A10.5070502@oracle.com> In-Reply-To: <504E6A10.5070502@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.500.1024-19176.005 x-tm-as-result: No--42.793000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB699F861AD841B5908C7CA9C956560237709B5AD6VSERVER1can_" MIME-Version: 1.0 X-OriginatorOrg: canoga.com X-Virus-Checked: Checked by ClamAV on apache.org --_000_97EB699F861AD841B5908C7CA9C956560237709B5AD6VSERVER1can_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dag for taking the time to respond. See the following which occurr= ed when trying to use FREEZE/UNFREEZE from a script using IJ: http://markmail.org/search/?q=3Dfreeze%20database%20brett#query:freeze%20da= tabase%20brett+page:2+mid:e54e5pc43qoymdja+state:results and also here: http://markmail.org/search/?q=3Dderby+freeze+backup+brett#query:derby%20fre= eze%20backup%20brett+page:1+mid:d36xvhbdnuqodqxi+state:results where Mike Matrigali commented: Here is the documentation for using freeze/unfreeze to do a backup. The expectation is that the freeze and unfreeze comes from the same connection (or at least that is likely what is tested in derb= y). http://db.apache.org/derby/docs/dev/adminguide/cadminhubbkup75469.html I don't remember but think it might be likely that future connection reques= ts are stalled while a database is frozen, as part of work necessary to keep a database in an ok state for a user backup routine to be called. Logically you just need to stop writing transactions but the implementation may just of have stall all connections. Obviously this does not work well for the 3 separate script steps you descr= ibe, but would be good to know if your use case works for the intended use of freeze/unfreeze. And even if derby only supports same connection freeze and unfreeze, we should understand what is expected if the connection execu= ting the freeze fails or exits before doing unfreeze. So from this, I still think it might be better to automatically unfreeze th= e database if a connection is lost. In the production environment it is qu= ite possible that between the freeze and copy that all of the remaining con= nections available become used and blocked waiting for the database to unfr= eeze and if a failure occurs, there is now no way to unfreeze the database. I have tried to use freeze/unfreeze from both a script and a utility applic= ation now to perform a backup as describe in the documentation, and both wa= ys I have had something fail and being locked out and unable to invoke unfr= eeze. From: Dag Wanvik [mailto:dag.wanvik@oracle.com] Sent: Monday, September 10, 2012 6:31 PM To: derby-dev@db.apache.org Subject: Re: Had a problem with SYSCS_FREEZE_DATABASE and am wondering is s= omething can be done make this more robust On 10.09.2012 20:07, Bergquist, Brett wrote: I am thinking this because I was told on a previous emailing when trying to= build this utility totally from a script point of view using IJ to freeze = the database, SH to perform the ZFS snapshot and IJ to unfreeze the databas= e that it was not expected that the freeze/unfreeze would be done from sepa= rate connections. I fact I ran into a problem with the utility at that poi= nt where the IJ connection to unfreeze could not be created because the dat= abase was frozen. Hmm. I just tried this, and found I can make another connection even when t= he database is frozen, although when I try to do an update the operation ha= ngs as expected. Maybe there is a bug the prohibits a new connection in som= e (hitherto uncharacterized) cases? Dag So I guess is there ever a use case that would require a database to be fro= zen and not unfrozen before the connection is closed/lost? --_000_97EB699F861AD841B5908C7CA9C956560237709B5AD6VSERVER1can_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks Dag for taking the time to respond.   See the follo= wing which occurred when trying to use FREEZE/UNFREEZE from a script using = IJ:

 

http://markmail.org/search/?q=3Dfreeze%20database%20br= ett#query:freeze%20database%20brett+page:2+mid:e54e5pc43qoymdja+state:resul= ts

 

and also here:

 

http://markmail.org/search/?q=3Dderby+freeze+back= up+brett#query:derby%20freeze%20backup%20brett+page:1+mid:d36xvhbdnuqodqxi+= state:results

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>where Mike Matrigali comment= ed:

&nbs= p;

Here is = the documentation for using freeze/unfreeze to do a backu= p.  The
expectation is that the freeze and unfreeze comes

from the same connection (or at least that is like= ly what is tested in derby).

http://db.apache.org/derby/docs/dev/adminguide/cadminhubbkup75469= .html

 

I don't= remember but think it might be likely that future connection requests
a= re stalled while a database is frozen, as part of work

ne= cessary to keep a database in an ok state for a user backup routine to be
called.  Logically you just need to stop writing tr= ansactions

but the implementation may just of have stall all connections.<= o:p>

 

Obviously this does not = work well for the 3 separate script steps you describe,
but would be goo= d to know if your use case works for

the intended use of freeze/unfreeze.  And even if derby only supports sam= e
connection freeze

and unfreeze, we should understand= what is expected if the connection executing
the freeze fails or exits before doing unfreeze.

 

So from this, I still thi= nk it might be better to automatically unfreeze the database if a connectio= n is lost.  In the production environment it is quite possible that be= tween the freeze and copy that all of the remaining connections available b= ecome used and blocked waiting for the database to unfreeze and if a failur= e occurs, there is now no way to unfreeze the database.

 

I have tried to u= se freeze/unfreeze from both a script and a utility application now to perf= orm a backup as describe in the documentation, and both ways I have had som= ething fail and being locked out and unable to invoke unfreeze.<= /p>

 

 

= From: Dag Wanvik [mailto:dag.wanvik@oracle.= com]
Sent: Monday, September 10, 2012 6:31 PM
To: derb= y-dev@db.apache.org
Subject: Re: Had a problem with SYSCS_FREEZE_= DATABASE and am wondering is something can be done make this more robust

 



On 10.09.2012 20:07, Bergquist, Brett wrote:

I am thinking this because I was told on a previous= emailing when trying to build this utility totally from a script point of = view using IJ to freeze the database, SH to perform the ZFS snapshot and IJ= to unfreeze the database that it was not expected that the freeze/unfreeze= would be done from separate connections.  I fact I ran into a problem= with the utility at that point where the IJ connection to unfreeze could n= ot be created because the database was frozen.

<= p class=3DMsoNormal>
Hmm. I just tried this, and found I can make anothe= r connection even when the database is frozen, although when I try to do an= update the operation hangs as expected. Maybe there is a bug the prohibits= a new connection in some (hitherto uncharacterized) cases?

Dag
<= br>

 <= /span>

So I guess is the= re ever a use case that would require a database to be frozen and not unfro= zen before the connection is closed/lost?

 

 

= --_000_97EB699F861AD841B5908C7CA9C956560237709B5AD6VSERVER1can_--