Download DB2 Concepts and Terminology for Oracle Professionals Antonio Maranhao, Presenter

DB2 Concepts and Terminology for Oracle
Professionals
Antonio Maranhao, Presenter
Slide 1
Welcome to the IBM® DB2® Webcast Series for Oracle Professionals. This is a series
of Webcasts specially targeted for the Oracle professionals out there. And each one
of these short presentations is going to give you some concepts in DB2, so you can
get up to speed on DB2 very quickly while still leveraging your current Oracle skills.
In this presentation we are going to be covering DB2 basic concepts and terminology
and compare that to Oracle’s. My name is Antonio Maranhao I am a manager at the
IBM Information Management Technology Ecosystem team. I am responsible for the
education and skills for Business Partners and clients.
Slide 2
So in this slide we are going to understand the architectural difference between DB2
and Oracle database servers. The concept, for example, of instance is similar for
both Oracle and DB2. In both cases, an instance is a combination of background
process and shared memory. The instance can be seen as the access point to the
database logical and physical structure. So whenever you want to access the
database, you do it through an instance.
But there is one important difference between DB2 and Oracle. In Oracle, there is a
one-to-one correspondence between database and instance. So these two
components are very closely related. In DB2, there is a clear distinction between
what an instance is and what a database is. For example, both of them have their
own memory structures. So you can see from the slide there are memory structures
concerned only with an instance and that therefore, affect all the databases in that
instance. And there are memory structures that are particular to each database. So
like Oracle, the DB2 database is composed of physical files. And like I said, they also
contain their own memory components, for example, buffer pools and configuration
-- which we actually call database configuration or DB config for short.
So after you install the DB2 product, an instance is created by default with no
databases. For example on the Windows® platform, the default instance is called
“DB2” while in Linux® and UNIX®, the default instance name is called “db2inst1”. If
needed, you can create other instances in the same machine. Although for regular
DB2 environments, you only have one instance and you create several database(s)
inside the single instance.
Slide 3
Let’s move on to the next slide. So now a little bit about how exactly DB2 and Oracle
handle memory. Oracle memory structures have two major components.
1. The System Global Area, also known as Shared Global Area, or SGA that
stores information on memory that’s shared by the various processes in
Oracle. The SGA contains, among other things, the database buffer cache
and the library cache that caches recently used SQL statements.
2. Another component is the Program Global Area - also known as Private
Global Area or PGA - which contains information that is private to a
particular process. The PGA contains among other things, sort space,
variables, areas, personal information that is specifically private to each one
of the processes -- accessing or opening instances.
So this specific example shows an Oracle session running in the server. Several
Oracle sessions can connect to the same Oracle instance. But the Oracle instance is
only able to connect to one Oracle database as we mentioned before. In terms of
Oracle, the databases can be seen as the actual physical files without any processes
that are directly related to them.
The DB2 memory is slightly different. So unlike Oracle’s SGA, you’ve got two distinct
areas. The first one is the instance memory which you can see in the blue square.
This area holds the instance process and threads and several heaps and buffers that
are actually shared by all the databases under that instance.
The second area in purple is the database memory. As I mentioned before, it
contains its own structure such as
• buffer pools that access the cache for the data read from the database
• and, utility heaps for example, that define the amount of memory that can be
used by some of the DB2 utility tools.
And lastly, the DB2 application shared memory, on top. It refers to the memory
allocated when an application connects to the database. So this memory is actually
shared and used by the DB2 agents that do the work requested by all the connected
clients.
Slide 4
Let’s take a closer look over each one of these several components. So if we move to
Slide 4. Here we present some of these components that you saw in the previous
slide. And we put them side-by-side with their counterparts in Oracle, so it is easier
for you to understand what each one of them is actually responsible for. So let’s
take a closer look. The Database Manager, which can also be called an instance, and
the Database Shared Memory play the same role as Oracle’s SGA area.
Oracle’s data buffer cache is the counterpart for DB2 buffer pools. So buffer pools in
DB2 are areas in the main memory that can be allocated by the Database Manager
for the purpose of caching table and index data, as data is read from the disk. And
DB2 can actually create several buffer pools in addition to the default ones created
when the database is actually created - which is a bit different than Oracle. Oracle
has a defined set of this buffer cache. Next, DB2 utility heap is similar to Oracle
large pool which is the amount of the space allocated in memory used by operations
such as backup and restore.
The Oracle data dictionary is similar to the DB2 system catalog. So the catalog in
DB2 contains mapped data, containing the database objects in the form of tables and
views. So you can use the catalog in DB2 to query about the information in the
database that obviously it exists in your environment. Also when needed, every time
-2-
this catalog is used, there is a cache - which is called catalog cache -- whose main
purpose is to cache information to speed up a performance.
Next, DB2 package cache. This one is usually for caching sections for static and
dynamic SQL or XQuery statements on a database. Transaction logs -- those are
files that store all the operations performed on the database regarding data. They
are essential for the recovery purposes. For example in case of power failure the
database server uses the transaction logs to restore the database to a consistent
state. And finally, similar to Oracle’s alert log file, we have in DB2, what we call
db2diag file, which is primarily intended for use by IBM’s support for trouble shooting
purposes.
Slide 5
So moving on to the next slide, now we know a little bit about how DB2 and Oracle
work in terms of the architecture of the server and what components they have in
memory. So let us take a look at the directory structure that is created.
So the location for the database server executable files and the database files
themselves are actually in two separate places on the file system. In this slide we
show the distribution on the Windows platform. You can see on the bottom, all of the
executable files, by default when you install the DB2 product, are stored under
Program Files slash IBM slash SQLIB. Inside this directory you’re going to find
several other directories, for example the BIN directory which contains all the
executables and you will find the DLL folder which contains a set of libraries that you
can use for compilation of runtime clients for the client, and several others.
Besides that, when you create the database, DB2 creates a falling directory structure
by default to start the actual files -- the data for the database. So on the top, you
see a directory called DB2. This is actually the instance name on the Windows
platform. So under the instance directory, you find one directory for each database
partition. A single partition instance, of course, is going to be only one directory
which is called Node0000. And inside the partition directory, now you’re going to
find the database records. So each database is going to have two directories. The
first one stores the table space files. Those files actually store the data, the actual
user data. The second directory that you can see here which is called SQL0001 is
responsible for storing the database configuration file and log files.
Slide 6
Moving to the next slide, on Slide 6, we have pretty much the same distribution in
Linux and UNIX, but the organization of the directories is a bit different than
Windows. On Linux and UNIX, the instance is tightly correlated with the instance
user. So for example the executable files, just like Windows, are located in one
directory. In the case of Linux and UNIX, it is the slash OPT slash IBM slash DB2
slash in this case V9.7 and that obviously is going to depend on the DB2 version
that’s installed.
The actual database files are going to be under the instance owner’s home directory.
So in this case (the default), the user name is DB2inst1 -- so you are going to find
the database files under slash home slash db2inst1. And inside the directory you are
going to find one directory called SQLLIB which is the one that actually contains all
the executables and the libraries, etc. And there is another directory called
-3-
Node0000. So just like Windows that’s the record that’s going to contain all the
database files and actually store the data you have in your database.
Slide 7
Moving to the next slide, so now you have your DB2 product installed and hopefully
you’re going to also have one default instance created. Here are some commands to
get you started and the counterparts in Oracle as well. So for example, to start a
database instance is very simple. You have to log into your database as the instance
owner. For example in the case of Linux, that is DB2inst1 and only that user has the
right, by default, to start and stop the database. So you can use the command
DB2start to start the database and DB2 activate database.
So as we mentioned the instance lives - it can live actually without a database. So
you must first start the instance that actually starts the DB2 server and you can
have several databases in that instance. So to activate the database which means it
brings up to memory all of the buffer pools and heaps, and reserves that memory for
the database activity, you have to issue the DB2 activate database command.
Although this command isn’t really required for you. As long as your instance is
running, if a client tries to connect to your database server, upon the first connection
DB2 will automatically activate the database.
Obviously to stop the instance, we have the command DB2stop with the optional
parameter, Force. In the case that you want to stop the DB2 server and drop all the
connections, you can use this option. If you want to drop a single connection or
session that is connected to the database, you can use the command Force
Application and you specify either the session ID or specify the parameter O to kill all
the applications.
Slide 8
Moving to the next slide [to talk] a little bit about how you can configure or set up
the instance and database configuration. So like I mentioned, with Oracle, you can
only configure the instance. And in DB2, you are going to have two sets of
configuration parameters. One is the Database Manager Configuration that is related
to the instance configuration which obviously is going to affect your whole database
server. And each individual database also is going to have their own set of
configuration parameters -- those are called Database Configuration.
To modify or view these parameters, DB2 doesn’t allow you to go directly to a file
and edit those, as you can do in Oracle for example. To access those configurations,
you are going to use two sets of commands. One is the update DBM configuration for
the instance configuration or the update database configuration for the database
configuration. Similarly you have the GET DBM config or GET DB config to list all the
current values.
Besides those configuration parameters for both database and instance, DB2 also
has a set of register variables which are mainly used to set up platform-specific
parameters. Those can be set using the DB2set command. Just specify the name of
the variable you want to change, equals, and then the new value you want to assign.
They are similar to Oracle’s environment variables. One note here: do not mistake
-4-
this DB2 register variables with Window’s register variables. They are completely
independent -- they only affect the DB2 environment.
Slide 9
Moving to Slide 9, here we try to give a brief comparison between how both DB2 and
Oracle handle storage and obviously each have their own terminology, but most of
them are actually very similar as you can see in the slide.
So the database is obviously the first object in the hierarchy. And it is defined as a
collection of objects. And each one of these objects is stored in table space. A table
space is nothing more than a logical organization of physical elements which can be
files where the data of the tables are stored. So table space in DB2 consists of one
or more containers. A container can be a directory, a device or file. And a single
table space can have several containers. Each object, which is similar to an Oracle
segment, is stored in one or more containers. Containers which are similar to an
Oracle data file, are defined as a collection for extent. So the concepts of
incorporating system blocks and data blocks are the same for both databases.
Finally the smallest storage unit in DB2 is called data page, which is exactly what
Oracle calls Oracle data blocks.
Slide 10
Moving to the next slide, slide 10, now that you know all of the components that
form the storage model for both DB2 and Oracle, let’s go a little deeper in what kind
of table spaces you can find in DB2. DB2 has two main types of table spaces, which
are called SMS or System Management Table Spaces, and DMS which are Database
Management Spaces.
The SMS table space is managed by the operating system. So when DB2 needs to
write data to those table spaces, it relies on the underlying IO calls from the OS.
The advantage of this is that the containers can grow and shrink as needed, so it
doesn’t need too much effort from the DBA perspective to administer the space
required for those table spaces.
DMS, on the other hand, is a named space. If you do specify those table spaces,
which is recommended, they provide you the best performance for your database,
and they are managed by the DB2 database server in the sense that DB2 bypasses
the IO calls from the operating system. So if you create this table space, for example
, and you issue a SQL create table space and specify a size of 100 megabytes, then
DB2 allocates and reserves 100 megabytes on the disk space for that purpose. And
that space cannot be touched by the OS. And DB2 actually decides exactly in which
point of the file to store the data. So once you choose a DMS table space, you still
have, three choices of table spaces.
1. One is the regular table space
2. Another is a large table space. Basically the only difference [from a regular
table space] is that the large table space can store large objects like LOBs
and CLOBs (besides the regular data packs like integers and VARCHARs).
Also, a table in a large table space can be larger than the table in a regular
table space because the role identifiers actually have more reserved space in
this kind of table space.
3. Finally there is something called temporary table space which is obviously
used to store temporary data. It can actually be defined in two parts. One is
the system temporary table space which stores temporary data that is
-5-
required during SQL operations such as sorting or reorganizing tables,
creating index, joining tables -- in summary, any kind of operation done by
the actual DB2 system and actually requires extra space. And there is
another set of temporary space, which is called user temporary table space.
This one is used to store temporary data created by the user or program
created by the user. For example, when you need to store the CLAD global
temporary tables.
So whenever you create a database in DB2, if you use all the defaults, you are going
to find three table spaces defined in your database.
1. Number 1 is SYSCAT space. This is the table space reserved by DB2 to store
the method data of the system catalog.
2. USERSPACE1 is a default table space to store the user data
3. TEMPSPACE1 which is the default to store system temporary data.
So right after you create the database, you’ll have everything that you need to start
using your database and storing data. Note though that you do not have a default
table space for user temporary data. So if you use some programs or have any
procedures that make use of temporary tables, you will need to explicitly create a
user temporary table space.
Slide 11
Next slide 11, after you create the database, you can create all the objects inside it
-- like for example, tables, views, indexes. When you want to refer to those objects,
you need to specify their names. There’s a little bit of difference between how Oracle
and DB2 handle that. You can see from the syntax in the slides, Oracle allows you to
specify the AT DB optional part of the object name. In DB2, this is not necessary
because to access any object, you first need to be connected to a specific database.
Another difference is that the schema names in DB2 don’t need to necessarily match
the user ID that you connected to. Although if you don’t explicitly specify the schema
name, DB2 will assume that your user ID is the schema name that you are referring
to. When you create any other objects in DB2 and Oracle, they both behave the
same and with most of them in DB2, in particular, you can use most size standard
SQL to create and manipulate all of these objects.
Slide 12
Moving to the next slide -- database security. So let’s take a quick look how DB2
handles database [security]. So one of the first mechanisms that any database
server provides is authentication, which is the process by which the system verifies a
user’s identity. Like Oracle, DB2 user authentication is completed by a security
facility outside the DB2 database system. The default in DB2 is to use the underlying
operating system authentication. That is when a client tries to connect to DB2, DB2
will ask the OS to authenticate the provided user ID and password. And optionally,
you can configure DB2 to use LDAP or single sign on as authentication method.
So that is probably the first thing Oracle DBAs should be aware of. DB2 does not
store any user/password information inside the database. Everything is handled by a
third party. As I mentioned, by default, it is the operating system authentication
mechanism but you can configure other types of mechanisms, like LDAP and single
sign on.
-6-
And once authentication is complete, Database Manager determines if the user is
allowed to access the requested data and to perform the operations that the program
is trying to. This process is called authorization. There are two types of authorization
in DB2. One is called privileged and the other is authority. Privileged is the regular
SQL privilege that can be granted or revoked using the grant and revoke SQL
statement. And authorities in DB2 are similar to Oracle rules -- they allow users or a
group of users, special administration rights in the DB2 system. Some of these
authorities are system administrator or security administrator for example. If you are
assigned system administration authority for example, you have the right to stop
and start the DB2 instance. If you are assigned security administration, you gain the
right to actually define the whole security policy for a specific database.
Regarding data encryption, if you want to encrypt the data in transit that is
exchanged between client and the DB2 server, you have two options. Number 1 is
setting the authentication manager to data encrypt. This authentication manager
tells the database server that it will only accept connections from clients who actually
can send encrypted data to the server. This is so if someone is trying to invade your
network, they cannot see the user ID and password being traffic-gated in the
network layer. Another option to encrypt the data, is to use DB2’s support for SSL
aka Secure Sockets Layer.
Slide 13
Moving on to the next slide, slide 13. In DB2 9.7 we introduced the Oracle database
compatibility features which is a group of improvements and functions that actually
facilitate moving Oracle applications to DB2. And this is because these features
reduce the syntax and semantic gap between Oracle and DB2. For example, DB2 9.7
supports native compilation of PL/SQL statements which are the native syntax from
Oracle. And it also accepts, for example, Oracle’s specific data types such as
VARCHAR2 and NUMBER. Other things like we have improved concurrency control …
we have a new isolation level called currently committed that provides exactly the
same behavior as Oracle. If you enable the compatibility features, DB2 can create a
set of views that mimic Oracle’s data dictionary. So you don’t need to map your
queries from Oracle’s data dictionary to DB2’s system catalog. You can use this
specific set of views in DB2, without any modification on the application.
So besides being very easy to move applications from Oracle to DB2, the Oracle
professional doesn’t need to learn a new syntax to start using DB2. You can just
simply open DB2’s CLP Plus tool, which is the counterpart for Oracle’s SQL*Plus. It is
basically a command line tool that provides the same set of commands as Oracle’s
SQL*Plus.
And then you can just type the commands you already know or create functions and
procedures using PL/SQL syntax. DB2 just compiles everything and executes the
code natively. It is important to note that this functionality is imbedded inside the
DB2 engine. So there is no kind of emulation which obviously would impact
performance. Everything that is compiled using PL/SQL, works exactly the same way
as if you were using the native SQL/PL DB2 syntax. Both of them are compiled to the
exact same object code and then run natively by the DB2 engine.
-7-
Slide 14
Next slide, so these were the topics that I tried to cover in this presentation. There
are obviously several topics that we can talk about when it comes to database
servers, but hopefully this will give you a quick understanding of the difference
between Oracle and DB2, and how the internal components of both the database
servers actually work.
In this Webcast series, you are going to find other topics as listed in the slide. And
also note that we do offer a special workshop called IBM DB2 Workshop for Oracle
Professionals which is a 2-day technical hands-on workshop. And it’s offered at no
charge for Oracle professionals. In this workshop, we offer much deeper coverage of
all the concepts that I talked about during this Webcast. And you also have the
opportunity to take the free certification and become certified right away in DB2.
You can follow the link here at www.ibm.com/db2workshop to see the agenda and
the upcoming events. If there is not an event scheduled for your city, you can also
sign up to be notified about upcoming events.
Slide 15
Finally the next slide. I’d like to thank everyone for listening to the Webcast and if
you want to get more details on how DB2 works and the differences between Oracle
and DB2, you can use the resources listed in this space. For example, we do provide
the DB2 e-kits, specifically for database professionals with a lot of information from
basic to advanced on how DB2 works.
There is an amazing article at developerWorks® called Leverage Oracle 11g skills to
learn DB2 9.7 which goes into much deeper detail about the topics I mentioned here.
And, [there are] several other resources like free Redbooks about how to convert
applications from Oracle to DB2. And, if you really want to get hands-on, you can
obviously download DB2 -- free DB2 software. You can download DB2 Express-C
which you can use for free. Or if you want to use all the advanced features, you also
can download the trial version of our Enterprise edition of DB2, which has all the
more advanced features like compression, partitioning, and you can give it a try for
up to 90 days.
Thank you everyone.
-8-
© Copyright IBM Corporation 2011.
IBM Software Group
Route 100
Somers NY 10589
U.S.A.
Produced in the United States of America
May, 2011
All Rights Reserved.
IBM, the IBM logo, ibm.com, and DB2 are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries or both. If these or other IBM trademarked
terms are marked with a trademark symbol (® or ™), these symbols indicate U.S. registered or common
law trademarks owned by IBM at the time this information was published. Such trademarks may also be
registered or common law trademarks in other countries. A current list of IBM trademarks is available on
the web at “Copyright and trademark information” at ibm.com/legal/copytrade.shtml
Oracle is a registered trademark of Oracle Corporation in the United States, other countries or both.
Linux is a registered trademark of Linus Torvalds in the United States, other countries or both.
UNIX is a registered trademark of The Open Group in the United States, other countries or both.
Windows is a trademark of Microsoft Corporation in the United States, other countries or both.
Other company, product or service names may be trademarks or service marks of others.
-9-