I spent several hours at the NetApp booth at Oracle OpenWorld this week, so I got to talk with lots of Oracle database administrators. For DBAs, FlexClone is the feature that attracted the most attention, especially for test and development environments. When we started the show, we had six different stations showing six different features. By the end, we had four of the six demoing FlexClone.
A FlexClone is a virtual copy. It looks exactly like a real copy, except that it doesn't consume any disk space. The clone uses magic with pointers so that the "copy" refers to all the same blocks on disk as the original. Of course, if you write to a clone, then it does use extra space. The write has to go to a new location on disk to avoid changing the original.
In test and dev, cloning is useful for two reasons.
Reason #1: Physical storage is expensive. If you have a 1 TB database, creating ten copies will cost you 10 TB. Creating ten clones takes no space at all. Of course, writing to the clones will consume space, but most tests overwrite only a small percentage of the database. With clones, you can create more copies, and run more tests in parallel, than if you had to pay for the storage.
I'm talking like the benefit is that you can create more copies, but the reality is that many people run their tests against small artificial data sets. You could argue that the real benefit is not that you get more copies, but that you can run all of your tests on full copies of the live data.
Reason #2: It's fast and easy to return to a known good state. Because no data is copied, creating a clone takes almost no time at all, even for a very large database. This makes it easy to run a test, check the result, make a small change, and then run the test again on the exact same data. Just run each test on a new clone, and blow away the clone when the test is done.
The folks at Oracle University use cloning for their classes. They have 500 classes per week, with a total of 6,500 students, and they have lots of hands-on labs. Before they started using NetApp clones, it took 36 hours to build all of the database instances for the week. With FlexClone, they reduced that to one hour. They just delete the used clones from last week and create new clones for next week. You can imagine a massively parallel test environment using the same approach.
People also use FlexClone in production. There is always some risk when you modify a production environment. It's safer to create a clone and make changes there. When you are convinced that everything worked, then you can put the clone into production. If something went wrong, delete the clone and try again.
I'm sorry if this reads more like a NetApp advertisement than most of my blogs. I'm just telling you, after talking with people all afternoon at our booth, this is the thing that really got them excited.
If you want more details, check out this paper on IBM's web site. (Now that IBM is a NetApp OEM, they put whitepapers about us on their website.) In the paper, they do all the steps manually, but we have a tool called SnapManager for Oracle that automates everything for DBAs who would rather not mess with the storage system themselves.
A FlexClone is a virtual copy. It looks exactly like a real copy, except that it doesn't consume any disk space. The clone uses magic with pointers so that the "copy" refers to all the same blocks on disk as the original. Of course, if you write to a clone, then it does use extra space. The write has to go to a new location on disk to avoid changing the original.
In test and dev, cloning is useful for two reasons.
Reason #1: Physical storage is expensive. If you have a 1 TB database, creating ten copies will cost you 10 TB. Creating ten clones takes no space at all. Of course, writing to the clones will consume space, but most tests overwrite only a small percentage of the database. With clones, you can create more copies, and run more tests in parallel, than if you had to pay for the storage.
I'm talking like the benefit is that you can create more copies, but the reality is that many people run their tests against small artificial data sets. You could argue that the real benefit is not that you get more copies, but that you can run all of your tests on full copies of the live data.
Reason #2: It's fast and easy to return to a known good state. Because no data is copied, creating a clone takes almost no time at all, even for a very large database. This makes it easy to run a test, check the result, make a small change, and then run the test again on the exact same data. Just run each test on a new clone, and blow away the clone when the test is done.
The folks at Oracle University use cloning for their classes. They have 500 classes per week, with a total of 6,500 students, and they have lots of hands-on labs. Before they started using NetApp clones, it took 36 hours to build all of the database instances for the week. With FlexClone, they reduced that to one hour. They just delete the used clones from last week and create new clones for next week. You can imagine a massively parallel test environment using the same approach.
People also use FlexClone in production. There is always some risk when you modify a production environment. It's safer to create a clone and make changes there. When you are convinced that everything worked, then you can put the clone into production. If something went wrong, delete the clone and try again.
I'm sorry if this reads more like a NetApp advertisement than most of my blogs. I'm just telling you, after talking with people all afternoon at our booth, this is the thing that really got them excited.
If you want more details, check out this paper on IBM's web site. (Now that IBM is a NetApp OEM, they put whitepapers about us on their website.) In the paper, they do all the steps manually, but we have a tool called SnapManager for Oracle that automates everything for DBAs who would rather not mess with the storage system themselves.
Comments