IBM SOA講堂 - WebSphere 動靜皆宜 : WebSphere MQ 7.0新功能介紹及與 PM4Data(檔案傳輸服務) & WTX(資料轉換引擎)的整合
Owen Chang WebSphere Technical Sales Specialist IBM Taiwan Software Group owench@https://www.doczj.com/doc/1e1212384.html,
Agenda
WebSphere MQ v7.0 新功能介紹 WebSphere MQ Integrate With WTX( 整合協同服務)資料轉換引擎 WebSphere MQ Integrate With PM4DATA(檔案傳輸服務) Summary
Next Version Objectives
Improved support for "standards-based" messaging
– Underpinning SOA and ESB architectures – Ease-of-use – Performance
Extension of publish/subscribe capabilities
– Leading to simplification with Message Broker
Easier programming in any environment
– Some features suggested by JMS requirements are useful in MQI
Common across Distributed and z/OS codebases
3
Platform Coverage
Essentially the same platforms as V6
– Minor updates to base OS levels – Linux based on RH4 or Suse 9; AIX V5.3; z/OS 1.8 (GA 3Q06)
Drop Linux/zSeries 31-bit
– 64-bit edition will continue
Drop Windows 2000
– Windows XP is base level – Will include Vista
Windows 2003 x86-64 support
– Adds 64-bit application support – Supporting existing 32-bit applications – Some exits will require recompiling to support both 32 and 64-bit modes
Java 1.4 and later
4
Publish/Subscribe
Point-to-point asynchronous messaging decouples applications
– But still implies a one-one relationship between sender and receiver
Publish/subscribe is a further stage of decoupling
– Sender has no direct knowledge of how many (if any) apps will see a message – Link between applications is a Topic, not a Queue
A natural part of the JMS API
– Combined both Publish/Subscribe and Point-to-Point styles – Want to make it a natural part of the native MQI
V5.3 and V6 (Distributed) included a Publish/Subscribe broker (nee MA0C) Also have Message Broker and Event Broker products Goal is to simplify and improve ...
5
Relationship with Message Broker
Next version of Message Broker will prereq this version of WMQ for pub/sub
– But WMB V6 will continue to work with new WMQ releases – Migration can be done one piece at a time
The publish/subscribe engine is removed from the broker
– The Nodes will call the WMQ engine transparently – Message Flows do not need to be changed
Administration tooling will be integrated with WMQ tooling
– One place to configure WMQ and WMB resources – V6 SupportPacs show direction
Looking for any other optimisations ...
– Vision is all TRANSPORT is in WMQ – For example, multicast
6
Publish/Subscribe Admin
Based on Topics Topic Objects
– New object type, like queue or channel definitions – A 48-character name which has a longer attribute for full topic string – Defines major points in a topic tree
In-use topics
– The topic strings that applications are publishing or subscribing on – Inherit attributes (eg security) from the "closest" defined topic object – Not defined administratively, but can be viewed DEFINED TOPIC TREE SPORTS CRICKET RUGBY / NEWS IN-USE TOPICS SUBSCRIBE("/SPORTS/CRICKET/WEST INDIES") SUBSCRIBE("/NEWS/POLITICS/WESTMINSTER" ) SUBSCRIBE("/TV/DRAMA/WEST WING")
7
Publish/Subscribe Admin (2)
Support for durable and non-durable subscriptions
– With durable, a client can go away and come back later without missing messages – Durable can cause queues to fill ... – No "cleanup" task needed for non-durable
Subscriptions
– Able to see who is subscribing to topics: like DISPLAY QSTATUS – Able to create subscriptions on behalf of a third party
Status and Statistics
– Items such as number of messages published on a topic
Security
– Use of a topic is restricted by permissions on the associated topic object – On z/OS drives need for mixed-case support in RACF – Follows existing WMQ model for security configuration (RACF or OAM)
8
Publish/Subscribe Topologies
WMQ V6 publish/subscribe networks based on hierarchies
– All brokers linked in parent/child tree
WMB publish/subscribe networks based on hierarchies of collectives
– All systems in a collective are connected to each other (mesh) – Also has "clones“
New product will have hierarchies and pub/sub clusters (a.k.a. collectives)
– With interoperability to other pub/sub systems through hierarchies
Design gives
– Scalability – Availability – Ease of administration
Collectives based on WMQ clustering
– Cluster can be defined independently of any existing cluster used for queueing
9
Publish/Subscribe MQI
Cannot change the JMS API
– But we want to make some of its facilities more easily available in the MQI – To improve MQI programming and improve (make thinner) the JMS layer
New verb for subscribing
– So you do not need to build RFH or RFH2 headers in the application – MQSUB registers a subscription – Includes information about where messages will be read from – Do not need to specify a queue – can be automatically assigned
New options on existing verbs
– MQOPEN to get access to a topic – MQCLOSE will deregister a subscription – MQPUT, MQGET to publish and to receive subscriptions – MQSUBRQ (new verb) for initial state
Conversion of point-to-point applications without code changes
– Administrative changes to objects
10
Publish/Subscribe Application Migration
New verbs remove need for some of the older interfaces
– Which will be deprecated – though not removed immediately – PCF and RFH1 facilities for WMQ publish/subscribe applications: Identity, Streams
New MQI operations will not be available for old VB and ActiveX programs
– Use .Net classes instead
A single application cannot mix new verbs with old options
– Can't use RFH1(Register Publisher) and MQPUT(topic) in same program
Separate daemon included to translate MA0C pub/sub commands
– With some performance cost – Not needed when all publish/subscribe applications have been converted
Migration step to convert existing WMQ and WMB subscriptions Most common "application" is IBM-supplied JMS/XMS layer
– New client design to take advantage of new facilities when they exist – So installing new JMS jar or XMS dll will be all that's needed
11
Message Properties
Arbitrary values associated with the message but not part of the body
– Like a user-extendable MQMD – Already part of JMS
MQMD
PROPS XX=YY
New verbs MQSETMP and MQINQMP
– Properties can be integers, strings, boolean, etc.
Easier to use than RFH2 folders
– Receiving apps do not see them unless they want – No need to parse and skip over message headers
BODY
Appear as RFH2 properties on older queue managers Permits explicit statement of relationships between messages
– eg Message X is a REPLY to Message Y – Which can then be exploited by products looking for patterns
12
Using Properties – Possible Scenario
// This is a router app - get a message and work with it // 1. Initial setup and read input MQCRTMH(hConn, &CrtMsgHOpts, &hRequestMsg, &RC, &RC); GetMsgOpts.MsgHandle = hRequestMsg; MQGET(hConn, hObj, &MsgDesc, &GetMsgOpts, BufLen, &Buffer, &DataLen, &CC, &RC); // 2. Forward request unchanged to a server app, named in the message PutMsgOpts.Action = MQPACT_FORWARD; PutMsgOpts.OriginalMsgHandle = hRequestMsg; MQPUT(hConn, hServerObj, &MD, &PutMsgOpts, DataLen, &Buffer, &CC, &RC); // 3. Tell requester message has been dealt with by updating existing property Name.VSPtr = “RequestStatus”; Name.VSLength = MQVS_NULL_TERMINATED; MQSETMP(hConn, hRequestMsg, &SetPropOpts, &Name, &PropDesc, MQTYPE_STRING, “REQUEST RECEIVED”, 16, &CC, &RC); PutMsgOpts.Action = MQPACT_REPLY; PutMsgOpts.OriginalMsgHandle = hRequestMsg; MQPUT(hConn, hReplyObj, &MD, &PutMsgOpts, DataLen, &Buffer, &CC, &RC); // 4. Also put a completely unrelated message to a logging queue PutMsgOpts.Action = MQPACT_NEW; PutMsgOpts.OriginalMsgHandle = MQMH_NONE; MQPUT(hConn, hLogObj, &MD, &PutMsgOpts, DataLen2, &LogMsgBuf, &CC, &RC); MQCMIT(hConn,&CC,&RC);
13
Other MQI Enhancements Asynchronous Message Reception
– New verb MQCB defines a callback function – Automatically Invoked when a message arrives – No need for MQGET(WAIT) or MQGET(SIGNAL)
Selectors
– Use a SQL92 clause to select messages by properties including MQMD fields – Can be specified on MQOPEN, MQSUB for filtering messages – Filtering is normally done inside queue manager for efficiency – Not filtering on message body contents – Message Broker still required for content filtering
14
New Quality of Service
Traditional WMQ non-persistent messages more reliable than some need Receiving Messages/Subscriptions:
– Messages sent to a client in advance of MQGET, queued internally – Administrative choice – no application changes needed – Higher performance in client
Sending/Publishing Messages:
– Application can indicate it doesn't want to wait for the return code – Maybe pick up return code later – MQSTAT verb – Maintains transactional semantics – Higher performance in client
Implementation also gives us more heartbeat opportunities
– Faster failure notification for clients
15
WMQ Explorer Enhancements
Grouping
– Queue Managers can be partitioned into groups within the Navigator – eg "Test", "Production"
Security Configuration
– Easy to set channel exits, userid/password configurations per queue manager – Still recommend a SVRCONN security exit for authentication – ... or globally for all queue managers in a group or workspace
Tighter JMS integration
– Creating an queue/topic can define a JMS destination at the same time
3rd party plug-ins can create new property pages for an object
– Makes them look even more integrated
Investigating alternative distribution mechanisms
– eg Eclipse Update site
16
Other Ease-of-use Items
Looking to produce items such as
– More sample programs – Demonstrations – Default configurations
Default configuration wizard will create all objects needed
– For JMS and for publish/subscribe operation
No need for command to start/stop a broker
– The "broker" process disappears unless needed for compatibility of old apps – All queue managers will have publish/subscribe function automatically available
17
HTTP-MQ Goals
Simplify access to MQ Apps from Rich Internet Applications
–
– –
–
Gives AJAX and Web 2.0 access to the Enterprise
Submit data direct to queues & topics from Browser Low Latency Web Pub/Sub
Stock price update, Sports scoreboard, Airport and Rail Departures / Arrivals notification
Enable MQ Application Connectivity from any Platform or Language with HTTP capabilities
–
–
–
Significantly increase range of supported platforms
e.g. – Linux distros, POS terminal running Windows Services for Unix environment, RFID reader, Mobile devices
No client library installation required
Lightweight (low qualities of service) messaging
18 18
Background: HTTP-MQ is Loosely Modeled on REST
REpresentational State Transfer (Roy Fielding)
o Everything is modeled as a Resource o Every resource is identified by an address (URI) o Resources have state (representation) o HTTP is used to transfer state to networked application o HTTP verbs operate on the resource
GET retrieves a resource’s state representation POST Updates resource (or other processing) DELETE deletes resource
PUT Creates / updates resource state
19 19
Summary
Improvements to publish/subscribe Improvements to JMS/XMS layer Ease-of-use for administrators Ease-of-use for MQI programmers Performance Tighter integration with Message Broker Continues to extend the enterprise messaging foundation
20
Oracle数据库11g新特性：安全性 默认口令 2006 年，OTN 发布了我撰写的一系列题为“安全保护项目：一种分阶段的数据库基础架构保护方法”的文章。在这些文章中，我讨论了如何应对常见的安全挑战（如用户使用默认口令）以及如何扫描您的数据库以查找这些用户。 对我而言很不幸的是，您可能已经忘记了我文章中的那一部分。Oracle 数据库11g 现在提供一种快速识别使用默认口令的用户的方法。该方法实施起来极为简单，只需检查单个数据字典视图：D BA_USERS_WITH_DEFPWD.（注意，DBA_ 是一个标准前缀，它不仅包含使用默认口令的DBA 用户。）您可以执行以下命令来识别这些用户： 输出如下：
由于SCOTT 使用了默认口令TIGER，因此您会看到他出现在上面的清单中。使用下面的语句进行更改： 现在，如果您查看该视图： 您就不会在该清单中看到SCOTT 了。就这么简单！ 区分大小写的口令 在版本11g 之前的Oracle 数据库中，用户口令是不区分大小写的。例如：
这种安排为支付卡行业（PCI）数据安全标准之类的标准带来了问题，这些标准要求口令区分大小写。 该问题得到了解决，在Oracle 数据库11g 中，口令也可以区分大小写。通过DBCA 创建数据库时，系统会提示您是否希望升级到“新的安全标准”，其中之一就是区分大小写的口令。如果您接受该标准，口令在创建时的大小写状态将被记录下来。假如您接受了新标准，相应的操作结果如下： 注意对“tiger”和“TIGER”的不同处理方式。 现在，您的某些应用程序可能无法立刻传递大小写正确的口令。典型示例是用户输入表单：很多表单在接受口令时不会进行大小写转换。然而，在Oracle 数据库11g中，这种登录方式可能会失败，除非用户以区分大小写格式输入口令，或者开发人员对应用程序进行了修改，使其能够进行大小写转换（这一点不可能迅速实现）。 不过，如果您希望的话，仍然可以通过更改系统参数SEC_CASE_SENSITIVE_LOGON 恢复到不区分大小写的状态，如以下示例所示。
Oracle Database 12c版本介绍 Oracle Database 12c有三种版本，提供多种企业版选件来满足客户对各种领域（性能和可用性、安全性和合规性、数据仓储和分析、非结构化数据和可管理性）的特定需求。 Oracle Database 12c标准版1 企业级的性能和安全性 Oracle Database 12c标准版1经过了优化，适用于部署在小型企业、各类业务部门和分散的分支机构环境中。该版本可在单个服务器上运行，最多支持两个插槽。Oracle Database 12c标准版1可以在包括Windows、Linux和Unix 在内的所有Oracle支持的操作系统上使用。 概述 ●快速安装和配置，具有内置的自动化管理 ●适用于所有类型的数据和所有应用 ●公认的性能、可靠性、安全性和可扩展性 ●使用通用代码库，可无缝升级到Oracle Database 12c标准版或Oracle Database 12c企业版 优势 ●以极低的每用户180美元起步（最少5个用户） ●以企业级性能、安全性、可用性和可扩展性支持所有业务应用 ●可运行于Windows、Linux和Unix操作系统 ●通过自动化的自我管理功能轻松管理 ●借助Oracle Application Express、Oracle SQL Developer和Oracle 面向Windows的数据访问组件简化应用开发 Oracle Database 12c标准版 经济实惠、功能全面的数据库 Oracle Database 12c标准版是面向中型企业的一个经济实惠、功能全面的数据管理解决方案。该版本中包含一个可插拔数据库用于插入云端，还包含Oracle真正应用集群用于实现企业级可用性，并且可随您的业务增长而轻松扩展。
SQL ANYWHERE 12四大关键新特性 当前，移动应用浪潮正以迅猛的速度席卷着世界的每个角落。尤其，移动应用正越来越多地出现在企业关键业务的各个环节——办公、销售、物流、财务、客服、流程管理等等。但与此同时，众多的系统平台和移动设备、广泛的移动应用也给企业数据管理带来了全新的挑战。据Kelton Research近期发布的一份调查结果显示，在受访的IT经理中，90%的受访者计划在2011年实施全新的移动应用，其中接近一半的IT 经理认为成功管理移动应用将成为他们的首要任务。面对移动应用的多样化、分散化给企业数据管理带来的巨大压力，企业迫切需要一个功能强大的、安全可靠的移动数据管理解决方案来帮其分忧。 事实上，作为企业移动化领域的公认领导者，Sybase推出的移动数据管理和同步解决方案——SQL Anywhere已经满足了企业移动数据管理的诸多要求。借助这一解决方案，移动员工可立刻通过智能电话或其它移动设备随时随地访问公司的后台数据，提高工作效率。 SQL Anywhere介绍 SQL Anywhere是Sybase公司推出的一款能够提供数据管理和企业数据交换技术的综合程序包，它可以帮助工作人员为服务器环境、桌面环境、移动环境以及远程办公环境快速开发由数据库驱动的应用程序，并能为开发人员提供处理复杂前端环境的技术、支持他们更轻松地架构应用程序的底层数据管理、同步、安全和远程支持。 2010年，SQL Anywhere两度创新——3月，Sybase推出具备先进的空间数据功能的全新版本，7月，Sybase推出SQL Anywhere? 12，该版本拥有新的、重要的增强功能，包括支持空间数据的存储和同步、支持iPhone设备和大型同步环境，以及全新的自我管理特性。优化的SQL Anywhere适用于那些对现场IT支持要求很少或甚至无要求、在传统数据中心环境之外运行的任务关键型数据库应用。这一版本的推出使得Sybase成为业界首家为iPhone、Blackberry和Windows Mobile智能手机设备提供数据库和同步支持的数据库供应商，也是首家在移动数据库和同步平台中提供空间数据支持的供应商。 对于在传统的数据中心之外运行的应用来说，SQL Anywhere是领先的数据管理和企业同步解决方案。从一开始，SQL Anywhere就被设计成具备企业级功能、开箱即用的高性能和强大同步能力的数据库解决方案，能实施成为网络、嵌入式以及移动环境中的任务关键型数据库。 传承了简单易用、自我管理和轻松嵌入的特质，最新版本的SQL Anywhere 12持续深化这些特质，并在开发人员生产力、高性能的开箱即用、可扩展性和监控和高级数据同步方面提供了关键的新特性，以及添加到MobiLink和UltraLite中的技术新功能。 SQL Anywhere 12四大关键新特性之一——提升开发者效率 最新版本的数据库和同步解决方案——SQL Anywhere 12新增了包括空间数据在内的诸多新功能和新选项，比如空间查看器、空间数据类型、方法、构造器和函数、空间向导等，这些功能使其在SQL Anywhere 数据库、UltraLite数据库以及MobiLink同步技术中支持空间数据，大大地提升了开发人员的工作效率。 空间数据
Oracle 12C优化器的巨大变化，上生产必读（上） 序言 优化器是Oracle数据库最吸引人的部件之一，因为它对每一个SQL语句的处理都必不可少。优化器为每个SQL语句确定最有效的执行计划，这是基于给定的查询的结构，可用的关于底层对象的统计信息，以及所有与优化器和执行相关的特性。 随着每个新版本的发布，优化器都会进化，利用新功能以及新的统计信息来生成更好的执行计划。随着对查询优化的新的自适应方法的引入，Oracle 12c数据库把这种进化更推上了一个台阶。 这份白皮书介绍了在Oracle 12c数据库中与优化器和统计相关的所有新特性并且提供了简单的，可再现的例子，使得你能够更容易地熟悉它们。它还概括了已有的功能是如何被增强以改善性能和易管理性。 优化器和统计信息新特性 1、自适应查询优化 到目前为止，Oracle 12c数据库中最大的变化是自适应查询优化。自适应查询优化是这样的一组功能，它使得优化器能够对执行计划进行实时调整，并且发现能够导致更佳的统计信息的额外信息。当现有的统计信息不足以产生一个优化的计划，这种新方法是极其有用的。自适应查询优化包括两个方面：自适应计划，它着重于改善一个查询的初次执行；自适应统计信息，它为后续的执行提供了额外的信息。 (图1. 自适应查询优化功能的组件) 2、自适应计划
自适应计划使得优化器能够延迟产生一个语句的最终计划，直到执行的时候才决定。优化器在它所选择的计划（缺省计划）中植入统计收集器，从而在运行的时候，它能够判断自己的基数估算与计划的操作所实际看到的行数是否有很大的偏差。如果有显著的区别，那么这个计划或者计划的一部分在SQL语句的首次执行就能够被自动调整来避免不理想的性能。 3、自适应的连接方式 通过为计划中的某些分支预先确定多个子计划，优化器能够实时调整连接方式。例如，在图2中优化器的初始计划（缺省计划）为order_items 和 product_info 之间的连接选定的是嵌套循环连接，通过对product_info表的索引读取。另一个可选的子计划也同时被确定，它允许优化器将连接方式切换到哈希连接。在候选计划中product_info是通过全表扫描来读取的。 在执行的时候，统计收集器收集了关于这次执行的信息，并且将一部分进入到子计划的数据行缓存起来。在这个例子中，统计收集器监控并缓存了对order_items的全表扫描。基于它在统计收集器中看到的信息，优化器会最终确定采用哪个子计划。在这个例子中，哈希连接被选为最终计划，因为来自order_items表的行数大于优化器最初的估计。 在优化器选择了最终计划之后，统计收集器停止收集统计信息以及对数据行的缓存，而仅仅是传递数据。在子游标随后的执行中，优化器禁止了数据缓存，并且选择了同一个最终计划。目前的优化器能够从嵌套连接切换到哈希连接，反之亦然。可是，如果初始选中的连接方法是排序合并连接，则自适应不会发生。 (图2. 自适应执行计划确定Order_items 和 Prod_info 表之间的连接) 在缺省情况下，explain plan命令只会显示优化器选定的初始（缺省）计划。而 DBMS_XPLAN.DISPLAY_CURSOR只显示查询所用的最终计划。
一. ASM 快速镜像再同步（ASMFast Mirror Resync） 1.1 无ASM快速镜像再同步时 每当ASM 无法向分配给某个磁盘的区执行写入操作时，就会使该磁盘脱机，同时会在其它磁盘上至少写入一个此区（ASM 数据区）的镜像副本（如果相应的磁盘组使用了ASM 冗余）。 使用OracleDatabase 10g 时，ASM 会假定脱机磁盘只包含过时数据，因此不再从此类磁盘中读取数据。磁盘脱机后不久，ASM 就会使用冗余区副本在磁盘组中的剩余磁盘上重新创建分配给磁盘的区（ASM 数据区），将脱机的磁盘从磁盘组中删除。此进程是一项开销相对较大的操作，可能要花费几小时来完成。 如果磁盘故障只是临时性的（如电缆、主机总线适配器、控制器故障或磁盘的电源中断），则必须在临时故障修复后重新添加磁盘。但是，将删除的磁盘重新添加回磁盘组还需要将区（ASM 数据区）迁回磁盘，因此增加了成本。
1.2 ASM 快速镜像再同步 1.2.1 概述 ASM 快速镜像再同步会显著减少重新同步临时故障磁盘所需的时间。如果某个磁盘因临时故障而脱机，ASM 将跟踪在中断期间发生修改的区。临时故障被修复后，ASM 可以快速 地仅重新同步在中断期间受到影响的ASM 磁盘区。此功能假定受到影响的ASM磁盘内容未发生损坏或修改。 某个ASM 磁盘路径出现故障时，如果您已设置了相应磁盘组的DISK_REPAIR_TIME 属性，则ASM 磁盘会脱机，但不会被删除。此属性的设置确定了ASM 可容忍的磁盘中断持续时间；如果中断在此时间范围内，则修复完成后仍可重新同步。 注：跟踪机制对每个已修改的区使用一个位，这样可确保跟踪机制非常高效。 1.2.2 设置ASM 快速镜像再同步 请按磁盘组设置此功能。可以在创建磁盘组后使用ALTER DISKGROUP 命令完成此操作。使用一个类似以下命令的命令启用ASM 快速镜像再同步：
ORACLE 12C新特性——CDB与PDB Oracle 12C引入了CDB与PDB的新特性，在ORACLE 12C数据库引入的多租用户环境（Multitenant Environment）中，允许一个数据库容器（CDB）承载多个可插拔数据库（PDB）。CDB全称为Container Database，中文翻译为数据库容器，PDB全称为Pluggable Database，即可插拔数据库。在ORACLE 12C之前，实例与数据库是一对一或多对一关系（RAC）：即一个实例只能与一个数据库相关联，数据库可以被多个实例所加载。而实例与数据库不可能是一对多的关系。当进入ORACLE 12C后，实例与数据库可以是一对多的关系。下面是官方文档关于CDB与PDB的关系图。 其实大家如果对SQL SERVER比较熟悉的话，这种CDB与PDB是不是感觉和SQL SERVER的单实例多数据库架构是一回事呢。像PDB$SEED可以看成是master、msdb等系统数据库，PDBS可以看成用户创建的数据库。而可插拔的概念与SQL SERVER中的用户数据库的分离、附加其实就是那么一回事。看来ORACLE也“抄袭”了一把SQL SERVER的概念，只是改头换面的包装了一番。 CDB组件（Components of a CDB） 一个CDB数据库容器包含了下面一些组件： ROOT组件 ROOT又叫CDB$ROOT, 存储着ORACLE提供的元数据和Common User,元数据的一个例子是ORACLE提供的PL/SQL包的源代码，Common User 是指在每个容器中都存在的用户。 SEED组件
Oracle 数据库 12c 新特性总结
导读：本系列文章是 Oracle ACE 总监 Syed Jaffer Hussain 对 Oracle 数据库 12c 的一些 新特性总结，包括数据库管理、RMAN、高可用性以及性能调优等内容。 关键词：Oracle 数据库 12c RMAN PGA 限制 不可见字段
【TechTarget 中国原创】 编者按：甲骨文公司近日正式发布了新版旗舰级数
据库 Oracle Database 12c，在 TechTarget 数据库网站之前的一些报道中，我 们曾对 12c 的一些新特性进行了介绍（参考：尝鲜 Oracle Database 12c 的十 二大新特性）而随着产品正式 GA，相关技术文档也披露了更多关于 12c 数据库 的细节。本系列文章是 Oracle ACE 总监 Syed Jaffer Hussain 对 Oracle 数据 库 12c 的一些新特性总结，包括数据库管理、RMAN、高可用性以及性能调优 等内容。
Oracle 数据库 12c 新特性总结（一）
在第一部分中，我们将介绍： 1. 在线迁移活跃的数据文件 2. 表分区或子分区的在线迁移 3. 不可见字段 4. 相同字段上的多重索引 5. DDL 日志 6. 临时 undo
7. 新的备份用户特权 8. 如何在 RMAN 中执行 SQL 语句 9. RMAN 中的表级别恢复 10. PGA 的大小限制问题
1. 在线重命名和重新定位活跃数据文件
不同于以往的版本，在 Oracle 数据库 12c R1 版本中对数据文件的迁移或 重命名不再需要太多繁琐的步骤，即把表空间置为只读模式，接下来是对数据文 件进行离线操作。 在 12c R1 中， 可以使用 ALTER DATABASE MOVE DATAFILE 这样的 SQL 语句对数据文件进行在线重命名和移动。而当此数据文件正在传输 时，终端用户可以执行查询，DML 以及 DDL 方面的任务。另外，数据文件可以 在存储设备间迁移，如从非 ASM 迁移至 ASM，反之亦然。 重命名数据文件：
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users01.dbf' TO '/u00/data/u sers_01.dbf';
从非 ASM 迁移数据文件至 ASM：
SQL> ALTER DATABASE MOVE DATAFILE '/u00/data/users_01.dbf' TO '+DG_DATA ';
将数据文件从一个 ASM 磁盘群组迁移至另一个 ASM 磁盘群组：
SQL> ALTER DATABASE MOVE DATAFILE '+DG_DATA/DBNAME/DATAFILE/users_0 1.dbf ' TO '+DG_DATA_02';
Oracle 12C RAC集群原理与管理实战 Oracle 集群（也叫Oracle RAC）推出已经很多年了，其技术本来比较复杂，再加上12C中的新概念，难上加难！我们正是想给你首先介绍12C RAC的基本概念，接着做几个完整的实验，通过实验，加深你对12C概念的理解。12C RAC涉及很多技术（主机、网络设备、存储、操作系统、clusterware、Oracle database软件），通过本课的学习，你将彻底的明白12C RAC的原理，并能够独立动手安装和运维Oracle 12C RAC。 课程大纲： 第一课：大型数据库高可用性解决方案与集群 什么是高可用性 Oracle高可用性解决方案概述 DB2高可用性解决方案概述 MySQL高可用性解决方案概述 什么是集群 使用ORACLE RAC 的优势-集群和可伸缩性 平衡的I/O 吞吐量 使用RAC 实现并行执行 集群件的体系结构和服务 Oracle ASM自动存储管理 ASM的关键功能和优点 ASM和Grid Infrastructure 第二课：Oracle RAC 12c的新特性 Flex集群和Flex ASM介绍 Flex集群架构 Flex集群的扩展性和可用性 第三课：Oracle 12c RAC 硬件构成 集群总体硬件结构图 小型机介绍
X86服务器介绍 网络设备介绍 存储设备介绍（DAS，NAS、SAN） RAC One Node 单实例高可用性 可识别集群的存储解决方案 Oracle 集群文件系统 第四课：Oracle 12c RAC 软件构成 Oracle Clusterware 资料档案库(OCR) CSS 表决磁盘功能 Oracle 本地注册表和高可用性 Oracle Clusterware 初始化 控制Oracle Clusterware 验证Oracle Clusterware 的状态 集群文件系统OCFS 网络文件系统NFS 自动存储管理ASM VIP SCAN VIP 第五课：Oracle 12C RAC安装环境准备（一）安装环境说明 DHCP配置(在192.168.0.88) DNS（Bind）配置(在192.168.0.88) 第六课：Oracle 12C RAC安装环境准备（二）创建用户和组，并创建相应目录 系统配置和准备 准备共享存储 配置裸设备 第七课：Grid Infrastructure 安装
OracleDatabase12c版本介绍 OracleDatabase12c?有三种版本，提供多种企业版选件来满足客户对各种领域（性能和可用性、安全性和合规性、数据仓储和分析、非结构化数据和可管理性）的特定需求。 OracleDatabase12c?标准版1 企业级的性能和安全性 OracleDatabase12c?标准版1经过了优化，适用于部署在小型企业、各类业务部门和分散的分支机构环境中。该版本可在单个服务器上运行，最多支持两个插槽。OracleDatabase12c?标准版1可以在包括Windows、Linux和Unix在内的所有Oracle支持的操作系统上使用。 概述 ●快速安装和配置，具有内置的自动化管理 ●适用于所有类型的数据和所有应用 ●公认的性能、可靠性、安全性和可扩展性 ●使用通用代码库，可无缝升级到OracleDatabase12c?标准版或 OracleDatabase12c?企业版 优势 ●以极低的每用户180美元起步（最少5个用户） ●以企业级性能、安全性、可用性和可扩展性支持所有业务应用 ●可运行于Windows、Linux和Unix操作系统 ●通过自动化的自我管理功能轻松管理 ●借助OracleApplicationExpress、OracleSQLDeveloper和Oracle面向 Windows的数据访问组件简化应用开发 OracleDatabase12c?标准版 经济实惠、功能全面的数据库 OracleDatabase12c?标准版是面向中型企业的一个经济实惠、功能全面的数据管理解决方案。该版本中包含一个可插拔数据库用于插入云端，还包含Oracle 真正应用集群用于实现企业级可用性，并且可随您的业务增长而轻松扩展。
Oracle 11g 新特性 ADR ADR 主目录 既然所有的焦点都集中于数据库的诊断能力，那么 Oracle 数据库是不是应该存储以结构化方式组织的所有跟踪文件、日志文件等等？在 Oracle 数据库 11g 中确实如此。自动诊断信息库 (ADR) 文件位于一个指定为诊断目标（或 ADR 基目录）的常用目录下的目录中。该目录由初始化参数 (diagnostic_dest) 设置。默认情况下，它设置为 $ORACLE_BASE，但是您可以将其显式设置为某些独占目录。（但是不建议这样做。）该目录下有一个 diag 子目录，您将在这个子目录中发现存储诊断文件的子目录。 ADR 存储所有组件（ASM、CRS、监听器等）的日志和跟踪文件，包括数据库本身的日志和跟踪文件。这使您可以方便地在一个位置查找特定的日志。 在 ADR 基目录中，可以有多个 ADR 主目录，每个组件和实例一个。例如，如果服务器有两个 Oracle 实例，则有两个 ADR 主目录。下面是数据库实例的 ADR 主目录的目录结构。 目录名称<在 DIAGNOSTIC_DEST 参数中提到的目录> →diag →rdbms →<数据库名称> →<实例名称> →alert →cdump →hm →incident →<所有事件目录存在这里> →incpkg 说明 XML 格式的警报日志存储在这里。核心转储存储在这里，相当于早期版本中的core_dump_dest。运行情况监视对多个组件运行检查，它在这里存储某些文件。所有事件转储都存储在这里。每个事件存储在一个不同的目录中，这些目录都存储在这里。当您打包事件时（在本文中可以了解打包），某些支持文件存
实践实战：在PoC中的Oracle 12c优化器参数推荐（含PPT） 最近，Oracle数据库优化器的产品经理 Nigel Bayliss 发布了一篇文档，介绍：Setting up the Oracle Optimizer for PoCs - 在PoC测试中优化器参数的设置和调节。优化器是Oracle 数据库的核心组件，我们一起来看一看12c 有哪些优化器的变化。 关注本公众号回复关键字：Internals 即可获得本文PPT（SettingUp..），同时附送了一系列的精彩PPT学习资源。 首先，作者描述了POC 测试的基本原则，遵循KISS 原则（Keep it Simple Stupid）,从一个尽可能简单的基线开始；优先考虑稳定性和一致性；通过测试掌控变化；持续向前： 首先，在Oracle 12cR1中，Oracle 引入了一个重要的新特性：自适应查询优化器- Adaptive Query Optimization，该特性的主要功能有两个：
对SQL的执行计划进行运行时（run-time）调整,（也就是在SQL执行过程 中，具备动态改变执行计划的能力）; ? ? 在SQL执行过程中，动态统计和发现新的统计信息，以实现更佳的执行计 划； ? 通过这个特性的描述，我们可以知道，当现有统计数据不足以生成最佳计划时，自适应查询优化器会很有用；当然相反方向是，如果我们数据库中执行计划是稳定的、优化的、满足需要的，那么这个新的特性对我们就基本不需要。 下图展示了这个新特性的两个路径：自适应执行计划、自适应统计信息。在12.1版本中，是否启用自适应优化器参数由初始化参数optimizer_adaptive_features决定。 基于在执行过程中获得的真实统计信息，优化器动态调整执行计划的能力可以极大地提高查询性能。 下图展示了一个最常见的场景，基于静态统计信息，Oracle选择了Nest Loop的执行计划，当执行中动态统计信息（自适应统计信息）被收集之后，SQL的执行计划自动变更为Hash Join 的执行方式。
Oracle 12c入门第一讲: Oracle 12c基本体系结构(1) 摘要: DataBi独家发布Oracle 12C 入门系列Oracle 12c基本结构简介，将容器数据库和传统的非容器数据库放在同一个server上比对，很容易概括出Oracle公司即将推出的Oracle 12c容器数据库和可插拔式数据库的基本架构。... ... https://www.doczj.com/doc/1e1212384.html, 独家发布Oracle 12c入门系列第一讲: Oracle 12c基本结构简介 将容器数据库和传统的非容器数据库放在同一个server上比对，很容易概括出Oracle公司即将推出的Oracle 12c容器数据库和可插拔式数据库的基本架构。 从文件角度： 在图示存储设备上保存着5个数据库的文件：分别是PDBA、PDBB、PDBC、CDB1和NDB。其中PDBA、PDBB、PDBC均属于容器数据库CDB1的可插拔式数据库，NDB 则为传统的非容器数据库。所以也可以这样描述：只有两个数据库CDB1和NDB 保存在存储设备上。 从实例角度： 在图示服务器节点上，运行着两个实例：分别是icdb1和i1，对应的数据库分别是CDB1和NDB。可以清楚地看到只有容器数据库和非容器数据库才有对应的
实例，可插拔式数据库PDBA、PDBB和PDBC共用容器数据库的实例—icdb1，并没有自身对应的实例。 从服务角度： 传统的非容器数据库可以通过实例名或服务名链接，但是可插拔式数据库只能通过服务名链接。至于容器数据库，就像一个非容器数据库一样，同样可以通过实例名或服务名链接。 这些基本概念是深入理解容器数据库的基础。
Oracle 12c入门第二讲: Oracle 12c体系结构 (2) 摘要: 在一个Oracle database 12c server上通过容器数据库集中三个应用的数据。其数据分别被部署到三个可插拔式数据库中. 在一个database server上通过容器数据库集中三个应用的数据。其数据分别被部署到三个可插拔式数据库中，名为App1、App2和App3: 图片上展示的是一个容器数据库，其内包含4个容器：Root容器和三个可插拔式数据库。每个可插拔式数据库为特定应用提供数据，它们既可以被三个不同的DBA管理也能够由一个容器数据库DBA统一管理，即用户SYS。 用户SYS在这种架构中是典型的“通用”用户，SYS可以登录在全部4个容器上，并且具备SYSDBA权限。 可插拔式数据库的一种定义是：一系列Schema的集合，从用户和应用看来是一个逻辑上独立的数据库。但是在物理角度上，实例和所有数据库文件都是属于容器数据库的。 通过将非容器数据库作为可插拔式数据库“插入”容器数据库，很容易实现数据集中。容器数据库避免了以下结构不必要的冗余： a. 后台进程
Oracle 12C引入了CDB与PDB的新特性，在ORACLE 12C数据库引入的多租用户环境（Multitenant Environment）中，允许一个数据库容器（CDB）承载多个可插拔数据库（PDB）。CDB全称为Container Database，中文翻译为数据库容器，PDB全称为Pluggable Database，即可插拔数据库。在ORACLE 12C之前，实例与数据库是一对一或多对一关系（RAC）：即一个实例只能与一个数据库相关联，数据库可以被多个实例所加载。而实例与数据库不可能是一对多的关系。当进入ORACLE 12C后，实例与数据库可以是一对多的关系。下面是官方文档关于CDB与PDB的关系图。 CDB组件（Components of a CDB） 一个CDB数据库容器包含了下面一些组件： ROOT组件 ROOT又叫CDB$ROOT, 存储着ORACLE提供的元数据和Common User,元数据的一个例子是ORACLE提供的PL/SQL包的源代码，Common User 是指在每个容器中都存在的用户。 SEED组件 Seed又叫PDB$SEED,这个是你创建PDBS数据库的模板，你不能在Seed中添加或修改一个对象。一个CDB中有且只能有一个Seed. 这个感念，个人感觉非常类似SQL SERVER 中的model数据库。 PDBS CDB中可以有一个或多个PDBS，PDBS向后兼容，可以像以前在数据库中那样操作PDBS，这里指大多数常规操作。 这些组件中的每一个都可以被称为一个容器。因此，ROOT(根)是一个容器，Seed(种子)是一个容器，每个PDB是一个容器。每个容器在CDB中都有一个独一无二的的ID和名称。 南京宝云教育