Islamic University of Technologyenamul86.weebly.com/uploads/3/1/3/3/31331981/bsc_thesis.pdf · Oracle release. The following are some generalized examples (acceptable values vary

Thesis on Performance Tuning Of a Distributed Database System and Online Transaction Processing System in Mobile Computing Environment

Submission Date:9th October,2008

S.M.Mashihure Romman 044402

Md.Enamul Haque 044415

Md. Humayan Kabir 044435

Supervisor: Ali-Al Mamun Lecturer, Dept. of CIT, IUT

Co-supervisor: S.M.Faisal Lecturer , Dept. of CIT, IUT

Islamic University of Technology Dept. of Computer Science and Information Technology

P a g e | 2

Performance Tuning Of a DDBMs and OLTP in Mobile Computing Environment

DECLARATION We, hereby, declare that the work presented in this project is the outcome of the

investigation performed by us under the supervision Mr. Ali Al Mamun, Lecturer and

Co-supervision Mr. S.M.Faisal, Lecturer, Department of Computer Science and

Information Technology, IUT, Dhaka. We also declare that no part of this project and

thereof has been or is being submitted elsewhere for the award of any degree or Diploma.

Countersigned Signature

….........................……............... ………………………………. Md. Ali-Al Mamun S.M.Mashihure Romman

…………………………. ………………………………. S.M. Faisal Md.Enamul Haque

……………………………….

Md.Humayan Kabir Supervisor Candidate

P a g e | 3


ABSTRACT Performance tuning is a very important factor in large database systems. The main focus of

Performance tuning of a database system is to minimize the response time and increase the

memory utilization. A study has been done to accomplish this task. For OLTP systems, the issue

of optimizing the insertion process is studied and an optimal point is established. Various types

of indexes play an important role for achieving optimum database performance. Comparison

between B-tree and bitmap index is done through experimental results and the optimal choice is

indicated for respective situations. The impact of composite and function-based index is also

studied. From the perspective of tuning schema, a study is done on clustering of tables and

partitioned tables. After that some experimental work is done on those partitions (range, list,

hash, composite). Rule based and cost based optimizezr mode is followed to measure the

performance of joining and query among different tables. An effective formula is stated to tune

the memory structure of the database. We have measured performance based on SQL joining and

made one web and mobile application for Online Transaction Processing System

P a g e | 4


ACKNOWLEDGEMENTS

We would like to thank our respected Prof. Dr. M.A Mottalib, Head of the Department,

Department of Computer Science and information technology, IUT, Dhaka, supervisor

Mr. Ali Al Mamun, Lecturer, and Co-Supervisor Mr. S.M. Faisal, Lecturer, Department of

Computer Science and Information Technology, IUT, Dhaka, Bangladesh for his continuous

guidance and cooperation along the way and numerous useful suggestions, time and again to

improve this document.

We are indebted to our department for library and internet and printing facilities that we got

throughout the project without which this project would have not been possible in time.

Last but not the least, we want to express out profound gratitude to our parents and family

members and friends for their blessings and encouragement during our project work.

P a g e | 5


TABLE OF CONTENT

INDEX PAGE

1. Chapter One Motivation 6

2. Chapter Two Background Study 10

3. Chapter Three System Architecture 18

4. Chapter Four Experimental Performance Tuning Work 22

5. Chapter Five Implementation Work 79

6. Chapter Six Summary and Conclusion 86

7. Chapter Seven Future Work 88

8. APPENDIX-A, B, C, D

9. REFERENCES

P a g e | 6


Chapter One

Motivation

1. Distributed Database System, A simple idea:

A Distributed Database System is a database system where data is physically stored across several sites, and each site is typically managed by a DBMS that is capable of running independently of the other sites. The location of data items and the degree of autonomy of individual sites have a significant impact on all aspects of the system. The distribution of data is governed by factors such as local ownership and increased availability, in addition to performance issues. 2. Reasons behind using Distributed Database Systems: Organizational and Economic reasons: Many organizations are decentralized, and a distributed database approach fits more naturally the structure of the organization. Interconnection of existing databases: Distributed databases are the natural solution when several databases already exist in an organization and the necessity of performing global application arises. Incremental growth: If an organization grows by adding new, relatively autonomous organizational units (new branches, new warehouses, etc.), then the distributed database approach supports a smooth incremental growth with a minimum degree of impact on the already existing units. Reduced communication overhead: In a geographically distributed database the fact that many applications are local clearly reduces the communication overhead with respect to a centralized database. Performance Considerations: The existence of several autonomous processors results in the increase of performance through a high degree of parallelism. Reliability and availability: The distributed database approach, especially with redundant data, can be used also in order to obtain higher reliability and availability. 3. Reasons for developing distributed database system:

P a g e | 7


1. The recent development of small computers, providing at a lower cost many of the capabilities which were previously provided by large mainframes, constitutes the necessary hardware support for the development of distributed information system.

2. The technology of distributed databases is based on two other technologies which have developed a sufficiently solid foundation during the seventies: computer network technology and database technology. It is a complex task to build a distributed database on top of computer network and a set of local database management systems at each site. It would be an infeasible effort without these building blocks.

4. Performance tuning of distributed database systems: 4.1 Performance Tuning, What it is? Performance tuning is the improvement of system performance. This is typically a computer application, but the same methods can be applied to economic markets, other complex systems. The motivation for such activity is called a performance problem, which can be real or anticipated. Most systems will respond to increased load with some degree of decreasing performance. A system's ability to accept higher load is called scalability, and modifying a system to handle a higher load is synonymous to performance tuning.

A performance problem may be identified by slow or unresponsive systems. This usually occurs because high system loading, causing some part of the system to reach a limit in its ability to respond. This limit within the system is referred to as a bottleneck.

A handful of techniques are used to improve performance. Among them- i) DML optimization ii) Indexing Technique iii) Partitioned Table iv) Clustering Technique v) Memory Structure are pretty helpful.

4.2 When to Tune Performance of a Database: We can tune our system in various ways. Some of them are given below. Proactive Monitoring usually occurs on a regularly scheduled interval, where a number of performance statistics are examined to identify whether the system behavior and resource usage has changed. Proactive monitoring also can be called proactive tuning. Usually, monitoring does not result in configuration changes to the system, unless the monitoring exposes a serious problem that is developing. In some situations, experienced performance engineers can identify potential problems through statistics alone, although accompanying performance degradation is usual. Experimenting with or tweaking a system when there is no apparent performance degradation as a proactive action can be a dangerous activity, resulting in unnecessary

P a g e | 8


performance drops. Tweaking a system should be considered reactive tuning, and the steps for reactive tuning should be followed. Monitoring is usually part of a larger capacity planning exercise, where resource consumption is examined to see the changes in the way the application is being used and the way the application is using the database and host resources.

Bottleneck Elimination Tuning usually implies fixing a performance problem. However, tuning should be part of the life cycle of an application, through the analysis, design, and coding, production, and maintenance stages. Many times, the tuning phase is left until the system is in production. At this time, tuning becomes a reactive fire-fighting exercise, where the most important bottleneck is identified and fixed.

Usually, the purpose for tuning is to reduce resource consumption or to reduce the elapsed time for an operation to complete. Either way, the goal is to improve the effective use of a particular resource. In general, performance problems are caused by the over-use of a particular resource. That resource is the bottleneck in the system. There are a number of distinct phases in identifying the bottleneck and the potential fixes. These are discussed in the sections that follow. Remember that the different forms of contention are symptoms that can be fixed by making changes in the following places:

-Changes in the application, or the way the application is used

-Changes in Oracle

-Changes in the host hardware configuration

Often, the most effective way of resolving a bottleneck is to change the application.

High Rates of Activity Examine the statistics normalized over seconds to identify whether the rates of activity are very high. It is difficult to make blanket recommendations on high values, because the thresholds are different on each site and are contingent on the application characteristics, the number and speed of CPUs, the operating system, the I/O system, and the Oracle release.

The following are some generalized examples (acceptable values vary at each site):

• A hard parse rate of more than 100 a second indicates that there is a very high amount of hard parsing on the system. High hard parse rates cause serious performance issues and must be investigated. Usually, a high hard parse rate is accompanied by latch contention on the shared pool and library cache latches.

• Check whether the sum of the wait times for library cache and shared pool latch events (latch: library cache, latch: library cache pin, latch: library cache lock and latch: shared pool) is significant compared to statistic DB time found in V$SYSSTAT. If so, examine the SQL ordered by Parse Calls section of the Automatic Workload Repository report.

• A high soft parse rate could be in the rate of 300 a second or more. Unnecessary soft parses also limit application scalability. Optimally, a SQL statement should be soft parsed once in each session and executed many times.

P a g e | 9


Changing Load The load profile statistics over seconds show the changes in throughput (that is, whether the instance is performing more work each second). The statistics over transactions identify changes in the application characteristics by comparing these to the corresponding statistics from the baseline report.

Examine the Host System Look at the load on the database server, as well as the database instance. Consider the operating system, the I/O subsystem, and network statistics; because examining these areas helps determine what might be worth further investigation. In multi-tier systems, also examine the application server middle-tier hosts.

Examining the host hardware often gives a strong indication of the bottleneck in the system. This determines which Oracle performance data could be useful for cross-reference and further diagnosis.

P a g e | 10


Chapter Two

Background Study While going throughout the project we required several concepts. For example Distributed Database, ORACLE, j2ME, C#, ASP.net, Socket programming, GPRS, EDGE, 1. Study on Distributed Database System:

DISTRIBUTED DBMS ARCHITECTURES There are three approaches to separate functionality across different DBMS-related processes; these are called:- • Client – Server Systems • Collaborating Server Systems • Middleware Systems Client – Server Systems- This is the traditional approach for building distributed databases. A Client-Server system has one or more client processes and one or more server processes, and a client process can send a query to any one server process. Clients are responsible for user-interface issues, and servers manage data and execute transaction. Thus, a client process could run on a personal computer and send queries to a server running on a mainframe. Middleware Systems- The idea is that we need just one database server that is capable of managing queries and transactions spanning multiple servers; the remaining servers only need to handle local queries and transactions. We can this of this special server as a layer of software that coordinates the execution of queries and transactions across one or more independent database servers; such software is often called middleware. Collaborating Server Systems- The Client-Sever architecture does not allow a single query to span multiple servers because the client process would have to be able to capable of breaking such a query into appropriate subqueries to be executed at different sites and then piecing together the answers to the subqueries. There is an alternative system called Collaborating Server Systems. In this system we have a collection of database servers, each capable of running transactions against local data, which cooperatively execute transactions spanning multiple servers. When a server receives a query that requires access to data at other servers, it generates appropriate subqueries to be executed by other servers and puts the results together to compute answers to the original query. The decomposition of the query is done using cost-based

P a g e | 11


optimization, taking into account the costs of network communication as well as local processing costs. It is this approach of Collaborating Servers, we have tried to implement in our distributed database system. 2. Study on ORACLE:

2.1 ORACLE Architectural Components

There are several files, processes, and memory structures in an Oracle server; however, not all of

them are used when processing a SQL statement. Some are used to improve the performance of

the database, to ensure that the database can be recovered in the event of a software or hardware

error, or to perform other tasks necessary to maintain the database. The Oracle server consists of

an Oracle instance and an Oracle database [2].

2.1.1 Oracle Instance:

It consists of the System Global Area (SGA) memory structure and the background processes

that are used to manage a database. An instance is identified by using methods specific to each

operating system. The instance can open and use only one database at a time.

2.1.2 Establishing a connection and creating a session:

Before users can submit SQL statements to an Oracle database, they must connect to an instance.

The user starts a tool such as SQL*Plus or runs an application developed using a tool such as

Figure2.1: Oracle architectural components

P a g e | 12


Oracle Forms. This application of tool is executed as a user process. When a user logs on to the

Oracle server, a process is created on the computer running the Oracle server. This process is

called a server process. The server process communicates with the Oracle instance on behalf of

the user process that runs on the client. The server process executes SQL statements on behalf of

the user.

2.2 Memory Structure: Oracle’s memory structure consists of two memory areas known as: System Global Area (SGA)

and Program Global Area (PGA).

a. System Global Area:

The SGA consists of several memory structures

Shared Pool

Database Buffer Cache

Redo Log Buffer

Other structures (for example, lock and latch management, statistical data)

There are two additional memory structures that can be configured within the SGA

-Large Pool

- Java Pool

The SGA is also called the shared global area. It is used to store database information that is

shared by database processes. It contains data and control information for the Oracle server and

is allocated in the virtual memory of the computer where the oracle resides.

2.2.2 Dynamic SGA:

A dynamic SGA implements an infrastructure that allows the SGA configuration to change

without shutting down the instance. This then allows the sizes of the Database Buffer Cache,

Shared Pool, and Large Pool to be changed without shutting down the instance. The database

buffer cache and shared pool could be initially under configured and would grow and shrink

depending upon their respective work loads, up to a maximum of SGA_MAX_SIZE

2.2.3 Shared Pool:

The Shared Pool environment contains both fixed and variable structures. The fixed structure

remains relatively the same size, whereas the variable structures grow and shrink based on user

and program requirements.

P a g e | 13


i. Library Cache:

The Library Cache size is based on the sizing defined for shared pool. Memory is allocated when

a statement is parsed or a program unit is called. If the size of the Shared Pool is too small,

statements are continually reloaded in the Library Cache, which affects performance. The

Library Cache is managed by an LRU algorithm.

The Library Cache consists of two structures:

2.2.4 Shared SQL:

The Shared SQL stores and shares the execution plan and parse tree for SQL statements run

against the database. The second time that an identical SQL statement is run, it is able to take

advantage of the parse information available in the shared SQL to expedite its execution.

2.2.5 Shared PL/SQL:

The shared PL/SQL area stores and shares the most recently executed PL/SQL statements.

ii. Data Dictionary Cache

The Data Dictionary Cache is also referred to as the dictionary cache or row cache. Information

about the database user account data, data file names, segment names, extent locations, table

descriptions, and user privileges are stored in the data dictionary tables. When this information is

needed by the server, the data dictionary tables are read, and the data that is returned is stored in

the Data Dictionary Cache.

2.2.6 Database Buffer Cache:

When a query is processed, the Oracle Server process looks in the Database Buffer Cache for

any blocks it needs. If the block is not found in the Database Buffer Cache, the server process

reads the block from the data file and places a copy in the Database Buffer Cache. The Oracle

server uses an LRU algorithm to age out buffers that have not been accessed recently to make

room for new blocks in the Database Buffer Cache.

2.2.7 Redo Log Buffer:

The Redo Log Buffer is a circular buffer that contains changes made to data file blocks. This

information is stored in redo entries. Redo entries contain the information necessary to re-create

the data prior to the changed made by INSERT, UPDATE, DELETE, CREATE, ALTER or

DROP operations.

P a g e | 14


2.2.8 Large Pool:

By allocating session memory from the large pool for shared server, ORACLE XA, or parallel

query buffers, Oracle can use the Shared Pool primarily for caching shared SQL statements, thus

relieving the burden on areas within the Shared Pool. The Shared Pool does not have to give up

memory for caching SQL parse trees in favor of shared server session information, I/O, backup

and recover processes. The Large Pool does not have an LRU list. It is different from reserved

space in the Shared Pool, which uses an LRU list.

2.2.9 Java Pool:

The Java Pool is an optional setting but is required if users are installing and using java. Its size

is set, in bytes using the JAVA_POOL_SIZE parameter.

b. Program Global Area (PGA):

The Program Global Area (PGA) is a memory region that contains data and control information

for a single server process or a single background process. The PGA is allocated when the

process is created and reallocated when the process is terminated. In contrast to the SGA, which

is shared by several processes, the PGA is an area that is used by only one process.

2.3 Process Structure: Oracle takes advantage of various types of processes:

a. User Process:

A database user who needs to request information from the database must first make a

connection with the Oracle server. The connection is requested using a database interface tool,

such as SQL*Plus, and beginning the user process. The user process does not interact directly

with the Oracle server.

b. Server Process:

Once a user has established a connection, a server process is started to handle the user process

requests. A server process can be either a dedicated server process or a shared server process. In

a dedicated server environment, the server process handles the request of single user process.

Once a user process disconnects, the server process is terminated. In a shared server

environment, the server process handles the request of several user processes. The server process

communication with the Oracle server using the Oracle Program Interface (OPI)

P a g e | 15


c. Background Process:

Background process maintains and enforces relationships between physical and memory

structures. The mandatory background processes are discussed below:

2.3.1 Database Writer (DBWn):

The server process records changes to undo and data blocks in the Database Buffer Cache.

DBWn writes the dirty buffers from the Database Buffer Cache to the data files. It ensures that a

sufficient number of free buffers (buffers that can be overwritten when server processes need to

read in blocks from the data files) are available in the Database Buffer Cache. Database Buffer

Cache is improved because server processes make changes only in the Database Buffer Cache.

2.3.2 Log Writer (LGWR):

LGWR performs sequential writes from the Redo Log Buffer to the online redo log file under the

following situations:

i. When a transaction commits

ii. When the Redo Log Buffer is one-third full

iii. When there is more than 1 MB of changes recorded in the Redo Log Buffer

iv. Before DBWn writes modified blocks in the Database Buffer Cache to the data files.

v. Every three seconds

Because the redo is needed for recovery, LGWR confirms the commit operation only after the

redo is written to disk. LGWR can also call on DBWn to write to the data files

2.3.3 System Monitor (SMON):

If the Oracle instance fails, any information in the SGA that has not been written to disk is lost.

