Shulou(Shulou.com)06/01 Report--

Anton Els, V í t pinka,Franck Pachot

Oracle Database 12c Release 2 Multitenant

EISBN 978-1-25-983609-1

Copyright ©2017 by McGraw-Hill Education.

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any

Means, electronic or mechanical, including without limitation photocopying, recording, taping, or any

Database, information or retrieval system, without the prior written permission of the publisher.

This authorized Chinese translation edition is jointly published by McGraw-Hill Education and Tsinghua

University Press Limited. This edition is authorized for sale in the People's Republic of China only

Excluding Hong Kong, Macao SAR and Taiwan.

Translation copyright ©2018 by McGraw-Hill Education and Tsinghua University Press Limited.

copyright. No part of this publication may be reproduced or disseminated in any way or by any means without the prior written permission of the publisher

Including but not limited to copying, recording, recording, or through any database, information or searchable system.

This authorized translation of simplified Chinese characters is jointly published by McGraw-Hill (Asia) Education Publishing Company and Tsinghua University Press Co., Ltd.

This version is authorized to be sold in Chinese mainland region only and cannot be sold to Hong Kong, Macao Special Administrative region and Taiwan of China.

Copyright ©2018 is owned by McGraw-Hill (Asia) Education Publishing Co., Ltd. and Tsinghua University Press Co., Ltd.

Registration number of copyright contract of Beijing Municipal copyright Administration: 01-2017-3077

The cover of this book is affixed with McGraw-Hill Education's anti-counterfeiting label, and those without labels are not allowed to sell it.

Copyright is reserved and infringement must be investigated. Infringement report Tel: 010-62782989 13701121933

Cataloging in publication (CIP) data

Oracle Database 12 R2 authoritative Guide to Multi-tenancy / (New Zealand) Anton Ayers (Anton Els), (Czech) Witts

Prink (V í t í pinka), (Switzerland) Frank Pachet (Franck Pachot); translated by Shi Yuedong. -Beijing: Tsinghua University

Publishing House, 2018

Original title: Oracle Database 12 Release 2 Multitenant

ISBN 978-7-302-50251-7

Ⅰ. ① O... Ⅱ. ① Ann... ② dimension... ③ Fu... History of ④... Ⅲ. ① Relational Database system-Guide

Ⅳ. ① TP311.138-62

Chinese version Library CIP data Core character (2018) No. 103253

Responsible Editor: Wang Jun and Li Weijie

Cover design: Niu Yanmin

Layout design: create scenic spots

Responsible proofreading: Cao Yang

Responsible printing: Dong Jin

Published by Tsinghua University Press

Network address: http://www.tup.com.cn, http://www.wqbook.com

Address: block A, Xueyan Building, Tsinghua University, Beijing Postal Editor: 100084

General Manager: 010-62770175 Mail purchase: 010-62786544

Contribution and Reader Service: 010-62776969, c-service@tup.tsinghua.edu.cn

Quality feedback: 010-62772015, zhiliang@tup.tsinghua.edu.cn

Printer: Beijing Xinfenghua Color Printing Co., Ltd.

Bookbinder: Sanhe Liyuan binding Factory

Sales: national Xinhua Bookstore

Open copy: 170mm x 240mm sheet: 23 words: 4511000 words

Edition: June 2018 1st edition printing time: June 2018 1st printing

Number of prints: 1: 3500

Fixed price: 79.80 yuan

Product number: 074808-01

I had planned to take advantage of the rest time to translate the 400-page book before the Lunar New year.

Who has ever wanted to be involved in everything? after a busy meal, it will be New year's Eve. So this book can only be in the spring.

It's done after the festival.

Strictly speaking, the book was translated in September last year, and in February 2018, it was another six months.

The time. Looking back on the translation of "Cloud Storage Oracle ASM Core Guide" last year, it was also intermittent.

It took another five months to finish. When I pay attention to it, I realize that translation is really a time-consuming task.

The work of the heart. Usually busy work, can only squeeze out the evening or weekend, or the rest of the time for translation.

And many words in the book have to be considered and pondered over and over again in order to accurately express the meaning of the original text.

Come on. To write your own book is to sort out the knowledge you know, while translation is to study what you can't.

West. Therefore, to some extent, the process of translation is essentially the learning of new technologies and knowledge.

The process.

Multi-tenancy, along with IMO, is called two key features of Oracle Database 12c. This time there are

Fortunately, it is also a pleasure to get the right to translate this book from Tsinghua University Press. Only a book related to IMO was translated by the original factory of Oracle. If both books are translated by the author

Plus the ASM in front of it, isn't it perfect? unfortunately.

Multi-tenant technology is a new feature introduced by Oracle since version 12.1. It's fundamentally

It has changed the architecture of Oracle database for a long time, and it is also the era of Oracle in this surging era.

Fully cater to the specific performance of cloud computing. For traditional Oracle DBA, proficient in 12c version

There is no doubt about this new feature in.

The back cover of the book indicates that the book was written by a team of OCM experts and, in fact, flipped through the book.

Readers of the preface will know that the three authors of this book are all Oracle ACE. Not only do they have many

Years of practical experience has also been shared in major technology communities and related conferences. Written by such a person

Write a book, the actual combat of the content of this book can be imagined. This book starts with the basic concept of multi-tenancy and covers CDB

With PDB creation and management, network and services, security, backup and recovery, data movement and multi-tenancy

, especially the in-depth discussion of many technologies in multi-tenant environments and in previous versions

The difference is that this is obviously a very valuable content for our practical work.

Of course, I still want to thank all those who helped me in the process of publishing this book.

Scholars, it is your constant care and help that the author is able to write continuously and move forward day by day.

Because the author has little talent and learning, there are bound to be some mistakes and deficiencies in the translation of this book.

When you see this, please do not hesitate to give us your advice.

February 22, 2018

Anton Els is an Oracle ACE and is currently a senior vice president of Dbvisit Software Co., Ltd.

Anton has more than 15 years of working experience in database technology, and is good at Oracle database and preparation.

Backup and recovery, database repository, Oracle Linux, virtualization and docker technology. Anton is independent.

An active member of the Oracle user group (Independent Oracle Users Group, IOUG) and a new

Vice Chairman of New Zealand Oracle user Group (New Zealand Oracle Users Group, NZOUG). Anton

Have Oracle Database 11g OCM certificates and all OCP certificates from 8i to 12c. With

He also holds the OCE certificate and Red Hat of Oracle Database 11g RAC and GI administrator direction.

5 RHSA certificate and SCSA certificate for Oracle Solaris 10. Anton often attends relevant industries

And user group meetings, such as some industry cooperation meetings, Oracle OpenWorld data held in Japan

Library Technology Conference, NZOUG, and Oracle Technology Network (OTN) year in Asia-Pacific and Latin America

I'll wait. You can visit his Twitter (@ aelsnz) or blog (www.oraclekiwi.co.nz).

V í t é pinka is an Oracle ACE-An and is currently the chief architecture of Dbvisit Software Co., Ltd.

Division. V í t also has more than 15 years of working experience in the field of database technology, mainly good at Oracle database

Technical. V í t is also an active member of IOUG and regularly attends activities related to Oracle OpenWorld, industry partnership conferences, UKOUG, DOAG and NZOUG. V í t owns Oracle Database 10g,

OCM certificate of 11g and 12c, OCP certificate from 9i to 12c, Oracle Database 10g

RAC administrator expert certification, as well as LPIC-2 Linux network professional certification. You can access his

