Creating the Recovery Catalog Schema

Working with the Recovery Catalog

Using the recovery catalog is purely optional, as Oracle can use the control file to store the RMAN repository data (metadata). However, as explained earlier in this chapter, it's a good idea to spend the little time it takes to create and use the recovery catalog. I assume the use of the recovery catalog in the discussions in this and the next chapter.

 Tip 

Make sure that the database in which the recovery catalog is being created runs in archivelog mode. This ensures that you can always perform a PITR.

To create the recovery catalog, you must first connect to the database in which you want to create the recovery catalog. You need to create a new recovery catalog owner schema (usually named rman), grant the necessary privileges to it, and then create the recovery catalog. Once you create the catalog, you can register databases in it.

Creating the Recovery Catalog Schema

In order to use the recovery catalog, you need to first create a recovery catalog schema. You can create this schema or user in an existing tablespace or in a new tablespace created for this purpose. The recovery catalog itself is stored in the default tablespace of this schema. The following example creates a schema called rman:

SQL> CREATE USER RMAN IDENTIFIED BY rman
     TEMPORARY TABLESPACE temp
     DEFAULT TABLESPACE rman_tbsp
     QUOTA UNLIMITED ON rman_tbsp
User created.
SQL>

Make sure you first create the rman_tbsp tablespace for the user rman.

Making the Necessary Grants

The new rman schema owner, rman, needs privileges to maintain and query the recovery catalog. You do this by granting the user the RECOVERY_CATALOG_OWNER role. The following code shows how to make the necessary grants to user rman:

SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
Grant succeeded.
SQL>
Connecting to RMAN

You can connect to RMAN in one of two ways. One way is to first invoke RMAN, and then use the CONNECT CATALOG command to connect to it, as shown here (nicko is the database containing the recovery catalog in this example):

$ rman
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:36:34 2008
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
RMAN> CONNECT CATALOG rman/rman@nicko
connected to recovery catalog database
RMAN>

You can also connect directly from the operating system level, as follows:

$ rman CATALOG rman/rman@nicko
connected to recovery catalog database
RMAN>

When you connect to the catalog database directly, you still aren't connected to the target database (unless the target and the catalog database are the same). To connect to the target database, you must now use the following command from within the RMAN interface (nina is the target database name):

RMAN> connect target nina
Connected to target database: NINA (DBID=1974138212)
RMAN>

Instead of first connecting to the recovery catalog and then to the target database, you can use the following method to connect to the recovery catalog and to the target database in one step:

$  rman catalog rman/rman@nicko target nina
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:36:34 2008
Copyright (c) 1982, 2007, Oracle.  All rights reserved.target database password:
connected to target database: NINA (DBID=1974138212)
connected to recovery catalog database
RMAN>

 Tip 

Although you can create the recovery catalog schema in the target database itself, Oracle recommends that you use a dedicated recovery catalog database, to secure the recovery catalog. This way, if the target database needs to be recovered, you'll have the necessary recovery data available in the recovery catalog.

Creating the Recovery Catalog

If you want to utilize the recovery catalog (instead of the default method of using the control file) to store the RMAN metadata, you must first create it in the recovery catalog owner's (rman) schema.

First, connect to the catalog database in one of the two ways shown in the previous section. Next, use the CREATE CATALOG command, which will create the recovery catalog:

RMAN> CREATE CATALOG;
recovery catalog created
RMAN>

The CREATE CATALOG command creates the RMAN recovery catalog in the tablespace rman_tbsp, which you assigned as the default tablespace for the user rman.

The DROP CATALOG command will remove the recovery catalog:

RMAN> DROP CATALOG;
Recovery catalog owner is RMAN
Enter DROP CATALOG command again to confirm catalog removal
RMAN> DROP CATALOG;
Recovery catalog dropped
RMAN>.
Registering a Database

For RMAN to do its job, you need to register the target database you want to back up and recover. Registration means that a database is enrolled in the recovery catalog. Once you register the database, RMAN will automatically get all the relevant metadata pertaining to the target database and store it in its own schema.

You don't need a separate recovery catalog for each of your Oracle databases; you can register all your databases in a single recovery catalog.

To register a new database in the recovery catalog, first connect to the target database:

$ rman catalog rman/rman@nicko target nina
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:36:34 2008
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
target database Password:
connected to target database: NINA (DBID=1974138212)
connected to recovery catalog database
RMAN>


 Caution 

Make sure you set the ORACLE_SID to the target database SID before you register a database in the recovery catalog. Otherwise, when you specify the target, you'll connect to the database whose instance name matches the ORACLE_SID of your UNIX session, not to the target database.

Next, register the database in the recovery catalog:

RMAN> REGISTER DATABASE;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN>

The target database is now successfully registered in the recovery catalog. At this point, you can use the REPORT SCHEMA command to make sure all the datafiles of the target database show up in the list.

You can also issue the following command to check the incarnation of the database:

RMAN> LIST INCARNATION;
List of Database Incarnations
DB Key  Inc Key DB Name      DB ID      STATUS   Reset SCN   Reset Time
------- ------- -------- -----------  ---------- ----------  -----------
1        8       NINA     1974138212    PARENT        1      11-JAN-08
1        2       NINA     1974138212    CURRENT  318842      05-JUN-08
RMAN>

Maintaining the Recovery Catalog

If you choose to create and use a recovery catalog, you must know how to maintain it. The following sections explain important recovery catalog maintenance tasks.

Resynchronizing the Recovery Catalog

Changes made to the target database structure aren't automatically propagated to the recovery catalog. The BACKUP and COPY commands automatically perform a resynchronization each time you perform a backup or copy. But you may need to manually resynchronize the recovery catalog under two circumstances: when your target database has just undergone a number of physical changes and when the target database is performing a very large number of log switches in between the backups.

During a resync operation, RMAN reads the target database's control file to update the information it keeps regarding datafiles, log switches, physical schema, and so forth. Oracle recommends that you resynchronize the recovery catalog after making any changes to the physical structure of a target database. You issue the RESYNC CATALOG command as follows, after connecting to the target database:

RMAN> RESYNC CATALOG;
starting full resync of recovery catalog
full resync complete
RMAN>
Backing Up the Recovery Catalog

You should always back up the recovery catalog database immediately after you back up the target database. Backing up the recovery catalog becomes even more critical if you're using a single recovery catalog to store the metadata of all the databases in your system. You should follow these principles to afford the maximum possible security to the recovery catalog database:

  • Back up the recovery catalog on a frequent basis.

  • Never store the recovery catalog in the target database. You could end up losing the target database and the recovery catalog at the same time if there's a media failure.

  • Always run the database holding the recovery catalog in archivelog mode.

  • Make multiple copies of the recovery catalog database backup, preferably to tape, in addition to disk backups.

  • Set the retention policy to a value greater than 1.

  • Set CONTROLFILE AUTOBACKUP to ON, thus ensuring that you can always recover the recovery catalog database, provided you have the control file auto-backup on hand.

  • Set a very high value for CONTROL_FILE_RECORD_KEEP_TIME, so the control file won't be over-written quickly, wiping out your RMAN repository data.

Note that in addition to using RMAN to back up the recovery catalog database, you can use the Data Pump Export utility to create logical backups of the recovery catalog database.

Recovering the Recovery Catalog

In order to restore and recover the recovery catalog database, you must first restore the control file and the server parameter file for the database from the auto-backups you made earlier. You can then restore and recover the database itself.

If you have failed to make backups of your recovery catalog, or if you have made the backups but are unable to use them (perhaps because you have lost parts of them), you must re-create the recovery catalog. You can re-create the recovery catalog in one of the following ways:

  • Execute the RESYNC CATALOG command to update the recovery catalog with the repository information from the control file of the target database. Of course, any aged out metadata will be lost for good.

  • Execute the CATALOG START WITH . . . command to recatalog any available backups.

Cataloging Backups

You can issue the CATALOG command to catalog older backups in the recovery catalog. By issuing the CATALOG command, you can catalog older backups that have aged out of the control file, thus enabling RMAN to use those backups during a file restore operation. Here's an example that shows how to use the CATALOG command:

RMAN> CATALOG DATAFILECOPY '/u01/old_backups/users01.dbf';

You can execute the CATALOG START WITH command to catalog multiple files in a directory, as shown here:

RMAN> CATALOG START WITH '/u01/old_backups/';

RMAN waits for your confirmation after listing each file, before adding the file to the recovery catalog.

Upgrading the Recovery Catalog

If your RMAN client is from the Oracle 11.1 release, but the recovery catalog schema is from an older version, you must upgrade the recovery catalog. You can determine the schema version of the recovery catalog by executing the following query:

SQL> SELECT * FROM rcver;

VERSION
---------
10.02.00

If the output of this query shows multiple rows, the highest version number is the catalog schema version. In our example, there's only one version number, 10.2.0, meaning that the catalog version is 10.2.0.

In order to upgrade the recovery catalog, follow these steps:

  1. If the recovery catalog owner that you created is from a release before 10.1, execute the following GRANT command (assuming that rman is the catalog owner):

    SQL> GRANT CREATE TYPE TO rman;
    
  2. Start RMAN and connect to the recovery catalog database.

    RMAN> connect catalog rman/rman;
    
  3. Execute the UPGRADE CATALOG command.

    RMAN> UPGRADE CATALOG;
    
  4. Confirm the command by rerunning it.

    RMAN> UPGRADE CATALOG;
    

You can now use the recovery catalog with the RMAN client from the Oracle Database 11g release.

Importing Recovery Catalogs

You may have multiple recovery catalogs, each taking care of databases from different versions of the Oracle database. You can consolidate those recovery catalogs into one catalog, by using the IMPORT CATALOG command. By default, the command imports metadata for all databases registered in the source recovery catalog to the destination recovery catalog. You can, however, specify the databases you want to import into the destination catalog. Also by default, RMAN unregisters an imported database from the source recovery catalog, but you can retain the imported databases in the source catalog by adding the NO UNREGISTER clause to the IMPORT CATALOG command.

