Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from turing.freelists.org (turing.freelists.org [206.53.239.180]) by malta2546.startdedicated.com (Postfix) with ESMTPS id A8C961002EC89A for ; Wed, 30 May 2018 06:55:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4CF11255DF; Wed, 30 May 2018 00:55:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1527656116; bh=SxqClR88uLImMHUs++7iyQC0CRYvS8cBRPsgH2hGrnk=; h=In-Reply-To:References:From:Date:Subject:To:Reply-To:List-help: List-unsubscribe:List-Id:List-subscribe:List-owner:List-post: List-archive; b=LEDPoWtUvDs2iGa9h5lyMU79k2fEtYKDsYraRhO+bguVGC8WjsMunQC4kZRXF/sHc DIVBaBA14r41ZdbENWg6sPG5qYAc31XuOEIhJ5SvxyANwDOSk9GlhMyvx/x3nqhvEb om6sFnihNwXg4ilmLGX/ojBEzr+MU2GlX2DmD0us= X-Virus-Scanned: Debian amavisd-new at turing.freelists.org 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 WSrs4OgW3hGK; Wed, 30 May 2018 00:55:16 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5E4BC25585; Wed, 30 May 2018 00:54:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1527656110; bh=SxqClR88uLImMHUs++7iyQC0CRYvS8cBRPsgH2hGrnk=; h=In-Reply-To:References:From:Date:Subject:To:Reply-To:List-help: List-unsubscribe:List-Id:List-subscribe:List-owner:List-post: List-archive; b=eszMalDzLhVplk8qAQXwrBe6leKZm5pWXP4wzrdAKlfI0/EBMiyzVJ9IJExu0XjVi fJPv4VkOcGSbYqqPVnBDMTJ9VOn9oRyj5Csiw3V9q8xokDWUmFrPzH7TY0vSNjYyvZ 1u6jJDsxqv/60WXK65cIjU9nB2xNYErzkPYr7Fvs= Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 30 May 2018 00:53:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8356C25577 for ; Wed, 30 May 2018 00:53:36 -0400 (EDT) Authentication-Results: turing.freelists.org; dkim=pass reason="2048-bit key; unprotected key" header.d=gmail.com header.i=@gmail.com header.b=SsUZQQA4; dkim-adsp=pass; dkim-atps=neutral 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 XVYPr4tDOPl4 for ; Wed, 30 May 2018 00:53:36 -0400 (EDT) Received: from mail-ot0-f174.google.com (mail-ot0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 48F9525576 for ; Wed, 30 May 2018 00:53:35 -0400 (EDT) Received: by mail-ot0-f174.google.com with SMTP id 15-v6so19645315otn.12 for ; Tue, 29 May 2018 21:53:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6FsGNfGCBRiO0R6SkxPMENeNTdUr1Y0ZvO6UcZbc54Y=; b=Tzb7VbyS+5mE+gzbsKnofar3B1dv12rQy8oD9hnSShZOgKVHc/OCV6wc/W4ayc8Qiy hZtCkocFDNi+1t1lOLv3RET6j8S/nX3g1ETrVzzg1lGCxSqJ405Kn/WipJq6Bllr1nOv jsggD6yzcWXP6TsOG29v6fyZQ2BV1RVQUvtgn51mxbpVZF5KxqwMMXhiX6jcvu3LJBP2 nxeDXDNwL3/twvbTwQd+JY9Xce5FT0uPEsLyRvlN45lBjQXhqx0n8dt9ezOHFtUFIErw LdgRxI05WrtGl5+CaH9QeGM+3802Zdp31LrhihmP17jll7kz+KH04x+7N9o+k88lJk5z 4RdA== X-Gm-Message-State: ALKqPwe8LoeA0RwqVOq5aiEg5O3s21rV8t9hsS4qTSre0OQ61kPKjS89 dEeZjkdRfzW+YUhjePQlPaIEaM5zFZchvhshJQJOew== X-Google-Smtp-Source: ADUXVKIwm2DNXigCjW+RX1hgQkb6ik98Nc94GqfKIVEYZZgHsSJvG8f0fr8YsRURTHRDo1KKH7SueD4/cWLhxYI4oIg= X-Received: by 2002:a9d:1057:: with SMTP id o23-v6mr789667oto.45.1527656015251; Tue, 29 May 2018 21:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:cb6:0:0:0:0:0 with HTTP; Tue, 29 May 2018 21:53:14 -0700 (PDT) In-Reply-To: References: From: William Sescu Date: Wed, 30 May 2018 06:53:14 +0200 Message-ID: Subject: Re: Slow connections with 12.2 client To: ORACLE-L Content-Type: multipart/alternative; boundary="00000000000020cc0c056d6522ee" X-archive-position: 71595 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: william.sescu@gmail.com Precedence: normal Reply-To: william.sescu@gmail.com 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 --00000000000020cc0c056d6522ee Content-Type: text/plain; charset="UTF-8" Hello Niall, I observed quite some time ago, that sqlplus connections in combination with LDAP is getting slower and slower with every release. The reason for it, is that Oracle does more and more LDAP searches with every release. With 10gR2, 1 LDAP search was sufficient, with 11gR2 you have already 2, and with 12cR1 and higher you got 3. For more information, that a look at: https://blog.dbi-services.com/oud -oracle-unified-directory-11-1-2-3-oracle-generates-more-and-more-ldap- lookups-with-every-release/ Unfortunately, there is no Patch or workaround that I am aware of, to fix this issue. Cheers, William On Tue, May 29, 2018 at 6:25 PM, Stefan Knecht wrote: > Not a windows guy at all, but have you tried tracing it? > https://stackoverflow.com/questions/3847745/systrace-for-windows > > Might show you the syscall it's hanging on which would confirm if it's > indeed some sort of lookup that hangs. > > Stefan > > > > On Tue, May 29, 2018 at 9:11 PM, Niall Litchfield < > niall.litchfield@gmail.com> wrote: > >> Hi >> >> Has anybody else observed initial connectivity with the 12.2 >> windows client to be significantly slower than in 12.1 (or 11.2). My setup >> has ldap and TNS_ADMIN involved. >> >> 12.1 >> ORACLE_HOME: C:\APP\ORACLE\INSTANTCLIENT_12_1 >> TNS_ADMIN: C:\APP\TNS >> >> 12.2 >> ORACLE_HOME: C:\APP\ORACLE\INSTANTCLIENT_12_2 >> TNS_ADMIN: C:\APP\TNS >> >> Extract from an admin level sqlnet trace in 12.1 >> >> (12180) [29-MAY-2018 14:53:56:171] nnflgetnlpactx: NLPA context >> successfuly initialized >> (12180) [29-MAY-2018 14:53:56:172] nnflgetnlpactx: exit >> (12180) [29-MAY-2018 14:53:56:517] nnfloidinfocache: entry >> (12180) [29-MAY-2018 14:53:56:517] nnfloidinfocache: Info: Inserted >> value DIRECTORY_SERVER_TYPE=OID at index 0 into NLPA_CACHE >> >> and from 12.2 >> >> (9712) [29-MAY-2018 14:47:01:777] nnflgetnlpactx: NLPA context >> successfuly initialized >> (9712) [29-MAY-2018 14:47:01:777] nnflgetnlpactx: exit >> (9712) [29-MAY-2018 14:47:38:195] nnfloidinfocache: entry >> (9712) [29-MAY-2018 14:47:38:195] nnfloidinfocache: Info: Inserted value >> DIRECTORY_SERVER_TYPE=OID at index 0 into NLPA_CACHE >> >> Note the extra 30 secs between exit from the nnflgetnlpactx function and >> entry to the OID related function nnfloidinfocache >> >> I have a ticket with Oracle Support but wondered if anyone else has seen >> this. >> -- >> Niall Litchfield >> Oracle DBA >> http://www.orawin.info >> > > > > -- > // > zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework! > Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/ > --00000000000020cc0c056d6522ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Niall,

I observed quite some time= ago, that sqlplu= s connections in combination with LDAP is getting slower and slower with every= release.
The reason for it, is that Oracle does more and more LDAP searche= s with every release.

With 10gR2, 1 LDAP search was sufficie= nt, with 11gR2 you have already 2, and with 12cR1 and higher you got 3. For= more information, that a look at:

https://blog.dbi-services.com/oud-oracle-uni= fied-directory-11-1-2-3-oracle-generates-more-and-more-ldap-lookups-with-every-release/

Unfortunately, there is no Patch or workaround that = I am aware of, to fix this issue.

Cheers,
William



On Tue, May 29, 2018 at 6:25 PM, Stefan K= necht <knecht.stefan@gmail.com> wrote:
Not a windows guy at all, but have you = tried tracing it?=C2=A0https://stackoverflow.com/q= uestions/3847745/systrace-for-windows

Might sho= w you the syscall it's hanging on which would confirm if it's indee= d some sort of lookup that hangs.

Stefan



On Tue, May 29, 2018 at 9:11 PM, Nia= ll Litchfield <niall.litchfield@gmail.com> wrote:
Hi

Has= anybody else observed initial connectivity with the 12.2 windows=C2=A0clie= nt to be significantly slower than in 12.1 (or 11.2).=C2=A0My setup has lda= p=C2=A0and TNS_ADMIN involved.

12.1=C2=A0
ORACLE_HOME: C:\APP\ORACLE\INSTANTCLIENT_12_1
TNS_ADMI= N: C:\APP\TNS

12.2
ORACLE_HOME: C:\APP\ORACLE\INSTANTC= LIENT_12_2
TNS_ADMIN:= C:\APP\TNS

Extract from an admin level sqlnet trace in= 12.1=C2=A0

(12180) [29-MAY-2018 14:53:56:171= ] nnflgetnlpactx: NLPA context successfuly initialized=C2=A0
(121= 80) [29-MAY-2018 14:53:56:172] nnflgetnlpactx: exit
(12180) [29-M= AY-2018 14:53:56:517] nnfloidinfocache: entry
(12180) [29-MAY-201= 8 14:53:56:517] nnfloidinfocache: Info:=C2=A0 Inserted value DIRECTORY_SERV= ER_TYPE=3DOID at index 0 into NLPA_CACHE

and= from 12.2=C2=A0

(9712) [29-MAY-2018 14:47:01= :777] nnflgetnlpactx: NLPA context successfuly initialized=C2=A0
<= div>(9712) [29-MAY-2018 14:47:01:777] nnflgetnlpactx: exit
(9712)= [29-MAY-2018 14:47:38:195] nnfloidinfocache: entry
(9712) [29-MA= Y-2018 14:47:38:195] nnfloidinfocache: Info:=C2=A0 Inserted value DIRECTORY= _SERVER_TYPE=3DOID at index 0 into NLPA_CACHE

Note the extra 30 secs between exit from the=C2=A0nnflgetnlpactx function and entry to the OID related functi= on=C2=A0nnfloidinfocache=C2=A0

I have a ticket with Oracle Support but=C2=A0wond= ered if anyone else has seen this.=C2=A0
--
Niall Litchfield
Oracle DBA<= br>http://www.orawin.i= nfo



--
//
zztat -= The Next-Gen Oracle Performance Monitoring and Reaction Framework!<= div style=3D"font-size:small">Visit us at=C2=A0zztat.net=C2=A0| @zz= tat_oracle | fb.me/zztat | zztat.net/blog/

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