版次注意事項


7.6 Chapter 8. Recovering a Database

|7.6.1 How to Use Suspended I/O

| | | | |

|In Chapter 8."Recovering a Database", the following new section on |using the suspended I/O function is to be added:

|Note:
The information below about the db2inidb utility supercedes |the information in the Version 7.2 What's New book. |

|db2inidb is a new tool shipped with DB2 that can perform crash recovery |and put a database in rollforward pending state.

|Suspended I/O supports continuous system availability by providing a full |implementation for online split mirror handling, that is, splitting a mirror |without shutting down the database. If a customer cannot afford doing offline |or online backups on a large database, backups or system copies can be done |from a mirror image by using suspended I/O and split mirror.

|Depending on how the storage devices are being mirrored, the uses of db2inidb |will vary. The following uses assume that the entire database is mirrored |consistently through the storage system.

|In a multi-node environment, the db2inidb tool must be run on |every partition before the split image can be used from any of the partitions. |The db2inidb tool can be run on all partitions simultaneously.

| |

  1. |Making a Clone Database

    |The objective here is to have a clone of the |primary database to be used for read-only purposes. The following procedure |describes how a clone database may be made: |

    1. |Suspend I/O on the primary system by entering the following command:
      |     db2 set write suspend for database
    2. |Use the operating system level command to split the mirror from the primary |database.
    3. |Resume I/O on primary system by entering the following command:
      |     db2 set write resume for database

      |After running the command, the |database on the primary system should be back to a normal state.

    4. |Attach to the mirrored database from another machine.
    5. |Start the database instance by entering the following command:
      |     db2start
    6. |Start the DB2 crash recovery by entering the following command:
      |db2inidb database_name AS  SNAPSHOT

      |

      |Note:
      This command |will rollback the changes made by transactions that are inflight at the time |of the split. |
      |

    |You can also use this process for an offline backup, |but if restored on the primary system, this backup cannot be used to roll |forward, because the log chain will not match. |

  2. |Using the Split Mirror as a Standby Database

    |As the mirrored (standby) |database is continually rolling forward through the logs, new logs that are |being created by the primary database, are constantly fetched from the primary |system. The following procedure describes how the split mirror can be used |as a standby database: |

    1. |Suspend I/O writes on the primary database.
    2. |Split the mirror from the primary system.
    3. |Resume the I/O writes on the primary database so that the primary database |goes back to normal processing.
    4. |Attach the mirrored database to another instance.
    5. |Place the mirror in roll-forward pending and roll forward the mirror. |Run the db2inidb tool (db2inidb <db_alias> as standby) to remove the suspend |write state and to place the mirrored database in a roll-forward pending state.
    6. |Copy logs by setting up a user exit program to retrieve log files from |the primary system to ensure that the latest logs will be available for this |mirrored database.
    7. |Roll forward the database to the end of the logs.
    8. |Go back to step f and repeat this process until the primary database is |down. |

    |

  3. |Using the Split Mirror as a Backup Image

    |The following procedure describes |how to use the mirrored system as a backup image to restore over the primary |system: |

    1. |Use operating system commands to copy the mirrored data and logs on top |of the primary system.
    2. |Start the database instance by entering the following command:
      |     db2start
    3. |Run the following command to place the mirrored database in a roll-forward |pending state and to remove the suspend write state.
      |db2inidb database_alias AS MIRROR
    4. |Roll forward the database to the end of the logs. |
    |

|7.6.2 Incremental Backup and Recovery

|In Chapter 8,"Recovering a Database," the following is a new section |about incremental backup and recovery: | | | |

|As the size of databases, and particularly warehouses, continues to expand |into the terabyte and petabyte range, the time and hardware resources required |to back up and recover these databases are also growing substantially. Full |database and table space backups are not always the best approach when dealing |with large databases, because the storage requirements for multiple copies |of such databases are enormous. Consider the following issues: |

|DB2 now supports incremental backup and recovery (but not of long field |or large object data). An incremental backup |is a backup image that contains only pages that have been updated since the |previous backup was taken. In addition to updated data and index pages, each |incremental backup image also contains all of the initial database meta-data |(such as database configuration, table space definitions, database history, |and so on) that is normally stored in full backup images.

|Two types of incremental backup are supported: |

