Oracle 1z0-599 Exam Practice Questions (P. 3)
- Full Access (91 questions)
- Six months of Premium Access
- Access to one million comments
- Seamless ChatGPT Integration
- Ability to download PDF files
- Anki Flashcard files for revision
- No Captcha & No AdSense
- Advanced Exam Configuration
Question #11
A customer needs to ensure that the number of threads servicing an application does not exceed the number of database connections available to the application.
What step must you take to address this situation?
What step must you take to address this situation?
- AConfigure a Max Threads Constraint and add your application to the list of applications for the Constraint.
- BConfigure a Work Manager with a Maximum Threads Constraint tied to the Connection Pool and configuration your application to use the Work Manager.
- CConfigure a Work Manager with a Minimum Threads Constraint tied to the Connection Pool and configure your application to use the Work Manager.
- DConfigure a global MaxThreads constraint and target it to the server or clusters where your application is deployed.
- EConfigure the startup parameter "-Dwls-maxThreads" to be the same as the number of database connections configured.
Correct Answer:
B
To manage work in your applications, you define one or more of the following Work Manager components:
Fair Share Request Class:
Response Time Request Class:
Min Threads Constraint:
Max Threads Constraint:
Capacity Constraint -
Context Request Class:
Note:
* max-threads-constraintThis constraint limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.
A max-threads-constraint can be defined in terms of a the availability of resource that requests depend upon, such as a connection pool.
A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair share of threads or meeting its response time goal. Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.
* WebLogic Server prioritizes work and allocates threads based on an execution model that takes into account administrator-defined parameters and actual run- time performance and throughput.
Administrators can configure a set of scheduling guidelines and associate them with one or more applications, or with particular application components.
* WebLogic Server uses a single thread pool, in which all types of work are executed. WebLogic Server prioritizes work based on rules you define, and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool.
The common thread pool changes its size automatically to maximize throughput. The queue monitors throughput over time and based on history, determines whether to adjust the thread count. For example, if historical throughput statistics indicate that a higher thread count increased throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the thread count. This new strategy makes it easier for administrators to allocate processing resources and manage performance, avoiding the effort and complexity involved in configuring, monitoring, and tuning custom executes queues.
Reference: Using Work Managers to Optimize Scheduled Work
B
To manage work in your applications, you define one or more of the following Work Manager components:
Fair Share Request Class:
Response Time Request Class:
Min Threads Constraint:
Max Threads Constraint:
Capacity Constraint -
Context Request Class:
Note:
* max-threads-constraintThis constraint limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.
A max-threads-constraint can be defined in terms of a the availability of resource that requests depend upon, such as a connection pool.
A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair share of threads or meeting its response time goal. Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.
* WebLogic Server prioritizes work and allocates threads based on an execution model that takes into account administrator-defined parameters and actual run- time performance and throughput.
Administrators can configure a set of scheduling guidelines and associate them with one or more applications, or with particular application components.
* WebLogic Server uses a single thread pool, in which all types of work are executed. WebLogic Server prioritizes work based on rules you define, and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool.
The common thread pool changes its size automatically to maximize throughput. The queue monitors throughput over time and based on history, determines whether to adjust the thread count. For example, if historical throughput statistics indicate that a higher thread count increased throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the thread count. This new strategy makes it easier for administrators to allocate processing resources and manage performance, avoiding the effort and complexity involved in configuring, monitoring, and tuning custom executes queues.
Reference: Using Work Managers to Optimize Scheduled Work
send
light_mode
delete
Question #12
What are the three steps you should take to tune a JDBC Connection pool in WebLogic from the initial settings in a production environment?
- AEnsure the maximum size is increased to an appropriate setting.
- BSet the minimum and maximum size of the connection pool to the same value.
- CIncrease the statement cache size.
- DAdd more heap to the JVM.
- EAdd more nodes to the cluster.
Correct Answer:
ACE
A:
* Troubleshooting Slow Response Time from the Client and Low Database Usage
These symptoms are usually caused by a bottleneck upstream of the database, perhaps in the JDBC connectionpooling. Monitor the active JDBC connections in the WebLogic Console and watch for excessive waiters and wait times; increase the pool size, if necessary.
* Attribute: Maximum Capacity
Maximum number of physical database connections that this connection pool can contain. Different JDBC Drivers and database servers may limit the number of possible physical connections.
C: Attribute: Statement Cache Size
The algorithm used to maintain the statement cache:
LRU - After the statementCacheSize is met, the Least Recently Used statement is removed when a new statement is used.
Fixed - The first statementCacheSize number of statements is stored and stay fixed in the cache. No new statements are cached unless the cache is manually cleared.
E: If the queue appears starved but adding execute threads does not improve performance, there may be resource contention. Because CPU utilization is low, the threads are probably spending much of their time waiting for some resource, quite often a database connection.
Use the JDBC monitoring facilities in the console to check for high levels of waiters or long wait times. Adding connections to the JDBC connection pool may be all that is required to fix the problem.
Note:
* If you had a JDBC connection pool where the Initial Capacity and Maximum Capacity attributes were different, you might want to create a gauge monitor to monitor the maximum and minimum number of connections.
By setting the Threshold Low value to be one less than the Initial Capacity, your gauge monitor trapcould monitor the Active Connections Current Count attribute of the JDBC Data Source Runtime MBean and alert you whenever the number of active connections are less than the Initial Capacity (which might indicate database connectivity problems).
ACE
A:
* Troubleshooting Slow Response Time from the Client and Low Database Usage
These symptoms are usually caused by a bottleneck upstream of the database, perhaps in the JDBC connectionpooling. Monitor the active JDBC connections in the WebLogic Console and watch for excessive waiters and wait times; increase the pool size, if necessary.
* Attribute: Maximum Capacity
Maximum number of physical database connections that this connection pool can contain. Different JDBC Drivers and database servers may limit the number of possible physical connections.
C: Attribute: Statement Cache Size
The algorithm used to maintain the statement cache:
LRU - After the statementCacheSize is met, the Least Recently Used statement is removed when a new statement is used.
Fixed - The first statementCacheSize number of statements is stored and stay fixed in the cache. No new statements are cached unless the cache is manually cleared.
E: If the queue appears starved but adding execute threads does not improve performance, there may be resource contention. Because CPU utilization is low, the threads are probably spending much of their time waiting for some resource, quite often a database connection.
Use the JDBC monitoring facilities in the console to check for high levels of waiters or long wait times. Adding connections to the JDBC connection pool may be all that is required to fix the problem.
Note:
* If you had a JDBC connection pool where the Initial Capacity and Maximum Capacity attributes were different, you might want to create a gauge monitor to monitor the maximum and minimum number of connections.
By setting the Threshold Low value to be one less than the Initial Capacity, your gauge monitor trapcould monitor the Active Connections Current Count attribute of the JDBC Data Source Runtime MBean and alert you whenever the number of active connections are less than the Initial Capacity (which might indicate database connectivity problems).
send
light_mode
delete
Question #13
You have a durable subscriber, and the subscriber is down or not reachable when the message is produced. Which two options regarding the expiry of these messages are true?
- Aafter the subscriber is unavailable for 10 minutes
- Bwhen the subscriber is available
- Cafter the subscriber is unavailable for after an hour
- Dare available until the specified time elapses
- Eare expired instantly
Correct Answer:
BD
By default, JMS messages never expire. When applications send messages to queues or topics with durable subscribers, WebLogic must retain the message until it is consumed. This is fine in most point-to-point messaging applications because consumers are constantly consuming messages. Any message sent to a queue will typically be consumed in a relatively short period of time. If the consumers get disconnected, they will usually reconnect as soon as possible and start processing any messages that might have built up in the queue.
D: For durable subscribers to a topic, this is not necessarily true. The messaging system is forced to retain any message that has not been consumed by a durable subscriber, regardless of whether that durable subscriber will ever return. In this case, WebLogic is at the mercy of the durable subscriber to unsubscribe when it no longer wishes to receive the messages. If the durable subscriber logic is flawed in such a way that the subscribers do not unsubscribe properly, the messaging system will start to fill up with messages that may never be delivered. This calls for real caution in using durable subscribers. Fortunately, there is another way to help deal with this problem. Message expiration can be set at the connection factory level. Using a connection factorys default time-to-live attribute, we can specify the number of milliseconds that WebLogic should retain an undelivered message after it is sent.
BD
By default, JMS messages never expire. When applications send messages to queues or topics with durable subscribers, WebLogic must retain the message until it is consumed. This is fine in most point-to-point messaging applications because consumers are constantly consuming messages. Any message sent to a queue will typically be consumed in a relatively short period of time. If the consumers get disconnected, they will usually reconnect as soon as possible and start processing any messages that might have built up in the queue.
D: For durable subscribers to a topic, this is not necessarily true. The messaging system is forced to retain any message that has not been consumed by a durable subscriber, regardless of whether that durable subscriber will ever return. In this case, WebLogic is at the mercy of the durable subscriber to unsubscribe when it no longer wishes to receive the messages. If the durable subscriber logic is flawed in such a way that the subscribers do not unsubscribe properly, the messaging system will start to fill up with messages that may never be delivered. This calls for real caution in using durable subscribers. Fortunately, there is another way to help deal with this problem. Message expiration can be set at the connection factory level. Using a connection factorys default time-to-live attribute, we can specify the number of milliseconds that WebLogic should retain an undelivered message after it is sent.
send
light_mode
delete
Question #14
Identify the two options that can be used to patch WebLogic Server without Incurring application downtime.
- Aautomated process using the Admin Server
- Bautomated using JDeveloper
- Cmanual process with or without Smart Update
- Dscripted with WLST
- Eautomated process using Enterprise Manager 12c
Correct Answer:
CD
Note:
* Rolling Upgrade is the process of upgrading a running WebLogic Server cluster with a patch, maintenance pack, or minor release without shutting down the entire cluster or domain. During the rolling upgrade of a cluster, each server in the cluster is individually upgraded and restarted while the other servers in the cluster continue to host your application.
CD
Note:
* Rolling Upgrade is the process of upgrading a running WebLogic Server cluster with a patch, maintenance pack, or minor release without shutting down the entire cluster or domain. During the rolling upgrade of a cluster, each server in the cluster is individually upgraded and restarted while the other servers in the cluster continue to host your application.
send
light_mode
delete
Question #15
WebLogic 12c, the Maven plug-in has been enhanced with which Maven goal?
- Awls:unzip, wls:install-domain, wls:start-domain, wls:wlst, wls:appc
- Bwls:install, wls:install-domain, wls:start-domain, wls:wlst, wls:appc
- Cwls:unzip, wls:create-domain, wls:start-domain, wls:wlst, wls:appc
- Dwls:install, wls:create-domain, wls:start-server, wls:wlst, wls:appc:
Correct Answer:
D
wls-maven-pluginDelivered in WebLogic Server 12c, provides enhanced functionality to install, start and stop servers, create domains, execute WLST scripts, and compile and deploy applications.
Reference: Developing Applications for Oracle WebLogic Server, Using the WebLogic Development Maven Plug-In
D
wls-maven-pluginDelivered in WebLogic Server 12c, provides enhanced functionality to install, start and stop servers, create domains, execute WLST scripts, and compile and deploy applications.
Reference: Developing Applications for Oracle WebLogic Server, Using the WebLogic Development Maven Plug-In
send
light_mode
delete
All Pages