Hi,
For the future (12.2) you will probably go to application containers and
container map (
http://docs.oracle.com/database/122/ADMIN/administering-application-containers-with-sql-plus.htm#ADMIN-GUID-E2668048-1657-49BC-9B6E-6837D5757463)
and then have only one connection string.
If you want multiple listeners for higher availability, then you don't need
to dedicate them per PDB. You may have multiple listeners listening for all
services each, and client being able to failover among them.
Regards,
Franck.
Franck Pachot | Oracle Certified Master 12*c* and Oracle ACE Director
On Thu, Jan 26, 2017 at 9:07 PM Hans Forbrich <fuzzy.graybeard@xxxxxxxxx>
wrote:
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>
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>
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
--
Sincerely,
WoodyMcKay
--
Sincerely,
WoodyMcKay