|The key difference between incremental and delta backup images is their |behavior when successive backups are taken of an object that is continually |changing over time. Each successive incremental image contains the entire |contents of the previous incremental image, plus any data that has changed, |or is new, since the previous backup was produced. Delta backup images contain |only the pages that have changed since the previous image was produced.

|Combinations of database and table space incremental backups are permitted, |in both online and offline modes of operation. Be careful when planning |your backup strategy, because combining database and table space incremental |backups implies that the predecessor of a database backup (or a table space |backup of multiple table spaces) is not necessarily a single image, but could |be a unique set of previous database and table space backups taken at different |times.

|To rebuild the database or the table space to a consistent state, the recovery |process must begin with a consistent image of the entire object (database |or table space) to be restored, and must then apply each of the appropriate |incremental backup images in the order described below (see the "Restore |Method" section).

|To enable the tracking of database updates, DB2 supports a new database |configuration parameter, TRACKMOD, which can have one of two accepted values: |

|The default TRACKMOD setting for existing databases is NO; |for new databases, it is YES.

|The granularity of the tracking is at the table space level for both SMS |and DMS table spaces.

|Although minimal, the tracking of updates to the database can have an impact |on the run-time performance of transactions that update or insert data.

|7.6.2.1 Restoring from Incremental Backup Images

|A restore operation from incremental backup images always consists of the |following steps: |

  1. |Identifying the incremental target image.The DBA must first determine |the final image to be restored, and request an incremental restore operation |from the DB2 restore utility. This image is known as the target image of |the incremental restore, because it will be the last image to be restored. |An incremental restore command against this image may initiate the creation |of a new database with the configuration and table space definitions from |this target image. The incremental target image is specified using the TAKEN |AT parameter in the RESTORE DATABASE command.
  2. |Restoring the most recent full database or table space image to establish |a baseline against which each of the subsequent incremental backup images |can be applied.
  3. |Restoring each of the required full or table space incremental backup |images, in the order in which they were produced, on top of the baseline |image restored in Step 2.
  4. |Repeating Step 3 until the target image from Step 1 is read a second time. |The target image is accessed twice during a complete incremental restore |operation. During the first access, only initial data is read from the image; |none of the user data is read. The complete image is read and processed only |during the second access.

    |The target image of the incremental restore operation |must be accessed twice to ensure that the database is initially configured |with the correct history, database configuration, and table space definitions |for the database that will be created during the restore operation. In cases |where a table space has been dropped since the initial full database backup |image was taken, the table space data for that image will be read from the |backup images but ignored during incremental restore processing. |

|For example:

|   1. db2 restore database sample incremental taken at <ts>
| 
|      where:
|        <ts> points to the last incremental backup image to be restored
| 
|   2. db2 restore database sample incremental taken at <ts1>
| 
|      where:
|        <ts1> points to the initial full database (or table space) image
| 
|   3. db2 restore database sample incremental taken at <tsX>
| 
|      where:
|        <tsX> points to each incremental backup image in creation sequence
| 
|   4. Repeat Step 3, restoring each incremental backup image up to and including image <ts>

|In cases where a database restore operation is being attempted, and table |space incremental backup images have been produced, the table space images |must be restored in the chronological order of their backup time stamps.

|7.6.3 Parallel Recovery

| |

|DB2 now uses multiple agents to perform both crash recovery and database |rollforward recovery. You can expect better performance during these operations, |particularly on symmetric multi-processor (SMP) machines; using multiple agents |during database recovery takes advantage of the extra CPUs that are available |on SMP machines.

|The new agent type introduced by this enhancement is db2agnsc. DB2 chooses |the number of agents to be used for database recovery based on the number |of CPUs on the machine. For SMP machines, the number of agents used is (number |of CPUs + 1). On a machine with a single CPU, three agents are used for |more efficient reading of logs, processing of log records, and prefetching |of data pages.

|DB2 distributes log records to these agents so that they can be reapplied |concurrently, where appropriate. The processing of log records is parallelized |at the page level (log records on the same data page are processed by the |same agent); therefore, performace is enhanced, even if all the work was done |on one table.

|7.6.4 Backing Up to Named Pipes

| |

|Support is now available for database backup to (and database restore from) |local named pipes on UNIX based systems. Both the writer and the reader of |the named pipe must be on the same machine. The pipe must exist and be located |on a local file system. Because the named pipe is treated as a local device, |there is no need to specify that the target is a named pipe. Following is |an AIX example:

