Creating Database

Environment
SCSP3713
DATABASE ADMINISTRATION
Semester 1 2021/2022
Objectives
• To define the principals in establishing a usable
database environment
• Choosing a DBMS
• DBMS architectures
• DBMS installations
• Upgrading DBMS – version/release
• Standards & procedures – DB, Data Administration, DB
security

2
 Introduction
• One of the primary tasks associated with the job of DBA is the process
of choosing and installing a DBMS. Unfortunately, many business
executives and IT professionals without database management
backgrounds assume that once the DBMS is installed, the bulk of the
work is done.
• The truth is, choosing and installing the DBMS is hardly the most
difficult part of a DBA's job.
• Establishing a usable database environment requires a great deal of skill,
knowledge, and consideration.

3
Defining the Organization's DBMS
Strategy
• The process of choosing a suitable DBMS for enterprise
database management is not as difficult as it used to be.
• Not an uncommon practice if a large company use 2 to 10
DBMS in one time .
• e.g. IMS or IDMS and DB2 on mainframe, Oracle and Informix on
UNIX servers, MS SQL server on Windows NT servers, Sybase, Ingres,
Adabas, DataCom on various platform.

• Why this kind of situation occurs?

• Driven by a business need or new application
• Desire to support the latest & greatest technology
The DBA group should be empowered to make the DBMS
decisions for the organization.

4
 Choosing a DBMS
Primary task of DBA:
• Process of choosing and installing a DBMS
• Establish a usable database environment
• Ensuring availability – anytime access to data
• Data backup
• Upgrading, etc.
• To establish a usable database environment requires a great
deal of skill, knowledge and consideration.
Most of the major DBMS products have similar features, and if the feature
or functionality does not exist today, it probably will within 18 to 24
months. So, exercise caution before deciding to choose a DBMS based
solely on its ability to support a specific feature.

5
 Choosing a DBMS
• When choosing a DBMS, select a product from a
Tier-1 vendor.

Examples of DBMS vendors:

• Tier 1 – largest vendors having the most heavily implemented and
supported product on the markets. E.G. DB2(IBM), Oracle(Oracle), SQL
Server (Microsoft)
• Tier 2 – vendors provide quality DBMS products, but their installed base is
smaller, and the companies are small with fewer resources. E.G. Informix
Dynamic Server (Informix), Adaptive Server Enterprise (Sybase)

6
 Choosing a DBMS
Factors to be considered:
• Operating system support
• Does the DBMS support the OS that you are currently using
or plan on using?
• Type of organization
• Conservative or non-conservative?
• Benchmarks
• Transaction Processing Performance Council (TPC)
• Publishes official database performance benchmarks.
Benchmarks are constantly updated to show new and improved performance
measurements.

7
The Transaction Processing Performance
Council (TPC)
• The Transaction Processing Performance Council (TPC) is an independent, not-for-
profit organization that manages and administers performance benchmark tests. Its
mission is to define transaction processing and database benchmarks to provide the
industry with objective, verifiable performance data. TPC benchmarks measure and
evaluate computer functions and operations.
1. What is TPC?
2. What is the applications?

• A typical TPC transaction includes the database updates for items such as inventory
control (goods), airline reservations (services), or banking (money). TPC benchmarks
measure performance in terms of the number of transactions a given system and
database can perform per unit of time-for example, number of transactions per second.

8
 The Transaction Processing
Performance Council (TPC)
• The TPC defines four benchmarks:
• TPC-C: Planned production workload in a transaction environment
• TPC-H: Ad hoc processing where transactions are not known and
predefined
• TPC-R: Business reporting in a decision report environment
• TPC-W: Transaction processing over the Web

Fact check!
Are these 4 the only benchmarks defined by TPC?
Go to www.tpc.org to find out. Submit the total number of
benchmarks and each of their purpose in e-Learning. The
submission link has been opened.
9
 Choosing a DBMS
• Scalability – Networking with DA etc.
• Does the DBMS support no. of users & database sizes you intend
to implement?
• How are large databases built, supported, and maintained- easily
or with a lot of pain?
• Are there independent users who can confirm the DBMS vendor's
scalability claims?
• Availability of supporting software tools
• Are the supporting tools you require available for the DBMS?
• Technicians
• Is there a sufficient of skilled database professional for the DBMS?

10
 Choosing a DBMS