For example, the failure of the operating system causes an instance failure. After the loss of the

instance, the background process SMON automatically performs instance recovery when the

database is reopened.

2.3.4 Process Monitor (PMON):

The background process PMON cleans up after failed processes by:

i. Rolling back the user’s current transaction

ii. Releasing all currently held table or row locks

iii. Freeing other resources currently reserved by the user

P a g e | 16


iv. Restarts dead dispatchers.

2.3.5 Checkpoint (CKPT):

Every three seconds the CKPT process stores data in the control file to identify that place in the

online redo log file where recovery is to begin, which is called a checkpoint. The purpose of a

checkpoint is to ensure that all of the buffers in the Database Buffer Cache that were modified

prior to a point in time have been written to the data files. This point in time (called the

checkpoint position) is where database recovery is to begin in the event of an instance failure.

DBWn will already have written all of the buffers in the Database Buffer Cache that were

modified prior to that point in time.

2.3.6 Oracle Database Structure:

The general purpose of a database is to store and retrieve related information. An Oracle

database has a logical and a physical structure.

2.4 Physical Structure:

The physical structure of the database is the set of operating system files in the database. An

Oracle database consists of three file types.

a. Data files: Contains the actual data in the database.

b. Online redo log files: Contains a record of changes made to the database to enable

recovery of the data in case of failures.

c. Control files: Contains information necessary to maintain and verify database integrity.

II. Logical Structure:

A logical structure hierarchy exists as follows:

• An Oracle database contains at least one table space.

• A table space contains one or more segments

• A segment is made up of extents.

• An extent is made up of logical blocks.

• A block is the smallest unit for read and writes operation.

The Oracle server enables control of disk space use through tablespace and logical storage

structures, including segments, extents, and data blocks. These are discussed below:

a. Tablespace

b. Data Files (Not a logical structure)

c. Segments

P a g e | 17


d. Extents

e. Data Blocks

3. Tools and Platform to be used: We are planning to build a mobile, desktop and web based application to access our OLTP (Online Transaction Processing System) system that is build with ORACLE database. For mobile based application development we need j2ME and java technology along with Socket programming. To develop desktop application, we are trying to use C#. For web based application we need both ASP.net and C#. GPRS and EDGE can be helpful to access internet by mobile via WAP. For now we can know a bit about the above technologies.

j2ME (java 2 Micro Edition): This is for developing software for mobile devices, e, g. handheld devices, PDA, cellular phones etc.

C# and ASP.net: Both can support dot net framework. C# is very useful programming language for any kind of software development. On the other hand ASP.net is becoming more and more popular to develop web applications along with C#.

Socket Programming: An Internet socket (or commonly, a socket or network socket), is an end-point of a bidirectional communication link that is mapped to a computer process communicating on an Internet Protocol-based network, such as the Internet. A socket is an interface between an application process or thread (child process) and the TCP/IP protocol stack provided by the operational system.

P a g e | 18


Chapter Three System Architecture 1. Generalized view of the system:

Above architecture defines the two aspect of our project where Distributed database is accessed via different hardware by different protocols. We are showing that any distributed database is accessed from different terminals. For example desktop, laptop, PDA, mobile phones etc. We want to use either HTTP/GPRS/EDGE/Bluetooth technology while using mobile devices to access databases. The following architectures define the detailed view of the above figure.

P a g e | 19


1.1 Accessing databases from different terminals using TCP/IP:

Fig: Accessing Databases from Different Terminals

OMS

Communication Network

Authenticated DBA

Client

SecurityExternal Entity

Organizational Person

Server 1

Server 2

Server n

P a g e | 20


1.2 Accessing databases from mobile devices using http/socket connections:

Fig: accessing database from mobile devices through GPRS/EDGE

P a g e | 21


1.3 Accessing databases from mobile devices using Bluetooth technology:

Mobile Console

Java Program

Bluetooth Terminal

Mobile Device

Third Party SoftwareGuest User

Gue

st U

ser A

cces

s

Server 1

Aut

hent

icat

ed U

sers

Server n

A

uthenticated Users

Oracle Management Server (OMS)


Security

External Entity

Security


Bluetooth Central Tower

Fig : Accessing Databases from mobile devices through Bluetooth

Guest User Access

P a g e | 22


Chapter Four

Experimental Performance Tuning Work

1. PERFORMANCE TUNING OF DML OPERATION Online transaction processing (OLTP) and decision support system, including online analytical

processing (OLAP) are two broad classes of applications handled by database systems. These

two classes of tasks have different requirements.

The characteristics of OLTP systems are:

• High-throughput, insert- and update- intensive

• Large, continuously growing data volume

• Concurrent access by many user

Typical OLTP systems are airline reservation systems, Large order-entry applications and

Banking applications.

The characteristics of OLAP systems are:

• OLAP system is targeted to deliver most responses to users within about five seconds,

with the simplest analyses taking no more than one second and very few taking more than

20 seconds.

• The system can cope with any business logic and statistical analysis that is relevant for

the application and the user.

• The system must provide a multidimensional conceptual view of the data, including full

support for hierarchies and multiple hierarchies.

P a g e | 23


Insertion is an important DML operation for OLTP systems. When a large volume of data is

inserted into the database, it should be ensured that the data is not lost due to any kind of failure.

So, it is an important point to commit data at a regular interval.

Committing a transaction means making permanent the changes performed by the SQL

statements within the transaction.

Before a transaction that modifies data is committed, the following has occurred [3]:

• Oracle has generated undo information. The undo information contains the old data

values changed by the SQL statements of the transaction.

• Oracle has generated redo log entries in the redo log buffer of the SGA. The redo log

record contains the change to the data block and the change to the rollback block. These

changes may go to disk before a transaction is committed.

• The changes have been made to the database buffers of the SGA. These changes may go

to disk before a transaction is committed.

When a transaction is committed, the following occurs [3]:

1. The internal transaction tables for the associated undo tablespace that the transaction has

committed, and the corresponding unique system change number (SCN) of the

transaction is assigned and recorded in the table.

2. The log writer process (LGWR) writes redo log entries in the SGA's redo log buffers to

the redo log file. It also writes the transaction's SCN to the redo log file. This atomic

event constitutes the commit of the transaction.

3. Oracle releases locks held on rows and tables.

4. Oracle marks the transaction complete.

As a result when insertion for millions of data takes place in the database, commit after every

single record would make the process slow. We intended to test the nature of the insertion at

various commit points. For this, we designed a table and inserted millions of data into it. We

P a g e | 24


choose some test commit points and monitor the performance of the insertion operation to locate

an optimum point.

1.1 Designing objects and procedures to simulate the performance tuning

The table is created in the tablespace PROJECT_DATA., under the schema PROJECT_USER.

So, prior to the creation of the table, we have to create a user named PROJECT_USER and a

tablespace named PROJECT_DATA.

Creating the user: CREATE USER "PROJECT_USER" IDENTIFIED BY "PROJECT" DEFAULT TABLESPACE PROJECT_DATA CREATE TEMPORARY TABLESPACE TEMP QUOTA 100M ON PROJECT_DATA QUOTA 50M ON TEMP; GRANT "CONNECT" TO "PROJECT_USER"; GRANT "DBA" TO "PROJECT_USER"; GRANT CREATE SESSION TO "PROJECT_USER"; ALTER USER "PROJECT_USER" DEFAULT ROLE NONE; Creating the tablespace: CREATE TABLESPACE PROJECT_DATA DATAFILE 'G:\PROJECT_DATA\DATA_FILE1.DBF' SIZE 1024 M REUSE AUTOEXTEND ON NEXT 4 M MAXSIZE UNLIMITED LOGGING DEFAULT NOCOMPRESS ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE FLASHBACK OFF /

P a g e | 25


Creating the test table: CREATE TABLE PROJECT_USER.IDENTIFICATION_DETAILS ( NATIONAL_ID NUMBER NOT NULL, DISTRICT_ID NUMBER NOT NULL, THANA_ID NUMBER NOT NULL, NAME VARCHAR2(30) NOT NULL, GENDER CHAR(1), DATE_OF_BIRTH DATE, BLOOD_GROUP CHAR(3), CONSTRAINT PK_IDENTIFICATION_DETAILS PRIMARY KEY (NATIONAL_ID ) ) TABLESPACE PROJECT_DATA Creating the procedure: We plan to insert millions of records into the table. So, we write a PL/SQL procedure to do that

insert. The PL/SQL procedure namely, testproject_insert is as given in APPENDIX – A.

This procedure uses a random function inside a package [4] which is also given in APPENDIX –

A.

Creating the sequence:

The primary key of the table is national_id which is implemented through sequence. It ensures

distinct value for each person without limit. The sequence is given in APPENDIX – A.

1.2 Result of the Observation Commit after every records, inserting 100,000 records: Hour Minute Second Fractional 2

Decimal place Of second

Time converted in Seconds

Required time in milliseconds

0 1 57 51 117.51 117084

0 1 57 42 117.42 0 1 56 85 116.85 0 1 56 57 116.57 0 1 57 7 117.07 Average = 117.084

Table-1.1: Averaging required time for 100,000 data insertion after every record.

P a g e | 26


Commit after every 1000 records, inserting 100,000 records: Hour Minute Second Fractional 2




0 1 43 10 103.1 104030

0 1 43 08 103.8 0 1 44 09 104.9 0 1 44 06 104.6 0 1 42 82 102.82 0 1 44 96 104.96 Average = 104.03

Table-1.2: Averaging required time for 100,000 data insertion after every 1000 records. Commit after every 10,000 records, inserting 100,000 records: Hour Minute Second Fractional 2




0 1 40 18 100.18 101227

0 1 40 85 100.85 0 1 40 76 100.76 0 1 42 31 102.31 0 1 42 04 102.04 Average = 101.227

Table-1.3: Averaging required time for 100,000 data insertion after every 10,000 records.

Commit after every 20,000 records, inserting 100,000 records: Hour Minute Second Fractional 2


Time convertedin Seconds


0 1 40 32 100.32 99805

0 1 39 20 99.20 0 1 40 67 100.67 0 1 39 03 99.03 Average = 99.805

Table-1.4: Averaging required time for 100,000 data insertion after every 20,000 records.

P a g e | 27


The net result can be shown as follows: Commit after records Time in milliseconds 1 1170841000 10403010000 101227 20000 99805

Table-1.5: Required time for inserting 100,000 records in the table. In a similar fashion, an observation was done in case of inserting 10 million data which is given

below: commit after 1 record

--------------------------------------

23:12:02 SQL> exec testproject_insert;

PL/SQL procedure successfully completed.

Elapsed: 02:50:49.59

02:03:55 SQL>

commit after 1000 records

---------------------------------------



Elapsed: 02:24:09.50

commit after 100000 records

---------------------------------------



Elapsed: 02:19:26.21

22:54:38 SQL>

Commit after records Time in HH:MI:SS 1 02:50:49.59 1000 02:24:09.50 100000 02:19:26.21

Table-1.6: Required time for Inserting 10,000,000 records in the table

P a g e | 28


1.3 Graphical representation of the calculations

Inserting 100000 records - Different commit point vs. time requirement

117084

104030101227

99805

90000

95000

100000

105000

110000

115000

120000

commit after

commit points

requ

ired

time(

mill

isec

onds

)

every 1 recordevery 1000 recordevery 10000 recordevery 20000 record

Figure-1.1: Graphical representation of 100000 records insertion

Inserting 10 million records - Different commit point vs. time requirement

171

144 139

0

20

40

60

80

100

120

140

160

180

commit after

commit point

requ

ired

time

(min

utes

)

every 1 recordevery 10000 recordevery 100000 record

Figure-1.2: Graphical representation of 10 million records insertion

P a g e | 29


1.4 Conclusion

From the above observation, it is seen that if every record is committed just after insertion, it will

take a long time compared to other commit points to complete the task of bulk insertion. The

required time does not vary much if records are committed after 1000 record interval or 10000

record intervals. So, we choose to commit after every 1000 records when inserting millions of

data. It may be argued that as the time required to insert 10 million records committing after

every 100000 records is quite close to the required time to insert after committing every 1000

records, and then the commit point of 100000 records can also be chosen. But the trade-off is

that committing after a larger number of records leaves a chance that in case of database failure,

a larger number of records would be lost. Hence the consistency of the database is not ensued.

Choosing every 1000 records as the commit point would make the operation faster as well as

least possible to lost in case of system failure We therefore conclude that committing after 1000

records is the optimum choice of commit point if we consider large volume of data insertion in

the range of millions of data.

2. PERFORMANCE TUNING OF INDEX

Oracle includes numerous data structures to improve the speed of Oracle SQL queries. Taking

advantage of the low cost of disk storage, Oracle includes many new indexing algorithms that

dramatically increase the speed with which Oracle queries are serviced. Oracle uses indexes to

avoid the need for large-table, full-table scans and disk sorts, which are required when the SQL

optimizer cannot find an efficient way to service the SQL query [5].

2.1 B-tree index

The oldest and most popular type of Oracle indexing is a standard B-tree index, which

Excels at servicing simple queries. The B-tree index was introduced in the earliest releases of

Oracle and remains widely used with Oracle. The implementation of well-known B+ tree index

in Oracle is known as B-tree index. B-tree indexes are used to avoid large sorting operations. For

example, a SQL query requiring 10,000 rows to be presented in sorted order will often use a B-

tree index to avoid the very large sort required to deliver the data to the end user.

P a g e | 30


Figure 2.1(a): An Oracle B-tree index

Oracle offers several options when creating an index using the default B-tree structure. It allows

one to index on multiple columns (concatenated indexes) to improve access speeds. Also, it

allows for individual columns to be sorted in different orders. The structure of an Oracle B-tree

index [2] is shown in the Figure-2.1(b)

Figure 2.1(b): Structure of Oracle B-tree index

P a g e | 31


Example 2.1

We can create a B-tree index on a column called last_name in ascending order and have a second

column within the index that displays the salary column in descending order.

create index name_salary_idx

on person( last_name asc, salary desc);

2.2 Bitmap index

A bitmap index on an indexed attribute consists of one vector of bits(i.e. bitmap) per attribute

value, where the size of each bitmap is equal to the cardinality of the indexed relation. The

bitmaps are encoded such that the i-th record has a value of v in the indexed attribute if and only

if the i-th bit in the bitmap associated with the attribute value v is set to 1, and the i-th bit in each

of the other bitmaps is set to 0. This is called a Value-List index [6]. An example of a Value-List

index for a 12-ecord relation R is shown in Figure-4.2, where each column in Figure-2.2(b)

represents a bitmap Bv associated with an attribute value v.

Figure 2.2: Example of a value-List Index. (a) Projection of indexed attribute values with duplicates preserved. (b) Value-List Index

(a) (b)

P a g e | 32


The Value-List index is a set of bitmaps, one per attribute value. In other words, if one views this

set as a two-dimensional bit matrix (Figure-2.2(b)), the focus is on the columns. If the focus

moves on the rows, however, then the index can be seen as the list of attribute values represented

some particular way. As there is a large number of possible representations for attribute values

(integer in this case), this clearly opens up the way for defining a whole host of bitmap indexing

schemes. In classifying all these representations, two major orthogonal parameters are identified

that define the overall space of alternatives. In particular, considering the value list index again,

we observe that each attribute value is represented as a single digit (in base-C arithmetic), this

digit being encoded in bits by turning exactly one out of C bits on. The arithmetic chosen for the

value representation, i.e., the decomposition of the value in digits according to some base, and

the encoding scheme of each digit in bits are the two dimensions of the space and are presented

below [6].

(1) Attribute Value Decomposition: Consider an attribute value v and a sequence of (n-1)

numbers < bn-1, bn-2 … b1 >. Furthermore, define bn = [C / (∏n-1i=1 bi)]. Then v can be

decomposed into a sequence of n digits < vn, vn-1 … v1> as follows:

v = V1

= V2b1 + v1

= V3 (b2b1) + v2b1 + v1

= V4 (b3b2b1) + v3 (b2b1) + v2b1 + v1

= ………

= vn (∏j=1 n-1 bj

) + . . . + vi (∏j=1 i-1 bj) + …. + v2b1+ v1

Where vi = Vi mod bi, Vi = [Vi-1 / bi-1], 1 gives a different

representation of attribute values, and therefore a different index. An index is well-defined if bi ≥

2, 1≤ i ≤ n. The sequence < bn, bn-1,….,b1> is the base of the index, which is in turn called a base

< bn, bn-1,….,b1> index. If bn = bn-1 = …. = b1 ≡ b, then the base is called uniform and the index is

called base-b for short.

P a g e | 33


(a) (b)

Figure 2.3: Example of a 2-Component Value-List Index (a) Projection of indexed attribute values with duplicates preserved. (b) Base-<3, 3> Value-List Index.

P a g e | 34


Figure 2.4: Example of a 2-Component Value-List Index -Base<3-3> Value-List Index rearranged.

The index consists of n components, i.e., one component per digit. Each component individually

is now a collection of bitmaps, constituting essentially a base-bj index.

Let ni denote the number of bitmaps in the ith component of an index and {Bini-1

, Bini-2… B1

0}

denote the collection of ni bitmaps that form the ith component. Figure-2.4 shows a base<3, 3>

Value-List index (based on the same 12 record relation on figure-2.2). By decomposing a single-

component index into a 2-component index, the number of bitmaps has been reduced from 9 to

6.

(2) Bitmap Encoding Scheme: Consider the ith component of an index with attribute

cardinality bi. There are essentially two major schemes to directly encode the corresponding

values vi ≤ (bi -1) in bits [6]:

● Equality Encoding: There are bi bits, one for each possible value. The representation of

value vi has all bits set to 0, except for the bit corresponding to vi, which is set to 1. Clearly, an

equality-encoded component consists of bi bitmaps

● Range Encoding: There are bi bits again, one for each possible value. The representation

of value vi has the vi rightmost bits set to 0 and the remaining bits

P a g e | 35


(Starting from the one corresponding to vi and to the left) set to 1. Intuitively, each bitmap Bivi

has

ПA(R) B2

1 B20 B1

1 B10

3 1 0 1 1 2 1 1 0 0 1 1 1 1 0 2 1 1 0 0 8 0 0 0 0 2 1 1 0 0 2 1 1 0 0 0 1 1 1 1 7 0 0 1 0 5 1 0 0 0 6 0 0 1 1 4 1 0 1 0

(c)

Figure 2.5: Examples of a Range-Encoded Bitmap Indexes, (a) Projection of indexed attribute values with duplicates preserved. (b) Single Component, Base-9 Range-Encoded Bitmap Index, (c) Base <3, 3> Range-Encoded Bitmap Index

1 in all the records whose ith component value is less than or equal to vi. . Since the bitmap Bibi-1

has all bits set to 1, it does not need to be stored, so a range encoded component consists of (bi-1)

ПA(R) B7 B6 B5 B4 B3 B2 B1 B0

P a g e | 36


bitmaps. Figure 2.5 (b) and (c) show the range-encoded indexes corresponding to the equality-

encoded indexes in Figure-2.2 and Figure-2.3, respectively. Using these compression techniques,

Bitmap indexes require less storage space than the B-tree indexes in case of low cardinality

columns.

2.3 Comparison of Bitmap and B-tree index

The main comparison between bitmap and B-tree index is done based on the cardinality of a

particular column on which the index is built. Cardinality of the column of a table is divided into

two classes as follows:

• Low-cardinality: If the column values have a few distinct values, the column is said to

have low cardinality.

• High-cardinality: If the column values have a large number of distinct values, it is a

high-cardinality column.

2.3.1 Performance Considerations

Bitmap indexes can substantially improve performance of queries [7] with the following

characteristics:

• The WHERE clause contains multiple predicates on low- or medium-cardinality

columns.

• The individual predicates on these low- or medium-cardinality columns select a large

number of rows.

• Bitmap indexes have been created on some or all of these low- or medium-cardinality

columns.

• The tables being queried contain many rows.

Multiple bitmap indexes can be created to evaluate the conditions on a single table. Bitmap

indexes are thus highly advantageous for complex ad hoc queries that contain lengthy WHERE

clauses. Bitmap indexes can also provide optimal performance for aggregate queries and for

optimizing joins in star schemas.

P a g e | 37


2.3.2 Storage Considerations

Bitmap indexes can provide considerable storage savings over the use of B-tree indexes. In

databases containing only B-tree indexes, one must anticipate the columns that would commonly

be accessed together in a single query, and create a composite B-tree index on these columns.

Not only would this B-tree index require a large amount of space, it would also be ordered. That

is, a B-tree index on (marital_status, region, gender) is useless for queries that only access

region and gender. To completely index the database, one must create indexes on the other

permutations of these columns. For the simple case of three low-cardinality columns, there are

six possible composite B-tree indexes. One must consider the trade-offs between disk space and

performance needs when determining which composite B-tree indexes to create.

Bitmap indexes solve this dilemma. Bitmap indexes can be efficiently combined during query

execution, so three small single-column bitmap indexes can do the job of six three-column B-tree

indexes. Bitmap indexes are much more efficient than B-tree indexes, especially in data

warehousing environments. Bitmap indexes are created not only for efficient space usage, but

also for efficient execution, and the latter is somewhat more important.

Bitmap indexes should not be created on unique key columns. However, For columns where

each value is repeated hundreds or thousands of times, a bitmap index typically is less than 25%

of the size of a regular B-tree index [7]. The bitmaps themselves are stored in compressed

format.

Simply comparing the relative sizes of B-tree and bitmap indexes is not an accurate measure of

effectiveness, however. Because of their different performance characteristics, B-tree indexes

should be kept on high-cardinality columns, while creating bitmap indexes on low-cardinality

columns.

2.3.3 Maintenance Considerations

Bitmap indexes benefit data warehousing applications, but they are not appropriate for OLTP

applications with a heavy load of concurrent INSERTs, UPDATEs, and DELETEs. In a data

P a g e | 38


warehousing environment, data is usually maintained by way of bulk inserts and updates. Index

maintenance is deferred until the end of each DML operation. For example, if 1000 rows are

inserted, then the inserted rows are placed into a sort buffer, and then the updates of all 1000

index entries are batched. This is why SORT_AREA_SIZE must be set properly for good

performance with inserts and updates on bitmap indexes [7]. Thus, each bitmap segment is

updated only once per DML operation, even if more than one row in that segment changes.

DML and DDL statements, such as UPDATE, DELETE, DROP TABLE, affect bitmap indexes

the same way they do traditional indexes: the consistency model is the same. A compressed

bitmap for a key value is made up of one or more bitmap segments, each of which is at most half

a block in size, but may be smaller. The locking granularity is one such bitmap segment. This

may affect performance in environments where many transactions make simultaneous updates. If

numerous DML operations have caused increased index size and decreasing performance for

queries, then one can use the ALTER INDEX ... REBUILD statement to compact the index and

restore efficient performance [8].

A B-tree index entry contains a single row-id. Therefore, when the index entry is locked, a single

row is locked. With bitmap indexes, an entry can potentially contain a range of rowids. When a

bitmap index entry is locked, the entire range of rowids is locked. The number of rowids in this

range affects concurrency. As the number of rowids increases in a bitmap segment, concurrency

decreases [9].

Locking issues affect DML operations, and may affect heavy OLTP environments. Locking

issues do not affect query performance. As with other types of indexes, updating bitmap indexes

is a costly operation. Nonetheless, for bulk inserts and updates where many rows are inserted or

many updates are made in a single statement, performance with bitmap indexes can be better

than with regular B-tree indexes [7].

2.3.4 Experimental result We try to compare the result of searching time of B-tree and bitmap index in case of high and

low cardinality columns.

P a g e | 39


• Test on low-cardinality columns

The column blood_group in the table identification_details is chosen for this test. As the

blood_group column can have one of the three values A+,B+ and AB+, its cardinality is thee;

hence it is a low-cardinality column.

Creating B-tree index on the blood_group column: CREATE INDEX PROJECT_USER.INDX_BLD_GRP_IDEN_DET ON PROJECT_USER.IDENTIFICATION_DETAILS(BLOOD_GROUP) TABLESPACE PROJECT_INDX Calculating size of the B-tree index: Using [10] the size of index is calculated. 09:07:12 SQL> select substr(segment_name,1,30) segment_name, bytes/1024/1024 "Si ze in MB" 09:08:00 2 from user_segments 09:08:06 3 where segment_name in (‘IDENTIFICATION_DETAILS’, 'INDX_BLD_GRP_IDEN_DET’); SEGMENT_NAME Size in MB ------------------------------ ---------- IDENTIFICATION_DETAILS 1344 INDX_BLD_GRP_IDEN_DET 528 We see that the table is 1344 MB i.e. 1.344 GB and the B-tree index size is 528 MB. Searching using B-tree index: We then search the database to find out the number of persons having blood_group AB+.

We take five sample values for this and take the average of them. The query is select count(*) from identification_details where blood_group = ‘AB+’; The result is given in the table 2.1.

Sample Required time (sec) Average time (sec) 1 11.68

11.88

2 12.12 3 12.07 4 11.28 5 12.26

Table-2.1: Result of searching 10 million data using B-tree index from a total of 30 million records where cardinality is 3.

P a g e | 40


Then we drop the B-tree index and create bitmap index on the low-cardinality column

blood_group.

Creating bitmap index on the blood_group column: CREATE BITMAP INDEX PROJECT_USER.INDX_BLD_GRP_IDEN_DET ON PROJECT_USER.IDENTIFICATION_DETAILS(BLOOD_GROUP) TABLESPACE PROJECT_INDX Calculating the size of bitmap index: 09:07:12 SQL> select substr(segment_name,1,30) segment_name, bytes/1024/1024 "Si ze in MB" 09:08:00 2 from user_segments 09:08:06 3 where segment_name in (‘IDENTIFICATION_DETAILS’, 'INDX_BLD_GRP_IDEN_DET’); SEGMENT_NAME Size in MB ------------------------------ ---------- IDENTIFICATION_DETAILS 1344 INDX_BLD_GRP_IDEN_DET 16 Here, the bitmap index size is 16 MB. Searching using bitmap index: We then search the database to find out the number of persons having blood_group AB+.

We take five sample values for this and take the average of them. The query is

select count(*) from identification_details where blood_group = ‘AB+’; The result is given in the table 2.2 Sample Required time (sec) Average time (sec) 1 0.20

0.06

2 0.03 3 0.03 4 0.03 5 0.01

Table-2.2: Result of searching 10 million data using Bitmap index from a total of 30 million records where cardinality is 3. • Test on high-cardinality columns

P a g e | 41


The column national_id is has unique values. So, it is a high-cardinality column. Creating B-tree index on the national_id column: CREATE INDEX PROJECT_USER.ID_BTREE_INDX ON PROJECT_USER.IDENTIFICATION_DETAILS(NATIONAL_ID) TABLESPACE PROJECT_INDX; Calculating size of the B-tree index: 07:29:06 SQL> select substr(segment_name,1,30) segment_name, bytes/1024/1024 "Si ze in MB" 07:29:16 2 from user_segments 07:29:29 3 where segment_name in ('IDENTIFICATION_DETAILS','ID_BTREE_INDX'); SEGMENT_NAME Size in MB ------------------------------ ---------- IDENTIFICATION_DETAILS 1344 ID_BTREE_INDX 592 Elapsed: 00:00:00.18 07:30:28 SQL> We see that the table is 1344 MB i.e. 1.344 GB and the B-tree index size is 592 MB. Searching using B-tree index: We then search the database to find out the total number of national_id.

We take five sample values for this and take the average of them. The query is select count(national_id) from identification_details; The result is given in the table 2.3


13.8

2 14.70 3 14.37 4 13.39 5 13.54

Table-2.3: Result of searching total number of national_id using B-tree index from a total of 30 million records where cardinality is equal to the number of records.

P a g e | 42


Then we drop the B-tree index and create bitmap index on the low-cardinality column

blood_group.

Creating bitmap index on the national_id column: CREATE BITMAP INDEX PROJECT_USER.ID_BITMP_INDX ON PROJECT_USER.IDENTIFICATION_DETAILS(NATIONAL_ID) TABLESPACE PROJECT_INDX Calculating the size of bitmap index: 07:50:01 SQL> select substr(segment_name,1,30) segment_name, bytes/1024/1024 "Size in MB” 07:52:51 2 from user_segments 07:53:03 3 where segment_name in ('IDENTIFICATION_DETAILS','ID_BITMP_INDX'); SEGMENT_NAME Size in MB ------------------------------ ---------- IDENTIFICATION_DETAILS 1344 ID_BITMP_INDX 904 Elapsed: 00:00:00.12 07:53:54 SQL> Here, the bitmap index size is 904 MB. Searching using bitmap index: We then search the database to find out the total number of national_id. We take five sample

values for this and take the average of them. The query is as follows

select count(national_id) from identification_details; The result is given in the table 2.4


30.97

2 31.90 3 31.23 4 30.34 5 30.03

Table-2.4: Result of searching total number of national_id using bitmap index from a total of 30 million records where cardinality is equal to the number of records.

P a g e | 43


2.3.5 Conclusion Low-cardinality columns:

The size of the bitmap index is 16MB whereas the size of the B-tree index was 528MB. So, we

should use bitmap index to reduce the index storage requirement in case of low cardinality

columns.

The average searching time for the bitmap index was 0.06 sec i.e. 60 milliseconds. On the other

hand, for the B-tree index, required average time was 11.88 sec. Hence, using bitmap index for

searching low-cardinality column improves performance over the B-tree index.

High-cardinality columns:

The size of the bitmap index is 904MB whereas the size of the B-tree index was 592MB. So, we

should use B-tree index to reduce the index storage requirement in case of high cardinality

columns.

The average searching time for the bitmap index was 30.97 seconds. On the other hand, for the

B-tree index, required average time was 13.8 seconds. Hence, using B-tree index for searching

high-cardinality column improves performance over the bitmap index.

2.4 Composite index

A composite index contains more than one key column. Composite indexes can provide additional advantages over

single-column indexes. A SQL statement can use an access path involving a composite index if the statement

contains constructs that use a leading portion of the index [7]. A leading portion of an index is a set of one or more

columns that were specified first and consecutively in the list of columns in the CREATE INDEX statement that

created the index. Let us consider this CREATE INDEX statement:

CREATE INDEX comp_ind

ON tab1(x, y, z);

These combinations of columns are leading portions of the index: x, xy, and xyz. These combinations of columns

are not leading portions of the index: yz, y, and z.

P a g e | 44


Now we do some test to observe the performance of composite index. 2.4.1 Experimental results First we create individual index on each of the three columns- district_id, thana_id and

blood_group and observe the required time needed to search using a query which involves these

three columns in the WHERE clause. Then we create composite index on all three columns and

observe the performance.

The following query is used for the testing purpose: select count(*) from identification_details where district_id=1 and thana_id=29 and blood_group='AB+';

• Testing using individual index on the columns: a) We create B-tree index on district_id column and perform the search 22:44:07 SQL> select count(*) from identification_details 22:44:38 2 where district_id=1 and thana_id=29 and blood_group='AB+'; COUNT (*) ---------- 362 Elapsed: 00:00:31.73 b) We create B-tree index on thana_id column and perform the search. Now both

district_id and thana_id have separate B-tree indexes 22:57:18 SQL> select count(*) from identification_details 22:58:58 2 where district_id=1 and thana_id=29 and blood_group='AB+'; COUNT(*) ---------- 362 Elapsed: 00:00:07.09 c) We create B-tree index on blood_group column and perform the search. Now district_id,

thana_id,blood_group each have B-tree index 23:08:28 SQL> select count(*) from identification_details 23:09:21 2 where district_id=1 and thana_id=29 and blood_group='AB+';

P a g e | 45


COUNT(*) ---------- 362 Elapsed: 00:00:08.53 d) We create bitmap index on blood_group column and perform the search. Now

district_id,thana_id each have B-tree index and blood_group have bitmap index.

23:40:06 SQL> select count(*) from identification_details 23:43:13 2 where district_id=1 and thana_id=29 and blood_group = 'AB+'; COUNT(*) ---------- 362 Elapsed: 00:00:00.81

• Testing using composite index: We create a B-tree composite index and a bitmap composite index on the columns district_id,

thana_id and blood_group. The leading portion of the composite index is one of the

combinations- district_id, district_id and thana_id, district_id and thana_id and blood group. The

non-leading portion is one of the combinations-thana_id and blood_group , thana_id ,

blood_group.

We test the performance of the query for the leading and non-leading portions Test for the B-tree composite index: 1. Result for the leading portions: a) district_id: 00:10:38 SQL> select count(*) from identification_details 00:14:28 2 where district_id = 1; COUNT(*) ---------- 497737 Elapsed: 00:00:00.43 b) district_id and thana_id: 00:10:32 SQL> select count(*) from identification_details 00:10:36 2 where district_id = 1 and thana_id=29;

P a g e | 46


COUNT(*) ---------- 1105 Elapsed: 00:00:00.01 c) district_id and thana_id and blood_group: 00:04:12 SQL> select count(*) from identification_details 00:04:21 2 where district_id=1 and thana_id=29 and blood_group = 'AB+'; COUNT(*) ---------- 362 Elapsed: 00:00:00.01

2. Result for the non-leading portions: a) thana_id and blood_group: 00:07:25 SQL> select count(*) from identification_details 00:07:29 2 where thana_id=29 and blood_group = 'AB+'; COUNT(*) ---------- 23678 Elapsed: 00:00:01.42 b) thana_id: 08:57:17 SQL> select count(*) from identification_details 09:06:04 2 where thana_id = 29; COUNT(*) ---------- 70205 Elapsed: 00:00:01.45 c) blood_group: 09:06:15 SQL> select count(*) from identification_details 09:07:12 2 where blood_group = 'AB+'; COUNT(*) ---------- 10619037 Elapsed: 00:00:17.82

P a g e | 47


Test for the bitmap composite index: 1. Result for the leading portions: a) district_id: 09:32:03 SQL> select count(*) from identification_details 09:32:07 2 where district_id = 1; COUNT(*) ---------- 497737 Elapsed: 00:00:00.07 b) district_id and thana_id: 00:10:32 SQL> select count(*) from identification_details 00:10:36 2 where district_id = 1 and thana_id=29; COUNT(*) ---------- 1105 Elapsed: 00:00:00.01 c) district_id and thana_id and blood_group: 00:04:12 SQL> select count(*) from identification_details 00:04:21 2 where district_id=1 and thana_id=29 and blood_group = 'AB+'; COUNT(*) ---------- 362 Elapsed: 00:00:00.01

2. Result for the non-leading portions: a) thana_id and blood_group: 00:07:25 SQL> select count(*) from identification_details 00:07:29 2 where thana_id=29 and blood_group = 'AB+'; COUNT(*) ---------- 23678 Elapsed: 00:00:03.23 b) thana_id:

P a g e | 48