|  1. Create a named pipe:
|      mkfifo /u/dbuser/mypipe
| 
|  2. Use this pipe as the target for a database backup operation:
|      db2 backup db sample to /u/dbuser/mypipe
| 
|  3. Restore the database:
|      db2 restore db sample into mynewdb from /u/dbuser/mypipe

|7.6.5 Backup from Split Image

|

|DB2 now supports a full offline database backup on the split mirrored copy |of a database. Online backup is not supported and is not necessary because |the database, which is in rollforward pending state, is unavailable. When |a split mirrored backup image is restored, it must be rolled forward because |there may have been active transactions when the split occurred.

|Note:
For DB2 Version 7.1 FixPak 3 and DB2 Version 7.2 this support |will be limited to databases that contain DMS table spaces only. If an attempt |is made to back up a database after a split and the database contains any |SMS table spaces, the backup will fail. |

|Once a database has been split, the db2inidb |utility must be used to specify one of the following options: |

|Following are some usage scenarios: |

|7.6.6 On Demand Log Archive

| | |

|DB2 now supports the closing (and, if the user exit option is enabled, |the archiving) of the active log for a recoverable database at any time. |This allows you to collect a complete set of log files up to a known point, |and then to use these log files to update a standby database.

|Note:
|On demand log archiving does not guarantee the |log files will be archived immediately; it truncates the log file and issues |an archive request, but it is still subject to delays associated with the |user exit program |

|You can initiate on demand log archiving by invoking the new DB2 ARCHIVE |LOG command, or by calling the new db2ArchiveLog |API.

|7.6.7 Log Mirroring

| | |

|In Chapter 8,"Recovering a Database," the following new section on |using the suspended I/O function is to be added:

|DB2 now supports log mirroring at the database level. Mirroring log files |helps protect a database from: |

|If you are concerned that your active logs may be damaged (as a result |of a disk crash), you should consider using a new DB2 registry variable, DB2_NEWLOGPATH2, |to specify a secondary path for the database to manage copies of the active |log, mirroring the volumes on which the logs are stored.

|The DB2_NEWLOGPATH2 registry variable allows the database to write |an identical second copy of log files to a different path. It is recommended |that you place the secondary log path on a physically separate disk (preferably |one that is also on a different disk controller). That way, the disk controller |cannot be a single point of failure.

|Note:
Because Windows NT and OS/2 do not allow "mounting" a device |under an arbitrary path name, it is not possible (on these platforms) to specify |a secondary path on a separate device. |

|DB2_NEWLOGPATH2 can be enabled (set to 1) or disabled (set |to 0). The default value is zero. If this variable is set to 1, the secondary path name is the current value of the LOGPATH variable |concatenated with the character 2. For example, in an SMP environment, |if LOGPATH is /u/dbuser/sqllogdir/logpath, the secondary log path |will be /u/dbuser/sqllogdir/logpath2. In an MPP environment, if |LOGPATH is /u/dbuser/sqllogdir/logpath, DB2 will append the node |indicator to the path and use /u/dbuser/sqllogdir/logpath/NODE0000 |as the primary log path. In this case, the secondary log path will be /u/dbuser/sqllogdir/logpath2/NODE0000.

|When DB2_NEWLOGPATH2 is first enabled, it will not actually be used |until the current log file is completed on the next database startup. This |is similar to how NEWLOGPATH is currently used.

|If there is an error writing to either the primary or secondary log path, |the database will mark the failing path as "bad", write a message to the db2diag.log file, and write subsequent log records |to the remaining "good" log path only. DB2 will not attempt to use the "bad" |path again until the current log file is completed. When DB2 needs to open |the next log file, it will verify that this path is valid, and if so, will |begin to use it. If not, DB2 will not attempt to use the path again until |the next log file is accessed for the first time. There is no attempt to synchronize |the log paths, but DB2 keeps information about access errors that occur, |so that the correct paths are used when log files are archived. If a failure |occurs while writing to the remaining "good" path, the database abends.

|7.6.8 Cross Platform Backup and Restore Support on Sun Solaris and HP

| |

|Support is now available for cross platform backup and restore support |between Sun Solaris and HP. When you transfer the backup image between systems, |you must transfer it in binary mode. On the target system, the database must |be created with the same code page/territory as the system on which the original |database was created.

|7.6.9 DB2 Data Links Manager Considerations/Backup Utility Considerations

|Replace the second paragraph in this section with:

|   When files are linked, the Data Links servers schedule them to be copied
|   asynchronously to an archive server such as ADSM, or to disk.
|   When the backup utility runs, DB2 ensures that all files scheduled
|   for copying have been copied. At the beginning of backup processing,
|   DB2 contacts all Data Links servers that are specified in the DB2
|   configuration file. If a Data Links server has one or more linked files
|   and is not running, or stops running during the backup operation, the backup
|   will not contain complete DATALINK information. The backup operation
|   will complete successfully. Before the Data Links server can be marked
|   as available to the database again, backup processing for all outstanding
|   backups must complete successfully. If a backup is initiated when there
|   are already twice the value of num_db_backups (see below) outstanding
|   backups waiting to be completed on the Data Links server, the backup
|   operation will fail. That Data Links server must be restarted
|   and the outstanding backups completed before additional backups are allowed.

|7.6.10 DB2 Data Links Manager Considerations/Restore and Rollforward Utility Considerations

|Replace paragraphs beginning with:

|   When you restore a database or table space and do not specify
|   the WITHOUT DATALINK...
| 
|   and
| 
|   When you restore a database or table space and you do specify
|   the WITHOUT DATALINK option...

|with:

|   When you restore a database or table space, the following conditions
|   must be satisfied for the restore operation to succeed:
| 
|   o If any Data Links Server recorded in the backup file is not running,
|     the restore operation will still complete successfully.
| 
|     Tables with DATALINK column information that are affected by the missing
|     Data Links server will be put into datalink reconcile pending state
|     after the restore operation (or the rollforward operation, if used) completes.
|     Before the Data Links servers can be marked as available to the database
|     again, this restore processing must complete successfully.
| 
|   o If any Data Links Server recorded in the backup file stops running during
|     the restore operation, the restore operation will fail. The restore can
|     be restarted with the Data Links Server down (see above).
| 
|   o If a previous database restore operation is still incomplete on any
|     Data Links server, subsequent database or table space restore operations
|     will fail until those Data Links servers are restarted, and the incomplete
|     restore is completed.
| 
|   o Information about all DATALINK columns that are recorded in the backup
|     file must exist in the appropriate Data Links servers' registration tables.
| 
|     If all the information about the DATALINK columns is not recorded
|     in the registration tables, the table with the missing DATALINK column
|     information is put into datalink reconcile not possible state after
|     the restore operation (or the roll-forward operation, if used) completes.
| 
|     If the backup is not recorded in the registration tables, it may mean
|     that the backup file that is provided is earlier than the value for
|     num_db_backups and has already been "garbage collected". This means that
|     the archived files from this earlier backup have been removed and cannot
|     be restored. All tables that have DATALINK columns are put into datalink
|     reconcile pending state.
| 
|     If the backup is not recorded in the registration tables, it may mean that
|     backup processing has not yet been completed because the Data Links server
|     is not running. All tables that have DATALINK columns are put into datalink
|     reconcile pending state. When the Data Links server is restarted,
|     backup processing will be completed before restore processing.
| 
|     The table remains available to users, but the values in the DATALINK
|     columns may not reference the files accurately (for example, a file
|     may not be found that matches a value for the DATALINK column). If you
|     do not want this behavior, you can put the table into check pending state
|     by issuing the "SET CONSTRAINTS for tablename TO DATALINK RECONCILE PENDING"
|     statement.

|If, after a restore operation, you have a table in datalink reconcile not |possible state, you can fix the DATALINK column data in one of the ways suggested |under "Removing a Table from the Datalink_Reconcile_Not_Possible State".

|The note at the bottom of the first paragraph remains the same.

|Add the following at the end of this section:

|   It is strongly recommended that the datalink.cfg file be archived
|   to cover certain unusual recovery cases, since the datalink.cfg file
|   in the database backup image only reflects the datalink.cfg as of
|   the backup time. Having the latest datalink.cfg file is required
|   to cover all recovery cases. Therefore, the datalink.cfg file must
|   be backed up after every ADD DATALINKS MANAGER or DROP DATALINKS MANAGER
|   command invocation. This would help to retrieve the latest
|   datalink.cfg file, if the latest datalink.cfg file is not available on disk.
| 
|   If the latest datalink.cfg file is not available on disk, replace
|   the existing datalink.cfg file (restored from a backup image) with the latest
|   datalink.cfg file that was archived before running a rollforward operation.
|   Do this after the database is restored.