• Cost of ownership
• Total Cost = license cost for the DBMS + license cost for
any supporting software + cost of DB professionals + cost
of computing resources to operate DBMS
• Release Schedule
• How often the DBMS vendor release a new version?
• Some vendors have rapid release cycle of 12 to 18
months
• Reference customers
• Can the DBMS vendors supply current user reference?
• Do things actually work as advertised?

11
 Convergence of Features and
Functionality in DBMS Software

New functionalities are added to new DBMS releases.

Must plan for and support all features of DBMS
12
DBMS Architectures
• The supporting architecture for the DBMS environment is
very critical to the success of the database applications. 4
levels of DBMS architecture:
1) Enterprise DBMS
• Designed for scalability & high performance. Must be
capable of supporting very large database, large no. of
concurrent users & multiple type of applications.
• DBMS features such as multiprocessing support,
parallel queries and other advanced features.

The enterprise DBMS runs on a large-scale machine,

typically a mainframe or a high-end server running
UNIX, Linux, or Windows NT/2000.
13
DBMS Architectures
2) Departmental DBMS (or workgroup DBMS)
• Supports small-to-medium-sized workgroups within an
organization.
• Typically runs on a UNIX, Linux or Windows NT Server.
• Falling cost of hardware & software enabling a
workgroup environment to scale up to serve the
enterprise.
• Hardware and software upgrades can allow a
departmental DBMS to tackle tasks that previously
could only be performed by an enterprise DBMS.

14
DBMS Architectures

3) Personal DBMS
• Designed for single user, typically on a low-to-
medium powered PC platform.
• Ex. Microsoft Access, Visual dBase, Personal Oracle,
DB2 Everyplace
• Suited for very-small-scale projects and should never
be deployed for multi-user applications.

15
DBMS Architectures
4) Mobile DBMS
• Specialized version of a departmental or enterprise
DBMS.
• Designed for remote users who are not connected to
the network.
• Provide mechanisms for synchronizing remote
database changes to a centralized departmental or
enterprise database server.

Must choose DBMS that meet specific data processing needs

Choose one to fit all may not be appropriate
If need different solutions to different levels, favor
solution from same vendor
16
 DBMS Clustering
• Clustering is the use of multiple “ independent”
computing system working together as a single, highly
available system.
• To enhance availability and scalability
• 2 predominant architectures:
• Shared Disk
• Shared nothing

A modern DBMS offers clustering support to enhance

availability and scalability.

17
DBMS Clustering
Give scenario on how to use shared
nothing and shared-disk.
1. Shared Nothing - Scalability for the organization
- Each system has its own private resources (memory,
disks, etc)
- Clustered processors communicate by passing messages
through a network.
- Requests from client are automatically routed to the
system that owns the resource.
- The main advantage of shared-nothing clustering is
scalability.
2. Shared-disk
- All connected systems share the same disk devices
- Each processor still has its own private memory, but all
the processors can directly address all disks.

18
DBMS Clustering
Shared-nothing architecture

19
DBMS Clustering
Shared-disk architecture

20
Give scenario shared disk and shared nothing in business process.

Shared Disk vs Shared Nothing

SHARED DISK SHARED NOTHING
Quick adaptability to changing workload Can exploit simple and cheaper hardware

High Availability Almost unlimited scalability

Perform best in heavy read environment Works well in high volumes, read write
environment.

Data is not partitioned Data is strictly partitioned across the cluster

The nodes share memory as well as storage Nodes do not share memory or storage

Disks have active nodes which are shared in Disks have individual nodes which cannot be
case of failure shared

The hardware in shared disk is The hardware is cheaper compared to

comparatively expensive shared disk architecture

It has dynamic load balancing It has fixed load balancing

21
DBMS Proliferation
• A proliferation of different DBMS products can be
difficult to support.
• DBMS Proliferation – more than 1 operational DBMS.
Effects – Difficult to support
Create confusion
• Rule of thumb: Create a policy that must be followed
before a new DBMS can be brought into the
organization.

22
Hardware Issues

• Factor hardware platform and operating system

constraints into the DBMS selection criteria.
• The hardware and operating system on which the
DBMS will run will greatly impact the reliability,
availability, and scalability (RAS) of the database
environment.
• Other issues such as cost, experience,
manageability, and the needs of the applications to
be developed must be considered.

23
 Installing the DBMS
