Received: (qmail 20715 invoked from network); 5 May 2012 03:41:18 -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:41:03 -0500
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2D9A0EC9C4E;
 Sat,  5 May 2012 04:40:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org;
 s=turing; t=1336207258; bh=Of2jTaCuJCf6cmZ8Dthm2Af8VLqyNe8e/Y7he0u6
 hNg=; h=References:From:In-Reply-To:Mime-Version:Date:Message-ID:
	 Subject:To:Cc:Content-type:Content-Transfer-Encoding:Sender:
	 Reply-To:List-help:List-unsubscribe:List-Id:List-subscribe:
	 List-owner:List-post:List-archive; b=Jj6SpqjzLLTnt2ONlz202HDi40oHQ
 CE2zFBMptIG3Ol2dG8FcolvRUZcbbFgkpSz+tUfVlywaIdAjjZoZtgrmOtwE9Ru3Ei6
 iGPiuwi9mS4xEzFLc/XvDoJzrtJm2jQbqeuw42Mm1QJ5lFYOv9eKtuJ50/w6dtOI1aj
 4H8XvgpQ=
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 Oniy1xyCzu2O; Sat,  5 May 2012 04:40:57 -0400 (EDT)
Received: from turing.freelists.org (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2B91EEC9BF0;
 Sat,  5 May 2012 04:40:15 -0400 (EDT)
Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 05 May 2012 04:39:33 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A1A97EC9B98
 for <oracle-l@freelists.org>; Sat,  5 May 2012 04:39:33 -0400 (EDT)
Authentication-Results: turing.freelists.org; dkim=pass (2048-bit key) header.i=@gmail.com
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 dcNoCX7Wpqn0 for <oracle-l@freelists.org>;
 Sat,  5 May 2012 04:39:33 -0400 (EDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 42C85EC9B97
 for <oracle-l@freelists.org>; Sat,  5 May 2012 04:39:26 -0400 (EDT)
Received: by obbup19 with SMTP id up19so5556737obb.10
        for <oracle-l@freelists.org>; Sat, 05 May 2012 01:39:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=references:from:in-reply-to:mime-version:date:message-id:subject:to
         :cc:content-type;
        bh=ZRherRitFjPh7rajOsAAkbMJOPWzu4jeV6SUnaX33ZU=;
        b=lTS7sPdIkN+oHNy8qdJBEiDUiBIMCxqW6cMCTKIwgfGFm9liGiNIW7XLyL2QVLt2WC
         ffsjtDXb0P0nyV/oNrAJKYo/dnHV1vEKG675UodIxXgEhdkuEXpwgPPsKlxigGbcGNFj
         eJLABchkXMpvkXf4gWdRu16EpnDLfVuIdn+bcUq41raC3/kopghA5FXvOaVRayg7U4NI
         rmuqzgxEiNsrp6EjXCE2/N5upWZPGW9gSYk6c8OZhAxWmmQVPJxQL2ESUVxSkcYMJL6T
         t2huc3egHbhoYHAa1+X4PPHKO0VV7bqHwsK2sOYgUQFxSgrog4kibQu0fs69rFit+Ig2
         h9Tg==
Received: by 10.50.45.133 with SMTP id n5mr4657920igm.34.1336207160865; Sat,
 05 May 2012 01:39:20 -0700 (PDT)
References: <CAHDOOG7qkYfjAMZpjf5GGN-d0tqdNt7adHybGJm3NhudoOV9sg@mail.gmail.com>
 <E456CBDCBA39124DA45560EA116A22E7C8486043EB@MBLEXCH.mbl.org>
 <4FA24199.8090902@gmail.com> <E456CBDCBA39124DA45560EA116A22E7C84860449C@MBLEXCH.mbl.org>
 <CAPptggXthOkQnnq7wOD8dfheDbB5Gz2SOF-EYPwJsBT83vA_ow@mail.gmail.com>
 <CABUxq=dBr1UemucQTPxgRdoD99VAnw1un3A8ryAeuuBk218+Vg@mail.gmail.com>
 <E456CBDCBA39124DA45560EA116A22E7C8486045DE@MBLEXCH.mbl.org>
 <4FA4359F.1020309@the-playground.de> <A250F0C68C23514CA9F3DF63D60EE10E0D601C3C@onews31>
 <4FA43B58.1030000@the-playground.de> <20120505082905.GA9771@app01.bos>
From: Frits Hoogland <frits.hoogland@gmail.com>
In-Reply-To: <20120505082905.GA9771@app01.bos>
Mime-Version: 1.0 (1.0)
Date: Sat, 5 May 2012 10:39:19 +0200
Message-ID: <-4328741704790634027@unknownmsgid>
Subject: Re: Oracle Security Alert for CVE-2012-1675 - 10g extended support
To: "maboc@maboc.nl" <maboc@maboc.nl>
Cc: Martin Bach <development@the-playground.de>, 
 "oracle-l@freelists.org" <oracle-l@freelists.org>
Content-type: text/plain
Content-Transfer-Encoding: 8bit
X-archive-position: 42718
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: frits.hoogland@gmail.com
Precedence: normal
Reply-To: frits.hoogland@gmail.com
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <oracle-l-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@freelists.org?Subject=subscribe>
List-owner: <mailto:steve.adams@ixora.com.au>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l

For dynamically registered databases, it takes a little while before
pmon registers itself to the listener. You can make pmon do it with
the 'alter database register' command. By default pmon does so for
listeners at port 1521 on the local machine's network interfaces. If
you want to register automatically to other local listeners, use the
local_listeners parameter, or remote (SCAN!) use remote_listeners.
Frits Hoogland

http://fritshoogland.wordpress.com
mailto:frits.hoogland@gmail.com
cell: +31 6 53569942

Op 5 mei 2012 om 10:30 heeft Martijn Bos <maboc@maboc.nl> het volgende
geschreven:

> 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
>
>

--
http://www.freelists.org/webpage/oracle-l


