just for short, digged another “circumstance” of oracle operation, in a data guard environment this time. i usually set up standby databases from a rman backup set, clone and adapt the spfile, clone the password file, create a new instance and so on. this works great, no problems so far.
this afternoon however, i got notified that some alert.log of a primary database is packed with messages of the following pattern:
there is lots of articles on the web that describe inbound connection timed out (ora-3136) in the realms of oracle 10gR2 and the new default setting of its sqlnet.ora-parameter SQLNET.INBOUND_CONNECT_TIMEOUT (the tnsnames.ora-parameter INBOUND_CONNECT_TIMEOUT_listener alike). people propose to reset the parameter back to 0, from 60, seconds to achive an indefinite wait for login authentication against the database. so far, so bad. that is, just tackling problems by turning around control buttons will not solve the problem nor will it help in understanding the root cause of the problem. this is especially true, iff the problem appears spuriously, not in a determinable order or user/application segment.
but, what may be the root cause? many argue that network misdesign along firewalls or nat might provoke the inbound connection timed out (ora-3136) warning with the alert.log. hhm, do not know, never saw or experienced that. however, what i can show is that this very warning can be easily induced by connecting a privileged session to an idle instance (remember the difference between instance and database, especially on windows; an instance is represented by a service and the database will be bound to it during startup) and such a way prove, that also an database/host overload can be responsible. just change the missing or unbound database with a non-responding database in your mind to grasp the experiment approach.
sometimes, i know not on our installations ;-), one may have forgotten to size and schedule oracle logging appropriately. a typical case is setting LOGGING_LISTENER = ON in the listener.ora and then just loosing sight of it. the next or another day later one will get a call that the system is slow, this time because oracle hardly works to still append to that multi-gigabyte listener.log file. oops, what to do know? one can’t delete the file because it is locked by the owning process. one can neither bounce the listener in a 24×7 environment. an option one has though is to shred the contents of the file by overwriting it with just nothing or NULL on windows (/dev/null on un*x):
type NUL > %my_correct_path%\listener.log
have fun
introduction
hi, you are facing the task to edit one tables data as well as an associated relationship table by id on a single apex page? you think that a multiselect list control will do for the relationship table entries but do not know how to integrate it? iff so, you are at the right stop. the following article will give you a screenshot tour of a step-by-step procedure with appropriate annotations.
placing and feeding the multiselect list control
#1 at first, on the dedicated edit page, create a new item within the form region.
Bitbach's Blog 
You must be logged in to post a comment.