• Installing a DBMS is not as simple as popping a CD into a drive
and letting the software install itself.
• You will need to understand the DBMS requirements and
prepare the environment for the new DBMS.
What are the pre-requisite of Oracle SE and
Factors to be considered: compare to your own device specification?
• DBMS Installation Basics Oracle SE requires 10GB
• Understand the prerequisites – installation manual contain
a list of the operating requirements that must be met for
the DBMS to function properly.
• Hardware Requirements
• Match your DBMS to requirements of the hardware.
• Every DBMS has basic CPU requirement i.e. CPU version &
processor speed.
24
Installing the DBMS Oracle APEX is the world's most popular
enterprise low-code application platform that
enables you to build scalable, secure enterprise
apps, with world-class features. These apps can be
• Storage Requirements deployed anywhere - cloud or on-premises

• Disk storage to store data as well as other stuff such as the indexes,
system catalog/data dictionary, log files, startup or control files and
error processing file.
• Tapes required for database backup.
• Factor in every storage requirement of the DBMS and reserve the
appropriate storage for its use.
• Memory Requirements Oracle SE – 2GB
• DBMS requires significant amount of memory to avoid I/O. Reading
data from storage device is always more expensive and slower.
• Besides data, memory is also used to store program structures (SQL
stmt, db authorization) used by programs as they are executed.

Read the installation guide from

cover to cover.
25
Memory Requirements
Traffic controller 1) Program 1 requests a row of data

DBMS Program
1

4) And to the
program
2) DBMS finds the requested
data
5) A subsequent request is made
6) DBMS finds the data in the for the same row of data
buffer pool

Program
2
Buffer
Database Pool

3) Data is moved to 7) And moves it to the program

the buffer pool without reading it from disk

No need to read the same data from disk

Ensure that the DBMS has a more than adequate supply of
memory at its disposal.
26
 Installing the DBMS
• Configuring the DBMS
• Configure the system parameters to control the way the DBMS
functions and the resources made available to it.
• E.g. Control of DBA authorization, memory used for data &
program and no. of active database logs.
• Incorrect configuration can cause performance problems, data
integrity problems or even DBMS failure.
• Each DBMS also provides a method to change the system
parameters once the DBMS is operational.
• Connection to Other System Software
• Each piece of supporting infrastructure software will have different
requirements for interfacing with the DBMS. (E.g. networks, web
servers, application servers. )

27
 Installing the DBMS

• Installation Verification
• After installation run tests to verify that the DBMS has
been properly installed and configured.
• Use standard interface to create a set of SQL code that
comprises SELECT, INSERT, UPDATE and DELETE
statements issued against a sample database.
• DBMS Environments
• Create multiple DBMS environments to support testing,
quality assurance, integration and production work.
Testing, backup and for security
purposes.

28
Installing DBMS Versions &
Releases
• Version  a new version DBMS comes with major
changes and new features.
Ex. Moving from Oracle7 to Oracle8 was a major change – a version
change.

• Release  typically minor, with fewer changes & not

as many new features
Ex. Oracle8.2 is a release – consisting of a smaller number of changes.

What is the diff between version and release?

29
Installing DBMS Versions &
Releases
Benefits of moving towards a new version/release:
• New features and functionality.
• Application that require a specific DBMS version or
release to enable specific functionality within the
application.
• Enhanced performance & availability features that can
optimized existing application.
• Better support from DBMS vendors for new
version/release.

30
 Installing DBMS Versions &
Releases
• Associated risks of upgrading to new version/ release:
• Disruption to business operations.
• Other disruptions: previously supported features were
removed from new version/release causing application
errors.
• Cost upgrade.
• Changes need to be done to take advantage of new
improvements.
• Supporting software products may lack immediate support
for the new version/release.

31
Installing DBMS Versions &
Releases
• Factors to be considered for an affective DBMS
version/release upgrade strategy:
• Features and Complexity
• New functionalities comes with complexity in supporting &
administering the new features.
• Complexity of the DBMS Environment
• The greater the no. of database servers, applications and users the
greater the complexity.

32
 Installing DBMS Versions &
Releases
• Reputation of the DBMS Vendors
• DBMS vendors have different reputations for technical
support, fixing problems and responding to problems.
• Support Policies of the DBMS
• As new version/release is introduced, DBMS vendors
will retire the older release and no longer support
them.
• Organization Style
• Every organization displays characteristics that reveal
its style when it comes to adopting new products &
technologies.
33
 Installing DBMS Versions &