|7.6.11 Restoring Databases from an Offline Backup without Rolling Forward

|You can only restore without rolling forward at the database level, not |the table space level. To restore a database without rolling forward, you |can either restore a nonrecoverable database (that is, a database that uses |circular logging), or specify the WITHOUT ROLLING FORWARD parameter on the |RESTORE DATABASE command.

|If you use the restore utility with the WITHOUT DATALINK option, all tables |with DATALINK columns are placed in datalink reconcile pending (DRP) state, |and no reconciliation is performed with the Data Links servers during the |restore operation.

|If you do not use the WITHOUT DATALINK option, and a Data Links server |recorded in the backup file is no longer defined to the database (that is, |it has been dropped using the DROP DATALINKS MANAGER command), tables that |contain DATALINK data referencing the dropped Data Links server are put in |DRP state by the restore utility.

|If you do not use the WITHOUT DATALINK option, all the Data Links servers |are available, and all information about the DATALINK columns is fully recorded |in the registration tables, the following occurs for each Data Links server |recorded in the backup file: |

|

|Note:
The above cannot be done if the backup image that was |used for the database restore operation was taken when at least one Data Links |server was not running, since the DATALINK information in the backup is incomplete. |The above is also not done if the backup image that was used for the database |restore operation was taken after a database restore with or without rollforward. |In both cases, all tables with DATALINK columns are placed in datalink reconcile |pending state, and no reconciliation is performed with the Data Links servers |during the restore operation. |

|7.6.12 Restoring Databases and Table Spaces, and Rolling Forward to the End of the Logs

|If you restore, then roll forward the database or table space to the end |of the logs (meaning that all logs are provided), a reconciliation check is |not required unless at least one of the Data Links servers recorded in the |backup file is not running during the restore operation. If you are not sure |whether all the logs were provided for the roll-forward operation, or think |that you may need to reconcile DATALINK values, do the following: |

  1. |Issue the SQL statement for the table (or tables) involved:

    |   SET CONSTRAINTS FOR tablename TO DATALINK RECONCILE PENDING
    |This puts the table into datalink reconcile pending state and check |pending state.
  2. |If you do not want a table to be in check pending state, issue the following |SQL statement:

    |   SET CONSTRAINTS FOR tablename IMMEDIATE CHECKED
    |This takes the table out of check pending state, but leaves it in datalink |reconcile pending state. You must use the reconcile utility to take the table |out of this state. |

|It may happen that the backup file contains DATALINK data that refers to |a DB2 Data Links Manager (that is, a DB2 Data Links Manager was registered |to the database when the backup was taken) that has been dropped from the |database. For each table space being rolled forward that contains at least |one table with DATALINK data referencing the dropped DB2 Data Links Manager, |all tables are put in DRP state by the rollforward utility.

|7.6.13 DB2 Data Links Manager and Recovery Interactions

| |