Twitter (@ vitspinka) or blog (http://vitspinka.blogspot.com)).

Franck Pachot is a director of Oracle ACE and is currently the chief executive of dbi Services (Switzerland)

Consultants, training experts and Oracle technical leaders. Franck has more than one in the field of Oracle technology

20 years working experience. Franck also often participates in Oracle OpenWorld, IOUG cooperation meetings,

Activities of DOAG, SOUG and UKOUG. He is an active member of SOUG and DOAG.

He was an honorary member of the OraWorld team at that time. Franck owns Oracle Database 11g and 12c

OCM certificate, with all OCP certificates from 8i to 12c, and Oracle Database 12c

OCE certificate for performance management and optimization. In addition, he owns Oracle Exadata Database.

Machine 2014 implements certification certificates. You can visit his Twitter (@ franckpachot) or blog

(http://blog.pachot.net).

Deiby G ó mez is the youngest Oracle ACE (23) and ACE director (25) in the world.

He is also the first ACE and ACE director of his home country, Guatemala, and the youngest in Latin America (24

Oracle 11g OCM certificate holder, aged 2015.2). He is the first OCM certificate holder in Guatemala.

The winner, who is also the youngest (26 years old, 2016.4) with the Oracle 12c OCM certificate, is the central government

America's first Oracle 12c OCM, winner of the most recent 2016 Editor of the year Award (Russ

Vegas, Nevada. He regularly speaks at Oracle global technology conferences, including 2013

Oracle Technology Network Latin American Annual meeting, Cooperation Conference (USA) and Oracle to 2016

OpenWorld et al. Deiby was also the first tester of Oracle 12cR2 beta in Guatemala.

Deiby has published a number of technical articles in English, Spanish and Portuguese.

The table is on the Oracle website and DELL's Toad World. In addition, on his blog, he also published

Hundreds of technical articles. He appeared as a distinguished expert in November and December 2014

In Oracle magazine. At the same time, Deiby is also the chairman of the Guatemalan Oracle user group (GOUG) and the technical support director of the Latin American Oracle user group community (LAOUC). He is also a member of the OraWorld team.

Co-sponsor. Currently, Deiby has its own company, NUVOLA,S.A, which provides customers in Latin America

Oracle technical services.

Arup Nanda has worked as a DBA for more than 20 years, and his work experience almost involves Oracle skills.

There are all aspects of technology, from modeling to performance tuning to Exadata. He's already published too much.

About 500 articles, is the co-author of five books, and has delivered more than 300 lectures. Its blog site is arup.

Blogspot.com, who is also a novice technical mentor, is an experienced DBA. He was in 2003,

Won the Oracle DBA Award of the year and the Enterprise architect of the year Award in 2012. So is he.

An ACE director and a member of the Oak Table network.

Mike Donovan joined Dbvisit in 2007, where Mike played a number of roles

Including serving as the leader of the global support team and a pioneer in digital business development. And just recently, he became

Is the CTO of the company. Mike has a passion for new technology, working with customers and partners

Work hard to build a bridge between database technology and cutting-edge technologies such as big data, so as to create business

Value. He likes to accept challenges and tries to explore smarter, lower-cost solutions or alternatives.

Mike has a compound background of technology, art, customer support and software development. He's right.

Oracle database technology is very enthusiastic and has been working for it for more than 10 years. He is also in a number of industries

Delivered speeches at the meeting, including OOW, RMOUG, Japan data Technology Conference and Cooperation Conference, etc.

Mike has worked as a product DBA for many years and has obtained a number of certifications from 9i to 12c.

In the Oracle Database 12cR1 version (12.1), a new option called "multi-tenancy" was introduced.

Since then, the new term "pluggable database" has spread. But this term often means

There is no clear understanding of this feature or its impact. Since the first version of 12c, multi-tenancy has been

Is one of the most significant architectural changes in Oracle databases, and this option has been implemented in database software

It has been implemented on the ground. The multi-tenant option brings a lot of new features, but it also affects Oracle DBA

The way in which daily management is carried out. Since the second version of 12c (12.2), special features are available for the multi-tenant option

Sex has been expanded even more. What is clear now is that the old system architecture has been abandoned.

Multi-tenancy has begun to take root-- not to be ignored.

The arrival of multi-tenancy in 12cR2 requires DBA to adjust their existing way of thinking and day-to-day.

The way it is often managed. Whether you are running a single tenant database or a database that contains a large number of tenants

All need to go through a new learning process. So, instead of simply describing the new thing of multi-tenancy,

What is included? this book is more likely to describe how the work related to DBA has changed.

Transformation, whether it is the core day-to-day maintenance operations, or some related advanced features. This book can be regarded as

Management guide for Oracle Database 12c. In addition, you can learn some practical knowledge about these new features, including syntax changes, as well as best practices. This book is composed of three people with abundant knowledge

Rich DBA experience and relevant certification of DBA writing, and through many skilled auditors

Conduct strict censorship, so that the value of the content can be further enhanced. Only in this way can you take it with you

Insight into all the passion to understand the management of Oracle database.

Part Ⅰ of this book describes the capabilities of multi-tenancy. The key questions include why Oracle cited

Enter this option, and how to imitate other database products, and whether this option can really

For the way we design and deploy applications. Chapter 1 focuses on these issues and explains the multi-tenant architecture.

Chapter 2 discusses the process of creating a container database (CDB) and how to do it correctly. Because

In version 12c, creating a CDB is already the default option, and believe it or not, we do encounter some

People created CDB without knowing anything about CDB. The various characteristics of multi-tenancy are being detailed.

Before describing it in detail, Chapter 3 will provide you with information to decide whether to use CDB or not.

The CDB database, and Chapter 3 also provides a summary of the different available versions and options.

The Ⅱ section will talk about how your daily work will change when you use the multi-tenant feature.

Change. This section begins with Chapter 4, which focuses on the creation and management of PDB and also deals with the number of generals.

According to the content of upgrading the library to version 12c. Chapter 5 will discuss the network and services of the database in detail. Take it.

In Chapter 6, we will focus on another important issue-- security-- we will discuss the isolation of PDB,

The publicity and encryption of users.

The Ⅲ section will discuss significant improvements in backup and replication operations. Of course, mainly in

PDB level. Chapter 7 will examine in detail the areas that every DBA should be sufficiently familiar with--

Backup and recovery-and, if necessary, how to restore the database to a previous state. The first

Chapter 8 discusses how to implement archiving using database flashback technology and how to implement time-based at the PDB level

Recovery from time to time. In the last chapter of this section, Chapter 9 will look at how to insert / pull PDB, as well as

How to clone, transfer or relocate PDB online (online relocation).

In part Ⅳ of this book, you will learn about multi-tenancy at a new level or level. When to many

When integrating PDB, you will have to be aware of the price of resource managers (Resource Manager, RM)

Value. RM will be discussed in Chapter 10. In a multi-tenant environment, RM will be extremely important.

It's what you want. Chapter 11 will focus on how to use DG to protect multi-tenant databases. No. 12

Chapter will discuss the problem of data sharing in CDB. Compared with physical cloning or synchronization technology, cloud-based

The solution requires that the data can be provided in a more flexible way. We will be on the 13th

The chapter discusses the relevant contents of logical replication.

Chapter 1 Overview of Multi-tenancy 3

1.1 History Class: IT Technology

New era 4

1.1.1 the road to multi-tenancy 5

1.1.2 scenario Integration 6

1.1.3 Table Integration 9

1.1.4 Server Integration 9

1.1.5 Virtualization 10

1.1.6 one instance manages multiple

Database 10

1.1.7 Integration Strategy Summary 11

1.2 system Dictionary and Multi-tenant Architecture 11

1.2.1 past: non-CDB 11

1.2.2 Multi-tenant Container 14

1.2.3 Multi-tenant Dictionary 16

1.2.4 use Container 21

1.3What is CDB level

Integration 27 1.4 Summary of this chapter 33

Chapter 2 create Database 35

2.1 create Container Database (CDB) 36

2.1.1 OMF Overview 36

2.1.2 CDB creation options 37

2.2 create a pluggable database

(PDB) 52

2.2.1 create using PDB$SEDD

New PDB 53

2.2.2 create using local cloning

New PDB 56

2.2.3 using SQL Developer

Create PDB 57

2.2.4 create PDB 60 using DBCA

2.2.5 using Cloud Control

Create PDB 61

2.3 use catcon.pl script 62

2.4 Summary of this chapter 64

Chapter 3 single tenant, Multi-tenant, and Application

Container 65

3.1 the multi-tenant architecture is not a

Option 66

3.1.1 discard non-CDB 66

3.1.2 incompatible features 67

3.2 single tenant in Standard Edition 68

3.2.1 data Mobility 68

3.2.2 Safety 69

3.2.3 Integration with SE2 69

3.3 single tenant 70 in Enterprise Edition

3.3.1 Flashback PDB 71

3.3.2 maximum number of PDB 71

3.4 use multi-tenant option 73

3.4.1 Application Container 73

3.4.2 Integration with multi-tenant option 76

3.5 Summary of this chapter 77

Chapter 4 Daily Management 79

4.1 Select the container to use 81

4.2 Managing CDB 83

4.2.1 create database 83

4.2.2 start and shut down the database 83

4.2.3 Delete database 84

4.2.4 modify the entire CDB 84

4.2.5 modify root container 85

4.3Managing PDB 86

4.3.1 create a new PDB 86

4.3.2 turn PDB 86 on and off

4.3.3 View the status of PDB 90

4.3.4 View the operation of PDB

History 90

4.3.5 running on multiple PDB

SQL 90

4.3.6 modify PDB 91

4.3.7 Delete PDB 93

4.4 Patch and upgrade 93

4.4.1 upgrade CDB 94

4.4.2 insert 103

4.4.3 Patch 105

4.5 use CDB level and PDB level

Parameter 106 of

4.5.1 CDB SPFILE 106

4.5.2 PDB SFPILE

Equivalence 106

4.5.3 SCOPE=MEMORY 108

4.5.4 ALTER SYSTEM

RESET 108

4.5.5 ISPDB_ MODIFIABLE 108

4.5.6 CONTAINER=ALL 109

4.5.7 DB_UNQIUE_

NAME 110

4.6 Summary of this chapter 111

Chapter 5 Networks and Services 113

5.1 Oracle Net 114

5.2 Oracle network snooping

5.3 LREG process 115

5.4 Network: multithreading vs.

Multi-tenant 117

5.5 Service name 119

5.5.1 default service and connection to

PDB 119

5.5.2 create Service 122

5.6 create dedicated listeners for PDB

5.7 Summary of this chapter 130

Chapter 6 Security 131

6.1 users, roles and permissions 132

6.1.1 Public users or local users

Users? 132

6.1.2 what is a user? 133

6.1.3 CONTAINER=

CURRENT 134

6.1.4 CONTAINER=

COMMON 135

6.1.5 Local Licensing 138

6.1.6 Public Authorization 139

6.1.7 conflict resolution 140

6.1.8 keep it clear and simple 143

6.1.9 CONTAINER_

DATA 143

6.1.10 role 145

6.1.11 proxy user 145

6.2 Lock profile

(lockdown profile) 147

6.2.1 disable database option 148

6.2.2 disable ALYTER

SYSTEM 148

6.2.3 disable feature 150

6.3 PDB isolation 150

6.3.1 PDB_OS_

CREDENTIALS 150

6.3.2 PATH_PREFIX 151

6.3.3 CREATE_FILE_

DEST 151

6.4 transparent data encryption (TDE) 151

6.4.1 create TDE 152

6.4.2 insertion and cloning with TDE

Operation 157

6.4.3 TDE Summary 157

6.5 Summary of this chapter 157

Chapter 7 backup and restore 161

7.1 back to basics 162

7.1.1 Hot backup and cold backup 162

7.1.2 RMAN: default configuration

7.1.3 RMAN redundant backup 165

7.1.4 SYSBACKUP permissions 166

7.2 CDB backup and PDB backup 166 7.2.1 CDB backup 167

7.2.2 PDB backup 171

7.2.3 Don't forget to file the log! 174

7.3 restore scenario 174

7.3.1 instance recovery 175

7.3.2 restore CDB and

Restore 176

7.3.3 restore PDB and

Restore 178

7.4 some aspects of RMAN optimization

Consider 180

7.5 data recovery guidance 183

7.6 pieces damaged 184

7.7 using Cloud Control for

Backup 184

7.8 Summary of this chapter 186

Chapter 8 flashback and point-in-time

Restore 189

8.1 PDB based on point in time

Restore 190

8.1.1 restore at a specified time

PDB 191

8.1.2 where is UNDO? 193

In 8.1.3 version 12.1

PDBPITR Summary 195

Local in version 12.2 of 8.2

UNDO 196

8.2.1 Database Properties 197

8.2.2 create database 197

8.2.3 modify UNDO tablespace 198

8.2.4 modify UNDO management

Mode 199

8.2.5 shared UNDO or local

UNDO? 200

PDBPITR 201 in 8.3 version 12.2

8.3.1 shared UNDO mode

PDBPITR 201

8.3.2 in local UNDO mode

PDBPITR 202

8.4Flashback PDB 202

8.4.1 Flashback log 203

8.4.2 using local UNDO

Flashback 205

8.4.3 using shared UNDO

Flashback 205

8.4.4 CDB and PDB level

Reduction point 206

8.4.5 Clean reduction Point 209

8.5 resetlogs 210

8.6Flashback and PITR 212

8.6.1 when PITR or

Flashback? 212

8.6.2 impact on repository 212

8.6.3 removal of secondary instances 214

8.7 Summary of this chapter 215

Chapter 9 Mobile data 217

9.1 Anchor PDB file location 218

9.2 insert and pull 218

9.2.1 pull out and insert PDB 219

9.2.2 unplugged ones that remain in the source library

Database 220

9.2.3 whether there is any in the XML file

What? 222

9.2.4 check for insert operation

Compatibility 225

9.2.5 insert 226 like a clone

9.2.6 archived files for PDB 228

9.3 Clone 229

9.3.1 Clone local PDB 229

9.3.2 Clone remote PDB 231

9.4 some considerations of the application container 236

9.5 convert non-CDB database 236

9.5.1 insert non-CDB 237

9.5.2 Clone non-CDB 239

9.6 move PDB to cloud 240

9.7 based on PDB operation

Trigger 241

9.8 full transfer Export / Import 241

9.9 transferable tablespace 244

9.10 Summary of this chapter 245

Chapter 10 Oracle Database Resources

Manager 249

10.1 Resource Manager Basics 250

10.1.1 Resource Manager key

Term 251

10.1.2 Resource Manager's

Demand 253

10.1.3 Resource Manager

Level 253

10.2 CDB Resource Planning254

10.2.1 Resource allocation and use

Limit 254

10.2.2 default and automatic tasks

Instruction 256

10.2.3 create CDB resources

Plan 257

10.3 PDB Resource Planning265

10.3.1 create a PDB resource

Program 266

10.3.2 enable or disable PDB resources

Program 268

10.3.3 remove PDB resources

Plan 269

10.4 use initialization parameters to manage PDB

Memory and iUnix O 269

10.4.1 memory allocation for PDB 269

10.4.2 limit I / O 270 of PDB

10.5 instance cage

(instance caging) 270

10.6 Monitoring Resource Manager 272

10.6.1 View resource plans and resources

Plan instruction 272

10.6.2 Monitoring by Resource Manager

Managed PDB 273

10.7 Summary of this chapter 274

Chapter 11 Data Guard 275

11.1 ADG option 276

11.2 create a physical repository 277

11.2.1 using RMAN for

Copy 277

11.2.2 create using EMCC

Reserve 289

11.3 manage in a multi-tenant environment

Physical repository 292

11.3.1 create a new on the source side

PDB 293

11.3.2 remove PDB from the source side

Delete 294

11.3.3 modify subset 295 11.3.4 EMCC 298

11.4 Depot on the cloud 298

11.5 Summary of this chapter 301

Chapter 12 sharing between PDB

Data 303

12.1 Database links 304

12.2 shared public read-only data 305

12.2.1 transferable tablespace 306

12.2.2 storing snapshots and write-based replications

System (copy on wirte) 307

12.3 Cross-PDB View 308

12.3.1 simple user Table 309

12.3.2 Integrated data 313

12.4 Cross-database replication 327

12.5 Summary of this chapter 327

Chapter 13 logical replication 329

13.1 Oracle log miner

(LogMiner) 331

13.2 expired features 332

13.2.1 Oracle CDC 332

13.2.2 Oracle streaming technology 332

13.2.3 Oracle Advanced replication 332

13.3 OGG (Oracle

GoldenGate) 333

13.3.1 Multi-tenancy in OGG

Support for 333

13.3.2 big data Adapter 343

13.4 Oracle XStream.

13.5 logical repository 346

13.6 other third-party options 347

13.6.1 Dbvisit Replicate 347

13.6.2 Dell SharePlex 347

13.7 this chapter summarizes what 347 multi-tenancy means

Multi-tenancy Overview

In Oracle Database 12c, Oracle introduces a

Major adjustments. Prior to Oracle Database 12c, only one database could be opened per instance. If

If you want to deal with multiple databases, you need to start multiple instances. Because they're all completely isolated.

Structure, even if these databases are installed on the same server. This is related to other types of relationship.

Databases are quite different. Many other databases can use a single instance to manage multiple data.

Library.

After entering Oracle Database 12c, one instance can open multiple pluggable databases

Or PDB (Pluggable DataBase). Oracle calls it the new multi-tenant architecture, and the old schema name has been discarded. Regardless of whether or not the multi-tenant option is used, all future Oracle data

Libraries run on a multi-tenant architecture. With regard to this fact, all DBA cannot be ignored.

1.1History Class: a New era of IT Technology

Before introducing the future architecture, let's briefly review the history of using databases. Like you.

As we can see in figure 1-1, we don't focus on time, but on the database version, going back and forth through it.

Consider the evolution of Oracle database.

Figure 1-1 Integration from IT to Cloud

When the Oracle Database 8i and 9i appear on the market, the use of medium-sized computers in data centers gradually becomes

It's in vogue. We have entered the client / server era since the mainframe era. And the Oracle at that time

The architecture of the database is obviously well suited to this trend. Because the Oracle database uses C #

Language, so it works successfully on a variety of platforms. And, all user management information

Stored in the data dictionary of the database. The Oracle database is obviously ready for the client / server architecture.

Standby, which can use the operating system to listen to the TCP/IP port and store files. In addition, the architecture of the database

It is also extensible on minicomputers, thanks to a feature called parallel servers. Of course, after

It is called RAC (Real Application Cluster).

As the number of servers grows, so does the number of databases. At that time, a company went to

Used to have a lot of physical servers and use DAS (Direct Attached Disks, direct attached storage)

As storage, and on each server, one or two Oracle Database8i or 9i is running

An example.

As the number of databases grows, managing all servers and disks becomes a nightmare.

Yes. In the face of exponential growth of data, internal disks are still used to manage the data.

Capacity planning becomes extremely difficult. At this time, Oracle Database 10g came into being. We need to integrate the storage so that we can store the database files in a storage array.

SAN (Storage Area Network, Storage area Network) allows all servers to share access.

This is storage integration.

With the passage of time, Oracle Database 11g began to debut. A popular idea in the early days

Yes, we use servers, and then there are disks on each server. However, compared to setting up more than one

In terms of server capacity and maintenance, virtualization software provides us with a new possibility:

We can put multiple physical servers together and provide virtual machines on that basis. In the past

In the modern era, we use such methods: application servers, SAN or NAS, and virtual machines.

Now, Oracle Database 12c brings us a new approach. Many have integrated storage

And server organizations have now realized that operating such an architecture is not really their core business.

Instead, they see the IT requirement as a service that should be extensible and flexible. A small company wants to

To use public clouds to provide the IT they need, larger companies plan to build their own private clouds.

In such cases, virtualization can provide IaaS (Infrastructure as a Service, infrastructure)

As a service). However, we also need AaaS (Application as a Service) and

DBaaS (DataBase as a Service, database as a service). For the IT technology ecosystem, this shows

However, it is a very significant change. This is the same as when it evolved from client / server architecture to application server.

The generations are quite similar, both in terms of scalability and importance. Of course, this process did not happen overnight.

Just-- it takes time. However, it can be asserted now that in the next decade, the hybrid model (press

Need supply / cloud) will become more powerful, but will eventually be slowly replaced by the cloud.

As we expect, the new era has different needs. The future of the database will also be integrated with,

Agile development and quick readiness are linked together. For Oracle, some features like this

Sex, in fact, has been in rapid evolution from 9i to 11g. Such as simple data transfer, cloning, to

And reduced instruction configuration (thin provisioning), etc. But there are two core architectural functions in the database: one

This has always been the case with an instance of a database and a database-data dictionary, and the integration has not yet been done.

Get ready. To this end, Oracle Database 12c provides the answer to these two questions: multi-tenancy. Be insured

On the basis of the original portability architecture, Oracle has made design adjustments to its architecture, thus making

Applications can be run on the same database-whether the program is running on a small server or running

Walk on a big cloud.

1.1.1 the road to multi-tenancy

The new era is about the era of integration. Some people will think of it as a centralized system and supplement it.

To manage centrally. But this brings a new challenge: we need more and more agility. Let a number

According to the rapid preparation of the library, it is not an easy task today. But at least, we can't let it become

Worse.

Consider such an example. You are an Oracle DBA. Then a developer comes to your office.

In front of the desk and said she needed a new database. In her mind, she might think that this is a simple requirement that you can do with just a few mouse clicks on an administrative interface. Look

Look at her, stare wide, and then tell her that she needs to fill out a demand application form, which needs to specify storage,

Memory, CPU, and availability. And, you have to explain, such a need needs to be met by a superior.

Guidance approval can take several days or even a week to set up a database. Apparently, this is the place

There are common misunderstandings between developers and operators.

The developer may not have used the Oracle database before, so she had some ideas

Thinks that the database is just a container used to hold her application tables, and this container

It's also a very lightweight thing-- in many other non-Oracle databases, this is actually

Database.

But in Oracle, on the contrary, we have some lightweight containers-- at the logical level.

(scheme), and tablespaces at the physical level (tablespace)-- but for databases, not only

It's just the whole combination of these things. The Oracle database is a collection of scenarios and tablespaces, and then

Coupled with the metadata (data dictionaries) used to manage these contents, and a large number of them are used to implement various

The PL/SQL code for the feature (DBMS package). Each database must have its own instance, and the real

The example consists of a set of background processes and a piece of shared memory. And every database has a corresponding knot.

Constructed to protect the integrity of transactions, such as UNDO table spaces and REDO logs.

Therefore, for these reasons, it is not a trivial matter to provide a new database.

Love. To create a new database, you need to communicate with the system administrator and the storage team because you need

Server and disk resources are required. You don't plan to deploy too many instances on one server, but neither do you

It is very possible to deploy only one database on a single server. Because of these, we usually use

Virtualization technology, and then provide a virtual machine (Virtual Machine, VM) for each instance. That's for sure,

This approach doesn't apply to every application or every environment, from an agile point of view-- because this

In that case, too many virtual machines are needed. In addition, when services have to be allocated for each database

When it comes to devices, storage, and instances, you will eventually find that this is a waste of too many resources.

Before Oracle Database 12c, this scenario was more appropriate for developers.

Is to create a new scheme for it in an existing database. But this method is not always available.

Yes, or it is feasible. Let's explain why.

1.1.2 scenario integration

Before Oracle Database 12c, solutions were available solutions. Every application

You can have your own scheme, or a set of schemes, if you want to separate the table from the stored procedure. These.

The scheme is logically isolated and uses rights management to ensure its security.

Physically, you can also set different tablespaces for each application. Which means that once

The data file is missing and only one application may be offline during the restore. If you want to change the table

The same is true of redistributing space to other file systems. But, in addition, in order to optimize resources,

Using, we share all other resources: instance processes and memory, SYSTEM and SYSAUX tablespaces, data dictionaries, and so on.

The backup strategy and the high availability (High Availability, HA) strategy are also the same. A DBA

Manage a database and then run multiple applications on that database. In the early days of the Oracle database

In this version, the database is designed in this way.

1. Transferable tablespace

In Oracle databases, many operations occur at the tablespace level. Especially the transferable table

The property of space. With this feature, the applied data files can be physically copied to other data.

Library, even if it is copied to a later version of the database. The transportable tablespace

The feature is important enough because it is considered to be the forerunner or ancestor of multi-tenant technology. In 1997, Oracle

The company applied for a patent for transportable tablespace technology, called "pluggable tablespaces for database systems". And now

In fact, the multi-tenant architecture is precisely the foundation of the pluggable database.

In this case, pluggable means that a physical structure (data file) can be plugged directly into a

And make it part of the database. With the feature of transferable tablespaces, you can

Insert the data file for the user tablespace into the database. Then you just need to import the corresponding metadata (number

According to the dictionary entity). In this way, in the new database, the definition of these logical objects is the same as the data file

The physical content in matches.

Of course, in Oracle Database 12c, tablespaces can also be transferred, which is sufficient

simple. If you want to transfer all the user tablespaces, use the "FULL=Y" option. But relevant.

The metadata still needs to be transferred logically. If there are hundreds of tables of metadata that need to be transferred, then this

It may take a long time. This is true even if these tables are empty. For example, if you want to migrate a

PeopleSoft database, which contains 20,000 + tables. Even if these tables are empty, import meta

It will also take a few hours.

As you will see, due to the better performance of multi-tenancy, transfer a pluggable database, real

Internationally, it becomes the transmission of all data files, including data files in SYSTEM and SYSAUX.

Obviously, this contains data dictionaries and possibly even UNDO information. Which means that

Some metadata will also be physically imported. Therefore, compared with the traditional transportable tablespace technology, such

The operation is much faster.

two。 Scheme name conflict

In the real world, it is actually very difficult to achieve solution integration. You may want to put a lot of

Applications are integrated into a database, and even the test environment of the same application wants to be integrated.

At this point, you will be faced with a series of application constraint problems.

What if the scheme owner in the application is hard-coded and cannot be modified? Such as

If we need to set up a telephone list system, and the corresponding scheme in the database is PB, but

Later, we want to integrate multiple environments into the test database, so this is obviously prohibited. The reason is

The name of the scheme has been hard-coded into applications and packages, among other things. If there are consultants from the application provider, we may also be able to better understand these strange scheme names.

But if not, you may have to guess what the names of these schemes meant in the first place.

Of course, if the application is designed under your control, then you can avoid this.

problem. And needless to say, you should never specify the name of the solution in your application.

Hard-coded. You can use a user to connect to the database and then simply use ALTER SESSION

SET CURRENT_SCHEMA statement to set the scheme owner of the current application, thus visiting the

Ask all the people involved. What if there are multiple plans? Then it doesn't count to use multiple scenarios for applications.

It's a bad idea.

For example, you can use code (PL/SQL package) to separate data (tables). This can make the data implementation better.

Isolation and encapsulation of. But even in this case, do not hard-code the scheme name where the table is located into the package

Medium. You can create synonyms for these objects in the same scenario as the package. In this way, it can be used in the

These objects are referenced in the PL/SQL code instead of using the scheme name (because the synonym is the same as the code

In the scenario, and these synonyms are automatically associated with the corresponding object. If the name of the object changes

Just recreate the synonym. These actions can be done easily or automatically.

3. Public synonyms and database links

For the synonyms mentioned above, obviously, we are talking about private synonyms. Do not use the public

Synonym. Because they cover private synonyms throughout the namespace. When an application creates

When a public synonym is used, it cannot be bound to anything else. This is a limitation of solution integration: no

Objects that belong to a specific solution are easily the same as those in other applications, versions or environments

A conflict occurs between the objects of the application.

4. Roles, tablespace names, and directories

An application can define or reference other objects as long as they are public in the database.

Common namespaces are fine-- such as roles, directories, and tablespace names. If an application is not available

If you run in the same environment, these environments can actually be integrated into the same database. All you have to do is hold on

When you run a DDL script, you set different parameters for different environments, so that these databases

Objects can be applied to different environments. If this is not the case, then you want to achieve solution integration.

It will be difficult.

On the other hand, these objects that are not part of a specific scheme will also make the implementation of data movement more

For complexity. For example, when you want to use the data pump (Data Pump) to import a scheme, these objects may

The creation needs to be completed in advance.

5. Cursor sharing

Even if an application is specifically designed for solution integration, everything is integrated

When you go to a database, you may also encounter performance problems. We've dealt with it before.

A database of 3000 scenarios is actually a bunch of data mart: the structure is the same, the data is different.

In addition, it is obvious that the code for the application is the same. The user needs to connect to one of them

Data Mart, and then execute queries that have been defined in the application. That's what it means.

It means that the same query-- even on the SQL text-- will run differently.

On the plan. If you know how cursor sharing in the Oracle database is implemented, you can immediately see

To the problem: a cursor will have thousands of sub-cursors. A parent cursor will be shared by all SQL text

Different child cursors are created when the objects are different. When this code is executed in multiple scenarios

Then the problem arises. SQL parsing requires scanning a fairly long list of child cursor chains, while during scanning

Need to hold latch, which obviously leads to serious cache competition.

In a multi-tenant environment, for integration purposes, the parent cursor is shared, but the child cursor is searched

The cable side needs to make some performance improvements in order to alleviate the above problems.

1.1.3 Table integration

When you want to integrate data from multiple environments, which have the same application

Order and code version, which means that the table to be used will have exactly the same structure, and you can set the

Some things are put in one table. Normally, we add the environment to each primary key value

ID (company, country, market, and other information) to distinguish the data. The advantage of this is that you can do it all at once.

Sex manages everything. For example, when you want to add an index, you can add it for all environments.

For performance and maintenance reasons, the data in the table can be processed based on the environment ID

Physical partitioning and storing different partition data in different tablespaces. However, in doing so, it will be different.

Leaving the level is very low, which in turn affects performance, security, and the availability of the system.

In fact, most applications use designs like this and generally store data

In an environment. In most cases, the ID added to the primary key value tends to have only one value

This is one of the reasons why Oracle introduces index skip scanning. You can use the virtual private database policy

To manage access to these environments. Partition switching technology can be used to physically implement these partitions

Independent management. If you want to find a similar example, you can take a look at RMAN's database

Record): all registered databases have information stored in the same table. However, in storing different rings

When the data in the environment (test, development, and production environment) is stored, or different versions are stored (there are not enough data models)

When the data is the same, such isolation is actually not enough.

1.1.4 Server integration

If you have multiple separate databases, but do not want to configure a server for each database, then

You can integrate these instances into a single server. If you have ever logged in to Oracle's Ask Tom network

Station (astome.oracle.com/), and asked about the recommended configuration of several instances on a server, Tom Kate

The answer is: "We do not recommend deploying multiple instances on a single host-- the host can be virtual

We don't care about machines or physical machines-- but you can think of it this way: a host = an instance. "but in real life, as we can see, there are often multiple running on a database server.

An example. You can install multiple versions of the database (ORACLE_HOME) on a single host, or on a

There are multiple instances running on the host-and many times it has to be. We once saw one.

There are up to 70 instances running on the server.

In this case, there are fewer ways to isolate between instances. Memory, for example, can be accessed.

Set the SGA_MAX_SIZE parameter to physically partition the memory. It can also be in Oracle

PGA_AGGREGATE_LIMIT is used in Database 12c to limit the memory used by processes. Sure

Use the instance cage policy to set the maximum number of processes per instance running on the CPU. In the latest

In Oracle Database 12cR2, you don't need the Enterprise Edition to use the instance cage strategy. We will be in

This topic is discussed in Chapter 3.

However, running a large number of instances on one server is still a problem. For example, when you want to restart the service

Server, you need to start a large number of processes and complete memory allocation. One server downtime, no matter it is calculated.

Both planned and unplanned will affect a large number of applications and consume a lot of resources

To handle multiple SGA and data dictionary tables.

1.1.5 Virtualization

Today, virtualization is a very good way to manage a large number of physical servers

Implement one instance and one server under the premise. You can make excellent isolation settings for the environment, and in the limiting model

Perimeter allocation of CPU, memory, and Iswap O bandwidth. You can even use different networks to isolate the data.

Library. However, even if these servers are virtual machines, they still cannot solve the waste of resources, because

Is to hold multiple OS, Oracle software, memory and data dictionaries. Also, you still have to manage multiple numbers.

Data base-backup and restore, high availability features such as Data Guard, etc. And then, there are still multiple.

OS needs patching and monitoring.

In addition, in a virtualized environment, software licensing is also a nightmare. When the software is installed

Oracle software is licensed according to the number of processors, and Oracle takes these factors into account.

Such as licensing issues related to virtualization technology, and installing and running software on virtual machines, and so on.

Of course, these also rely on the hypervisors provided by the vendor, as well as the versions of these hypervisors.

1.1.6 one instance manages multiple databases

So the question is, how to find a way to achieve such an isolation level: can

At the same time, it meets the two purposes of environmental isolation and resource integration. Obviously, this level of isolation is higher than the scheme isolation.

But it is also lower than the examples and databases that we now know. In other words, we can work in a service.

A single instance is used to manage multiple databases.

In versions of the Oracle database prior to 12c, there was obviously no such feature. But today,

In the multi-tenant architecture, this approach is quite feasible. Now, an integrated database can manage

Manage multiple pluggable databases. In addition, there is a new isolation level, that is, stand-alone database-pluggable database, which provides the phase in the aspects of environment preparation, mobility and system upgrade.

When high agility.

1.1.7 Summary of integration strategy

Table 1-1 briefly summarizes the differences between several optional integration strategies before the advent of multi-tenancy technology.

Something in common.

Table 1-1 Analysis of the advantages and disadvantages of different integration strategies

The integrated strategy advantage and disadvantage table manages all the content as a whole, and the isolation level is limited, and it is not applicable to

The same environment solution can implement instance, data dictionary and HA level.

Conflicts are easy to occur between other shared public objects.

Off-level restricted databases only need to manage one database requires multiple SGA and groups of background processes, also

Need to maintain multiple backups and HA configuration virtualization to provide the best level of isolation that can be achieved

Separation of responsibilities and provision of HA and vMotion

The issue of feature licensing in the aspect, you need to learn new technologies

Need to manage and run multiple hosts

1.2 system Dictionary and Multi-tenant Architecture

In the multi-tenant architecture, the system dictionary is one of the most changing parts. Let's take a look at the past.

How the system dictionary is implemented, and in Oracle Database 12c, it occurs again

What has changed.

1.2.1 past: non-CDB

Both data and metadata are stored in the database. For example, suppose that under the SCOTT scenario there is a

A table EMP. The description of the table-- name, columns contained, data type, etc.-- is also stored.

Stored in the database. These descriptions-- that is, metadata-- are stored in system tables and are

Part of the system dictionary.

1. Dictionaries

Codd's rules (established by E.F.Codd, which proposed a relational model) define the definition of a relational database

Metadata must be represented in the same way as data: you can use SQL to query metadata or numbers

According to. As a database administrator, this is done almost every day. By querying the dictionary view, for example

Such as DBA_TABLES, to get information about objects in the database. Although the rules of Codd are only used for

Express the logical level and provide this information by the dictionary view; but Oracle goes further-- by physically storing this metadata information in relational tables-- for the same type of tables and application tables, which

These are owned by the SYS scheme and stored in the system tablespaces (SYSTEM and SYSAUX).

In fact, when dealing with data and metadata information storage, there is no need to use the actual Oracle dictionary

The name and details are shown in figure 1-2. Table SCOTT.DEPT is used to store user data, and the

Definitions are stored in the dictionary table, that is, SYS.COLUMNS. The dictionary table is used to store information about columns.

And because the dictionary itself is a table, its definition information is stored in the same way.

Figure 1-2 Storage of data and metadata information

Of course, not only the definition information of the table is stored in the system dictionary table. All the way to version 8i, data storage

The physical description information stored (the extent information of the table) is also stored in the dictionary table. But, for the sake of fitness

Tablespaces have become increasingly self-contained in response to pluggable requirements. Therefore, the processor of the data store

Which has changed with the advent of locally managed tablespaces. On the other hand, in every new data

In the library version, a lot of new information will be added to the system dictionary. In the current database version

A large part of the functions of Oracle database software are implemented in PL/SQL packages, and this

Some contents are also stored in the system dictionary.

2. Objects managed by Oracle

As far as Oracle database is concerned, the implementation of its system dictionary is what we discussed earlier:

The dictionary is stored in the database. Each database has its own system dictionary. And when using logic

When the import / export tool (EXP/IMP or data pump) moves the database, you may find that some dictionaries

Objects belong to the system, some user objects belong to the application, and how to distinguish these objects is a very tricky matter. When a database is imported completely (using FULL=Y in IMPDP

Option, which will be discussed in Chapter 8) when you create a new database, you don't want to import dictionary information as well

Because these contents already exist in the target database.

Of course, the objects in the SYS scheme are dictionary objects, and they are ignored by the data pump. But

If someone creates user objects under sys, those objects will be lost, based on the sys object's

Authorization will also be lost. And some system objects can also be found in other places, such as OUTLN,

MDSYS and XDB. In addition, there are many roles in the system, and you can also create your own

The role. It's not that easy to tell them apart.

Fortunately, in version 12c, DBA_OBJECTS, DBA_USERS, and DBA_ROLES

The view contains a tag that indicates which objects are maintained by the database and are created by the database

And does not belong to your application. We can query these Oracle maintained in version 12c

List of scenarios:

In version 12c, this is obviously a very big improvement. It is easy to identify which options

It belongs to your application, and which belongs to the database system. ORACLE_MAINTAINED marker

Columns exist in the DBA_OBJECTS, DBA_USERS, and DBA_ROLES views, so now

You can easily tell which objects are created by the database and which are created by the application

Created.

Note: 12c Oracle EXP/IMP EXU8USR KU_NOEXP_TAB Data Guard LOGSTDBY_SKIP_SUPPORT DEFAULT_PWD$ V$SYSAUX_OCCUPANTS DBA_REGISTRY 3. System metadata and application metadata

We have described the following metadata structures: scenarios, objects, and roles. Let's go a little deeper.

Go deep into the data and take a look. You already know that the definition information of the table is stored in the dictionary table, for example, in figure 1-2

We briefly mentioned the SYS.COLUMN table. However, the dictionary data model is actually very complex.

In fact, object names are stored in SYS.OBJ$, table information is stored in SYS.TAB$, and column

The information is stored in SYS.COL$, and so on. These are tables, and each has its own definition.

Information-- metadata-- is stored in the dictionary table SYS.TAB$. For example, it stores yourself.

Information about the tables created, but also stores information about all dictionary tables.

In SYS.TAB$, there is a row of data used to store its own definition information. You might ask.

How this row is inserted into the table when the table is created (and, of course, when the database is created), because at that time

This form should not exist yet. In ORACLE_HOME, Oracle has a special boot code (off

In this part, it is beyond the scope of this book. But you can check ORACLE_HOME/.

Dcore.bsq file in the rdbms/admin directory. You can also query the BOOTSTRAP$ table to see if it is enabled.

In the dynamic phase, how the database creates these tables in the dictionary buffer. At this point, these basic metadata

Are available immediately, allowing access to the remaining metadata.

All metadata is stored in these tables, but in non-multi-tenant environments there is a problem: the system

Information (information that belongs to the database) is mixed with user information (information that belongs to the application). this

Some metadata is stored in the same table, and all these things are stored in the same container-- number.

According to the library.

This is what is different in the multi-tenant architecture: we can now use multiple containers, from

The system information is separated from the application information.

1.2.2 Multi-tenant container

In a multi-tenant database, the most important structure is the container. A container contains data and metadata.

The difference in multi-tenancy is that a container can contain multiple containers to separate objects, regardless of

Physically or logically. A container database can contain multiple pluggable databases, as well as a

The root container is used to store public objects.

A multi-tenant database is a container database (Container DataBase, CDB). In the original architecture

A database is a single container and can no longer be divided, which is called non-CDB. In version 12c

You can choose whether to create CDB or non-CDB. You can create a CDB, that is, multi-tenant data

Library, by setting ENABLE_PLUGGABLE=true in the instance parameters, and in CREATE

Add the ENBALE PLUGGABLE option to the DATABASE statement to complete (for more details, see

Chapter 2).

This creates a CDB that can contain other containers. These containers can use numbers,

The container is identified by ID or name. A CDB contains at least one root container and one seed container

You can also add your own containers, up to 252 containers in version 12.1 and up to thousands in version 12.2.

1. Pluggable database

The purpose of multi-tenancy is integration. Instead of deploying multiple databases on a single server, we now

All you need to do is create an integrated database, CDB. It can contain multiple pluggable

Database (PDB). And every PDB is a complete database for its users.

It has multiple schemes, common objects, system tablespaces, dictionary views, and so on.

A multi-tenant architecture can be used to integrate on private or public clouds. Can achieve hundreds or even

Integration of thousands of PDB. The aim is to provide fast ready services for multiple PDB, but present

The state of coming out is like a database. According to this design, any connection to a PDB

Users can't tell whether they are connected to a PDB or a separate database.

In addition, all commands used in previous versions are still available. For example, when connecting to a PDB

You can close the PDB by executing shutdown. Of course, it doesn't actually close the instance.

Because this instance also manages other PDB. But for the user, what he sees is the same as shutting down a

Stand-alone databases are no different.

Consider another example. We are connecting to a PDB and we do not have our own UNDO

Tablespace, because it is CDB-level (in version 12.2, we can change this

But you won't see it until Chapter 8). Let's try creating an UNDO tablespace:

There is no mistake here. But the UNDO tablespace is clearly not created. After all, to create a

A 100TB data file is impossible. The statement we submitted is simply ignored. The idea is that

Since a script submitted in a database can create an UNDO tablespace, this syntax

Obviously, it should also be accepted in a PDB. The reason for being accepted is that all are available in non-CDB

What is done must and can be done in PDB. But it was ignored because of UNDO

Tablespaces are CDB-level objects.

In a multi-tenant environment, there are also some new commands available, and all the commands you know are also

Are accepted by PDB. A PDB user can be granted the DBA role so that the user can do the

Everything a DBA can do. And the PDB user will be isolated from other PDB

And will not be able to see CDB-level information. 2. CDB$ROOT

How big is your SYSTEM table space? When the database was first created, it was close to a few GB

It's so big. When it comes to database creation, we don't mean CREATE DATABASE statements here, but

It means running catalog.sql and catproc.sql (of course, in a multi-tenant environment, we don't call it that.

We call them catcdb.sql. The actual running script is the same). A word in an empty database

Classic tables, which will also take up several GB of space, are used to store dictionary structures and system packages, which are all Oracle

Part of the software-- binaries under ORACLE_HOME-- but they are stored procedures

And packages are deployed in the database. If you deploy 50 databases on one server, there are

50 SYSTEM table spaces and store the same content (assuming they have the same version and patch number). If

If you want to integrate hundreds or thousands of databases, as you did with PDB, you may not want to integrate every

A database stores the same content. All public data can be stored in only one container

And let other containers share this content. This is CDB$ROOT: it is the only non-in a CDB

PDB container, which is used to store all common information between PDB.

Basically, CDB$ROOT will store all dictionary tables, dictionary views, and system packages (in dbms_

) and system users (SYS, SYSTEM, etc.)-- and no other content is stored. Not in

User data is stored in CDB$ROOT. If necessary, you can create your own use in all PDB

Hou. You can learn more about public users in Chapter 6.

You can also think of CDB$ROOT as an extension of ORACLE_HOME. It is one of the database software.

Section and stored in the database. It is related to the version of ORACLE_HOME, as long as the version is the same

Then the CDB$ROOT in all CDB is the same. CDB$ROOT in version 12.2.0.1

It's basically the same as your database.

3. PDB$SEED

The purpose of the multi-tenant database CDB is to create multiple PDB. Not only that, but also should be able to be based on

Need to create a PDB simply and quickly. This is also DBaaS (DataBase as a Service, database ready service).

Service) the concern of the structure. How to quickly create a database through DBCA? You can go through a bag

A template containing all the files to create the database. If you can clone a ready-made empty database, then

There is no need to recreate everything (as catalog.sql and catproc.sql do). That's it.

Is PDB$SEED: it is an empty PDB that can be cloned to create another PDB.

It cannot be modified because it is read-only and can only be used as the source of a new PDB.

A CDB contains at least one CDB$ROOT container and one PDB$SEED container. Can't.

Modify them so that you can only use them. Only when upgrading or patching CDB, they

The structure will change.

1.2.3 Multi-tenant Dictionary

One of the purposes of the multi-tenant architecture is to separate the system metadata from the application metadata. System metadata, all common information between PDB, is stored in CDB$ROOT, which is called system.

Object. For example, the definition of the package is stored in the dictionary table SOURCE$, which we can query by

DBA_SOURCE view to get this content. In a non-CDB, the table stores the system package

And the packages you create-- some are owned by SYS, some are owned by application solutions; just let

Let's call it ERP. In a multi-tenant environment, CDB$ROOT contains only system metadata, so in the

In the previous example, this means that these are all SYS packages.

In the PDB we point to the application, we call it PDBERP, and in SOURCE$ we will

Contains only our application's package, that is, ERP's package. Let's look at an example. We use

CDB$ROOT and count the number of rows in SOURCE$. We relate it to DBA_OBJECTS.

To show which objects (system objects) are managed by Oracle:

All lines in SOURCE$ are objects managed by Oracle, that is, system packages.

Now let's take a look at PDB:

The result here is not the system package, but the package created by the application. Of course, in your environment,

The query results may be different. But this example basically shows a multi-tenant ring.

How dictionary information is separated in this context: in non-CDB, metadata is stored in the same dictionary table

But now it is stored in different containers, thus separating the Oracle metadata from the application metadata

Come on. Note that unlike partitions, they are more like different databases for dictionary tables.

1. Dictionary view

You know why we query SOURCE$ instead of DBA_SOURCE, assuming they can mention

For the same result? Check the following:

In CDB$ROOT, this is the same number of rows as the above query. But in PDB:

Here, we see more rows. Actually, we saw it in CDB$ROOT.

These lines. There are two reasons. First of all, we say that what is stored in CDB$ROOT is public information.

So it is clear that this information can also be seen in PDB. Second, we say that when a user connects to a

In PDB, what the user can see in a separate database should also be seen in a PDB

What can I see. In a separate database, DBA_SOURCE-based queries should show

All the content, including the system and the application. But this is not the case when querying SOURCE$

Sample. Of course you don't want that. Only the view records this information, and you would expect to query

These views.

The dictionary view in PDB, which provides information about PDB, as well as information from CDB$ROOT.

It is not a partition or a database link. We will see in the next section that Oracle is such as

How to deal with it.

When you connect to the CDB$ROOT, the DBA_SOURCE view will display only the information in the container.

But the new view that starts with CDB_ displays the contents of all containers, which you will see later in this section

See this in the "5. Dictionary View in Container" section of Section 1.2.4.

Therefore, physically speaking, the dictionary information is separate. Each container stores its own use

The metadata of the user object, and the root container stores the common part-- mainly the system metadata. Logically

Say, from these views, we can see all the information, because we can in non-CDB

As you can see, PDB should obviously be compatible with this.

two。 Metadata link

Oracle introduces a new way to link objects in one container to other containers: meta

Data link. Each container has all the dictionary objects stored in OBJ$ and can be accessed through the

DBA_OBJECTS access), such as the system package name used in the previous example. But more right.

Like definition information (such as the code text of a package) is not stored in all containers, but only in

In CDB$ROOT. In OBJ$, each container has an identity, which can be done through DBA_

Get the SHARING column in OBJECTS. When you need to get the definition information of an object, the flag tells Oracle that the information needs to be switched to the CDB$ROOT container to get it.

Here is some information about one of these packages, all containers contain the same definition

For information, query the DBA_OBJECTS of CDB$ROOT:

The following information is obtained from PDB:

As you can see, these objects all have the same name and type, and are defined as Oracle-managed

The SHARING column is also METADATA LINK. They have different objects, ID. Are working on them.

When linking, you only need to use the name and internal tags. According to these contents, we can know that these

Objects are system objects (managed by Oracle), so when we query these objects in PDB

Oracle will know that you need to switch to the root container to get their information. This is the tool for metadata linking.

Body processing behavior. Dictionary objects tend to be large, so they are only stored in CDB$ROOT. But

They can be accessed anywhere through the dictionary view.

This is related to metadata. For applications, the relevant metadata is stored in the corresponding

In PDB. Objects managed by Oracle are stored in CDB$ROOT. The latter are static messages: they

It is updated only when the database is upgraded or patched. As you can see, the benefits of doing so,

It can reduce the repetition of information, and second, it can speed up the upgrade of PDB, because only in PDB

It's just some links.

Figure 1-3 shows how dictionary information is separated, which is, of course, a simple extension of previous figure 1-2.

3. Data links (called object links in version 12.1)

Of course, it's not just metadata in the dictionary. At the CDB level, multi-tenant databases also store

Store some data. Here is a simple example. Suppose CDB needs to maintain a list of containers, and

Store it in the system table CONTAINER$ and then access it through the dictionary view DBA_PDBS

Ask. This data can be updated to store state information for the container. However, although this data is meaningful only at the CDB level, all PDB is accessible. Let's take a look at it.

See how this information is shared.

Figure 1-3 Separation of system and user metadata

Query CDB$ROOT first:

Then query PDB:

As you can see, accessing the view of CONTAINER$ is essentially a data link. Which means

When there is a session to execute these queries, the information is actually obtained from CDB$ROOT. Actual situation

The CONTAINER$ table exists in all containers, but only in the root container is actually stored

The data, everything else is empty.

1.2.4 using containers

Now that you have so many PDB, how do you use them? You can start by identifying them.

1. Identify the container by name and ID

An integrated CDB can contain multiple containers, either by name and number, or by

It's the CON_ID to identify it. In version 12c, all are used to show what is contained in an instance

An additional column has been added to the V$ view of the object to display the CON_ID to mark where the object belongs

A container. CDB itself is a container, and its container ID is CON_ID=0. Be marked as

CON_ID=0 objects are CDB-level objects and are not associated with other containers.

For example, the following is the information we get after querying V$DATABASE in the root container:

Here is how to execute the query in PDB:

If you execute the above query in different containers, the results may also be different. But wherever it is,

In this case, the database information obtained is only at the CBD level. The information contained in this view

From the control file, you will see that these are actually public information, so CON_ID is set to.

If it is not CDB, then for all objects, CON_ID is. But if it's in one,

In a multi-tenant architecture, most objects belong to specific containers.

In any CDB environment, the first container is the root container, named CDB$ROOT, and

CON_ID=1 . All other containers are PDB.

The first PDB in any CDB is a seed container called PDB$SEED. Because it is

The second container in CDB, so CON_ID=2.

The container for CON_ID > 2 is the user PDB. In version 12.1, you can create an additional 252

A PDB. In version 12.2, it is 4096 PDB.

two。 Container list

The dictionary view DBA_PDBS lists all the PDB (all containers except the root container) and their status:

For PDB, its status is NEW when it is first created, and it is read / for the first time

When the write mode is turned on, its state is adjusted to NORMAL, because when you open PDB for the first time, you need to enter

Do some related actions. A status of UNUSABLE indicates that the PDB creation failed and the only allowed

The action is to delete it. The status is UNPLUGGED, indicating that the PDB will be transferred to another

CDB, and on the source CDB, the only thing you can do is delete the PDB.

In version 12.1, you can see states like NEW, as well as other states: NEED

UPGRADE, indicating that the PDB is from another version of the database; CONVERTING, indicating that the

From a non-CDB. Of course, there are three other states: RELOCATING and REFRESHING

And RELOCATED. We will discuss these in Chapter 9.

The following information is found in the database dictionary. We can list the container information through an example

Its open status is shown here:

In non-CDB, the MOUNTED status indicates that the current control file has been read, but the data

The file has not been opened by the instance process. The result here is similar: one is closed

The PDB of the state whose data file is not open. PDB has no NOMOUNT status because of control

Making documents is public.

Note that both SQL*Plus and SQL Developer have a shortcut that can

Used to display the current PDB. If you are in the root container, you can also display all the PDB:

3. Identify containers through CON_UID and DBID

As you can see, in addition to the name of the container, it can also be identified by the CON_ID in ID or CDB

The container. However, when you move a PDB, its CON_ID will change. For this reason, we still need to

A unique identifier CON_UID. This number can still be used to identify the PDB when it moves.

PDB . CDB$ROOT is a container but not a PDB, and it doesn't move, so its CON_UID

Is 1.

Based on database compatibility considerations, each container has a DBID. The DBID of CDB is

The DBID of CDB$ROOT and PDB is CON_UID.

In addition, each container has a GUID: a RAW value that contains 16 bytes. it

It is generated when the PDB is created and will never change again. When using OMF (Oracle Managed

Files, files managed by Oracle), GUID is used for the directory structure and as the unique identity of the PDB

Fu.

All of these identifiers are stored in V$CONTAINER, and of course you can use these functions to get the

Take the ID of a container: CON_NAME_TO_ID, CON_DBID_TO_ID, CON_UID_TO_ID

And CON_GUID_TO_ID. If the container does not exist, the null value is returned. Here are some examples:

4. Connect to a container

Our previous analysis of multi-tenancy is used as a way to break through the limitations of solution integration.

It was discussed. So the question is, how do you switch between multiple scenarios? Instead of using the solution for users to enter

OK, direct connection? Here, you can use ALTER SESSION SET CURRENT_SCHEMA.

Of course, you can also connect directly to a PDB, but we will do this in Chapter 5.

Discuss. This content is related to services, and this is the right way to connect to PDB from a user or application

Law. But now that you are connected to CDB, you can use ALTER SESSION SET

CONTAINER command to simply switch the session to a new container.

Now, we have connected to CDB$ROOT:

Let's change the current container:

Now we are in PDB:

If a transaction is opened in one container, it cannot be opened in another container.

Other business.

You can leave the current transaction and switch containers:

But the DML statement cannot be executed at this time because it requires a new transaction:

First, you need to go back to the original container and end the transaction:

You can then open a new transaction in another container:

If a cursor is opened in one container, it will not be able to access the cursor in another container.

Mark to perform the acquisition operation. You need to go back to the container where the cursor is located and get it:

Basically, it is often easy to switch from one container to another. But in a different way

The operations performed in the container are isolated from each other, and the state in the previous container cannot be shared.

For example, we connect to PDB1, set serveroutput to on, and then use dbms_output

Command:

Dbms_output produces output, and you can see that USERENV displays the current container name.

Now let's switch to PDB2:

There is no output here. Serveroutput is just set up in PDB1, and I

You also need to set it in PDB2:

Now let's go back to PDB1:

There is no need to set up serveroutput again. When we switch back, we get it back

The state in the original PDB.

With JDBC or OCI, our example runs in SQL*Plus, but other customers

Duan can't do that. When using a user (public user) defined in the root container, and

When the user is also granted the SET CONTAINER system permission of PDB, you can switch to this

PDB . You can use JDBC (Java DataBase Connectivity) or OCI (Oracle Call Interface)

To complete this operation. For example, you can configure a connection pool on the application server so that when you get the connection

Then, you can switch the connection to the desired container. When creating public application services for database multi-tenancy

This method is worth considering.

Note: 12.2 PDB 12.2 ORA-24964:ALTER SESSION SET CONTAINER setting container triggers for some reason, if you want to perform a container switch in a session

For some actions, such as setting different optimizer parameters, you can create a BEFORE SET CONTAINER

And AFTER SET CONTAINER triggers.

Here is how these triggers work:

● creates BEFORE SET CONTAINER triggers in PDB1, when in PDB1

It is then triggered when the ALTER SESSION SET CONTAINER is executed. If triggered

The device reads the name of the container, which is PDB1.

● creates an AFTER SET CONTAINER trigger in PDB2, when ALTER is executed

It triggers when SESSION SET CONTAINER=PDB2 occurs.

This means that if you create before and after triggers in PDB1 and PDB2, respectively, then

When switching from PDB1 to PDB2, both triggers are triggered separately.

These are two different ways of working in PDB. You can also connect to the container through a service, and we will

These are discussed in Chapter 5. At this point, at the beginning of the session, you can use AFTER LOGON ON

The PLUGGABLE DATABASE trigger executes some code. Alternatively, you can use SET

CONTAINER, and then use AFTER SET CONTAINER ON PLUGGABLE DATBASE

Trigger. When a user is working in PDB, if you want to make some certain settings for these sessions

Then both of the operations mentioned above need to be defined. Pay attention to the PLUGGABLE words here.

It is not necessary because the syntax here is compatible with the behavior of the database.

5. Dictionary view in container

PDB contains everything you want to see from a database. Which means that for a PDB

The result of the query from the dictionary view in the should be the same as the result returned by the query against a database

To. You also have a DBA_/ALL_/USER_ view, which is used to get metadata for objects in PDB.

Those objects either have access or you create them yourself. The fact is that system objects are stored in the

Where is transparent: system objects can be seen in DBA_OBJECTS, in DBA_TABLES

You can see the system table in and the instance information in the V$ view. But whatever you see, it's up to you.

Related to the PDB where the former is located.

When you are in CDB$ROOT, you can see the CDB_ view. These views are like all

Open the UNION ALL result of the DBA_ view in the container. This is an CDB database administrator that can

The method used to view all objects. For CDB$ROOT users, the V$ view will be displayed

Displays information in all containers.

Finally, you may want to know whether you are in a non-CDB environment or a multi-tenant environment.

The CDB column in V$DATABASE provides you with the answer:

1.3 what is CDB-level integration

As far as integration is concerned, realizing the commonality of shared resources is its main goal. On top of examples and dictionaries

Many database structures are managed at the CDB level. We're not talking about data files here.

Because they are assigned to each container. And the only thing they have in common is that they have to have

The same character set (except when transferring a container from another CDB, of course I

We won't discuss it until Chapter 9. In a container database, other types of files are public.

SPFILE

The database instance is common to all containers, and SPFILE holds the relevant parameters of the instance

Count and set the property for the entire CDB. SPFILE contains settings that cannot be stored in a database or control

System file, because these settings must be available before the database is in the mount state.

Some parameters can be set at the PDB level (in V$PARAMETER, the

ISPDB_MODIFIABLE is listed as TRUE). Of course, changes to such parameters can also be persisted.

Come on. But when you modify these parameters, even if you set SCOPE=SPFILE syntactically, these PDB

Level parameters are actually stored in CDB's dictionary table (that is, PDB_SPFILE$). They won't be saved.

Stored in your own PDB, because these parameters must be accessible before opening the PDB. Later on

We will see that when moving a PDB (insert / pull), these parameters will be extracted and stored

Into a XML file and transferred along with the PDB data file.

Control file

The control file is related to all other structures in the database. For example, the control file is the only true

The place where the name of the data file is being stored is the FILE_ID column in the dictionary table, just a reference to the specific location

It's just for use. In a multi-tenant environment, the control file is at the CDB level and holds all PDB data

File information. You can see this related to PDB in Chapter 9, that is, when a PDB is pulled

When you export / insert, all data file information related to the PDB will also be exported from the control file

It is then stored in a XML file.

Note: (control files) when discussing data files, there is an initialization parameter that can be used to control what an instance can open.

Maximum number of files. It is DB_FILES, and its default value is 200. Note that if you want to create hundreds

PDB, then this limit will be reached soon. No new tablespace or PDB can be created at that time

Unless the instance is restarted. In a multi-tenant environment, restarting an instance means downtime for many applications

Operation. So this should be avoided. So when you plan to manage multiple PDB in a container, don't forget

Remember to set the DB_FILES parameter correctly.

UNDO

In version 12.1, the first version of the Oracle database with a multi-tenant architecture, UNDO

The tablespace is public and at the CDB level. But in version 12.2, we have a new choice.

Item to run CDB in local UNDO mode. If LOCAL UNDO is set to on

Then each PDB has its own UNDO tablespace, and when all sessions go to PDB blocks

When you write data in, its UNDO information is stored in the local UNDO table space of the PDB. Only

The UNDO information will be recorded to the UNDO of root only if there are modification operations performed in CDB$ROOT

In the table space.

To put it simply, it's better to run CDB in native UNDO mode if possible. UNDO

Contains application data, and if we store this data in a public UNDO file

Then we will not be able to achieve PDB isolation. One reason to use native UNDO mode

That's when we're going to do a quick flashback of PDB or a point-in-time recovery. We will be on the 8th

The chapter explains these contents.

Temporary tablespace

Temporary tablespaces can be created at the CDB or PDB level. If a user in a PDB is running

No temporary tablespace is specified during the session, and the PDB does not have a default temporary tablespace, the session will

CDB's temporary tablespaces are used. But this is not recommended. We can make a temporary watch for root

Set a limit on the space (MAX_SHARED_TEMP_SIZE) to control the use of it by PDB.

When you need to assign a workspace to complete a recursive query on a linked view of an object, CDB$ROOT

Temporary tablespaces are typically used by sessions connected to the root container, or by sessions from a PDB

Use.

When you set a temporary tablespace to the default temporary tablespace, if you created the

PDB, then you can also specify other temporary table spaces as the default temporary table space. But here,

After that, you cannot set the temporary table space of the CBD to the default temporary table space of the PDB.

Redo log

Redo logs are used to protect instances, so they are also public. The main use of redo logs

The way is to record all changes in buffer cache and ensure that all committed transactions are changed

The change can last forever.

The REDO data flow in a multi-tenant environment is similar to that in previous versions, except in each REDO

Additional information is added to the record to mark outside the container. And for restore operations, REDO

The format of the data is also critical, and based on this, Oracle rarely changes these things.

Use a unified REDO thread to handle all PDB, for DBA management CDB

It's also very beneficial. In a non-CDB environment, when preparing a new database, it will take

It takes a lot of time and effort to set the recovery area size, establish backups, and create and configure Data Guard

Physical repository, if used. But in a multi-tenant environment, you only need to do a similar job.

Once is enough, that is, CDB. Because this is where the functions related to database availability converge: you

Backup, Data Guard, and RAC configuration of. You can simply create a new PDB from this

Benefit from an environment that has been configured for availability: it automatically backs up with CDB, automatically in the physical

Created in the repository (of course, you need to use Active Data Guard here), and can be automatically used by all RAC

Instance access. Again, this is because the key architecture used to achieve database availability--

REDO data streams operate at the CDB level.

However, using only one REDO data stream can sometimes cause performance problems. If ever

Experienced performance problems related to log writes, such as long waits based on "log file sync" events

Then you can imagine that when the LGWR process needs to do all REDO writes to PDB, it will

What happened. As a result, if LGWR cannot keep up with the speed of REDO generation, then

When the user performs the submit operation, he has to enter the waiting state.

Therefore, based on the scalability of LGWR, Oracle introduced multithreading in version 12c.

LGWR structure. Here, LGWR is a coordination process, followed by multiple subordinate processes (LG00, LG01)

Etc.) associated with it. In this way, the REDO data stream of the instance can be written in parallel.

Operation. Of course, RAC is still another way to implement REDO parallel processing. You need to keep it in mind.

What's important is that in a multi-tenant environment, adjusting the number of LGWR and REDO writes is critical.

When integrating, you need to pay special attention to the performance of the disk that holds the REDO logs.

Data file

Data files stored in tablespace blocks belong to their respective containers, but they are also

Managed by CDB. For CDB, these data files have unique identifiers, that is,

FILE_ID:

Relative file number, the relative file number in Chinese, is introduced with the transferable tablespace

I'm here. So in versions prior to 12c, this feature has been around for quite some time. Multi-tenant

Environment, in PDB, the data file is through the tablespace number and the relative text of the file in the tablespace

The item number (RELATIVE_FNO) is used for identification. In addition, when moving, cloning or inserting files

Changes to the file number are not required when entering the PDB. Only the absolute document number (FILE_ID) will

Renumber to ensure its uniqueness in CDB-but in control files and data files

In the head, this renumbering action is extremely fast.

CDB-level data and metadata

So far, we have explained the dictionaries related to system objects, which are stored in CDB$ROOT

In the SYSTEM and SYSAUX tablespaces of They are public and can be accessed by PDB. But...

There are many more than these basic database objects (created by catalog.sql and catproc.sql)

Public information is also stored in the root container.

1. APEX

By default, once APEX is installed (you can select this component in version 12.2), it

At the CDB level. APEX is similar to system dictionaries in that they are used to store metadata and do not require

Installed in PDB$SEED or other PDB. However, this approach has a very big drawback: in

There is only one APEX version in your CDB. And when you want to insert a running APEX into the CDB

When version 5. 0 is not CDB, you will encounter problems. For example, in the Oracle cloud service, the current CDB

Version 4.2 of APEX is installed on the.

Note: Mike Dietrich blogs.oracle.

Com/UPGRADE/entry/apex_in_pdb_dose_not APEX 5.0 Oracle APEX PDB Oracle Application

Express (APEX) 2. AWR

AWR (Automatic Workload Repository, automatic workload data Archive) slave instance

A large amount of information (statistics, wait events, etc.) is collected in the state view. In a multi-tenant environment, these are

Done at the CDB level. There is only one job to collect all statistics for all containers and store them

In CDB$ROOT. This is the object link view-- the AWR view (starting with DBA_HIST)

The main application cases. They can be queried by each PDB, but the data read is actually

Stored in the root container.

Therefore, there are two important conclusions. First, if you move a PDB, then AWR

The historical data will not move with it; instead, it will remain in the original CDB. Can be used

The original database reads these views or exports them elsewhere. But the data stored in AWR

CON_ID, which is supposed to be the container ID when the snapshot is generated, so you need to check the CON_DBID so that

Confirm a specified PDB. In each view that starts with DBA_HIST, there are actually three

Different identifiers:

● DBID is the DBID of CDB, which is the same as in non-CDB environments. This identifier is identical to SNAP_ID

Together with INSTANCE_NUMBER, it can be used to determine a unique snapshot.

● CON_ID is the container ID, which is the container ID where the V$ view queried when the snapshot is generated.

Some rows in the view may not be associated with any container, so CON_ID=0 at this point. Other line rules

The statistics of a container object are recorded, so when a snapshot is generated, the phase is recorded

Should be CON_ID.

● CON_DBID is used to uniquely identify a PDB, and it and DBID are used to uniquely identify a number

According to the library.

For AWR, which collects statistics at the CDB level, the second conclusion is that when in PDB

When you run the AWR report at a level, it only filters out the statistics related to your container, and it is related to the

Ask the V$ view in PDB to get the same information. But you still need to know that in the same AWR newspaper

In the notice, you can still see some statistics collected at the CDB level (the CON_ID=0 of these lines).

This means, for example, that you can see the logic completed by the instance in the instance statistics section of AWR

The number of readings, but when showing specific details (in the SQL section or paragraph section), it will only be displayed with you

Information related to PDB of Let's look at an example.

Before reading the details of the AWR report, we usually check most of the captured SQL

Statement, because if we are not going to study the details of the SQL statement, such an action is not necessary

Here we go. The following is the SQL ordered by Gets section of an AWR report:

This shows that 89% of the SQL statements are captured, and we know that when we want to study high logic

When we read the questions, we have the details we need. If the proportion is low, it usually means that we are born

Cheng's report covers a too large time window. So most SQL statements are in end snapshot

It has been moved out of the shared pool due to timeout before. However, when running the AWR newspaper on a PDB

You can also see another reason for telling the time:

You don't see any difference here, except that only 21% of the SQL statements are captured. Need to check the AWR newspaper

Notice the head to see if it covers only one PDB. Actually, we have two PDB at this time.

Active, here is another PDB:

From an PDB, there is no way to confirm that all SQL statements of that PDB have been captured.

For this PDB, there are no statistics such as total logical reads.

Note: 12.1 PDB Venture Conn _

SYSSTAT ARW 12.2 DBA_HIST_CON_SYSSTAT (DBA_HIST_CON_SYS_TIME_MODEL) (DBA_HIST_CON_ SYSTEM_

EVENT) 12.2 AWR statspack if you don't have a diagnostic package, you can't use AWR and you can install statspack. Pass

By referring to the relevant documentation (spdoc.txt), you can see that statspack can only be installed at the PDB level. When

However, we think it is also useful to install at the CDB level, because you will want to analyze

The activities of CDB$ROOT. Each PDB that wants to collect snapshots will store its own statistics

information. Because statistics are now collected at the PDB level, the related behavior is similar to AWR

Different. We took a snapshot of statspack at the same point in time as in the previous example, and at this point, from the

The information read in spreport.sql is as follows: when the report is running on CDB$ROOT, the session logic reads

Is 24 956 570; when running on one of the PDB, it is 5 709 168 (22%); in

The value on the other PDB is 17138586 (68%). When running on the root container, the statspack receives

Sets statistics related to the CDB, and when running on PDB, collects statistics for the container.

1.4 Summary of this chapter

In the previous long introduction, we have explained why Oracle should be included in the version in 2013.

The multi-tenant feature is introduced in 12c. We've seen different integration options, and of course you might think

There is no need to run the application in a multi-tenant environment. However, this new architecture will become the only Oracle in the future.

A supported database architecture, the original non-CDB architecture is being abandoned. So, even if you don't want to,

To run multiple PDB on an instance, you also have to run what we call a "single tenant" database (we

This will be discussed in Chapter 3), and you also have to manage the container database.

In addition to integration, the new architecture also separates application data from metadata from the system dictionary, thus

Provide greater agility for data movement and location transparency. We will discuss these in Chapter 9.

In the next chapter, we will start by creating an integrated database.

Purchase address:

Https://item.jd.com/12393662.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.