Releases
• DBA Staff Skill Set
• The risks of an upgrade increases as the skills of the DBA
staff decrease.
• Platform Support
• Not all platforms and operating systems are immediately
supported.
• Supporting Software
• Consider the impact of a DBMS upgrade on any supporting
software such as reporting and analysis tool.
• Each of the software vendors have different time-frame for
supporting and exploiting new DBMS upgrade.

34
Installing DBMS Versions &
Releases
• Fallback Planning
• Fallback procedures to return to prior version/release in the
event that the upgrade contains a bug, performance
problems or other problems during migration.
• Migration Verification
• Perform test to verify that the upgrade is working correctly
and performing satisfactorily.
• DBMS Upgrade Strategy
• A well-thought DBMS upgrade strategy helps to prepare
organization to support new DBMS releases with minimum
impact.
35
Database Standards and
Procedures
• Standards  to ensure the consistency and
effectiveness of database environment
E.g. Database naming convention
• Procedures  processes required for handling specific
events
E.g. Disaster Recovery Plan
• Failure to implement database standards &
procedures will result in database environment that is
confusing and difficult to manage.
36
Database Administration
Standards
Database Object Naming Standards
• Create and publish naming standards for all DB objects.
• Should coexist with other IT standards.
• Minimize name changes across environments.
• Do not impose unnecessary restrictions on the names of
objects by end users.
• Table names (and all DB objects) should be descriptive as
possible.
• Standard Abbreviation.
• Avoid encoding table names to make them shorter.

37
Database Administration
Standards
Other DB Admin. Std.
• Standards that outline how requests are made to
create a new database or changes to existing
databases.
• Standards to establish backup and recovery
procedures.
• Standards that cover database performance
monitoring and tuning.

38
 Data Administration
Standards
• The data administration standard should include the
following items:
• A clear statement of the organization’s overall policy with
regard to data.
• Guidelines for establishing data ownership and
stewardship.
• Rules for data creation, data ownership and data
stewardship.
• Metadata management policy

39
 Data Administration Standards
• Conceptual and logical data modeling guidelines.
• Organization’s goal with regard to creating an
enterprise data model.
• Organizational data sharing policies.
• Guidelines on communication data administration
and DB administration to ensure effective
DBcreation and usage.

40
System Administration
Standards
• DBMS installation and testing procedures
• Upgrade policies and procedures
• Bug fix and maintenance practices
• A checklist of departments to notify for impending
changes
• Interface considerations
• DBMS storage, usage, and monitoring procedures

41
Database Application Development
Standards
• A description of how database access differs from flat file
access
• SQL coding standards
• SQL performance tips and techniques
• Program preparation procedures and guidance on how to
embed SQL in an application program
• Interpretations of SQL STATEs and error codes
• References to other useful programming materials for
teleprocessing monitors, programming languages, and
general application development standards

42
Database Security Standards
• Details on what authority to grant for specific types of situations: For
example, if a program is being migrated to production status, what DBMS
authorization must be granted before the program will operate successfully
in production?
• An definitive list of who can approve what types of database authorization
requests.
• Information on any interfaces being used to connect DBMS security with
operating system security products.
• Policies on the use of the WITH GRANT OPTION clause of the SQL GRANT
statement and how cascading REVOKEs are to be handled.
• Procedures for notifying the requester that database security has been
granted.
• Procedures for removing security from retiring, relocating, and terminated
employees.

43
 Application Migration and
Turnover Procedures
• Unit testing— for developing and testing individual
programs
• Integration testing— for testing how individual
programs interoperate
• User acceptance testing— for end user testing prior
to production status
• Quality assurance— for shaking out program bugs
• Education— for training end users how to work the
application system

44
DBMS Education
• DBMS Overview: a one-day management level class that
covers the basics of DBMS
• Data Modeling and Database Design: a thorough course
covering conceptual, logical, and physical database design
techniques for DAs and DBAs
• Database Administration: in-depth technical classes for
DBAs, SAs, and systems programmers
• Introduction to SQL: an introductory course on the basics of
SQL for every DBMS user
• Advanced SQL: an in-depth course on complex SQL
development for DBAs and programmers
• Database Programming: an in-depth course for application
programmers and systems analysts that teaches students
how to write programs that use the DBMS
45