Ah! Windows.
Yes, multiple listeners are a serious consideration. Especially with
those poorly written multi-connect apps.
All the best on the migration. When you get to 12.1 - look seriously at
RAS and UCP to mitigate that connection problem.
/Hans
On 2017-01-26 12:54 PM, Woody McKay wrote:
Thanks Hans. All true. It has happened - we've had hung listeners in the past. Many had issues from running out of windows heap memory (all used the same system account) and we still have some old apps that connect/disconnect on just about every call as well as test connections before using them :( The move to Linux next year should get rid of many of the problems due to windows o/s.
Thanks for the reminder about established connections are not broken during a listener bounce.
On Thu, Jan 26, 2017 at 1:56 PM, Hans Forbrich <fuzzy.graybeard@xxxxxxxxx <mailto:fuzzy.graybeard@xxxxxxxxx>> wrote:
Bouncing a listener only impacts connection *attempts*. A fully
automated bounce would stop people from *asking* for a new
connection for, say, 1/50th of a second? This might impact a
badly written application that gets a new connection for each data
lookup, but that would have other serious consequences.
Remember that the listener is no longer involved once the
connection is established. Bouncing a listener does absolutely
nothing to those established connections.
I find it fairly rare to needc to bounce a listener anyway. But
... to each his own.
/Hans
On 2017-01-26 11:36 AM, Woody McKay wrote:
Thanks Hans.
All connections would be via JDBC from applications. Ok, one or
more listeners as needed and jdbc thin with host:port/service.
Each PDB defaults with a service of the same name/domain.
Should be easy enough. Hosting prefers one listener per customer
so that a needed bounce only impacts that one customer.
Thanks...
On Thu, Jan 26, 2017 at 1:23 PM, Hans Forbrich
<fuzzy.graybeard@xxxxxxxxx <mailto:fuzzy.graybeard@xxxxxxxxx>> wrote:
When you add a PDB to a container instance, the PDB's service
is automatically registered based on the pdb name and the
domain. You can optionally add one or more services that
direct to the PDB if needed, for example, for resource
management.
The big question is "How do you connect to the environment?"
- if you use TNSNAMES.ORA ('@tnsentry'), then you pretty much
want to manage te TNSNAMES.ORA manually. The service is not
automatically added; This needs to be managed at each
TNSNAMES.ORA location. Consider centralizing using LDAP ...
- if you use "CONNECT to root and 'alter session set
container={pdb}" then you might simply ignore tnsnames.ora
all together.
- similarly, if you use EZConnect or JDBC:thin
("@//host:port/service") then ignire TNSNAMES.ora
- I've noticed a lot of people still try ("@//host:port:sid")
which obviously does not work (a PDB is NOT an instance)
unless you monkey with the service==sid setting. While
possible, it becomes one more workaround thing to manage, so
I'd avoid it and prefer to use the correct .../service syntax.
As for listener, I'd use one listener properly configured,
unless multiples are absolutly required due to load or
setting differences.
/Hans
The above being my opinion, and not an official statement by
my employer.
On 2017-01-26 11:01 AM, Woody McKay wrote:
Hi,
Is anyone using multi-tenant in production or about to?
What have you found to be the best listener setup?
I'm doing R&D using many PDB's with one per customer
district. Each PDB would have its own service, but I'm
not exactly sure on how listener.ora and/or tnsnames.ora
entries should look like. Each PDB would have the same
schema, but unique with customer data. The connection
schema name would be the same in each PDB.
I've not found much documentation discussing this...
--
//www.freelists.org/webpage/oracle-l
<//www.freelists.org/webpage/oracle-l>
-- Sincerely,
WoodyMcKay
--
Sincerely,
WoodyMcKay
