What are the differences between a load balancer, a reverse proxy, and an API gateway?
All three are used to optimize and manage web traffic. However, they vary in their function and use cases:
A 𝗹𝗼𝗮𝗱 𝗯𝗮𝗹𝗮𝗻𝗰𝗲𝗿 is a device that distributes incoming network traffic across multiple servers. The goal is to ensure that no single server is overwhelmed with traffic, which can lead to slow response times or even downtime. Load balancers are ideal for high-traffic websites or applications that need to handle a large volume of requests.
A 𝗿𝗲𝘃𝗲𝗿𝘀𝗲 𝗽𝗿𝗼𝘅𝘆, on the other hand, is a server that sits between the client and the web server. The reverse proxy intercepts requests from clients and forwards them to the appropriate server. The reverse proxy can also cache frequently requested content, which can help improve performance and reduce server load. Reverse proxies are ideal for websites or applications that need to handle a large number of concurrent connections.
An 𝗔𝗣𝗜 𝗴𝗮𝘁𝗲𝘄𝗮𝘆 is a server that acts as an intermediary between clients and backend servers. The API gateway is responsible for managing API requests, enforcing security policies, and handling authentication and authorization. API gateways are ideal for microservices architectures, where multiple services need to be accessed through a single API.
Thank you for giving your valuable time to read the above information.
If you want to be updated with all our articles send us the Invitation or Follow us:
PL/SQL lets you use all SQL data manipulation, cursor control, and transaction control statements, and all SQL functions, operators, and pseudo columns…
PL/SQL fully supports SQL data types – You need not convert between PL/SQL and SQL data types.
You can give a PL/SQL data item the data type of a column or row of a database table without explicitly specifying that data type
using %TYPE Attribute and %ROWTYPE Attribute.
PL/SQL supports both static and dynamic SQL. Static SQL is SQL whose full text is known at compile time.
Dynamic SQL is SQL whose full text is not known until run time. Dynamic SQL lets you make your applications more flexible and versatile.
2) High Performance
PL/SQL lets you send a block of statements to the database, significantly reducing traffic between the application and the database.
Bind Variables
When you embed a SQL INSERT, UPDATE, DELETE, MERGE, or SELECT statement directly in your PL/SQL code,
the PL/SQL compiler turns the variables in the WHERE and VALUES clauses into bind variables.
Oracle Database can reuse these SQL statements each time the same code runs, which improves performance.
PL/SQL does not create bind variables automatically when you use dynamic SQL, but you can use them with dynamic SQL by specifying them explicitly.
Optimizer
The PL/SQL compiler has an optimizer that can rearrange code for better performance.
Subprograms
PL/SQL subprograms are stored in executable form, which can be invoked repeatedly. Because stored subprograms run in the database server,
a single invocation over the network can start a large job. This division of work reduces network traffic and improves response times.
Stored subprograms are cached and shared among users, which lowers memory requirements and invocation overhead.
3) High Productivity
PL/SQL has many features that save designing and debugging time, and it is the same in all environments.
PL/SQL lets you write compact code for manipulating data.
PL/SQL can query, transform, and update data in a database.
4) Portability
You can run PL/SQL applications on any operating system and platform where Oracle Database runs.
5) Scalability
PL/SQL stored subprograms increases scalability by centralizing application processing on the database server.
The shared memory facilities of the shared server let Oracle Database support thousands of concurrent users on a single node.
6) Manageability
PL/SQL stored subprograms increase manageability because you can maintain only one copy of a subprogram, on the database server,
rather than one copy on each client system.
Any number of applications can use the subprograms, and you can change the subprograms without affecting the applications that invoke them.
Thank you for giving your valuable time to read the above information.
If you want to be updated with all our articles send us the Invitation or Follow us:
1) Decode is an oracle function.
2) Decode function can not be used as a parameter to a procedure or function.
3) Decode function internally uses only the equality operator.
4) Decode function is only used in SQL statements.
5) Decode function does not expect datatype consistency.
6) Decode function performance is low.
Case Statement:
1) Case statement is ANSI standard product.
2) Case statements can be used as a parameter to a procedure or function.
3) Case statement works with all SQL operators.
4) Case statements can be used in the PLSQL construct also.
5) Case statement expects datatype consistency.
6) Case statement performance is high.
Thank you for giving your valuable time to read the above information.
If you want to be updated with all our articles send us the Invitation or Follow us:
1) For each row clause used
2) Allow using when clause in row level trigger
3) Row level trigger has: new: old qualifiers
4) In row-level trigger, the trigger body is executed for each and every row for a DML statement
5) Performance low as compared to statement level trigger
Statement level trigger:
1) For each row clause not used
2) Not allowed using when clause in statement level trigger
3) Statement level trigger does not have: new: old qualifiers
4) in statement level trigger, the trigger body is executed only once per DML statement
5) Performance is high as compared to row-level trigger
Please find out all of our articles send us the Invitation or Following us:
1)Used mainly to execute a certain process
2)Cannot call in SELECT statement
3)Use the OUT parameter to return the value
4)It is not mandatory to return the value
5)RETURN will simply exit the control from the subprogram.
6)Return datatype will not be specified at the time of the creation
Function:
1)Used mainly to perform some calculation
2)A Function that contains no DML statements can be called in the SELECT statement
3)Use RETURN to return the value
4)It is mandatory to return the value
5)RETURN will exit the control from the subprogram and also returns the value
6)Return datatype is mandatory at the time of the creation
Please find out all of our articles send us the Invitation or Following us:
In Oracle, a SQL Profile creates extra information about a particular SQL that the optimizer can use at run time to select the optimal plan to ensure the best performance. In essence, the SQL Profile enables dynamic behavior where the optimizer has multiple plans to choose from at run time based on run time bind variables, etc. When you run the SQL Tuning Advisor for the list of recommendations you will see that the recommendation specifies whether a SQL can be improved by creating a SQL Profile or SQL Baseline. It is preferable to choose a SQL Profile simply because it allows the optimizer to pick the best execution plans at run time.
SQL Baseline on the other hand is more of a brute force method when you simply marry a particular SQL to stay with a specific SQL execution plan. So no matter what the run time bind variables are for a given SQL, the optimizer will always try to use the SQL Baseline plan. This may work fine for most cases but in instances, where data skew, is high it is preferable that one pick more efficient plans based on bind variable values passed at run time instead of always picking the same plan as generated by the SQL Baseline.
In any case knowledge of the application, and data may make you prefer one over the other, in case you are clueless about this, then I would suggest you stick with the SQL Profile.
A SQL patch is a SQL manageability object that can be generated by the SQL Repair Advisor, in order to circumvent a plan which causes a failure. In essence, a SQL patch tells the optimizer to change the plan in some way or avoid an optimization so that the failure does not occur. For instance, if a failure happens during index access, then generating a plan without that index (or without any index) may work around the failure
Oracle provides three mechanisms to deal with execution plans: SQL Profiles, SQL Baselines, and SQL Patches. Profiles are proposed by the Tuning Advisor and it’s mostly based on adapting the cardinalities to match reality. Baselines allow us to provide a list of the accepted execution plans for a statement.SQL Patches are part of the SQL Repair Advisor and add hints to a specific statement.
Please find out all of our articles send us the Invitation or Following us:
It is very important to have 64bit unixODBC libraries path (/usr/lib64/libodbc.so) in LD_LIBRARY_PATH because we run RHEL x64 and Oracle 64-bit software.
Step 6 –
Create init<sid>.ora. In my case, I will call this dg4odbc (initdg4odbc.ora). The content should be like below.
HS_DB_NAME = H1X
HS_FDS_CONNECT_INFO = H1X <===== This is the DSN name that comes from step 2 /etc/odbc.ini
The Oracle session has requested and is waiting for multiple contiguous database blocks (up to DB_FILE_MULTIBLOCK_READ_COUNT) to be read into the SGA from the disk.
Full Table scans
Fast Full Index Scans
ACTIONS:
Optimize multi-block I/O by setting the parameter DB_FILE_MULTIBLOCK_READ_COUNT
Partition pruning to reduce the number of blocks visited
Consider the usage of multiple buffers pools and caches of frequently used indexes/tables in the KEEP pool
Optimize the SQL statement that initiated most of the waits. The goal is to minimize the number of physical and logical reads.
Should the statement access the data by a full table scan or index FFS? Would an index range or unique scan be more efficient?
Does the query use the right driving table?
Are the SQL predicates appropriate for hash or merge join?
If full scans are appropriate, can parallel query improve the response time?
The objective is to reduce the demands for both the logical and
physical I/Os, and this is best achieved through SQL and application tuning.
Make sure all statistics are representative of the actual data. Check the LAST_ANALYZED date.
REMARKS:
If an application that has been running fine for a while suddenly clocks a lot of time on the DB file scattered read event and there hasn’t been a code change, you might want to check to see if one or more indexes have been dropped or become unusable.
DB file scattered read Reference Note# 34558.1
Thank you for giving your valuable time to read the above information.
If you want to be updated with all our articles send us the Invitation or Follow us:
