In my last post I wrote down some notes about my experience while experimenting with the ZFSSA simulator. A simulator is a great way to get familiar with the user interface and general usability of a product. What I wanted to find out using the ZFSSA simulator was the answer to the question: “what happens to a clone of a database when I roll the master copy forward?”
In the first part of the series I explained how I created a clone of a database, named CLONE1. It is based on a backup of my NCDB database. On top of the backup I have created a snapshot as the basis for my clone. A clone in ZFS(SA) terminology is a writeable snapshot, and CLONE1 uses it. But what would happen to CLONE1 if I modified the source database, NCDB? And can I create a new clone-CLONE2-based on a new backup of the source without modifying the first clone? Let’s try this.
Changing the Source Database
Let’s change the source database a little by creating a new tablespace with a couple of data files. To add a little bit of spice to the scenario I decided to create a new user. Its only schema object will be created on the new tablespace.
[oracle@oraclelinux7 ~]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Thu Mar 3 17:25:57 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics and Real Application Testing options SQL> create tablespace dropme datafile size 5m; Tablespace created. SQL> alter tablespace dropme add datafile size 5m; Tablespace altered. SQL> grant dba to new_user identified by ...; Grant succeeded. SQL> create table new_user.t1 tablespace dropme as 2 select * from dba_source where rownum <= 100; Table created. SQL>
This should be enough for this quick test.
Backing Up
The next step is to roll my existing image copies forward to reflect the changes. That’s not too hard, essentially you create an incremental backup “for recover of copy” … followed by a recover “copy of database with tag” … When the backup/recover command combination completed you also need to back up the archived logs in a second step.
At the risk of repeating myself, please be careful: adding this procedure to an existing backup strategy might have adverse side effects-as always make sure you understand the implications of this technique and its impact. Test thoroughly!
As with the previous backup I stored the incremental backup “for recover” of my image copies in ‘/zfssa/ncdb_bkp/data/’. That’s a location mounted via NFS from the ZFSSA. This is the same location I previously used for the image copies. There is nothing too exciting to report about the backup.
Just as with the previous post my archived logs went to ‘/zfssa/ncdb_bkp/archive/’ to complete the preparations. Here are the files that were created:
[oracle@oraclelinux7 ~]$ ls -lrt /zfssa/ncdb_bkp/data/ total 3035612 -rw-r-----. 1 oracle asmdba 7192576 Mar 3 17:26 6qqvijpt_1_1 -rw-r-----. 1 oracle asmdba 3702784 Mar 3 17:26 6pqvijps_1_1 -rw-r-----. 1 oracle asmdba 1851392 Mar 3 17:40 6tqvikjv_1_1 -rw-r-----. 1 oracle asmdba 442368 Mar 3 17:40 6sqvikjv_1_1 -rw-r-----. 1 oracle asmdba 5251072 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-DROPME_FNO-7_6uqvikk2 -rw-r-----. 1 oracle asmdba 650125312 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-SYSAUX_FNO-3_6kqvie3k -rw-r-----. 1 oracle asmdba 5251072 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-DROPME_FNO-2_6rqvijq0 -rw-r-----. 1 oracle asmdba 828383232 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-SYSTEM_FNO-1_6jqvie1q -rw-r-----. 1 oracle asmdba 5251072 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-USERS_FNO-6_6mqvie57 -rw-r-----. 1 oracle asmdba 293609472 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-UNDOTBS1_FNO-4_6lqvie4d -rw-r-----. 1 oracle asmdba 1304174592 Mar 3 17:40 data_D-NCDB_I-3358649481_TS-EXAMPLE_FNO-5_6iqvie1p [oracle@oraclelinux7 ~]$ ls -lrt /zfssa/ncdb_bkp/archive/ total 8204 -r--r-----. 1 oracle asmdba 1024 Mar 3 16:06 1_118_905507850.arc -r--r-----. 1 oracle asmdba 2869760 Mar 3 16:06 1_117_905507850.arc -r--r-----. 1 oracle asmdba 1024 Mar 3 17:49 1_120_905507850.arc -r--r-----. 1 oracle asmdba 5426688 Mar 3 17:49 1_119_905507850.arc [oracle@oraclelinux7 ~]$
The image copies are now current, and you can see the 2 data files for the new tablespace “DROPME” that didn’t exist before.
Creating the Second clone Database
With the preparations in place it is time to see if I can create a new clone that reflects the new tablespace and users. I also would like to see if the following steps have any implications on my database CLONE1.
On the ZFSSA Simulator
I headed over to the ZFSSA (simulator) and navigated to shares -> projects. After selecting “NCDB_BKP” I chose Snapshots and hit the (+) button to create snap1. You should see snap0 on that view as well if you are following the examples.
The next task is to create a new project. You should already see the projects pane on the left hand side. Click on the (+) sign next to ALL to create a new one. I named the project NCDB_CLONE2 to stay in line with the naming convention I used previously. With the project created, you should set the properties as needed. I moved the mount point to /export/ncdb_clone2/. On a real ZFSSA you’d set others as well, but that is out of scope of this post. Consult the relevant white papers for more information.
Just as described in the first post now you need to create clones based on snap1. To do so, switch back to the NCDB_BKP project and select (the list of) shares. You should see alert, archive, data and redo. Create clones for each, by following these steps per share:
- Hover the mouse over the share name
- Click on the share’s pencil icon to edit share properties
- Select “snapshots”
- Hover the mouse over the snapshot name, snap1
- In the “Clones” column, click on the [+] sign
- In the resulting pop-up, make sure to create the clone in NCDB_CLONE2 and give it the same name as the share you are creating the snapshot for
The end result should be 4 shares shown in the new project, all of them based on snapshots of their cousins from NCDB_BKP. That concludes the work on the ZFSSA for now.
NB: you can script this :)
On the database Server
If you haven’t done so yet, create the directories to mount the new shares. Everything I mount from the ZFSSA goes to /zfssa on the database server, and as a result I have my files in /zfssa/ncdb_clone2/{alert,archive,data,redo}. Update /etc/fstab accordingly and mount the shares.
The remaining steps are the same as for the creation of CLONE1, and I am not repeating them here. Because it’s very important, here is the warning again: Be careful with the path information in the create controlfile statement and make sure they point to /zfssa/ncdb_clone2/!
Reviewing the Outcome
After CLONE2 is created, my initial questions may be answered.
- Is the new tablespace part of CLONE2?
- Can I access the newly created table new_user.t1 in CLONE2?
- Did anything change for CLONE1?
Starting with CLONE2, I can see the new tablespace, and the data in new_user.t1 is available as well:
SQL> select name from v$database;
NAME
---------
CLONE2
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
EXAMPLE
DROPME
7 rows selected.
SQL> select count(*) from new_user.t1;
COUNT(*)
----------
100
SQL>
And what about CLONE1?
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
EXAMPLE
6 rows selected.
SQL> select count(*) from new_user.t1;
select count(*) from new_user.t1
*
ERROR at line 1:
ORA-00942: table or view does not exist
Well that looks ok!
Martins Blog 