|The following table shows the different types of recovery that you can |perform, the DB2 Data Links Manager processing that occurs during restore and roll-forward processing, |and whether you need to run the Reconcile utility after the recovery is complete:
|
Type of Recovery DB2 Data Links Manager Processing during Restore DB2 Data Links Manager Processing during Rollforward Reconcile
Non-recoverable database (logretain=NO)
Database restore of a complete backup, all Data Links Servers up Fast reconcile is performed N/A Can be optionally run if problem with file links is suspected
Database restore using WITHOUT DATALINK option Tables put in Datalink_Reconcile _Pending state N/A Required
Database restore of a complete backup, at least one Data Links server down Fast reconcile is performed only on those tables in table spaces that do not have links to a Data Links server that is down, other tables put in Datalink_Reconcile_Pending state NA Required for tables in table spaces with links to the Data Links server that is down
Database restore of an incomplete backup, all Data Links servers up Fast reconcile is not performed, all tables with DATALINK columns put in Datalink_Reconcile_Pending state NA Required
Recoverable database (logretain=YES)
Database restore using WITHOUT ROLLING FORWARD option, using a complete backup, all Data Links servers up Fast reconcile is performed N/A Optional
Database restore using WITHOUT ROLLING FORWARD and WITHOUT DATALINK options, using a complete or incomplete backup, Data Links servers up or down Tables put in Datalink_Reconcile _Pending state N/A Required
Database restore using WITHOUT ROLLING FORWARD option, using a complete backup, at least one Data Links server down Fast reconcile is performed only on those tables in table spaces that do not have links to the Data Links servers that are down, other tables put in Datalink_Reconcile_Pending state N/A Required on tables in table spaces with links to the Data Links servers that are down
Database restore using WITHOUT ROLLING FORWARD option, using an incomplete backup, Data Links servers up or down Fast reconcile is not performed, all tables with DATALINK columns put into Datalink_Reconcile_Pending state N/A Required
Database restore and roll forward to end of logs, using a complete backup, all Data Links servers up No action No action Optional
Database restore and roll forward to end of logs, using a complete backup, at least one Data Links server down during roll forward processing No action No action Optional
Database restore and roll forward to end of logs, using a complete or an incomplete backup, any Data Links server down during restore No action All tables with DATALINK columns put into Datalink_Reconcile_Pending state Required for all tables with DATALINK columns
Database restore and roll forward to end of logs, using an incomplete backup, all Data Links servers up during restore No action No action Optional
Database restore and roll forward to end of logs, using a complete or an incomplete backup, all Data Links servers up, backup unknown at any Data Links server No action All tables in table spaces with links to a Data Links server where the backup is unknown put in Datalink_Reconcile_Pending state Required
Table space restore and roll forward to end of logs, using a complete backup, all Data Links servers up No action No action Optional
Table space restore and roll forward to end of logs, using a complete backup, at least one Data Links server down during roll forward processing No action No action Optional
Table space restore and roll forward to end of logs, using a complete or an incomplete backup, any Data Links server down during restore processing No action All tables in table spaces with links to any Data Links server that is down put into Datalink_Reconcile_Pending state Required for tables in table spaces with links to any Data Links server that is down
Table space restore and roll forward to end of logs, using an incomplete backup, all Data Links servers up No action No action Optional
Database restore and roll forward to a point in time, using a complete or an incomplete backup, Data Links servers up or down during restore and/or roll forward processing No action Tables put in Datalink_Reconcile _Pending state Required
Table space restore and roll forward to a point in time, using a complete or an incomplete backup, Data Links servers up or down during restore and/or rollfoward processing No action Tables put in Datalink_Reconcile _Pending state Required
Database restore to a different database name, alias, hostname, or instance with no roll forward (NOTE1) Tables put in Datalink_Reconcile _Not_Possible state N/A Optional, but tables in Datalink_Reconcile _Not_Possible state must be manually fixed
Database restore to a different database name, alias, hostname or instance, and roll forward No action Tables put in Datalink_Reconcile _Not_Possible state Optional, but tables in Datalink_Reconcile _Not_Possible state must be manually fixed
Database restore from an unusable backup (image has been garbage-collected on the Data Links server) with no roll forward (NOTE1), with or without WITHOUT DATALINK option Tables put in Datalink_Reconcile _Pending state No action Required
Database restore from an unusable backup (image has been garbage-collected on the Data Links server), and roll forward, with or without WITHOUT DATALINK option No action Tables put in Datalink_Reconcile _Pending state Required
Table space restore from an unusable backup (image has been garbage-collected on the Data Links server), and roll forward No action Tables put in Datalink_Reconcile _Pending state Required

|Note:

  1. |A restore using an offline backup and the WITHOUT ROLLING FORWARD |option (logretain is on), or a restore using |an offline backup (logretain is off).

  2. |A complete backup is a backup taken when |all required Data Links servers were running. An incomplete backup is a backup taken when at least one required Data Links |server was not running.

  3. |Fast reconcile processing will not be performed if the backup image that |was used for the database restore operation was taken after a database restore, |with or without rollforward. In this case, all tables with DATALINK columns |are put in Datalink_Reconcile_Pending state. |

|7.6.14 Detection of Situations that Require Reconciliation

|Following are some situations in which you may need to run the reconcile |utility: |


[ 頁面頂端 | 前一頁 | 下一頁 | 目錄 | 索引 ]