08:57:17 SQL> select count(*) from identification_details 09:06:04 2 where thana_id = 29; COUNT(*) ---------- 70205 Elapsed: 00:00:03.36 c) blood_group: 09:06:15 SQL> select count(*) from identification_details 09:07:12 2 where blood_group = 'AB+'; COUNT (*) ---------- 10619037 Elapsed: 00:00:2.93 The result for searching using individual indexes is given in the Table-2.5

district_id district_id, thana_id

district_id,thana_id,blood_group(B-tree)

district_id,thana_id, blood_group(bitmap)

Required time (seconds)

31.73

7.09

8.53

0.81

Table-2.5: Required time to search using individual indexes for multiple columns The result for searching using B-tree composite index is given in the Table-2.6

Leading portion Non-leading portion

district_id district_id and thana_id

district_id and thana_id and blood_group

thana_id and blood_group

thana_id blood_ group

Required Time (seconds)

0.43

0.01

0.01

1.42

1.45

17.82

Table-2.6: Required time to search using composite B-tree index

P a g e | 49


The result for searching using bitmap composite index is given in the Table-2.7

Leading portion Non-leading portion district_id district_id

and thana_id

district_id and thana_id and blood_group

thana_id and blood_group

thana_id blood_ group

Required Time (seconds)

0.07

0.01

0.01

3.23

3.36

2.93

Table-2.7: Required time to search using composite bitmap index

2.4.2 Conclusion

From our observation, these guidelines should be followed for choosing keys for composite indexes:

• It should be considered to create a composite index on keys that are frequently used

together in WHERE clause conditions combined with AND operators, especially if their

combined selectivity is better than the selectivity of either key individually.

• If several queries select the same set of keys based on one or more key values, then it

should be considered to create a composite index containing all of these keys.

• In the example, district_id and blood_group has relatively low cardinality compared to

thana_id as there are 64 districts and 3 blood_groups whereas there are 460 thanas in our

test table. Using bitmap composite index for these columns make the query faster than

using the B-tree composite index. So, we should use bitmap composite index when

maximum of the columns are of low-cardinality and B-tree composite index when

columns are of high-cardinality.

These guidelines should be followed for ordering keys in composite indexes:

• Index should be created so the keys used in WHERE clauses make up a leading portion.

P a g e | 50


• If some keys are used in WHERE clauses more frequently, then we should be sure to

create the index so that the more frequently selected keys make up a leading portion to

allow the statements that use only these keys to use the index.

• If all keys are used in WHERE clauses equally often, then ordering these keys from most

selective to least selective in the CREATE INDEX statement best improves query

performance.

• If all keys are used in the WHERE clauses equally often but the data is physically ordered

on one of the keys, then that key should be placed first in the composite index.

2.5 Function-based index One of the most important advances in Oracle indexing is the introduction of function-based

indexing. Function-based indexes allow creation of indexes on expressions, internal functions,

and user-written functions in PL/SQL and Java [7]. Function-based indexes ensure that the

Oracle designer is able to use an index for its query. .

Here, Function-based index can be built on the predicates of where clause. Prior to Oracle8i, the

use of a built-in function would not be able to match the performance of an index. Consequently,

Oracle would perform the full-table scan. Examples of SQL with function-based queries might

include:

2.5.1 Experimental result

We consider a query to count the number of persons whose date of birth are greater than or equal

to 1970. A function based index is created on the expression of the where clause to determine the

performance.

Before applying function based index 20:24:46 SQL> SELECT COUNT(1) 20:38:29 2 from identification_details 20:38:31 3 WHERE TO_CHAR(DATE_OF_BIRTH,'YYYY') > ='1970';

Example:

Select * from customer where substr(cust_name,1,4) = ‘BURL’;

Select * from customer where to_char(order_date,’MM’) = ’01;

Select * from customer where upper(cust_name) = ‘JONES’;

Select * from customer where initcap(first_name) = ‘Mike’;

P a g e | 51


COUNT(1) ---------- 300142 Elapsed: 00:00:13.71 Creating function based index 20:39:45 SQL> CREATE INDEX PROJECT_USER.INDX_DOB_IDEN_TAB 20:41:04 2 ON PROJECT_USER.IDENTIFICATION_DETAILS (DATE_OF_BIRTH, TO_CHAR (DATE_OF_BIRTH,'YYYY')); Index created. Elapsed: 00:01:22.51 20:42:51 SQL> SELECT COUNT(1) 20:43:12 2 from identification_details 20:43:12 3 WHERE TO_CHAR(DATE_OF_BIRTH,'YYYY') > ='1970'; COUNT (1) ---------- 300142 Elapsed: 00:00:06.73 The result of applying function based index is as follows:

With B-tree index With function-based index

Time required 13.71 sec 6.73 sec Table-2.8: Required time for query with and without function based index . 2.5.1 Conclusion Oracle always interrogates the where clause of the SQL statement to see if a matching index

exists. By using function-based indexes, the Oracle designer can create a matching index that

exactly matches the predicates within the SQL where clause. This ensures that the query is

retrieved with a minimal amount of disk I/O and the fastest possible speed.

2.6Performance improvement issues of index Oracle indexes can greatly improve query performance but there are some important indexing

issues to be considered.

P a g e | 52


1. Indexes and blocksize

Indexes that experience lots of index range scans of index fast full scans (as evidence by

multiblock reads) will greatly benefit from residing in a 32k block size. Today, most Oracle

tuning experts utilize the multiple block size feature of Oracle because it provides buffer

segregation and the ability to place objects with the most appropriate block size to reduce buffer

waste. Some of the world record Oracle benchmarks use very large data buffers and multiple

block sizes. According to [11], larger block sizes can help in certain situations: A bigger block

size means more space for key storage in the branch nodes of B-tree indexes, which reduces

index height and improves the performance of indexed queries. In any case, there appears to be

evidence that block size affects the tree structure, which supports the argument that data blocks

affect the structure of the tree.

2. Indexes and clustering

The CBO's decision to perform a full-table vs. an index range scan is influenced by the

clustering_factor (located inside the dba_indexes view), db_block_size, and avg_row_len [11]. It

is important to understand how the CBO uses these statistics to determine the fastest way to

deliver the desired rows. Conversely, a high clustering_factor, where the value approaches the

number of rows in the table (num_rows), indicates that the rows are not in the same sequence as

the index, and additional I/O will be required for index range scans. As the clustering_factor

approaches the number of rows in the table, the rows are out of synchronization with the index.

If Index Range scans are involved, more blocks than necessary could be being visited if the

index is unselective: by forcing or enabling the use of a more selective index, we can access the

same table data by visiting fewer index blocks (and doing fewer physical I/Os). If the index

being used has a large clustering_factor, then more table data blocks have to be visited in order

to get the rows in each Index block: by rebuilding the table with its rows sorted by the particular

index columns we can reduce the clustering_factor and hence the number of table data blocks

that we have to visit for each index block.

2.6.1Conclusion

In this chapter we studied the performance of various types of indexes.

P a g e | 53


• We compared between bitmap and B-tree indexes and reached a decision that for low-

cardinality columns, using bitmap index is the best option and for the high cardinality

columns, B-tree indexes show optimum performance.

• We also conclude that using bitmap index for low cardinality columns requires lower

storage than B-tree index.

• Our observation shows that using composite index efficiently will ensure better

performance for searching multiple predicates in where clause.

• Ordering of composite indexes should be maintained such that leading portions are used

for searching operation. If non-leading portion of the composite index are used for

searching specific items, then it will not be optimum.

• Function-based index is very useful for Oracle designer so that he can create a matching

index that exactly matches the predicates within the SQL where clause. This ensures that

the query is retrieved with a minimal amount of disk I/O and the fastest possible speed

P a g e | 54


3. PERFORMANCE IMPROVEMENT ON CLUSTER I/O is often the single greatest component of response time. Disk I/O is expensive because when

Oracle retrieves a block from a data file on disk, the reading process must wait for the physical

I/O operation to complete. Disk operations are about 10,000 times slower than a row's access in

the data buffers [12]. Consequently, anything one can do to minimize I/O or reduce bottlenecks

caused by contention for files on disk-greatly improves the performance of any Oracle database.

.

Figure-3.1: Un-Clustered table rows

Figure-3.2: Clustered table rows

P a g e | 55


If we group like rows together we can get all of the rows with a single block read because the rows are together

A cluster provides an optional method of storing table data. A cluster is made up of a group of

tables that share the same data blocks [9]. The tables are grouped together because they share

common columns and are often used together. For example, if the emp and dept table share the

deptno column, when we cluster the emp and dept tables as in Figure-3.3, Oracle physically stores

all rows for each department from both the emp and dept tables in the same data blocks.

Figure-3.3(a): Example of table clustering

P a g e | 56


3.1 Oracle Index Cluster Tables

An index cluster uses an index to maintain row sequence. A table cluster is a group of tables that

share the same data blocks, since they share common columns and are often used together. When

one creates cluster tables, Oracle physically stores all rows for each table in the same data

blocks. The cluster key value is the value of the cluster key columns for a particular row. In a

multi-table index cluster, related table rows are grouped together to reduce disk I/O.

For example, we assume that databases have a customer and orders table

and 95% of the access is to select all orders for a particular customer.

Oracle will have to perform an I/O to fetch the customer row and then

multiple I/O’s to fetch each order for the customer.

Figure-3.3(b): Multiple-table cluster table

We consider this SQL where we fetch all orders for a customer:

Select customer_name,order_date

from customer natural join orders

where cust_key = ‘IBM’;

If this customer has eight orders, each on a different data block, we must perform nine block

fetches to return the query rows. Even if these blocks are already cached in the data buffers, we

still have at least nine consistent gets:

P a g e | 57


If we re-define the table as a index cluster table, Oracle will physically store the orders rows on

the same data block as the parent customer row, thereby reducing I/O by a factor of eight:

Index clusters will only result in a reduction of I/O when the vast majority of data access is via

the cluster index. Any row access via another index will still result in randomized block fetches.

3.2 Script for creating index cluster tables Here a script for creating a cluster is given as an example. We select district_id from our test

database table identification_details as the clustering column and create a cluster for districts

having id 20 and 30.

Figure-3.4: Data-blocks without clustering

Figure-3.5: Data-blocks when clustered

P a g e | 58


CREATE CLUSTER district (district_id NUMBER) SIZE 512 STORAGE (initial 100K next 50K); CREATE INDEX idx_district ON CLUSTER district; CREATE TABLE dist_20 CLUSTER district (district_id) AS SELECT * FROM identification_details WHERE district_id = 20; CREATE TABLE dist_30 CLUSTER district (district_id) AS SELECT * FROM identification_details WHERE district_id = 30; 3.3 Conclusion We discuss about the advantages and disadvantages of clusters bellow:

Advantages:

Clusters store related rows of different tables together in the same data blocks. We get two

primary benefits from this:

• Disk I/O is reduced and access time improves for joins of clustered tables.

• In a cluster, a cluster key value (that is, the related value) is only stored once, no matter

how many rows of different tables contain the value. Therefore, less storage may be

required to store related table data in a cluster than is necessary in non-clustered table

format.

To identify data that would be better stored in clustered form, we should look for tables that are

related through referential integrity constraints and tables that are frequently accessed together

using a join. If we cluster tables on the columns used to join table data, we reduce the number of

data blocks that must be accessed to process the query; all the rows needed for a join on a cluster

key are in the same block.

P a g e | 59


Disadvantages:

• If the all the rows for a cluster key cannot fit in a single block, they may cause join

statements to consume more resources.

• Clusters can reduce the performance of DML statements (INSERTs, UPDATEs, and

DELETEs) as compared to storing a table separately with its own index. These

disadvantages relate to the use of space and the number of blocks that must be visited to

scan a table. Because multiple tables share each block, more blocks must be used to store

a clustered table than if that same table were stored non-clustered. We decide about using

clusters with these trade-offs in mind.

Clusters should be used depending on the need. Clusters do not always ensure performance

improvements if it is not used properly. We should be concerned about the advantages and

disadvantages of cluster to get the optimum benefit.

4. PERFORMANCE OF PARTITIONED TABLE

Partitioning addresses key issues in supporting very large tables and indexes by letting us

decompose them into smaller and more manageable pieces called partitions [9]. SQL queries and

DML statements do not need to be modified in order to access partitioned tables. However, after

partitions are defined, DDL statements can access and manipulate individual partitions rather

than entire tables or indexes. This is how partitioning can simplify the manageability of large

database objects. Also, partitioning is entirely transparent to applications. Each partition of a

table or index must have the same logical attributes, such as column names, data types, and

constraints, but each partition can have separate physical attributes such as pctfree, pctused, and

tablespaces [9].

Partitioning is useful for many different types of applications, particularly applications that

manage large volumes of data. OLTP systems often benefit from improvements in manageability

and availability, while data warehousing systems benefit from performance and

manageability.All partitions of a partitioned object must reside in tablespaces of a single block

size.

P a g e | 60


4.1 Advantages of partitioning

• Partitioning enables data management operations such data loads, index creation and

rebuilding, and backup/recovery at the partition level, rather than on the entire table. This

results in significantly reduced times for these operations.

• Partitioning improves query performance. In many cases, the results of a query can be

achieved by accessing a subset of partitions, rather than the entire table. For some

queries, this technique (called partition pruning) can provide order-of-magnitude gains in

performance.

• Partitioning can significantly reduce the impact of scheduled downtime for maintenance

operations.

• Partition independence for partition maintenance operations lets the user perform

concurrent maintenance operations on different partitions of the same table or index. We

can also run concurrent SELECT and DML operations against partitions that are

unaffected by maintenance operations.

• Partitioning increases the availability of mission-critical databases if critical tables and

indexes are divided into partitions to reduce the maintenance windows, recovery times,

and impact of failures.

• Partitioning can be implemented without requiring any modifications to an application.

For example, we could convert a nonpartitioned table to a partitioned table without

needing to modify any of the SELECT statements or DML statements which access that

table. We do not need to rewrite our application code to take advantage of partitioning.

4.2 Partition Key

Each row in a partitioned table is unambiguously assigned to a single partition. The partition key is a set of one or

more columns that determines the partition for each row. Oracle automatically directs insert, update, and delete

operations to the appropriate partition through the use of the partition key. A partition key should maintain the

following characteristics [9]:

• Consists of an ordered list of 1 to 16 columns.

P a g e | 61


• Cannot contain a LEVEL or ROWID pseudocolumn.

• Can contain columns that are NULLable.

Tables can be partitioned into up to 64,000 separate partitions. Any table can be partitioned

except those tables containing columns with LONG or LONG RAW data types. We can,

however, use tables containing columns with CLOB or BLOB data types.

4.3 Partitioning Methods

Oracle provides the following partitioning methods [9]:

• Range Partitioning: Range partitioning uses ranges of column values to map rows to

partitions. Partitions by range are well suited for historical databases. However, it is not

always possible to know beforehand how much data will map to a given range and in

some cases sizes of partitions may differ quite substantially, resulting in sub-optimal

performance for certain operations like parallel DML.

• Hash Partitioning: This method uses a hash function on the partitioning columns to

stripe data into partitions. It controls the physical placement of data across a fixed

number of partitions and gives a highly tunable method of data placement.

• List Partitioning: The list partitioning allows explicit control over how rows map to

partitions. This is done by specifying a list of discrete values for the partitioning column

in the description for each partition.

• Composite Partitioning: Composite partitioning is a combination of other partitioning

methods. Oracle currently supports range-hash and range-list composite partitioning.

P a g e | 62


Figure-6.1: Different types of partitioning method

We will observe the performance of partitioned table using all Partitioning.

4.4 Range Partitioning

Range partitioning maps data to partitions based on ranges of partition key values that we

establish for each partition. It is the most common type of partitioning and is often used with

dates. For example, we might want to partition sales data into monthly partitions.

When using range partitioning, the following rules should be considered:

• Each partition has a VALUES LESS THAN clause, which specifies a noninclusive upper

bound for the partitions. Any binary values of the partition key equal to or higher than

this literal are added to the next higher partition.

• All partitions, except the first, have an implicit lower bound specified by the VALUES

LESS THAN clause on the previous partition.

• A MAXVALUE literal can be defined for the highest partition. MAXVALUE represents

a virtual infinite value that sorts higher than any other possible value for the partition key,

including the null value.

4.4.1 Implementing Partitioned table to observe the performance improvement

• First of all Different tablespaces for different partitions are created.

• Then the user partition_user is created.

P a g e | 63


• Now the table and desired sequences are cerated .

• 12400000 records are inserted , commit after 10000 records, through the procedure

person_info_insert as given in APPENDIX – B.

4.4.2 Experimental result We search the partitioned table for two different queries. These two queries are also used to

search from the main table identification_details.

Searching in the partitioned table: Query-1: 10:13:02 SQL> select count(1) from person_info_prt_dist where district_id between 24 and 26; COUNT(1) ---------- 609209 Elapsed: 00:00:04.98 Query-2: 10:20:43 SQL> select count(*) from person_info_prt_dist where (district_id between 44 and 46) or district_id < 5; COUNT(*) ---------- 1421904 Elapsed: 00:00:09.43 Searching in the table without partition: Query-1 10:18:31 SQL> select count(*) from identification_details where district_id between 24 and 26; COUNT(*) ---------- 614149

P a g e | 64


Elapsed: 00:00:11.81

Query-2 10:18:49 SQL> select count(*) from identification_details where (district_id between 44 and 46) or district_id < 5; COUNT(*) ---------- 1432278 Elapsed: 00:00:14.78 The result of performance improvement is shown in the table below: With partitioned table Normal table Query-1 4.98 sec 11.81 sec Query-2 9.43 sec 14.78 sec

