Received: (qmail 20235 invoked from network); 5 May 2012 03:30:49 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by static-ip-85-25-126-90.inaddr.ip-pool.com with SMTP; 5 May 2012 03:30:38 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 94592EC9BC3; Sat, 5 May 2012 04:30:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1336206637; bh=N/9C6ADkbMbnCVgCKFROaSn3AAi5WhAmnQsWU5GX Za0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-type:In-Reply-To:Content-Transfer-Encoding:Sender:Reply-To: List-help:List-unsubscribe:List-Id:List-subscribe:List-owner: List-post:List-archive; b=Qxtk1LHHOZHs6UnVP5QHUnyl4Wdgays+uaVfHKqY GLesaTzfLv8DbJGukoYp1uFw+R//vh1qqBLouI4sD13TLVVOI680/rUe94HCGGATfdx UFxQ23qE+XAqVU7xlo7xi7FFRo7RiZR0tTgjj/zcIjO/NHfsYys8IAED3AxFvVLM= X-Virus-Scanned: Debian amavisd-new at localhost.localdomain Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4-Mpx4sGDzf; Sat, 5 May 2012 04:30:37 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 946C8EC9B8B; Sat, 5 May 2012 04:29:54 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 05 May 2012 04:29:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id ECA80EC9B89 for ; Sat, 5 May 2012 04:29:12 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xPiKpQKBXfn for ; Sat, 5 May 2012 04:29:12 -0400 (EDT) Received: from dutch65.vdx.nl (dutch65.vdx.nl [85.158.248.87]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 325BCEC9B88 for ; Sat, 5 May 2012 04:29:11 -0400 (EDT) X-ClientAddr: 62.45.189.137 Received: from localhost (137-189-045-062.dynamic.caiway.nl [62.45.189.137]) (authenticated bits=0) by dutch65.vdx.nl (8.13.8/8.13.8) with ESMTP id q458T6Qk018652; Sat, 5 May 2012 10:29:06 +0200 Date: Sat, 5 May 2012 10:29:05 +0200 From: Martijn Bos To: Martin Bach Cc: "oracle-l@freelists.org" Subject: Re: Oracle Security Alert for CVE-2012-1675 - 10g extended support Message-ID: <20120505082905.GA9771@app01.bos> References: <4FA24199.8090902@gmail.com> <4FA4359F.1020309@the-playground.de> <4FA43B58.1030000@the-playground.de> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA43B58.1030000@the-playground.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virtual-Dynamix-dutch65-MailScanner-Information: Please contact Virtual Dynamix (www.vdx.nl) for more information X-Virtual-Dynamix-dutch65-MailScanner: Found to be clean X-Virtual-Dynamix-dutch65-MailScanner-From: maboc@maboc.nl X-Spam-Status: No Content-Transfer-Encoding: 8bit X-archive-position: 42717 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: maboc@maboc.nl Precedence: normal Reply-To: maboc@maboc.nl List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l Hi, > > In your (and everyone else's experience), how long does a listener > start/stop take? If it's in a shell script it might be very quick, and > done over a quiet period shouldn't hurt too much. > In my experience stopping/starting a listener doesn't take more then a few seconds. However, it can take a while (have no figures available) before the "locallistener databases" will register them selfs with the listener. The other day it took about 30 seconds for the last local listener to register, in out test environment. The existing connections are not impacted, only new connections can't be made. So I gues that applications which user some kind of connection-pooling mechanism are not hurt, since they do not (generally) need to create new connections all the time. Applications whitout connection pools may suffer from "database loss" or "no database" for a while. I guess it's up to "the bussiness" to see whether that is acceptable. Best Regards, Martijn -- http://www.freelists.org/webpage/oracle-l