Your target databases, recovery catalog databases, and the recovery catalog schema can be from different database versions. However, Oracle recommends that you consolidate all your recovery catalogs into a single catalog at the most recent version of the recovery catalog schema. The IMPORT CATALOG command helps you do this.

In the following example, I use the IMPORT CATALOG command to merge two recovery catalogs, one from the 10.2 release and the other from 11g, into a single 11g release catalog schema. Here are the steps:

  1. Connect to the destination recovery catalog.

    $ rman
    RMAN> connect catalog rman/rman@rman11
    
    
  2. Issue the IMPORT CATALOG command along with the connection information for the source recovery catalog (rman10) in step 1.

    RMAN> import catalog rman1/rman1@rman10;
    Starting import catalog at 30-MAR-08
    connected to source recovery catalog database
    import validation complete
    database unregistered from the source recovery catalog
    Finished import catalog at 30-MAR-08
    RMAN>
    

By default, the IMPORT CATALOG command imports all the registered databases from the source catalog into the destination catalog, but you can specify a particular database or databases, as shown here:

RMAN> import catalog rman10/rman10@tenner
       dbid = 123456, 1234557;
RMAN> import catalog rman10/rman10@tenner
      db_name = testdb, mydb;

The first example shows how you can specify one or more database identifiers (DBIDs), whereas the second example shows how you can give the names of databases to import. In either case, you are able to limit the import to a specific database or databases.

Moving the Recovery Catalog

You can move the recovery catalog to a different database by using the IMPORT CATALOG command. First, create an empty recovery catalog into the destination database and then issue the IMPORT CATALOG command, as shown in the following example:

$ rman
RMAN> connect catalog rman/rman@target_db
RMAN> import catalog rman10/rman10@source_db;

The IMPORT CATALOG command moves the recovery catalog contents to the destination database.

The IMPORT CATALOG command imports the source_db recovery catalog contents to a catalog in the target_db database.

Dropping a Recovery Catalog

Execute the DROP CATALOG command to remove a recovery catalog, as shown here:

RMAN> DROP CATALOG;

When you drop the recovery catalog, the actual backups made by RMAN will be untouched. The control files of the target database will contain records of the most recent backups made by RMAN. You can re-create the recovery catalog and register the target database to make the existing backups usable by RMAN again.


### LlamaIndex 多模态 RAG 实现 LlamaIndex 支持多种数据类型的接入与处理,这使得它成为构建多模态检索增强生成(RAG)系统的理想选择[^1]。为了实现这一目标,LlamaIndex 结合了不同种类的数据连接器、索引机制以及强大的查询引擎。 #### 数据连接器支持多样化输入源 对于多模态数据的支持始于数据收集阶段。LlamaIndex 的数据连接器可以从多个异构资源中提取信息,包括但不限于APIs、PDF文档、SQL数据库等。这意味着无论是文本还是多媒体文件中的内容都可以被纳入到后续的分析流程之中。 #### 统一化的中间表示形式 一旦获取到了原始资料之后,下一步就是创建统一而高效的内部表达方式——即所谓的“中间表示”。这种转换不仅简化了下游任务的操作难度,同时也提高了整个系统的性能表现。尤其当面对复杂场景下的混合型数据集时,良好的设计尤为关键。 #### 查询引擎助力跨媒体理解能力 借助于内置的强大搜索引擎组件,用户可以通过自然语言提问的形式轻松获得所需答案;而对于更复杂的交互需求,则提供了专门定制版聊天机器人服务作为补充选项之一。更重要的是,在这里实现了真正的语义级关联匹配逻辑,从而让计算机具备了一定程度上的‘认知’功能去理解和回应人类意图背后所蕴含的意义所在。 #### 应用实例展示 考虑到实际应用场景的需求多样性,下面给出一段Python代码示例来说明如何利用LlamaIndex搭建一个多模态RAG系统: ```python from llama_index import GPTSimpleVectorIndex, SimpleDirectoryReader, LLMPredictor, PromptHelper, ServiceContext from langchain.llms.base import BaseLLM import os def create_multi_modal_rag_system(): documents = SimpleDirectoryReader(input_dir='./data').load_data() llm_predictor = LLMPredictor(llm=BaseLLM()) # 假设已经定义好了具体的大型预训练模型 service_context = ServiceContext.from_defaults( chunk_size_limit=None, prompt_helper=PromptHelper(max_input_size=-1), llm_predictor=llm_predictor ) index = GPTSimpleVectorIndex(documents, service_context=service_context) query_engine = index.as_query_engine(similarity_top_k=2) response = query_engine.query("请描述一下图片里的人物表情特征") print(response) ``` 此段脚本展示了从加载本地目录下各类格式文件开始直到最终完成一次基于相似度排序后的top-k条目返回全过程。值得注意的是,“query”方法接收字符串参数代表使用者想要询问的内容,而在后台则会自动调用相应的解析模块并结合先前准备好的知识库来进行推理计算得出结论。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值