Table-4.1: Performance of Range partitioned table Conclusion

• Using partitioned table enables faster query compared to the normal table

• Same procedure can be used to insert data into the partitioned table as it was used for

inserting into the master table. Based on the range of values, records are inserted into the

desired partitions.

• There is no need to create index for the entire set of records. It can be created on the

partitioned data. So, maintenance cost of index in case of high volume of DML

operations is reduced.

4.5 Implementing Hash Partitioned table to observe the performance improvement

Under this type of partitioning the records in a table, are partitions based of a Hash value found in the value of the column that is used for partitioning. “Hash Partitioning" does not have any

P a g e | 65


logical meaning to the partitions as do the range partitioning. Let’s take one example, APPENDIX-C. 4.5.1 Experimental result We search the partitioned table for two different queries. These two queries are also used to search from the main table part. Searching in the partitioned table: Query-1: 10:13:02 SQL> select count (1) from hash_part where prof_history_id between 24 and 26; COUNT (1) ---------- 609209 Elapsed: 00:00:02.98 Query-2: 10:20:43 SQL> select count (*) from hash_part where (prof_history_id between 44 and 46) or prof_history_id < 8; COUNT (*) ---------- 1421904 Elapsed: 00:00:06.43 Searching in the table without partition: Query-1 10:18:31 SQL> select count (*) from part where prof_history_id between 24 and 26; COUNT (*) ---------- 614149

Elapsed: 00:00:11.81

P a g e | 66


Query-2 10:18:49 SQL> select count (*) from part where (prof_history_id between 44 and 46) or prof_history_id < 8; COUNT (*) ---------- 1432278 Elapsed: 00:00:14.78 The result of performance improvement is shown in the table below: With partitioned table Normal table Query-1 2.98 sec 11.81 sec Query-2 6.43 sec 14.78 sec

Table4.2: Performance of Hash partitioned table

4.6 Implementing List Partitioned table to observe the performance improvement

1. Script for creating the partitioned table: 1. CREATE TABLE list_part ( deptno NUMBER(10), deptname VARCHAR2(20), quarterly_sales NUMBER(10,2), State VARCHAR2 (2)) PARTITION BY LIST (state) ( PARTITION q1_northwest VALUES ('OR', 'WA') TABLESPACE part1, PARTITION q1_southwest VALUES ('AZ', 'CA', 'NM') TABLESPACE part2, PARTITION q1_northeast VALUES ('NY', 'VT', 'NJ') TABLESPACE part1, PARTITION q1_southeast VALUES ('FL', 'GA') TABLESPACE part2, PARTITION q1_northcent VALUES ('MN', 'WI') TABLESPACE part1, PARTITION q1_southcent VALUES ('OK', 'TX') TABLESPACE part2); 2. SELECT table_name, tablespace_name, partitioned FROM user_tables; 3. SELECT partition_name, tablespace_name, high_value FROM user_tab_partitions; INSERT INTO list_part VALUES (10, 'A', 1000, 'OR'); INSERT INTO list_part VALUES (20, 'B', 1000, 'AZ'); INSERT INTO list_part VALUES (10, 'A', 1000, 'WA'); INSERT INTO list_part VALUES (20, 'B', 1000, 'WA'); INSERT INTO list_part VALUES (10, 'A', 1000, 'AZ'); INSERT INTO list_part VALUES (20, 'B', 1000, 'CA'); COMMIT;

P a g e | 67


4.6.1 Experimental result We search the partitioned table for two different queries. These two queries are also used to search from the table List_ part. Searching in the partitioned table: Query-1: 10:13:02 SQL> select count (1) from list_part where state between 10 and 10000; COUNT (1) ---------- 609209 Elapsed: 00:00:04.98 Query-2: 10:20:43 SQL> select count (*) from list_part where (state between 20 and 10000) or state < 10; COUNT (*) ---------- 1421904 Elapsed: 00:00:07.43 Searching in the table without partition: Query-1 10:18:31 SQL> select count (*) from part where state between 10 and 10000; COUNT (*) ---------- 614149

Elapsed: 00:00:14.81 Query-2 10:18:49 SQL> select count (*) from part where (state between 20 and 10000) or state < 10; COUNT (*)

P a g e | 68


---------- 1432278 Elapsed: 00:00:20.78 The result of performance improvement is shown in the table below: With partitioned table Normal table Query-1 4.98 sec 14.81 sec Query-2 7.43 sec 20.78 sec

Table 4.3: Performance of List partitioned table

4.7Implementing Composite Partitioned table to observe the performance improvement

1. Script for creating the partitioned table: CREATE TABLE composite_rng_hash ( cust_id NUMBER(10), cust_name VARCHAR2 (25), amount_sold NUMBER(10,2), time_id DATE) PARTITION BY RANGE (time_id) SUBPARTITION BY HASH (cust_id) SUBPARTITION TEMPLATE ( SUBPARTITION sp1 TABLESPACE part1, SUBPARTITION sp2 TABLESPACE part2, SUBPARTITION sp3 TABLESPACE part3, SUBPARTITION sp4 TABLESPACE part4) ( PARTITION sales_2004 VALUES LESS THAN (TO_DATE ('01/01/2004','DD/MM/YYYY')), PARTITION sales_2005 VALUES LESS THAN (TO_DATE ('01/01/2005','DD/MM/YYYY')), PARTITION sales_2006 VALUES LESS THAN (TO_DATE ('01/01/2006','DD/MM/YYYY')), PARTITION sales_2007 VALUES LESS THAN (TO_DATE ('01/01/2007','DD/MM/YYYY')), PARTITION sales_2008 VALUES LESS THAN (TO_DATE ('01/01/2008','DD/MM/YYYY')), PARTITION sales_future VALUES LESS THAN (MAXVALUE)); 4.7.1 Survey result We search the partitioned table for two different queries. These two queries are also used to search from the table composite_rng_hash, part.

P a g e | 69


Figure 4.1: Composite Partitioning methods with sub partitioning Searching in the partitioned table: Query-1: 10:13:02 SQL> select count (1) from composite_rng_hash where time_id between ’09-jan-2004’and ’20-apr-2006 and cust_id between 2 and 10000; COUNT (1) ---------- 69209 Elapsed: 00:00:01.98 Query-2: 10:20:43 SQL> select count (*) from composite_rng_hash where (time_id between ’09-jan-2004’and ’20-apr-2006 and cust_id between 2 and 10000) or cust_id < 5 and time_id < sysdate; COUNT (*) ---------- 1421904

P a g e | 70


Elapsed: 00:00:06.43 Searching in the table without partition: Query-1: 10:13:02 SQL> select count (1) from part where time_id between ’09-jan-2004’and ’20-apr-2006 and cust_id between 2 and 10000; COUNT (1) ---------- 69209 Elapsed: 00:00:15.98 Query-2: 10:20:43 SQL> select count (*) from part where (time_id between ’09-jan-2004’and ’20-apr-2006 and cust_id between 2 and 10000) or cust_id < 5 and time_id < sysdate; COUNT (*) ---------- 1421904 Elapsed: 00:00:24.43 The result of performance improvement is shown in the table below: With partitioned table Normal table Query-1 1.98sec 15.98sec Query-2 6.43sec 24.43sec

Table 4.4: Performance of Composite partitioned table

4.8 Conclusion

• Using partitioned table enables faster query compared to the normal table

• Same procedure can be used to insert data into the partitioned table as it was used for

inserting into the master table. Based on the range of values, records are inserted into the

desired partitions.

• There is no need to create index for the entire set of records. It can be created on the

partitioned data. So, maintenance cost of index in case of high volume of DML

operations is reduced.

P a g e | 71


5. LOCKING MECHANISM IS ANOTHER WAY FOR PERFORMANCE MEASUREMENT The oracle server automatically manages locking. The default locking mechanisms lock data at the lowest level of restriction to guarantee data consistency while allowing the highest degree of data concurrency.

1. Data concurrency: locks are designed to allow a high level of data concurrency; that is, many users can safely access the same data at the same time.

• DML locking is at row level. • A query holds no locks, unless the user specifies that it should.

2. Data consistency: the oracle server also provides multi-version consistency; that is, the

user sees a static picture of the data, even if other users are changing it. 3. Duration: locks are held until the transaction is committed, rollback or terminated. If a

transaction terminates abnormally, then PMON process cleans up the locks. 4. Different types of locking mechanism: basically there are two types of locking

mechanism are used for locking the tables. They are –

• LOCK IN EXCLUSIVE MODE • LOCK IN SHARE MODE

Here we show some example in distributed system and more than one user are logged in the database same object. Transaction 1 Transaction 2 SQL> update emp 2 set sal = sal+15000 3 where empno = 7639; 1 row updated.

SQL> update emp 2 set sal = sal+15000 3 where empno = 7639; Transaction 2 waits.

Table 5.1: Exclusive locks are set at row level for a DML transaction Transaction 1 Transaction 2 SQL> update emp 2 set sal = sal+15000 3 where empno = 7639; 1 row updated.

SQL> update emp 2 set sal = sal+15000 3 where empno = 7638; 1 row updated.

Table 5.2: Share locks are set at row level for a DML transaction

P a g e | 72


Lock Duration: Transactions hold locks until the transactions are committed or rolled back: Transaction 1 Transaction 2 SQL> update emp 2 set sal = sal+15000 3 where empno = 7639; 1 row updated. SQL>commit; Commit complete.

SQL> update emp 2 set sal = sal+15000 3 where empno = 7639; Transaction 2 waits until Transaction 1 is committed. 1 row update.

Table 5.3: locking duration Result of observation: As soon as transaction 1 is committed. Transaction 2 can update the row, because the transaction acquired the requested lock. Transaction 2 must wait because it wants to update the same row as transaction 1.

6. Oracle Query Optimizers There are basically two types of optimizers are present, they are – • Rule-based

– Looks at possible execution paths and rates the alternatives according to a set of rules

• Cost-based – Uses database information (e.g. table sizes) to determine the best execution path – Requires table analysis using ANALYZE command

• Oracle uses rule-based on un-analyzed tables 6.1 What do Optimizers Consider?

• SQL statement syntax • WHERE clauses (conditions) • Tables accessed by the statement • Oracle version • Current optimizer mode (rule, cost, choose) • SQL statement hints • Available object statistics (ANALYZE) • Table location in distributed DBs • Certain INIT.ORA setting

P a g e | 73


6.2 Rule-Based Optimizer (RBO)

• Older, more predictable, but not as smart • Does NOT require ANALYZE • Follows 20 condition rankings (rules) • If statement meets condition #1 it is used; if not #2 is checked, etc. • Rules are available in Oracle docs

6.2.1 RBO Examples

• Path #1: ROWID constant used in WHERE clause SELECT * FROM EMP WHERE ROWID = ‘AA..12’;

• Path #4: Primary key constant used in WHERE clause SELECT * FROM EMP WHERE EMPID = 1234; • Path #9:WHERE clause uses columns of one or more columns from a single-column

indexes in = conditions SELECT * FROM EMP WHERE JOB = ‘DBA’;

6.3 RBO and Driving Tables

• RBO must select a driving table for multi-table queries

– Driving table is the one that’s scanned and sorted first – If table-1 has a unique or primary key index and table-2 doesn’t, table-1 is driver – (other rules) – If RBO can’t choose based on rules, the right-most table in FROM clause drives

6.3.1 RBO Driving Table Example

• Consider 2 tables – Table-A has 16,000 rows, Table-B has 1 row

SELECT COUNT(*) FROM TABLE-A, TABLE-B SELECT COUNT(*) FROM TABLE-B, TABLE-A

Driving table

1 sec.

26 sec.

P a g e | 74


6.4 Cost-Based Optimizer (CBO) • More sophisticated than RBO • Uses table information to determine best execution path • ANALYZE command makes the required table information available

– CBO can be used if one or more tables in a query have been analyzed – CBO makes estimates about non-analyzed tables based on analyzed table(s)

6.4.1 How CBO Works • CBO generates set of potential plans for the statement • CBO estimates the cost of each plan based on statistics from ANALYZE command or

DBMS_STATS package – Stats are stored in data dictionary – Cost is the estimated value in proportion to the expected resource use

• CBO chooses the plan with the lowest cost 6.4.2 CBO Architecture

Figure 6.1: Cost Base Optimizer Architecture

P a g e | 75


6.5 Working Mechanism:

1. Parsed query enters Trans. 2. Transformed query sent to estimator 3. Stats are reviewed from data dic. 4. Query and estimates sent to plan gen. 5. Plan gen. either returns plan to est., or sends to row source gen.

6.6 Optimizer Statistics

• Table statistics – Number of rows, blocks, avg. row length

• Column statistics – Number of distinct values and nulls, data distribution (histogram)

• Index statistics – Number of leaf blocks, levels, clustering factor

• System statistics – I/O & CPU performance and utilization

7. TUNING THE MEMORY STRUCTURE

Sizing the SGA According to [13], the total memory that should be allocated to SGA and to each instance is given below:

a) Total amount of memory for all SGAs -

i) For servers having 1gb or less memory

Total amount of memory for all SGA’s = server memory * 0.55

ii) For servers having more than 1gb

Total amount of memory for all SGA’s = server memory * (0.60 to 0.75)

b) Total amount of memory per instance –

Total memory per instance=(server memory *0.55)/number of oracle instances

Shared pool = total memory per instance * 0.45

Buffer cache = total memory per instance *0.45

Log buffer = total memory per instance *0.10

Here, 32-bit restrictions should be considered.

Calculating the Size of the Shared Pool

P a g e | 76


Shared pool is the amount of fixed, preallocated space in the SGA for use by multi-threaded

server session PGA, shared SQL area, and other small, dynamically allocated SGA data

structures. Since shared pool usage is highly application dependent, it is necessary to examine

each database application individually in order to project a recommended shared pool value.

While analyzing shared pool sizing, it is helpful to first increase the shared pool to a very large

value, so that the dynamically allocated SGA structures may be allowed to expand to a desirable

size. Once this sizing exercise has been completed, the shared pool may be downsized to the

appropriate value.

Shared pool calculation is especially critical when the multi-threaded server is in use because the

PGA for each multi-threaded server database user will be allocated from shared pool.

The default value for the shared pool supplied by the Oracle RDBMS is not optimum. According

to [15] an optimized formula for calculating the size of the shared pool is given in Formula:

Formula Max Session Memory * No. of concurrent users + Total Shared SQL Area Usage + PLSQL Sharable Memory + Minimum 30% Free Space ------------------------------------------- = Minimum Allowable Shared Pool Example of calculating the size of shared pool using Formula Finding the SID for an example user session: SQLDBA> select sid from v$process p, v$session s 2> where p.addr=s.paddr and s.username='OPS$JSMITH'; SID ---------- 29 1 row selected.

P a g e | 77


Getting the maximum session memory for this session: SQLDBA> select value from v$sesstat s, v$statname n 2> where s.statistic# = n.statistic# 3> and n.name = 'session uga memory max'

4> and sid=29;

