Oracle Database Memory Management
Memory management – focus is to maintain optimal sizes for memory structures.
Three basic options for memory management are as follows:
If you create a database with Database Configuration Assistant (DBCA) and choose the basic installation option, then automatic memory management is the default.
The memory structures include three areas of memory:
System Global Area
The SGA is a read/write memory area that stores information shared by all database processes and by all users of the database (sometimes it is called the Shared Global Area).
The SGA is allocated when an Oracle instance (database) is started up based on values specified in the initialization parameter file (either PFILE or SPFILE).
The SGA has the following mandatory memory structures:
Additional optional memory structures in the SGA include:
The SHOW SGA SQL command will show you the SGA memory allocations.
SQL> connect / as sysdba
Connected.
SQL> show sga
Total System Global Area 1610612736 bytes
Fixed Size 2084296 bytes
Variable Size 1006633528 bytes
Database Buffers 587202560 bytes
Redo Buffers 14692352 bytes
Early versions of Oracle used a Static SGA. This meant that if modifications to memory management were required, the database had to be shutdown, modifications were made to the init.ora parameter file, and then the database had to be restarted.
Oracle 11g uses a Dynamic SGA. Memory configurations for the system global area can be made without shutting down the database instance. The DBA can resize the Database Buffer Cache and Shared Pool dynamically.
Several initialization parameters are set that affect the amount of random access memory dedicated to the SGA of an Oracle Instance. These are:
The size of the SGA cannot exceed the parameter SGA_MAX_SIZE minus the combination of the size of the additional parameters, DB_CACHE_SIZE, LOG_BUFFER, SHARED_POOL_SIZE, LARGE_POOL_SIZE, and JAVA_POOL_SIZE.
Memory is allocated to the SGA as contiguous virtual memory in units termed granules. Granule size depends on the estimated total size of the SGA, which as was noted above, depends on the SGA_MAX_SIZE parameter. Granules are sized as follows:
Granules are assigned to the Database Buffer Cache, Shared Pool, Java Pool, and other memory structures, and these memory components can dynamically grow and shrink. Using contiguous memory improves system performance. The actual number of granules assigned to one of these memory components can be determined by querying the database view named
V$BUFFER_POOL.
Granules are allocated when the Oracle server starts a database instance in order to provide memory addressing space to meet the SGA_MAX_SIZE parameter. The minimum is 3 granules: one each for the fixed SGA, Database Buffer Cache, and Shared Pool. In practice, you’ll find the SGA is allocated much more memory than this. The SELECT statement shown below shows a current_size of 1,152 granules.
SELECT name, block_size, current_size, prev_size, prev_buffers
FROM v$buffer_pool;
NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE PREV_BUFFERS
——————– ———- ———— ———- ————
DEFAULT 8192 560 576 71244
For additional information on the dynamic SGA sizing, enroll in Oracle’s Oracle11g Database Performance Tuning course.
Program Global Area (PGA)
A PGA is:
The Program Global Area is also termed the Process Global Area (PGA) and is a part of memory allocated that is outside of the Oracle Instance.
The content of the PGA varies, but as shown in the figure above, generally includes the following:
User Global Area
The User Global Area is session memory.
A session that loads a PL/SQL package into memory has the package state stored to the UGA. The package state is the set of values stored in all the package variables at a specific time. The state changes as program code the variables. By default, package variables are unique to and persist for the life of the session.
The OLAP page pool is also stored in the UGA. This pool manages OLAP data pages, which are equivalent to data blocks. The page pool is allocated at the start of an OLAP session and released at the end of the session. An OLAP session opens automatically whenever a user queries a dimensional object such as a cube.
Note: Oracle OLAP is a multidimensional analytic engine embedded in Oracle Database 11g. Oracle OLAP cubes deliver sophisticated calculations using simple SQL queries – producing results with speed of thought response times.
The UGA must be available to a database session for the life of the session. For this reason, the UGA cannot be stored in the PGA when using a shared server connection because the PGA is specific to a single process. Therefore, the UGA is stored in the SGA when using shared server connections, enabling any shared server process access to it. When using a dedicated server connection, the UGA is stored in the PGA.
Automatic Shared Memory Management
Prior to Oracle 10G, a DBA had to manually specify SGA Component sizes through the initialization parameters, such as SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, and LARGE_POOL_SIZE parameters.
Automatic Shared Memory Management enables a DBA to specify the total SGA memory available through the SGA_TARGET initialization parameter. The Oracle Database automatically distributes this memory among various subcomponents to ensure most effective memory utilization.
The DBORCL database SGA_TARGET is set in the initDBORCL.ora file:
sga_target=1610612736
With automatic SGA memory management, the different SGA components are flexibly sized to adapt to the SGA available.
Setting a single parameter simplifies the administration task – the DBA only specifies the amount of SGA memory available to an instance – the DBA can forget about the sizes of individual components. No out of memory errors are generated unless the system has actually run out of memory. No manual tuning effort is needed.
The SGA_TARGET initialization parameter reflects the total size of the SGA and includes memory for the following components:
If SGA_TARGET is set to a value greater than SGA_MAX_SIZE at startup, then the SGA_MAX_SIZE value is bumped up to accommodate SGA_TARGET.
When you set a value for SGA_TARGET, Oracle Database 11g automatically sizes the most commonly configured components, including:
There are a few SGA components whose sizes are not automatically adjusted. The DBA must specify the sizes of these components explicitly, if they are needed by an application. Such components are:
The granule size that is currently being used for the SGA for each component can be viewed in the view V$SGAINFO. The size of each component and the time and type of the last resize operation performed on each component can be viewed in the view V$SGA_DYNAMIC_COMPONENTS.
SQL> select * from v$sgainfo;
More…
NAME BYTES RES
——————————– ———- —
Fixed SGA Size 2084296 No
Redo Buffers 14692352 No
Buffer Cache Size 587202560 Yes
Shared Pool Size 956301312 Yes
Large Pool Size 16777216 Yes
Java Pool Size 33554432 Yes93
Streams Pool Size 0 Yes
Granule Size 16777216 No
Maximum SGA Size 1610612736 No
Startup overhead in Shared Pool 67108864 No
Free SGA Memory Available 0
11 rows selected.
Shared Pool
The Shared Pool is a memory structure that is shared by all system users.
Memory can be allocated to the Shared Pool by the parameter SHARED_POOL_SIZE in the parameter file. The default value of this parameter is 8MB on 32-bit platforms and 64MB on 64-bit platforms. Increasing the value of this parameter increases the amount of memory reserved for the shared pool.
You can alter the size of the shared pool dynamically with the ALTER SYSTEM SET command. An example command is shown in the figure below. You must keep in mind that the total memory allocated to the SGA is set by the SGA_TARGET parameter (and may also be limited by the SGA_MAX_SIZE if it is set), and since the Shared Pool is part of the SGA, you cannot exceed the maximum size of the SGA. It is recommended to let Oracle optimize the Shared Pool size.
The Shared Pool stores the most recently executed SQL statements and used data definitions. This is because some system users and application programs will tend to execute the same SQL statements often. Saving this information in memory can improve system performance.
The Shared Pool includes several cache areas described below.
Library Cache
Memory is allocated to the Library Cache whenever an SQL statement is parsed or a program unit is called. This enables storage of the most recently used SQL and PL/SQL statements.
If the Library Cache is too small, the Library Cache must purge statement definitions in order to have space to load new SQL and PL/SQL statements. Actual management of this memory structure is through a Least-Recently-Used (LRU) algorithm. This means that the SQL and PL/SQL statements that are oldest and least recently used are purged when more storage space is needed.
The Library Cache is composed of two memory subcomponents:
Data Dictionary Cache
The Data Dictionary Cache is a memory structure that caches data dictionary information that has been recently used.
The database server manages the size of the Data Dictionary Cache internally and the size depends on the size of the Shared Pool in which the Data Dictionary Cache resides. If the size is too small, then the data dictionary tables that reside on disk must be queried often for information and this will slow down performance.
Server Result Cache
The Server Result Cache holds result sets and not data blocks. The server result cache contains the SQL query result cache and PL/SQL function result cache, which share the same infrastructure.
SQL Query Result Cache
This cache stores the results of queries and query fragments.
PL/SQL Function Result Cache
The PL/SQL Function Result Cache stores function result sets.
Buffer Caches
A number of buffer caches are maintained in memory in order to improve system response time.
Database Buffer Cache
The Database Buffer Cache is a fairly large memory object that stores the actual data blocks that are retrieved from datafiles by system queries and other data manipulation language commands.
The purpose is to optimize physical input/output of data.
When Database Smart Flash Cache (flash cache) is enabled, part of the buffer cache can reside in the flash cache.
A query causes a Server Process to look for data.
Database blocks are kept in the Database Buffer Cache according to a Least Recently Used (LRU) algorithm and are aged out of memory if a buffer cache block is not used in order to provide space for the insertion of newly needed database blocks.
There are three buffer states:
Each buffer has one of two access modes:
The buffers in the cache are organized in two lists:
The write list (also called a write queue) holds dirty buffers – these are buffers that hold that data that has been modified, but the blocks have not been written back to disk.
The LRU list holds unused, free clean buffers, pinned buffers, and free dirty buffers that have not yet been moved to the write list. Free clean buffers do not contain any useful data and are available for use. Pinned buffers are currently being accessed.
When an Oracle process accesses a buffer, the process moves the buffer to the most recently used (MRU) end of the LRU list – this causes dirty buffers to age toward the LRU end of the LRU list.
When an Oracle user process needs a data row, it searches for the data in the database buffer cache because memory can be searched more quickly than hard disk can be accessed. If the data row is already in the cache (a cache hit), the process reads the data from memory; otherwise a cache miss occurs and data must be read from hard disk into the database buffer cache.
Before reading a data block into the cache, the process must first find a free buffer. The process searches the LRU list, starting at the LRU end of the list. The search continues until a free buffer is found or until the search reaches the threshold limit of buffers.
Each time a user process finds a dirty buffer as it searches the LRU, that buffer is moved to the write list and the search for a free buffer continues.
When a user process finds a free buffer, it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list.
If an Oracle user process searches the threshold limit of buffers without finding a free buffer, the process stops searching the LRU list and signals the DBWn background process to write some of the dirty buffers to disk. This frees up some buffers.
Database Buffer Cache Block Size
The block size for a database is set when a database is created and is determined by the init.ora parameter file parameter named DB_BLOCK_SIZE.
Because tablespaces that store oracle tables can use different (non-standard) block sizes, there can be more than one Database Buffer Cache allocated to match block sizes in the cache with the block sizes in the non-standard tablespaces.
The size of the Database Buffer Caches can be controlled by the parameters DB_CACHE_SIZE and DB_nK_CACHE_SIZE to dynamically change the memory allocated to the caches without restarting the Oracle instance.
You can dynamically change the size of the Database Buffer Cache with the ALTER SYSTEM command like the one shown here:
ALTER SYSTEM SET DB_CACHE_SIZE = 96M;
You can have the Oracle Server gather statistics about the Database Buffer Cache to help you size it to achieve an optimal workload for the memory allocation. This information is displayed from the V$DB_CACHE_ADVICE view. In order for statistics to be gathered, you can dynamically alter the system by using the ALTER SYSTEM SET DB_CACHE_ADVICE (OFF, ON, READY) command. However, gathering statistics on system performance always incurs some overhead that will slow down system performance.
SQL> ALTER SYSTEM SET db_cache_advice = ON;
System altered.
SQL> DESC V$DB_cache_advice;
Name Null? Type
—————————————– ——– ————-
ID NUMBER
NAME VARCHAR2(20)
BLOCK_SIZE NUMBER
ADVICE_STATUS VARCHAR2(3)
SIZE_FOR_ESTIMATE NUMBER
SIZE_FACTOR NUMBER
BUFFERS_FOR_ESTIMATE NUMBER
ESTD_PHYSICAL_READ_FACTOR NUMBER
ESTD_PHYSICAL_READS NUMBER
ESTD_PHYSICAL_READ_TIME NUMBER
ESTD_PCT_OF_DB_TIME_FOR_READS NUMBER
ESTD_CLUSTER_READS NUMBER
ESTD_CLUSTER_READ_TIME NUMBER
SQL> SELECT name, block_size, advice_status FROM v$db_cache_advice;
NAME BLOCK_SIZE ADV
——————– ———- —
DEFAULT 8192 ON
<more rows will display>
21 rows selected.
SQL> ALTER SYSTEM SET db_cache_advice = OFF;
System altered.
KEEP Buffer Pool
This pool retains blocks in memory (data from tables) that are likely to be reused throughout daily processing. An example might be a table containing user names and passwords or a validation table of some type.
The DB_KEEP_CACHE_SIZE parameter sizes the KEEP Buffer Pool.
RECYCLE Buffer Pool
This pool is used to store table data that is unlikely to be reused throughout daily processing – thus the data blocks are quickly removed from memory when not needed.
The DB_RECYCLE_CACHE_SIZE parameter sizes the Recycle Buffer Pool.
Redo Log Buffer
The Redo Log Buffer memory object stores images of all changes made to database blocks.
The Redo Log Buffer as a circular buffer that is reused over and over. As the buffer fills up, copies of the images are stored to the Redo Log Files that are covered in more detail in a later module.
Large Pool
The Large Pool is an optional memory structure that primarily relieves the memory burden placed on the Shared Pool. The Large Pool is used for the following tasks if it is allocated:
The Large Pool size is set with the LARGE_POOL_SIZE parameter – this is not a dynamic parameter. It does not use an LRU list to manage memory.
Java Pool
The Java Pool is an optional memory object, but is required if the database has Oracle Java installed and in use for Oracle JVM (Java Virtual Machine).
Streams Pool
This pool stores data and control structures to support the Oracle Streams feature of Oracle Enterprise Edition.
SQL Statements are processed differently depending on whether the statement is a query, data manipulation language (DML) to update, insert, or delete a row, or data definition language (DDL) to write information to the data dictionary.
Processing a query:
Processing a DML statement:
Processing a DDL statement:
Oracle server: An Oracle server includes an Oracle Instance and an Oracle database.
Oracle instance: An Oracle Instance consists of two different sets of components:
Oracle database: An Oracle database consists of files.
User and server processes: The processes shown in the figure are called user and server processes. These processes are used to manage the execution of SQL statements.
This figure from the Oracle Database Administration Guide provides another way of viewing the SGA.
Connecting to an Oracle Instance – Creating a Session
System users can connect to an Oracle database through SQLPlus or through an application program like the Internet Developer Suite (the program becomes the system user). This connection enables users to execute SQL statements.
The act of connecting creates a communication pathway between a user process and an Oracle Server. As is shown in the figure above, the User Process communicates with the Oracle Server through a Server Process. The User Process executes on the client computer. The Server Process executes on the server computer, and actually executes SQL statements submitted by the system user.
The figure shows a one-to-one correspondence between the User and Server Processes. This is called a Dedicated Server connection. An alternative configuration is to use a Shared Server where more than one User Process shares a Server Process.
Sessions: When a user connects to an Oracle server, this is termed a session. The User Global Area is session memory and these memory structures are described later in this document. The session starts when the Oracle server validates the user for connection. The session ends when the user logs out (disconnects) or if the connection terminates abnormally (network failure or client computer failure).
A user can typically have more than one concurrent session, e.g., the user may connect using SQLPlus and also connect using Internet Developer Suite tools at the same time. The limit of concurrent session connections is controlled by the DBA.
If a system users attempts to connect and the Oracle Server is not running, the system user receives the Oracle Not Available error message.
]]>A) Start Oracle Apps Process
1. Login to the Linux server system with the login credentials specified whilst installation of Oracle Apps server.
e.g. In this case, user logged in with “Oracle” user.
2. Check the network connectivity.
3. Check the filesystem for space available and required in future.
4. Refer to the last session stop log file for any error if occurred.
5. Now set the environment in the db stack (oracle db home) by executing the <dbname>_<hostname>.env
e.g. user executed below command from “/oracle/u01/oraprod/11.2.0”
. VIS_step.env
6. Now start the listener : listener start <listener name>
e.g lsnrctl start VIS
7. Now login to Database as sys user and start the database.
[oracle@step 11.2.0]$ sqlplus “/as sysdba”
SQL*Plus: Release 11.2.0.3.0 Production on Sat Jul 9 13:38:55 2016
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
8. Please confirm the database is up and running along with the listener.
9. Go to APPL_TOP and set the environment of Apps.
10. Go to ADMIN_SCRIPTS_HOME
11. Now, Run adstrtal.sh to start Application Server
adstrtal.sh apps/apps
It will ask for Weblogic Password. We need to enter weblogic password.
12. Once the script is executed till the point we keep on receiving ——–“exited with 0” means that the everything is going on track, the moment we get exited with 1 means that part of server has not been up due to any reason, the details of the same can be viewed in the log file of the same.
B) Stop Oracle Apps Server
1. Go to APPL_TOP and set the environment of Apps.
e.g. cd /oracle/u01/applprod/fs1/EBSapps/appl
13. Go to ADMIN_SCRIPTS_HOME and run adstpall.sh to stop Application Server
adstpall.sh apps/apps
It will ask for weblogic password, which we need to provide.
14. Ensure that the script exits with 0 if not then refer to the log file.
15. Now before shutting down DB please ensure that all the oracle apps process is down by checking the FNDLIBR process.
ps -ef |grep FNDLIBR
It is showing 4 processors.
Keep on executing FNDLIBR command as above to confirm that each and every process is closed.
16. Now, set DB environment.
17. Now login to Database as sys user and stop the database.
18. Now we can stop the listener.
]]>Oracle 9i | Oracle10g | Oracle11g |
RAC Introduced
– Providing High avaliability |
RAC Improvements
– improved clusterware – Introduction of VIP’s for RAC |
Further RAC Improvements
– Faster failover of services – Grid Plug&Play allowing seamless additions/removal of nodes |
DataGuard enhancements
– Detection of gasps and automatic resolution |
DataGuard improvements
– Realtime apply and log compressions – Fast start failover added |
Active DataGuard added
– Standby Database can now be queried whilst redo apply is active |
Backup and Recovery
– Block level recovery – Improved reporting and automation |
Data Pump added
– Extract and import data faster than ever |
Improved Manageability
– ASM Cluster FileSystem (ACFS) Introduced – Virtual Columns added |
Oracle 11g | Oracle 12c | |
Varchar 2 Size | max 4K | max 32K |
Multiple Indexes on a Single Column | max 1 | a column can be part of multiple index |
Pluggable Database | NA | Available |
In-Memory Column Store | Data Buffer was available | IM Column Store along with DB Cache |
Data Pump Support for the In-Memory Column Store | NA | Available |
Force full database caching mode | NA | Available |
Oracle Multitenant option | NA | Available |
Full transportable export/import | NA | Available |
Target Enviroment | Grid | Cloud |
We would initiate the job by creating a VM on the base windows machine, the installation of Oracle / linux remains same with installation on base machine other than VM part.
Please follow the steps as specified in the image any explanation if required, that would be available at the bottom of the image.
Over here u can use NAT as well.
Preferred using single file as u might see in newer versions of the VM.
Please select the first option and press enter.
Skip the media test option.
Please select Yes.
If u r aware of self creation of various partitions then u should change or rather leave it as it is.
Please select yes.
If u wanna configure the n/w settings then u can use this option.
Please remember to select the Customize now or rather u will install the default config OS with no GUI.
Desktop Environments
GNOME Desktop Environment
Applications
Graphical Internet
Development
Development Libraries, Development Tools, GNOME Software Development, Java Development, X Software Development (Select libxpdevel and openmotif)
Servers
Server Configuration Tools, Web Server, Windows File Server
Base System
Administration Tools, Base , Java , Legacy Software Support (select compatdb) , System Tools (select sysstat) , X Window System
Please Disbale the Firewall settings.
Please Disable the Selinux Settings.
Do not Enable the kdump setting as not necessary.
Install VMware Tools.
Drag n Drop the VMWare Tools package and unzip the same.
Drag n drop the .pl file to the terminal to install the vmware tools, Just keep on pressing enter.
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 2147483648
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.filemax = 6815744
fs.aiomaxnr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 1048576
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
Post entry do > /sbin/sysctl -p
vi /etc/pam.d/login
add the line
session required pam_limits.so
vi /etc/security/limits.conf
add the following lines
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
Create the required directories
vi /home/oracle/.bash_profile
add the following code line
export ORACLE_HOME=/u01/home/oracle/product/11.2.0/db_1 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib export PATH=$ORACLE_HOME/bin:$PATH
Now copy downloaded oracle installation files to the /tmp directory. Ensure that oracle user can access the files and folder.
Switch the user to oracle and unzip both the 11g installer dir. This should create a single dir database. Post this logout and login with oracle
Now go to the database dir and run the runInstaller.
Now select the options as per your requirement to install the oracle db software.
At this point you would come to know what’s missing and accordingly install the packages or perform changes in OS.
Run these scripts from root login.
Now ur db is up and running and ready for use.
]]>1. Pluggable Databases through Database Consolidation:
Oracle is doing everything to jump into the cloud bandwagon. With 12C, Oracle is trying to address the problem of Multitenancy through this feature. There is a radical change and a major change in the core database architecture through the introduction of Container Databases also called CBD and Pluggable Databases (PDB). The memory and process is owned by the Container Database. The container holds the metadata where the PDBs hold the user data. You can create up to 253 PDBs including the seed PDB.
In a large setup, it is common to see 20 or 30 different instances running in production environment. With these many instances, it is a maintenance nightmare as all these instances have to be separately
With Pluggable Databases feature, you just have to do all this for ONE single instance. Without this feature, prior to 12C, you would have to create separate schemas and there is always a thread of security how much ever the isolation we build into it. There are problems with namespace conflicts, there is always going to be one public synonym that you can create. With PDBs you can have a separate HR or Scott schema for each PDB, separate Emp, Dept Tables and separate public synonyms. Additionally, 2 PDBs can talk to each other through the regular DB Link feature. There is no high start-up cost of creating a database any more. Instead of one instance per day, the shift is into one instance per many databases. For the developer community, you can be oblivious of all this and still continue to use the PDBs as if it were a traditional database, but for the DBAs the world would look like it has changed a lot.
Another cool feature is, you can allocate a CPU percentage for each PDB.
2. Redaction Policy:
This is one of the top features in Oracle 12C. Data Redaction in simple terms means, masking of data. You can setup a Data Redaction policy, for example SSN field in a Employee table can be masked. This is called redaction. From SQL Developer you can do this by going to the table:
Employee->Right click on Security Policy->click on New->click on Redaction Policy->Enter SSN.
When you do a select * from employee, it will show that the SSN is masked.
The new data masking will use a package called DBMS_REDACT. It is the extension to the FGAC and VPD present in earlier versions.
By doing this, whoever needs to view the data will be able to see it where as the other users will not be able to view it.
3. Top N Query and Fetch and offset Replacement to Rownum:
With the release of Oracle Database 12c, Oracle has introduced this new SQL syntax to simplify fetching the first few rows. The new sql syntax “Fetch First X Rows only” can be used.
4. Adaptive Query Optimization and Online Stats Gathering:
With this feature, it helps the optimizer to make runtime adjustments to execution plan which leads to better stats. For statements like CTAS (Create Table As Select) and IAS (Insert As Select), the stats is gathered online so that it is available immediately.
5. Restore a Table easily through RMAN:
Earlier if you had to restore a particular table, you had to do all sorts of things like restoring a tablespace and or do Export and Import. The new restore command in RMAN simplifies this task.
6. Size Limit on Varchar2, NVarchar2, Raw Data Types increased:
The previous limit on these data types was 4K. In 12C, it has been increased to 32,767 bytes. Up to 4K, the data is stored inline. I am sure everyone will be happy with this small and cute enhancement.
7. Inline PL/SQL Functions and Procedures:
The in line feature is extended in Oracle 12C. In addition to Views, we can now have PL/SQL Procedures and Functions as in line constructs. The query can be written as if it is calling a real stored procedure, but however the functions do not actually exist in the database. You will not be able to find them in ALL_OBJECTS. I think this will be a very good feature for the developers to explore as there is no code that needs to be compiled.
8. Generated as Identity/Sequence Replacement:
You can now create a col with ‘generated as identity’ clause. Thats it. Doing this is equivalent to creating a separate sequence and doing a sequence.nextval for each row. This is another handy and a neat feature which will help developer community. This is also called No Sequence Auto Increment Primary Key.
9. Multiple Indexes on a Single Column:
Prior to 12C, a column cant be in more than one index. In 12C, you can include a column in B-tree index as well as a Bit Map index. But, please note that only one index is usable at a given time.
10. Online Migration of Table Partition or Sub Partition:
You can very easily migrate a partition or sub partition from one tablespace to another. Similar to how the online migration was achieved for a non-partitioned table in prior releases, a table partition or sub partition can be moved to another tablespace online or offline. When an ONLINE clause is specified, all DML operations can be performed without any interruption on the partition|sub-partition which is involved in the procedure. In contrast, no DML operations are allowed if the partition|sub-partition is moved offline.
11. Temporary UNDO:
Prior to 12C, undo records generated by TEMP Tablespace is stored in the undo tablespace. With Temp undo feature in 12C, temp undo records can be stored in temporary table instead of UNDO TS. The benefit is – reduced undo tablespace and reduced redo log space used.
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=2G;
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0; –disables the hard limit
12. In Database Archiving:
This feature enables archiving rows within a table by marking them as inactive. These inactive rows are in the database and can be optimized using compression but are not visible to the application. These records are skipped during FTS (Full Table Scan).
Other Features:
Advanced Replication and Streams are Dead. It is being replaced with Oracle Golden Gate.
Invisible Columns. You can now have a invisible column in a table. When a column is defined as invisible, the column won’t appear in generic queries
PGA Aggregate Limit setting:
In 12c, you can set a hard limit on PGA by enabling the automatic PGA management, which requires PGA_AGGREGATE_LIMIT parameter settings. Therefore, you can now set the hard limit on PGA by setting the new parameter to avoid excessive PGA usage.
DDL Logging:
The DDL statements will automatically get recorded in xml/log file if ENABLE_DDL_LOGGING is set to True. ALTER SYSTEM|SESSION SET ENABLE_DDL_LOGGING=TRUE
]]>FNDLOAD is an Oracle utility that allows for the transfer of a wide range of Oracle Foundation (FND) data from one instance to the other. The loader reads a configuration file (LCT) to determine what data to access. It works by downloading the data in the source instance into a text file (LDT file) that can then be uploaded into target instances. FNDLOAD ensures consistent migration of the objects within Oracle Applications
— —————————–
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct XX_CON_PROG_SHORT_NAME.ldt PROGRAM APPLICATION_SHORT_NAME=”XXCUST” CONCURRENT_PROGRAM_NAME=”XX_CON_PROG_SHORT_NAME”
FNDLOAD apps/apps 0 Y UPLOAD $FND_TOP/patch/115/import/afcpprog.lct XX_CON_PROG_SHORT_NAME.ldt – WARNING=YES UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
— ————-
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/aflvmlu.lct XXCUST_LOOKUPTYPE.ldt FND_LOOKUP_TYPE APPLICATION_SHORT_NAME=”XXCUST” LOOKUP_TYPE=”XXCUST_LOOKUPTYPE”
FNDLOAD apps/apps O Y UPLOAD $FND_TOP/patch/115/import/aflvmlu.lct XXCUST_LOOKUPTYPE.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
— ———
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afscprof.lct XXCUST_PROFILE.ldt PROFILE PROFILE_NAME=”XXCUST_PROFILE” APPLICATION_SHORT_NAME=”XXCUST”
$FND_TOP/bin/FNDLOAD apps/apps 0 Y UPLOAD $FND_TOP/patch/115/import/afscprof.lct XXCUST_PROFILE.ldt – WARNING=YES UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
— ——————————
FNDLOAD apps/apps 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcprset.lct XXCUST_REQUESTSET.ldt REQ_SET REQUEST_SET_NAME=”XXCUST_REQUESTSET”
FNDLOAD apps/apps 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcprset.lct XXCUST_REQSET_LINKS.ldt REQ_SET_LINKS REQUEST_SET_NAME=”XXCUST_REQUESTSET”
Links
FNDLOAD apps/apps O Y UPLOAD $FND_TOP/patch/115/import/afcprset.lct XXCUST_REQUESTSET.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
FNDLOAD apps/apps O Y UPLOAD $FND_TOP/patch/115/import/afcprset.lct XXCUST_REQSET_LINKS.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
— ———————
FNDLOAD apps/apps 0 Y DOWNLOAD $FND_TOP/patch/115/import/afmdmsg.lct XXCUST_MSG.ldt FND_NEW_MESSAGES APPLICATION_SHORT_NAME=”XXCUST” MESSAGE_NAME=”XXCUST_MSG”
FNDLOAD apps/apps O Y UPLOAD $FND_TOP/patch/115/import/afmdmsg.lct XXCUST_MSG.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
— ———
FNDLOAD apps/apps 0 Y DOWNLOAD $ALR_TOP/patch/115/import/alr.lct XXCUST_ALR.ldt ALR_ALERTS APPLICATION_SHORT_NAME=XXCUST ALERT_NAME=”Alert Name”
FNDLOAD apps/apps 0 Y UPLOAD $ALR_TOP/patch/115/import/alr.lct XXCUST_ALR.ldt CUSTOM_MODE=FORCE
— ————–
FNDLOAD apps/apps 0 Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct XXCUST_VALSET.ldt VALUE_SET FLEX_VALUE_SET_NAME=”Custom Value Set Name”
FNDLOAD apps/apps 0 Y UPLOAD $FND_TOP/patch/115/import/afffload.lct XXCUST_VALSET.ldt – WARNING=YES UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE
— ————–
FNDLOAD apps/apps 0 Y DOWNLOAD $FND_TOP/patch/115/import/affrmcus.lct ARXTWMAI.ldt FND_FORM_CUSTOM_RULES form_name=ARXTWMAI
FNDLOAD apps/apps 0 Y UPLOAD $FND_TOP/patch/115/import/affrmcus.lct ARXTWMAI.ldt
— ———————————————————-
FNDLOAD apps/apps 0 Y DOWNLOAD $XDO_TOP/patch/115/import/xdotmpl.lct XXCUST_DD_TEMPLATE.ldt XDO_DS_DEFINITIONS APPLICATION_SHORT_NAME=XBOL DATA_SOURCE_CODE=XXCUST_DD_TEMPLATE
FNDLOAD apps/trxappsttrxi 0 Y UPLOAD $XDO_TOP/patch/115/import/xdotmpl.lct XXCUST_DD_TEMPLATE.ldt
— ———————————————————-
java oracle.apps.xdo.oa.util.XDOLoader DOWNLOAD -DB_USERNAME apps -DB_PASSWORD apps -JDBC_CONNECTION ‘(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=HOST NAME)(PORT=PORT NUMBER))(CONNECT_DATA=(SERVICE_NAME=SERVICE NAME)))’ -LOB_TYPE TEMPLATE -LOB_CODE XXCUST_CODE -APPS_SHORT_NAME XBOL -LANGUAGE en -TERRITORY 00 -lct_FILE $XDO_TOP/patch/115/import/xdotmpl.lct -LOG_FILE XXCUST_CODE.log
java oracle.apps.xdo.oa.util.XDOLoader UPLOAD -DB_USERNAME apps -DB_PASSWORD apps -JDBC_CONNECTION ‘(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=HOST NAME)(PORT=PORT NUMBER))(CONNECT_DATA=(SERVICE_NAME=SERVICE NAME)))’ -LOB_TYPE TEMPLATE -LOB_CODE XXCUST_CODE -XDO_FILE_TYPE RTF -FILE_NAME XXCUST_CODE_RTF_FILE.rtf -APPS_SHORT_NAME XBOL -LANGUAGE en -TERRITORY 00 -CUSTOM_MODE FORCE -LOG_FILE XXCUST_CODE_RTF_UPLOAD.log
]]>FND SRWINIT:
FND SRWINIT sets your profile option values and allows Oracle AOL user exits to detect that they have been called by a Oracle Reports program.[Before Report trigger, P_CONC_REQUEST_ID lexical parameter]. We should always call FND SRWINIT from the Before Report Trigger
SRW.USER_EXIT(‘FND SRWINIT’);
FND SRWEXIT:
FND SRWEXIT ensures that all the memory allocated for Oracle AOL user exits has been freed up properly. [After Report trigger]. You always call FND SRWEXIT from the After Report Trigger
SRW.USER_EXIT(‘FND SRWEXIT’); Note:- Mandatory Parameter with SRWINIT AND SRWEXIT is P_CONC_REQUEST_ID. Datatype Should be Number(15).
FND FORMAT_CURRENCY:
FND FORMAT_CURRENCY is used for MULTIPLE CURRNECY REPORTING (MRC)[formula Column, P_MIN_PRECISION lexical parameter]
SRW.USER_EXIT(‘FND FORMAT_CURRENCY ‘);
FND FORMAT_CURRENCY
CODE=”:column containing currency code”
DISPLAY_WIDTH=”field width for display”
AMOUNT=”:source column name”
DISPLAY=”:display column name”
[MINIMUM_PRECISION=”:P_MIN_PRECISION”] [PRECISION=”{STANDARD|EXTENDED}”] [DISPLAY_SCALING_FACTOR=””:P_SCALING_FACTOR”
DESCRIPTION:
CODE – Specify the column which contains the currency code for the amount. The type of this column is CHARACTER.
DISPLAY_WIDTH – Specify the width of the field in which you display the formatted amount.
AMOUNT – Specify the name of the column which contains the amount retrieved from the database. This amount is of type NUMBER.
DISPLAY – Specify the name of the column into which you want to display the formatted values. The type of this column is CHARACTER.
MINIMUM_PRECISION – Specify the precision to which to align all currencies used in this report region. You specify the MINIMUM_PRECISION token in mixed currency report regions to ensure all currency values align at the radix character for easy readability. Your user can adjust the report by setting an input parameter when submitting the report to specifically tailor the report output to a desired minimum precision or accept the default which is determined from the profile option
CURRENCY:MIXED_PRECISION (Currency: Mixed Currency Precision). Your report submission must pass the value as a report argument. You use P_MIN_PRECISION as the name of this lexical.
PRECISION – If specified as STANDARD, then standard precision is used
DISPLAY_SCALING_FACTOR- Optionally, specify the scaling factor to be applied to the amount in that column. If this token is not specified or is negative no scaling is performed. You use
P_SCALING_FACTOR as the name of this lexical parameter.
FND FLEXSQL:
FND FLEXSQL this API is used for get SELECT/WHERE/HAVING/ORDER BY/GROUP BY from flex field tables. This call changes the value of the lexical parameter P_FLEXDATA at runtime to the SQL fragment that selects all flexfields value data. For example, the parameter changes to (SEGMENT1||’n’||SEGMENT2||’n’||SEGMENT3||’n’||SEGMENT4).
SRW.REFERENCE(:P_STRUCT_NUM);SRW.USER_EXIT(‘FND FLEXSQL CODE=”GL#” NUM=”:P_STRUCT_NUM”APPL_SHORT_NAME=”SQLGL” OUTPUT=”:P_FLEXDATA” MODE=”SELECT” DISPLAY=”ALL”‘);
FND FLEXIDVAL:
FND FLEXIDVAL this API is used for get descriptions from flex fields gets input from FND FLEXSQL.
Call this user exit to populate fields for display. You pass the key flex fields data retrieved by the query into this exit from the formula column. With this exit you display values, descriptions and prompts by passing appropriate token (VALUE/DESCRIPTION/APROMPT/LPROMPT).
it will take inputs from columns of query , the columns are defined by FND FLEXSQL.
SRW.USER_EXIT(‘FND FLEXIDVAL’)
FND FLEXIDVALCODE=”flexfield code”APPL_SHORT_NAME=”application short name”DATA=”:source column name”[NUM=”:structure defining source column/lexical”][DISPLAY=”{ALL|flexfield qualifier|segment number}”][IDISPLAY=”{ALL|flexfield qualifier|segmentnumber}”][SHOWDEPSEG=”{Y | N}”][VALUE=”:output column name”][DESCRIPTION=”:output column name”][APROMPT=”:output column name”][LPROMPT=”:output column name”][PADDED_VALUE=”:output column name”][SECURITY=”:column name”]CODE means Key flexfield code(GL# is for Accounting Flex field, for all other check the table FND_ID_FLEXS)NUM is the structure of the key flex field(Chart of Accounts Number)DATA is where you store the retrieved data (your sql output).
]]>