VALUE ---------- 273877 1 row selected. Getting the total shared SQL area: SQLDBA> select sum (sharable_mem) from v$sqlarea; SUM (SHARAB ------------------- 8936625 1 row selected. Getting the PLSQL sharable memory area: SQLDBA> select sum (sharable_mem) from v$db_object_cache; SUM (SHARAB ------------------- 4823537 1 row selected. Example shared pool calculation: 274K shared memory * 400 users + 9M Shared SQL Area + 5M PLSQL Sharable Memory + 60M Free Space (30%) --------------------------------- = 184M Shared Pool In this example, the recommended shared pool value is 184M.

P a g e | 78


7.1 Conclusion

The formulae to calculate the size of SGA and shared pool are very efficient as described in [13].

Hence we should always consider these formulae when we need to tune the memory structures to

ensure the optimum performance of the database.

P a g e | 79


Chapter Five

IMPLEMENTATION WORK

1. Online Transaction Processing System This site has been designed with an online transaction processing scenario in mind, but it can be used for a wide variety of other purposes as well. Online Transaction Processing System may be of various kinds for example Online Banking System, Online Shopping System, Online Gaming zone etc. We tried to show one of the examples of the above. And that is Online Shopping mall software.

The target is to maintain the customers from worldwide. All the features are available like Online ordering, Shipping and Payment, Online Order Processing system, User registration, searching etc. So this demo site introduces possible features for OLTP (Online Transaction Processing System)

We develop mobile software with the help of the J2ME and develop a shopping cart (website) with the help of PHP and HTML. (APPENDIX-D)

1.1 Access by Mobile

In Java 2 Standard Edition (J2SE), network programming is fairly straightforward. Most of the network related classes are packaged in java.net. There are about 20 classes available in this package. These classes provide a rich set of functionality to support the network communication in Java applications. However, the java.net package is not suitable for the wireless applications that run on cell phones and two-way pagers. The size of java.net is around 200KB. It is too big to fit in with the wireless devices that only have a few hundred kilobytes of total memory and storage budget. Besides the size issue, there is another challenge when dealing with wireless devices: J2ME needs to support a variety of mobile devices that come with different sizes and shapes, different networking capabilities, and different file I/O requirements.

The networking in J2ME has to be very flexible to support a variety of devices and has to be very device specific at the same time. To meet these challenges, the Generic Connection framework is first introduced in the CLDC. The idea of the Generic Connection framework is to define the abstractions of the networking and file I/O as general as possible to support a broad range of handheld devices, and leave the actual implementations of these abstractions to individual device manufacturers. These abstractions are defined as Java interfaces. The device

P a g e | 80


manufacturers choose which one to implement in their MIDP based on the actual device capabilities.

There is 1 class (Connector) and 7 connection interfaces (Connection, Content Connection, Datagram Connection, Input Connection, Output Connection, Stream Connection, and Stream Connection Notified) defined in the Generic Connection framework. They can be found in the javax.microedition.io package that comes with J2ME CLDC. Please note that there is no implementation of the connection interfaces at the CLDC level. The actual implementation is left to MIDP.

The 7 connection interfaces define the abstractions of 6 basic types of communications: basic serial input, basic serial output, datagram communications, sockets communications, notification mechanism in a client-server communication, and basic HTTP communication with a Web server.

The relationships between these interfaces are illustrated in the following diagram:

As shown in the figure, Connection is the base interface and the root of the connection interface hierarchy. All the other connection interfaces derive from Connection. Stream Connection derives from Input Connection and Output Connection. It defines both the input and output capabilities for a stream connection. Content Connection derives from Stream Connection. It adds three additional methods from MIME handling on top of the I/O methods in Stream Connection.

P a g e | 81


The Connector class is the core of Generic Connection framework. The reason we say that is because all connection objects we mentioned above are created by the static method open defined in Connector class. Different types of communication can be created by the same method with different parameters. The connection could be file I/O, serial port communication, datagram connection, or an http connection depending on the string parameter passed to the method. Such design makes J2ME implementation very extensible and flexible in supporting new devices and products.

Here is how the method is being used:

Connector.open(String connect);

The parameter connect is a String variable. It has a URL-like format: {protocol} :[{ target}] [{params}] and it consists of three parts: protocol, target, and params.

Protocol dictates what type of connection will be created by the method. There are several possible values for protocol: file, socket, comm., datagram and http. file indicates that the connection will be used for file I/O, comm. indicates that the connection will be used for serial port communication, and http indicates that the connection is created for accessing web servers.

Target can be a host name, a network port number, a file name, or a communication port number.

params is optional, it specifies the additional information needed to complete the connect string.

The following examples illustrate how to use the open method to create different types of communication based on different protocols:

HTTP communication:

Connection hc = Connector.open("http://www.wirelessdevnet.com");

Stream-based Socket communication:

Connection sc = Connector.open("socket://localhost:9000");

Datagram-based socket communication:

Connection dc = Connector.open("datagram://:9000");

P a g e | 82


Serial port communication:

Connection cc = Connector.open("comm:0;baudrate=9000");

File I/O

Connection fc = Connector.open("file://foo.dat");

As we mentioned earlier, the support for these protocols varies from vendor to vendor. Developers have to check the documentation from each MIDP device manufacturers to see if they support the specific protocol. I tested the socket, datagram, and http connections with Moto SDK (a development kit from Motorola). All three types of connections are supported by the Motorola’s MIDP. Sun’s MIDP reference implementation supports only the http connections. We will talk more about this later. If your program is trying to create a connection based on a protocol that is not supported by your device manufacturer, a ConnectionNotFoundException exception will be thrown.

The Http Connection Class

The Http Connection class is defined in J2ME MIDP to allow developer to handle http connections in their wireless applications. The Http Connection class is guaranteed available on all MIDP devices.

Theoretically you may use either sockets or datagram for remote communication in your J2ME applications if your MIDP device manufacturer supports them. But this creates a portability issue for your applications, because you can’t always count on that other device manufacturers will support them as well. This means that your program may run on one MIDP device but fail on others. So you should consider using the Http Connection class in your application first, because HTTP Connection is mandatory for all MIDP implementations.

In this section, we will take a hard look at the Http Connection class. A complete sample program using Http Connection is shown in the next section.

The Http Connection interface derives from the Content Connection interface in CLDC. It inherits all I/O stream methods from Stream Connection, all the MIME handling methods from Content Connection and adds several additional methods for handling http protocol specific needs.

Here is a laundry list of all the methods available in Http Connection:

I/O related:

DataInputStream openDataInputStream ()

P a g e | 83


Input Stream openInputStream ()

DataOutputStream openDataOutputStream ()

Output Stream openOutputStream ()

An input stream can be used to read contents from a Web server while output stream can be used to send request to a Web server. These streams can be obtained from the HttpConnection object after the connection has been established with the Web Server. In the following example, an http connection is established with Web server www.wirelessdevnet.com at port 80 (the default http port). Then an input stream is obtained for reading response from the Web:

HttpConnection hc = (HttpConnection); Connector.open("http://www.wirelessdevnet.com");InputStream is = new hc.openInputStream(); int ch; // Check the Content-Length first long len = hc.getLength(); if(len!=-1) { for(int i = 0;i<len;i++) if((ch = is.read())!= -1) System.out.print((char) ch)); } else { // if the content-length is not available while ((ch = is.read()) != -1) System.out.print((char) ch)); } is.close(); hc.close();

MIME related:

String get Encoding ()

Long get Length ()

String get Type ()

Once the http connection is established, these three methods can be used to obtain the value of the following three fields in the HTTP header: Content-Length, Content-Encoding and Content-Type

P a g e | 84


Http Protocol related:

Long get Date ()

long get Expiration()

String get File ()

String getHeaderField (int index)

String getHeaderField (String name)

long getHeaderFieldDate(String name, long def)

int getHeaderFieldInt(String name, int def)

String getHeaderFieldKey (int n)

String get Host ()

Long getLastModified ()

int get Port()

String get Protocol ()

String get Query ()

String getRef ()

String getRequestMethod ()

String getRequestProperty (String key)

int getResponseCode()

String getResponseMessage ()

String getURL ()

void setRequestMethod(String method)

void setRequestProperty(String key, String value)

P a g e | 85


GetResponseCode and getResponseMessage can be used to check the response status code and message from the Web server. In this typical response message from a Web server: "HTTP/1.1 401 Unauthorized", you will get a response code "401" and a response message "Unauthorized".

The following methods are used for obtaining additional header information: get Date, get Expiration, get File, getHeaderField, getHeaderField, getHeaderFieldDate, getHeaderFieldInt, getHeaderFieldKey and getLastModified

The following methods are used for retrieving the individual components parsed out of the URL string: Get Host, get Port, get Protocol, get Query, getRef, getRequestMethod, getRequestProperty, getResponseCode, getResponseMessage, and getURL.

These three methods are used for dealing with the HEAD, GET, and POST requests: setRequestMethod, setRequestProperty, and getRequestMethod.

1.2 Access by Website

We develop a website or an online shopping cart which is a sample implementation of our OLTP system.

P a g e | 86


Chapter Six

Summary and Conclusion

1. Summary

Our project work starts with the analysis of nature of insertion depending on the various commit

points in case of millions of data. As the 24/7 OLTP systems should ensure consistency, it is a

crucial point to choose the appropriate point of commit so that the trade-off between the volume

of data and the time required for insertion is minimized. Hence, we need an optimal point of

commit to get the maximized performance. Chapter 3 provides an answer to this problem.

We have discussed different types of indexes and their performance. We specially concentrate on

the performance of B-tree and bitmap indexes in different situations. Function based index and

its applications are discussed which clarify how the developers can take advantage of this type of

indexing. We also discuss composite index and its proper ordering to get the maximized

performance.

Concentrates on the features of clustering provided by Oracle. Here, clustering of tables is

discussed and its advantages and disadvantages are revealed.

We discuss the partitioned table. Advantages of partitioning and performance gain using

partitioned table is an interesting feature of this chapter. We analyze the performance of

partitioned table by implementing the Range Partitioning method.

In our recent experimental work we have included list, hash and composite partitioning. We also

introduced the rule based and cost based optimizer mode to measure performance of joining and

query among different tables.

P a g e | 87


Tuning the memory structures is an important part of database tuning. It is system dependent but

we give some formulas to calculate the appropriate size which is system independent. We

collected this information by our continuous research on articles published by Oracle

Corporation.

On the other hand, we built web and mobile application for showing the OLTP system to be in

working condition. OLTP emphasizes the online transaction processing system both in mobile

and web environment. Our web application provides the features of Online Shopping mall.

Mobile application features the data fetching from remote web server using J2ME, GPRS, and

EDGE technology.

2. Conclusion The objective of this project is to be able to tune some database performance bottlenecks using

some efficient methods so that the scenario of a real world large database system can be

understood. The results found by our experiments and study is acceptable for the optimization

of a database system in the respective fields that were discussed throughout the chapters of this

dissertation. For Online Transaction Processing System we have made one website and mobile

application. Hence, the project was able to achieve its goal and objective.

P a g e | 88


Chapter Seven

Future Work

We have tried to implement some application for Online Transaction Processing System (OLTP). Among them one was using Bluetooth technology. But that is not yet implemented. So our future work would be to implement that part.

P a g e | 89


APPENDIX – A

This provides the listing (source code) of various procedure to insert data into the test table and

also script of the sequence creation as stated in the Chapter-4.

1. Procedure testproject_insert to insert data into the table identification_details: create or replace procedure testproject_insert as a_nm number; dt date := '02-dec-1980'; j number:=1; begin insert into TEST_TRACKING(start_time,VARIABLE,TIMESTAMP ) values(sysdate,'beforeinsert',to_char(sysdate,'dd-mon-yyyy hh24:mi:ss')); commit; dt:=to_date(lpad(random.rand_max(30),2,0)||'-'||lpad(random.rand_max(12),2,0)||'-19'||lpad(random.rand_max(89),2,0),'dd-mm-yyyy'); for i in 1..100000 loop update TEST_TRACKING1 set VARIABLE =i; if j=10000 then---- Here, commit is done after every 10,000 records, this number is changed to change the commit point commit; j:=0; end if; j:=j+1; a_nm:=random.rand_max(3); if a_nm=1 then insert into identification_details (national_id,district_id,thana_id,name,gender,date_of_birth,blood_group) values(IDENTIFICATION_SEQ.nextval,random.rand_max(64),random.rand_max(460),'A'||'Khan',decode (random.rand_max(2),1,'M','F'), dt,'A+');

P a g e | 90


elsif a_nm=2 then insert into identification_details (national_id,district_id,thana_id,name,gender,date_of_birth,blood_group) values(IDENTIFICATION_SEQ.nextval,random.rand_max(64),random.rand_max(460),'K'||'Islam',decode (random.rand_max(2),1,'M','F'), dt,'B+'); elsif a_nm=3 then insert into identification_details (national_id,district_id,thana_id,name,gender,date_of_birth,blood_group) values(IDENTIFICATION_SEQ.nextval,random.rand_max(64),random.rand_max(460),'H'||'Akhter',decode (random.rand_max(2),1,'M','F'), dt,'AB+'); end if; commit; end loop; insert into TEST_TRACKING(start_time,VARIABLE,TIMESTAMP ) values(sysdate,'afterinsert',to_char(sysdate,'dd-mon-yyyy hh24:mi:ss')); commit; end; / 2. Random function used in the procedure: create or replace package random is pragma restrict_references( random, WNDS, RNPS ); procedure srand( new_seed in number ); function rand return number; pragma restrict_references( rand, WNDS ); procedure get_rand( r OUT number ); function rand_max( n IN number ) return number; pragma restrict_references( rand_max, WNDS); procedure get_rand_max( r OUT number, n IN number ); end random; / create or replace package body random is multiplier constant number := 22695477; increment constant number := 1; "2^32" constant number := 2 ** 32;

P a g e | 91


"2^16" constant number := 2 ** 16; "0x7fff" constant number := 32767; Seed number := 1; -- procedure srand( new_seed in number ) is begin Seed := new_seed; end srand; -- function rand return number is begin seed := mod( multiplier * seed + increment, "2^32" ); return bitand( seed/"2^16", "0x7fff" ); end rand; -- procedure get_rand( r OUT number ) is begin r := rand; end get_rand; -- function rand_max( n IN number ) return number is begin return mod( rand, n ) + 1; end rand_max; -- procedure get_rand_max( r OUT number, n IN number ) is begin r := rand_max( n ); end get_rand_max; -- begin select userenv( 'SESSIONID' ) into seed from dual; end random; / 3. Script for the sequence: CREATE SEQUENCE PROJECT_USER.IDENTIFICATION_SEQ START WITH 1 INCREMENT BY 1 NOCACHE NOCYCLE NOORDER /

P a g e | 92


APPENDIX- B This provides the listing (source code) of various procedure to insert data into the test table and

also script of the user, table and sequence creation as stated in the Chapter-4

1. Scripts for creating different tablespaces for different partitions. A. CREATE TABLESPACE PR_PARTITION_1

DATAFILE 'J:\ORA_DATA_FILE\ORA_FILE_TAB_PARTITION.DBF' SIZE 200 M REUSE AUTOEXTEND ON NEXT 4 M MAXSIZE UNLIMITED

LOGGING DEFAULT NOCOMPRESS ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE FLASHBACK OFF B. CREATE TABLESPACE PR_PARTITION_2

DATAFILE 'J:\ORA_DATA_FILE\ORA_FILE_TAB_PARTITION_2.DBF' SIZE 200 M REUSE AUTOEXTEND ON NEXT 4 M MAXSIZE UNLIMITED LOGGING

DEFAULT NOCOMPRESS ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE FLASHBACK OFF C. CREATE TABLESPACE PR_PARTITION_3

DATAFILE 'J:\ORA_DATA_FILE\ORA_FILE_TAB_PARTITION_3.DBF' SIZE 200 M REUSE AUTOEXTEND ON NEXT 4 M MAXSIZE UNLIMITED

LOGGING DEFAULT NOCOMPRESS ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE FLASHBACK OFF D. CREATE TABLESPACE PR_PARTITION_4

DATAFILE 'J:\ORA_DATA_FILE\ORA_FILE_TAB_PARTITION_4.DBF' SIZE 200 M REUSE AUTOEXTEND ON NEXT 4 M MAXSIZE UNLIMITED

LOGGING DEFAULT NOCOMPRESS ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE FLASHBACK OFF Tablespace created.

P a g e | 93


Elapsed: 00:00:04.17 2. Script for creating user: CREATE USER "PARTITION_USER" IDENTIFIED BY "PROJECT" DEFAULT TABLESPACE PR_PARTITION_1 TEMPORARY TABLESPACE TEMP PROFILE DEFAULT QUOTA UNLIMITED ON PR_PARTITION_1 QUOTA UNLIMITED ON TEMP; 3. Script for creating the partitioned table: CREATE TABLE PARTITION_USER.person_info_prt_dist ( national_id NUMBER NOT NULL, district_id NUMBER NOT NULL, thana_id NUMBER NOT NULL, name VARCHAR2(30) NOT NULL, gender CHAR(1), date_of_birth DATE, blood_group CHAR(3), CONSTRAINT PK_person_info PRIMARY KEY (national_id ) ) PARTITION BY RANGE (district_id) ( PARTITION dist_1_16 VALUES LESS THAN (17) TABLESPACE PR_PARTITION_1, PARTITION dist_16_32 VALUES LESS THAN (33) TABLESPACE PR_PARTITION_2, PARTITION dist_32_48 VALUES LESS THAN (49) TABLESPACE PR_PARTITION_3, PARTITION dist_48_64 VALUES LESS THAN (65) TABLESPACE PR_PARTITION_4 ) 4. Script for creating the sequence: CREATE SEQUENCE PARTITION_USER.PERSON_SEQ START WITH 1 INCREMENT BY 1 NOCACHE NOCYCLE NOORDER

/

5. Procedure person_info_insert: create or replace procedure person_info_insert as a_nm number;

P a g e | 94


dt date := '02-dec-1980'; j number:=1; begin insert into TEST_TRACKING(start_time,VARIABLE,TIMESTAMP ) values(sysdate,'before insert',to_char(sysdate,'dd-mon-yyyy hh24:mi:ss')); commit; dt:=to_date(lpad(random.rand_max(30),2,0)||'-'||lpad(random.rand_max(12),2,0)||'-19'||lpad(random.rand_max(89),2,0),'dd-mm-yyyy'); for i in 1..100000 loop update TEST_TRACKING1 set VARIABLE =i; if j=10000 then commit; j:=0; end if; j:=j+1; a_nm:=random.rand_max(3); if a_nm=1 then insert into PERSON_INFO_PRT_DIST (national_id,district_id,thana_id,name,gender,date_of_birth,blood_group)values(PERSON_SEQ.nextval,random.rand_max(64),random.rand_max(460),dbms_random.string('L',20),decode (random.rand_max(2),1,'M','F'), dt,'A+'); elsif a_nm=2 then insert into PERSON_INFO_PRT_DIST (national_id,district_id,thana_id,name,gender,date_of_birth,blood_group)values(PERSON_SEQ.nextval,random.rand_max(64),random.rand_max(460),dbms_random.string('L',20),decode (random.rand_max(2),1,'M','F'),dt,'B+'); elsif a_nm=3 then insert into PERSON_INFO_PRT_DIST (national_id,district_id,thana_id,name,gender,date_of_birth,blood_group)values(PERSON_SEQ.nextval,random.rand_max(64),random.rand_max(460),dbms_random.string('L',20),decode (random.rand_max(2),1,'M','F'), dt,'AB+');

P a g e | 95


end if; commit; end loop; insert into TEST_TRACKING(start_time,VARIABLE,TIMESTAMP ) values(sysdate,'after insert',to_char(sysdate,'dd-mon-yyyy hh24:mi:ss')); commit; end; /

P a g e | 96


APPENDIX – C This provides the listing (source code) of Partitioning methods as started in chapter- 4. 1. Scripts for creating different tablespaces for different partitions. A.CREATE TABLESPACE part1 DATAFILE 'j: \temp\part01.dbf' SIZE 10M BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K SEGMENT SPACE MANAGEMENT AUTO ONLINE; B.CREATE TABLESPACE part2 DATAFILE 'j: \temp\part02.dbf' SIZE 10M BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K SEGMENT SPACE MANAGEMENT AUTO ONLINE; C.CREATE TABLESPACE part3 DATAFILE 'j: \temp\part03.dbf' SIZE 10M BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K SEGMENT SPACE MANAGEMENT AUTO ONLINE; D.CREATE TABLESPACE part4 DATAFILE 'j: \temp\part04.dbf' SIZE 10M BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K SEGMENT SPACE MANAGEMENT AUTO ONLINE; E.CREATE TABLESPACE part5 DATAFILE 'j: \temp\part05.dbf' SIZE 10M BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K SEGMENT SPACE MANAGEMENT AUTO ONLINE; Tablespace created. Elapsed: 00:00:04.17 2. Script for Alter user: ALTER USER project_user QUOTA UNLIMITED ON part1; ALTER USER project_user QUOTA UNLIMITED ON part2; ALTER USER project_user QUOTA UNLIMITED ON part3; ALTER USER project_user QUOTA UNLIMITED ON part4; ALTER USER project_user QUOTA UNLIMITED ON part5; 3. Script for creating the partitioned table: CREATE TABLE project_user .hash_part ( Prof_history_id NUMBER (10), person_id NUMBER(10) NOT NULL,

P a g e | 97


Organization_id NUMBER (10) NOT NULL, record_date DATE NOT NULL, prof_hist_comments VARCHAR2 (2000)) PARTITION BY HASH (prof_history_id) PARTITIONS 3 STORE IN (part1, part2, part3);

P a g e | 98


APPENDIX – D

This provides the listing (source code) of J2ME script of the mobile application as stated in the

Chapter-5.

/* * OLTP.java * * Created on April 17, 2008, 7:01 PM */ import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.DataInputStream; import java.io.DataOutputStream; import java.io.IOException; import java.io.InputStream; import java.util.Date; import javax.microedition.io.Connector; import javax.microedition.io.StreamConnection; import javax.microedition.midlet.*; import javax.microedition.lcdui.*; import javax.microedition.rms.InvalidRecordIDException; import javax.microedition.rms.RecordStore; import javax.microedition.rms.RecordStoreException; import javax.microedition.rms.RecordStoreNotOpenException; public class OLTP extends MIDlet implements CommandListener { public static RecordStore resultRecord; String dbout; int num=0; public OLTP() { initialize(); recordCreator("Database"); try { num = resultRecord.getNumRecords(); } catch (RecordStoreNotOpenException ex) { ex.printStackTrace(); } if(num<1) { for(int x=1;x<11;x++) {

P a g e | 99


Integer ts=new Integer(x); writeStream(ts.toString(),"null",11); } } } public void readStream() { try { byte[] recData = new byte[50]; ByteArrayInputStream strmBytes =new ByteArrayInputStream(recData); DataInputStream strmDataType =new DataInputStream(strmBytes); resultRecord.getRecord(9, recData, 0); String ID="\nID: "+strmDataType.readUTF(); strmBytes.reset(); resultRecord.getRecord(10, recData, 0); String CGPA="\nCGPA: "+strmDataType.readUTF(); strmBytes.reset(); String GPA=""; for (int i = 1; i <= resultRecord.getNumRecords()-2; i++) { resultRecord.getRecord(i, recData, 0); GPA+="\n Semester: " + strmDataType.readUTF()+"\n GPA: " +strmDataType.readUTF(); strmBytes.reset(); } strmBytes.close(); strmDataType.close(); dbout=ID+"\n"+GPA+"\n"+CGPA; } catch (Exception e) { } } public void recordCreator(String name){ try { resultRecord = RecordStore.openRecordStore(name, true);

P a g e | 100


} catch (RecordStoreException ex) { ex.printStackTrace(); } } public static void writeStream(String sem, String gpa, int flg){ try { ByteArrayOutputStream strmBytes = new ByteArrayOutputStream(); DataOutputStream strmDataType =new DataOutputStream(strmBytes); byte[] record; strmDataType.writeUTF(sem); strmDataType.writeUTF(gpa); strmDataType.flush(); record = strmBytes.toByteArray(); if(flg==9) resultRecord.setRecord(9,record, 0, record.length); else if (flg==10) resultRecord.setRecord(10,record, 0, record.length); else if(flg==11) resultRecord.addRecord(record, 0, record.length); else resultRecord.setRecord(flg,record, 0, record.length); // Toss any data in the internal array so writes starts at beginning (of the internal array) strmBytes.reset(); strmBytes.close(); strmDataType.close(); } catch (Exception e) { e.printStackTrace(); } } private Form InputForm;//GEN-BEGIN:MVDFields private org.netbeans.microedition.svg.SVGWaitScreen WaitScreen1; private Command okCommand1; private Command backCommand1; private Alert alert1; private TextField textField1; private Command backCommand2; private javax.microedition.m2g.SVGImage svgImage1; private org.netbeans.microedition.util.SimpleCancellableTask simpleCancellableTask1; private Command backCommand3; private org.netbeans.microedition.svg.SVGMenu svgMenu1;

P a g e | 101


private javax.microedition.m2g.SVGImage svgImage2; private Command okCommand2; private org.netbeans.microedition.svg.SVGSplashScreen Splash; private javax.microedition.m2g.SVGImage svgImage3; private Form showresult; private Form inputID; private TextField textField2; private Command okCommand3; private Command okCommand4; private Alert alert2; private Command okCommand5; private StringItem stringItem1; private Form form1; private Command backCommand4; private Command backCommand5;//GEN-END:MVDFields String s; String name; int dept; public static int k; public static String studentname,gpa,cgpa,result,sem; private String ErrMsg=""; private Alert ErrAlert; private DateField dat; //GEN-LINE:MVDMethods public void sav(){ int sm=Integer.parseInt(sem); writeStream(sem,gpa,sm); writeStream(cgpa,"null",10); showresult = null; getDisplay().setCurrent(get_alert2(), get_svgMenu1().getSvgCanvas()); } public void Check(TextField tf){ int err=0; String rol=""; rol=tf.getString().trim(); if(rol.compareTo("")==0){ ErrMsg="Enter an ID"; err=1;

P a g e | 102


} else{ String y; //if(rol.charAt(0)=='0') y=rol.substring(1,2); //else y=rol.substring(0,2); Date cur=new Date(); String yer,timestring; timestring=cur.toString(); yer=timestring.substring(timestring.length()-2); //System.out.println(yer); Integer frth=new Integer(Integer.parseInt(yer)-4); Integer thrd=new Integer(Integer.parseInt(yer)-4 +1); Integer scnd=new Integer(Integer.parseInt(yer)-4 +2); Integer frst=new Integer(Integer.parseInt(yer)-1); String frths, thrds, scnds, frsts; if(frth.intValue()<10){ frths="0"+frth.toString(); } else{ frths=frth.toString(); } if(thrd.intValue()<10) thrds="0"+thrd.toString(); else thrds=thrd.toString(); if(thrd.intValue()<10) scnds="0"+scnd.toString(); else scnds=scnd.toString(); if(frst.intValue()<10){ frsts="0"+frst.toString(); } else{ frsts=frst.toString(); } //System.out.println(y); if(rol.length()>6 || rol.length()<6){ ErrMsg="Student id mustbe 6 Char";

P a g e | 103


err=1; } else if(y.compareTo(frths)!=0 && y.compareTo(thrds)!=0 && y.compareTo(scnds)!=0 && y.compareTo(frsts)!=0 ){ ErrMsg=frths+" to "+frsts+" batches are in IUT now.\n\nNB: May be ur system date is not Currect"; err=1; } else if( (rol.charAt(4)=='0') && (rol.charAt(5)=='0')){ ErrMsg="ID should be a valid number"; err=1; } else if( ('0'>rol.charAt(4) || '9'<rol.charAt(4)) || ('0'>rol.charAt(5) || '9'<rol.charAt(5)) ){ ErrMsg="ID should be a valid number"; err=1; } else { char typ=rol.charAt(3); char typ1=rol.charAt(2); if(typ!='4' && typ!='3' ){ ErrMsg="Fourth position of ID will be 4 / 3 "; err=1; } else if(typ1!='4' && typ1!='3' && typ1!='2' && typ1!='1' ){ ErrMsg="Third position of ID will be 4 / 3 / 2/ 1 "; err=1; } if(err!=1) dept=(int)(typ1-48); //System.out.println(dept); } } if(err==0){ if(num<1) { getDisplay().setCurrent(get_svgMenu1().getSvgCanvas()); writeStream(textField2.getString().trim(),"null",9); writeStream("null","null",10);

P a g e | 104


} else getDisplay().setCurrent(get_WaitScreen1().getSvgCanvas()); //readStream() ; ErrMsg=""; err=0; } if(err==1){ getDisplay().setCurrent(get_ErrAlert()); ErrMsg=""; err=0; } } public Alert get_ErrAlert() { if (ErrAlert == null) { // Insert pre-init code here ErrAlert = new Alert(null,ErrMsg, null, AlertType.ERROR); ErrAlert.setTimeout(1000); // Insert post-init code here } else ErrAlert = new Alert(null,ErrMsg, null, AlertType.ERROR); return ErrAlert; } /** Called by the system to indicate that a command has been invoked on a particular displayable.//GEN-BEGIN:MVDCABegin * @param command the Command that ws invoked * @param displayable the Displayable on which the command was invoked */ public void commandAction(Command command, Displayable displayable) {//GEN-END:MVDCABegin // Insert global pre-action code here if (displayable == WaitScreen1) {//GEN-BEGIN:MVDCABody if (command == WaitScreen1.SUCCESS_COMMAND) {//GEN-END:MVDCABody // Insert pre-action code here /*canvas = new ChildCanvas(this); byte[] recData2 = new byte[50]; ByteArrayInputStream strmBytes =new ByteArrayInputStream(recData2); DataInputStream strmDataType =new DataInputStream(strmBytes); String OwnRol="";

P a g e | 105


try { resultRecord.getRecord(9, recData2, 0); OwnRol= strmDataType.readUTF(); } catch (Exception ex) { ex.printStackTrace(); } if(OwnRol.compareTo(textField1.getString().trim())!=0){ canvas.removeCommand(ChildCanvas.Save); } canvas.setFullScreenMode(true); getDisplay().setCurrent(canvas); */ getDisplay().setCurrent(get_form1());//GEN-LINE:MVDCAAction6 // Insert post-action code here } else if (command == WaitScreen1.FAILURE_COMMAND) {//GEN-LINE:MVDCACase6 // Insert pre-action code here getDisplay().setCurrent(get_alert1(), get_InputForm());//GEN-LINE:MVDCAAction7 // Insert post-action code here }//GEN-BEGIN:MVDCACase7 } else if (displayable == InputForm) { if (command == backCommand1) {//GEN-END:MVDCACase7 // Insert pre-action code here getDisplay().setCurrent(get_svgMenu1().getSvgCanvas());//GEN-LINE:MVDCAAction11 // Insert post-action code here } else if (command == okCommand1) {//GEN-LINE:MVDCACase11 // Insert pre-action code here name=textField1.getString().toString().trim(); try { num = resultRecord.getNumRecords(); } catch (RecordStoreNotOpenException ex) { ex.printStackTrace(); } Check(textField1); // Do nothing//GEN-LINE:MVDCAAction9 // Insert post-action code here }//GEN-BEGIN:MVDCACase9 } else if (displayable == svgMenu1) { if (command == svgMenu1.SELECT_COMMAND) { switch (svgMenu1.getSelectedIndex()) { case 0://GEN-END:MVDCACase9

P a g e | 106


// Insert pre-action code here getDisplay().setCurrent(get_InputForm());//GEN-LINE:MVDCAAction25 // Insert post-action code here break;//GEN-BEGIN:MVDCACase25 case 1://GEN-END:MVDCACase25 // Insert pre-action code here getDisplay().setCurrent(get_showresult());//GEN-LINE:MVDCAAction27 // Insert post-action code here break;//GEN-BEGIN:MVDCACase27 case 2://GEN-END:MVDCACase27 // Insert pre-action code here exitMIDlet();//GEN-LINE:MVDCAAction29 // Insert post-action code here break;//GEN-BEGIN:MVDCACase29 } } } else if (displayable == Splash) { if (command == Splash.DISMISS_COMMAND) {//GEN-END:MVDCACase29 // Insert pre-action code here getDisplay().setCurrent(get_inputID());//GEN-LINE:MVDCAAction34 //System.out.println(num); getDisplay().setCurrent(get_inputID()); }//GEN-BEGIN:MVDCACase34 } else if (displayable == inputID) { if (command == okCommand3) {//GEN-END:MVDCACase34 // Insert pre-action code here String str=textField2.getString(); if(str.compareTo("ad")==0){ getDisplay().setCurrent(get_svgMenu1().getSvgCanvas()); }else { StringItem sii= new StringItem("Warning :","Wrong Password."); inputID.append(sii); } // Check(textField2); // Do nothing//GEN-LINE:MVDCAAction50 // Insert post-action code here }//GEN-BEGIN:MVDCACase50 } else if (displayable == showresult) { if (command == okCommand5) {//GEN-END:MVDCACase50 // Insert pre-action code here getDisplay().setCurrent(get_svgMenu1().getSvgCanvas());//GEN-LINE:MVDCAAction59 // Insert post-action code here }//GEN-BEGIN:MVDCACase59 } else if (displayable == form1) {

P a g e | 107


if (command == backCommand5) {//GEN-END:MVDCACase59 // Insert pre-action code here getDisplay().setCurrent(get_svgMenu1().getSvgCanvas());//GEN-LINE:MVDCAAction64 // Insert post-action code here }//GEN-BEGIN:MVDCACase64 }//GEN-END:MVDCACase64 // Insert global post-action code here }//GEN-LINE:MVDCAEnd /** This method initializes UI of the application.//GEN-BEGIN:MVDInitBegin */ private void initialize() {//GEN-END:MVDInitBegin // Insert pre-init code here getDisplay().setCurrent(get_Splash().getSvgCanvas());//GEN-LINE:MVDInitInit // Insert post-init code here }//GEN-LINE:MVDInitEnd /** * This method should return an instance of the display. */ public Display getDisplay() {//GEN-FIRST:MVDGetDisplay return Display.getDisplay(this); }//GEN-LAST:MVDGetDisplay /** * This method should exit the midlet. */ public void exitMIDlet() {//GEN-FIRST:MVDExitMidlet getDisplay().setCurrent(null); destroyApp(true); notifyDestroyed(); }//GEN-LAST:MVDExitMidlet /** This method returns instance for InputForm component and should be called instead of accessing InputForm field directly.//GEN-BEGIN:MVDGetBegin4 * @return Instance for InputForm component */ public Form get_InputForm() { if (InputForm == null) {//GEN-END:MVDGetBegin4 // Insert pre-init code here InputForm = new Form(null, new Item[] {get_textField1()});//GEN-BEGIN:MVDGetInit4 InputForm.addCommand(get_okCommand1()); InputForm.addCommand(get_backCommand1());

P a g e | 108


InputForm.setCommandListener(this);//GEN-END:MVDGetInit4 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd4 return InputForm; }//GEN-END:MVDGetEnd4 /** This method returns instance for WaitScreen1 component and should be called instead of accessing WaitScreen1 field directly.//GEN-BEGIN:MVDGetBegin5 * @return Instance for WaitScreen1 component */ public org.netbeans.microedition.svg.SVGWaitScreen get_WaitScreen1() { if (WaitScreen1 == null) {//GEN-END:MVDGetBegin5 // Insert pre-init code here WaitScreen1 = new org.netbeans.microedition.svg.SVGWaitScreen(get_svgImage1(), getDisplay());//GEN-BEGIN:MVDGetInit5 WaitScreen1.setCommandListener(this); WaitScreen1.setTask(get_simpleCancellableTask1());//GEN-END:MVDGetInit5 // Insert post-init code here WaitScreen1.setFullScreenMode(true); }//GEN-BEGIN:MVDGetEnd5 return WaitScreen1; }//GEN-END:MVDGetEnd5 /** This method returns instance for okCommand1 component and should be called instead of accessing okCommand1 field directly.//GEN-BEGIN:MVDGetBegin8 * @return Instance for okCommand1 component */ public Command get_okCommand1() { if (okCommand1 == null) {//GEN-END:MVDGetBegin8 // Insert pre-init code here okCommand1 = new Command("Go", Command.OK, 1);//GEN-LINE:MVDGetInit8 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd8 return okCommand1; }//GEN-END:MVDGetEnd8 /** This method returns instance for backCommand1 component and should be called instead of accessing backCommand1 field directly.//GEN-BEGIN:MVDGetBegin10 * @return Instance for backCommand1 component */ public Command get_backCommand1() { if (backCommand1 == null) {//GEN-END:MVDGetBegin10 // Insert pre-init code here

P a g e | 109


backCommand1 = new Command("Back", Command.BACK, 1);//GEN-LINE:MVDGetInit10 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd10 return backCommand1; }//GEN-END:MVDGetEnd10 /** This method returns instance for alert1 component and should be called instead of accessing alert1 field directly.//GEN-BEGIN:MVDGetBegin12 * @return Instance for alert1 component */ public Alert get_alert1() { if (alert1 == null) {//GEN-END:MVDGetBegin12 // Insert pre-init code here alert1 = new Alert(null, "Connection Cannot be reached.", null, AlertType.ERROR);//GEN-BEGIN:MVDGetInit12 alert1.setTimeout(-2);//GEN-END:MVDGetInit12 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd12 return alert1; }//GEN-END:MVDGetEnd12 /** This method returns instance for textField1 component and should be called instead of accessing textField1 field directly.//GEN-BEGIN:MVDGetBegin14 * @return Instance for textField1 component */ public TextField get_textField1() { if (textField1 == null) {//GEN-END:MVDGetBegin14 // Insert pre-init code here textField1 = new TextField("Enter Product ID", null, 120, TextField.ANY);//GEN-LINE:MVDGetInit14 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd14 return textField1; }//GEN-END:MVDGetEnd14 /** This method returns instance for backCommand2 component and should be called instead of accessing backCommand2 field directly.//GEN-BEGIN:MVDGetBegin15 * @return Instance for backCommand2 component */ public Command get_backCommand2() { if (backCommand2 == null) {//GEN-END:MVDGetBegin15 // Insert pre-init code here backCommand2 = new Command("Back", Command.BACK, 1);//GEN-LINE:MVDGetInit15 // Insert post-init code here

P a g e | 110


}//GEN-BEGIN:MVDGetEnd15 return backCommand2; }//GEN-END:MVDGetEnd15 /** This method returns instance for svgImage1 component and should be called instead of accessing svgImage1 field directly.//GEN-BEGIN:MVDGetBegin17 * @return Instance for svgImage1 component */ public javax.microedition.m2g.SVGImage get_svgImage1() { if (svgImage1 == null) {//GEN-END:MVDGetBegin17 // Insert pre-init code here try {//GEN-BEGIN:MVDGetInit17 svgImage1 = (javax.microedition.m2g.SVGImage) javax.microedition.m2g.SVGImage.createImage(OLTP.class.getResourceAsStream("/wait5.svg"), null); } catch (java.io.IOException exception) { exception.printStackTrace(); }//GEN-END:MVDGetInit17 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd17 return svgImage1; }//GEN-END:MVDGetEnd17 /** This method returns instance for simpleCancellableTask1 component and should be called instead of accessing simpleCancellableTask1 field directly.//GEN-BEGIN:MVDGetBegin18 * @return Instance for simpleCancellableTask1 component */ public org.netbeans.microedition.util.SimpleCancellableTask get_simpleCancellableTask1() { if (simpleCancellableTask1 == null) {//GEN-END:MVDGetBegin18 // Insert pre-init code here simpleCancellableTask1 = new org.netbeans.microedition.util.SimpleCancellableTask();//GEN-BEGIN:MVDGetInit18 simpleCancellableTask1.setExecutable(new org.netbeans.microedition.util.Executable() { public void execute() throws Exception { getloginname(); } });//GEN-END:MVDGetInit18 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd18 return simpleCancellableTask1; }//GEN-END:MVDGetEnd18 /** This method returns instance for backCommand3 component and should be called instead of accessing backCommand3 field directly.//GEN-BEGIN:MVDGetBegin20 * @return Instance for backCommand3 component

P a g e | 111


*/ public Command get_backCommand3() { if (backCommand3 == null) {//GEN-END:MVDGetBegin20 // Insert pre-init code here backCommand3 = new Command("Back", Command.BACK, 0);//GEN-LINE:MVDGetInit20 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd20 return backCommand3; }//GEN-END:MVDGetEnd20 /** This method returns instance for svgMenu1 component and should be called instead of accessing svgMenu1 field directly.//GEN-BEGIN:MVDGetBegin22 * @return Instance for svgMenu1 component */ public org.netbeans.microedition.svg.SVGMenu get_svgMenu1() { if (svgMenu1 == null) {//GEN-END:MVDGetBegin22 // Insert pre-init code here svgMenu1 = new org.netbeans.microedition.svg.SVGMenu(get_svgImage2(), getDisplay());//GEN-BEGIN:MVDGetInit22 svgMenu1.setCommandListener(this); svgMenu1.addMenuElement("Button_1"); svgMenu1.addMenuElement("Button_2"); svgMenu1.addMenuElement("Button_3");//GEN-END:MVDGetInit22 // Insert post-init code here svgMenu1.setFullScreenMode(true); }//GEN-BEGIN:MVDGetEnd22 return svgMenu1; }//GEN-END:MVDGetEnd22 /** This method returns instance for svgImage2 component and should be called instead of accessing svgImage2 field directly.//GEN-BEGIN:MVDGetBegin30 * @return Instance for svgImage2 component */ public javax.microedition.m2g.SVGImage get_svgImage2() { if (svgImage2 == null) {//GEN-END:MVDGetBegin30 // Insert pre-init code here try {//GEN-BEGIN:MVDGetInit30 svgImage2 = (javax.microedition.m2g.SVGImage) javax.microedition.m2g.SVGImage.createImage(OLTP.class.getResourceAsStream("/menu4.svg"), null); } catch (java.io.IOException exception) { exception.printStackTrace(); }//GEN-END:MVDGetInit30 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd30

P a g e | 112


return svgImage2; }//GEN-END:MVDGetEnd30 /** This method returns instance for okCommand2 component and should be called instead of accessing okCommand2 field directly.//GEN-BEGIN:MVDGetBegin31 * @return Instance for okCommand2 component */ public Command get_okCommand2() { if (okCommand2 == null) {//GEN-END:MVDGetBegin31 // Insert pre-init code here okCommand2 = new Command("Back", Command.OK, 1);//GEN-LINE:MVDGetInit31 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd31 return okCommand2; }//GEN-END:MVDGetEnd31 /** This method returns instance for Splash component and should be called instead of accessing Splash field directly.//GEN-BEGIN:MVDGetBegin33 * @return Instance for Splash component */ public org.netbeans.microedition.svg.SVGSplashScreen get_Splash() { if (Splash == null) {//GEN-END:MVDGetBegin33 // Insert pre-init code here Splash = new org.netbeans.microedition.svg.SVGSplashScreen(get_svgImage3(), getDisplay());//GEN-BEGIN:MVDGetInit33 Splash.setCommandListener(this); Splash.setTimeout(6000);//GEN-END:MVDGetInit33 // Insert post-init code here Splash.setFullScreenMode(true); }//GEN-BEGIN:MVDGetEnd33 return Splash; }//GEN-END:MVDGetEnd33 /** This method returns instance for svgImage3 component and should be called instead of accessing svgImage3 field directly.//GEN-BEGIN:MVDGetBegin40 * @return Instance for svgImage3 component */ public javax.microedition.m2g.SVGImage get_svgImage3() { if (svgImage3 == null) {//GEN-END:MVDGetBegin40 // Insert pre-init code here try {//GEN-BEGIN:MVDGetInit40 svgImage3 = (javax.microedition.m2g.SVGImage) javax.microedition.m2g.SVGImage.createImage(OLTP.class.getResourceAsStream("/SplashFinal.svg"), null); } catch (java.io.IOException exception) { exception.printStackTrace();

P a g e | 113


}//GEN-END:MVDGetInit40 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd40 return svgImage3; }//GEN-END:MVDGetEnd40 /** This method returns instance for showresult component and should be called instead of accessing showresult field directly.//GEN-BEGIN:MVDGetBegin43 * @return Instance for showresult component */ public Form get_showresult() { if (showresult == null) {//GEN-END:MVDGetBegin43 // Insert pre-init code here showresult = new Form(null, new Item[] {get_stringItem1()});//GEN-BEGIN:MVDGetInit43 showresult.addCommand(get_okCommand5()); showresult.setCommandListener(this);//GEN-END:MVDGetInit43 // Insert post-init code here //readStream(); //StringItem si= new StringItem("Credits: "); //showresult.append(si); }//GEN-BEGIN:MVDGetEnd43 return showresult; }//GEN-END:MVDGetEnd43 /** This method returns instance for inputID component and should be called instead of accessing inputID field directly.//GEN-BEGIN:MVDGetBegin47 * @return Instance for inputID component */ public Form get_inputID() { if (inputID == null) {//GEN-END:MVDGetBegin47 // Insert pre-init code here inputID = new Form(null, new Item[] {get_textField2()});//GEN-BEGIN:MVDGetInit47 inputID.addCommand(get_okCommand3()); inputID.setCommandListener(this);//GEN-END:MVDGetInit47 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd47 return inputID; }//GEN-END:MVDGetEnd47 /** This method returns instance for textField2 component and should be called instead of accessing textField2 field directly.//GEN-BEGIN:MVDGetBegin48 * @return Instance for textField2 component

P a g e | 114


*/ public TextField get_textField2() { if (textField2 == null) {//GEN-END:MVDGetBegin48 // Insert pre-init code here textField2 = new TextField("Enter Password:\n", null, 120, TextField.ANY);//GEN-LINE:MVDGetInit48 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd48 return textField2; }//GEN-END:MVDGetEnd48 /** This method returns instance for okCommand3 component and should be called instead of accessing okCommand3 field directly.//GEN-BEGIN:MVDGetBegin49 * @return Instance for okCommand3 component */ public Command get_okCommand3() { if (okCommand3 == null) {//GEN-END:MVDGetBegin49 // Insert pre-init code here okCommand3 = new Command("Ok", Command.OK, 1);//GEN-LINE:MVDGetInit49 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd49 return okCommand3; }//GEN-END:MVDGetEnd49 /** This method returns instance for okCommand4 component and should be called instead of accessing okCommand4 field directly.//GEN-BEGIN:MVDGetBegin55 * @return Instance for okCommand4 component */ public Command get_okCommand4() { if (okCommand4 == null) {//GEN-END:MVDGetBegin55 // Insert pre-init code here okCommand4 = new Command("Ok", Command.OK, 1);//GEN-LINE:MVDGetInit55 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd55 return okCommand4; }//GEN-END:MVDGetEnd55 /** This method returns instance for alert2 component and should be called instead of accessing alert2 field directly.//GEN-BEGIN:MVDGetBegin57 * @return Instance for alert2 component */ public Alert get_alert2() { if (alert2 == null) {//GEN-END:MVDGetBegin57 // Insert pre-init code here

P a g e | 115


alert2 = new Alert(null, "Result saved....", null, AlertType.CONFIRMATION);//GEN-BEGIN:MVDGetInit57 alert2.setTimeout(500);//GEN-END:MVDGetInit57 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd57 return alert2; }//GEN-END:MVDGetEnd57 /** This method returns instance for okCommand5 component and should be called instead of accessing okCommand5 field directly.//GEN-BEGIN:MVDGetBegin58 * @return Instance for okCommand5 component */ public Command get_okCommand5() { if (okCommand5 == null) {//GEN-END:MVDGetBegin58 // Insert pre-init code here okCommand5 = new Command("Back", Command.OK, 1);//GEN-LINE:MVDGetInit58 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd58 return okCommand5; }//GEN-END:MVDGetEnd58 /** This method returns instance for stringItem1 component and should be called instead of accessing stringItem1 field directly.//GEN-BEGIN:MVDGetBegin60 * @return Instance for stringItem1 component */ public StringItem get_stringItem1() { if (stringItem1 == null) {//GEN-END:MVDGetBegin60 // Insert pre-init code here stringItem1 = new StringItem("Credits:", "\nProject Supervisor :\nAli-Al Mamun \n\nProject Co-Supervisor :\nS.M. Faisal\n\n\nProject Member :\n\nS.M. Mashihura Romman\nEnamul Haque\nMd. Humayan Kabir");//GEN-LINE:MVDGetInit60 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd60 return stringItem1; }//GEN-END:MVDGetEnd60 /** This method returns instance for form1 component and should be called instead of accessing form1 field directly.//GEN-BEGIN:MVDGetBegin61 * @return Instance for form1 component */ public Form get_form1() { if (form1 == null) {//GEN-END:MVDGetBegin61 // Insert pre-init code here form1 = new Form(null, new Item[0]);//GEN-BEGIN:MVDGetInit61 form1.addCommand(get_backCommand5()); form1.setCommandListener(this);//GEN-END:MVDGetInit61

P a g e | 116


// Insert post-init code here form1.append(new StringItem("Name :",studentname)); form1.append(new StringItem("GPA :",gpa)); form1.append(new StringItem("CGPA :",cgpa)); }//GEN-BEGIN:MVDGetEnd61 return form1; }//GEN-END:MVDGetEnd61 /** This method returns instance for backCommand4 component and should be called instead of accessing backCommand4 field directly.//GEN-BEGIN:MVDGetBegin62 * @return Instance for backCommand4 component */ public Command get_backCommand4() { if (backCommand4 == null) {//GEN-END:MVDGetBegin62 // Insert pre-init code here backCommand4 = new Command("Back", Command.BACK, 1);//GEN-LINE:MVDGetInit62 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd62 return backCommand4; }//GEN-END:MVDGetEnd62 /** This method returns instance for backCommand5 component and should be called instead of accessing backCommand5 field directly.//GEN-BEGIN:MVDGetBegin63 * @return Instance for backCommand5 component */ public Command get_backCommand5() { if (backCommand5 == null) {//GEN-END:MVDGetBegin63 // Insert pre-init code here backCommand5 = new Command("Back", Command.BACK, 1);//GEN-LINE:MVDGetInit63 // Insert post-init code here }//GEN-BEGIN:MVDGetEnd63 return backCommand5; }//GEN-END:MVDGetEnd63 public void startApp() { } public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void getloginname() throws IOException {

P a g e | 117


StreamConnection conn = null; InputStream in = null; StringBuffer data = new StringBuffer(); String dat,pag; if(dept==1) pag="MCE.HTM"; else if(dept==2) pag="EEE.HTM"; else if(dept==3) pag="ITS.HTM"; else pag="CIT.HTM"; //String URL = "http://iutoic-dhaka.edu/results/"+pag; String URL="http://localhost/results/"+pag; conn = (StreamConnection) Connector.open(URL); in = conn.openInputStream(); int ch,i,j,l=0; studentname=""; gpa=""; cgpa=""; k=1; while ( (ch = in.read()) != -1) { if (ch != '\n') data.append( (char) ch); else { // System.out.println(data.toString()); dat=data.toString(); k=1; l=0; for(i=0;i<dat.length();i++){ if(dat.charAt(i)==name.charAt(0)){ k=0; for(j=i,l=0;l<name.length();j++,l++){ if(dat.charAt(j)!=name.charAt(l)) {k=1; break; } } } else if(dat.charAt(i)=='S'){ if((dat.substring(i,i+11).compareTo("Semester No"))==0) { while(true){ //<td> if( ((ch = in.read()) == -1) ) {k=1; break; } else if (ch == '\n') break; } data = new StringBuffer(); while ( (ch = in.read()) != -1) { if (ch != '\n') data.append( (char) ch); else { dat=data.toString(); sem= dat.substring(dat.indexOf("Arial")+7,dat.indexOf("")).trim(); break; } } break; }

P a g e | 118


} if(k==0) break; //This terminates inner for } if(k==0) { while(true){ //<td> if( ((ch = in.read()) == -1) ) {k=1; break; } else if (ch == '\n') break; } if(k==0){ //name data = new StringBuffer(); while ( (ch = in.read()) != -1) { if (ch != '\n') data.append( (char) ch); else { dat=data.toString(); studentname= dat.substring(dat.indexOf("Arial")+7,dat.indexOf("")).trim(); //System.out.println(studentname); break; } } } //end of inner if(k==0) while(true){ //<td2> if( ((ch = in.read()) == -1) ) {k=1; break; } else if (ch == '\n') break; } if(k==0){ //gpa data = new StringBuffer(); while ( (ch = in.read()) != -1) { if (ch != '\n') data.append( (char) ch); else { dat=data.toString(); gpa= dat.substring(dat.indexOf("")+3,dat.indexOf("")).trim(); gpa=gpa.trim(); //System.out.println(gpa); break; } }

P a g e | 119


} //end of inner if(k==0) while(true){ //<td3> if( ((ch = in.read()) == -1) ) {k=1; break; } else if (ch == '\n') break; } if(k==0){ //cgpa data = new StringBuffer(); while ( (ch = in.read()) != -1) { if (ch != '\n') data.append( (char) ch); else { dat=data.toString(); cgpa= dat.substring(dat.indexOf("")+3,dat.indexOf("")).trim(); cgpa=cgpa.trim(); //System.out.println(cgpa); break; } } } //end of inner if(k==0) break; // This for outer while } //end of outer if(k==0) data = new StringBuffer(); } } if(k==1) studentname="No Match Found"; in.close(); } }

P a g e | 120


Glossary SGA – System Global Area

PGA – Process Global Area

OLTP – Online Transaction Processing

OLAP – Online Analytical processing.

clustering_factor -Oracle provides a column called clustering_factor in the dba_indexes view

that provides information on how the table rows are synchronized with the index. The table rows

are synchronized with the index when the clustering factor is close to the number of data blocks

and the column value is not row-ordered when the clustering_factor approaches the number of

rows in the table.

CBO – Cost Based Optimizer; It is Oracle’s SQL optimizer

ROWID – The unique number assigned to a row by the Oracle server

dba_indexes – Data dictionary view used to store information about indexes

pseudocolumn – a virtual column created to show the result of a query

PCTFREE – Specifies the percentage of space in each data block of the table

PCTUSED – Specifies the minimum percentage of used space that is maintained for each data

block of the table.

Documents

Islamic University of Technologyenamul86.weebly.com/uploads/3/1/3/3/31331981/bsc_thesis.pdf · Oracle release. The following are some generalized examples (acceptable values vary