Experiences #6 - Loading a database into itself
So being a bit mischievous, I asked the question "can you store a database within itself". I bet any DBA has thought about this at sometime when looking at lobs.
With securefiles and high compression, you could store in theory any database within a lob.
You can certainly store a virtualisation within a lob, but what about the exact same database? Would you be able to point to it, and store it in itself?
The exercise to do this is just one of those fun scenario's to play with.
The program I used for loading is one I have been using to test load virtualisations into the database. I have been saying for over a year now, that as the number of virtualisations grow, they will need to be managed.
I have to deal with over 30 at the moment, and then back them up and work out which ones go where and how they are to be used. Some are small and as little as 2Gb, and some are over 100Gb in size.
Having a database manage them seems sensible, even though they are quite large in size. Disk prices in the last 12 months have dropped to the point where 1Tb costs under $300.
One can't run the virtualisation from within the database, maybe that will happen later, but one can certainly back them up and store copies in the database.
So what happens when you try to load a database into a lob in the same database? As my database is split over 2 drives, I broke it up into two steps. The first step loaded the core database files, like system and sysaux.
They loaded in ok.
Source code found at : http://www.xor.com.au/presentations/prog.sql
(note: the routines os_command.directory_listing and gl.img_size, are my own routines used for getting directory listings and formatting output, so you need to replace them with your own equivalents).
Here is what happened:
WEBSYS vnlz> @w:\vmware_in_database\prog Start at:09-JUL-08 10.10.32.937000000 AM +10:00 . Deleted at:+000000000 00:00:00.031000000 . Loading:O1_MF_SYSAUX_46Y67DGN_.DBF[834224128]F . . Size:814.7 Mb . . Inserted at:+000000000 00:00:29.391000000 . Loading:O1_MF_SYSTEM_46Y66Z0H_.DBF[1073758208]F . . Size:1,048.6 Mb . . Inserted at:+000000000 00:00:56.234000000 . Loading:O1_MF_TEMP_46Y67SFO_.TMP[1073758208]F . . Size:1,048.6 Mb . . Inserted at:+000000000 00:00:17.219000000 . Loading:O1_MF_UNDOTBS1_46Y67GWS_.DBF[1073758208]F . . Size:1,048.6 Mb . . Inserted at:+000000000 00:00:42.313000000 . Loading:O1_MF_USERS_46Y684X9_.DBF[5259264]F . . Size:5.1 Mb . . Inserted at:+000000000 00:00:00.156000000 Finish:+000000000 00:02:25.344000000
The second part involved loading in 131Gb of allocated datafiles into itself. These datafile were pretty much empty.
Off course I was expecting it to fail, as even if it compressed it, there would be some point of infinite regression where it would have to fail.
This is the table definition:
create table vmware ( id number(16), core_file ordsys.ordsource ) tablespace piction_med_1 LOB (core_file.localdata) STORE AS SECUREFILE l_core_file (TABLESPACE PICTION_IMG_2 disable storage in row RETENTION AUTO COMPRESS HIGH KEEP_DUPLICATES STORAGE (MAXEXTENTS UNLIMITED PCTINCREASE 0) NOCACHE LOGGING);
Nothing fancy, just a PK and the tablespace it loads into.
This is the tablespace creation commands:
CREATE TABLESPACE PICTION_IMG_2 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1G segment space management auto datafile 'r:\oradata\VNLZ\piction_img_2a.dbf' size 60G; alter tablespace PICTION_IMG_2 add datafile 'r:\oradata\VNLZ\piction_img_2b.dbf' size 60G;
I had to create 2 datafiles because there is a max file size.
This was done on Windows XP, 64bit running 11.1.0.6. I just happen to have more free storage on this platform than on Linux. And the database resides on off the shelf SATA drives.
There is 8Gb of memory on the box.
Curious yet as to what happened?
WEBSYS vnlz> @w:\vmware_in_database\prog Start at:09-JUL-08 10.16.53.578000000 AM +10:00 . Loading:PICTION_ARC_1.DBF[104873984]F . . Size:102.4 Mb . . Inserted at:+000000000 00:00:02.860000000 . Loading:PICTION_IMG_1.DBF[-2147467264]F . . Size:10.49 Gb . . Inserted at:+000000000 00:04:47.047000000 . Loading:PICTION_IMG_2A.DBF[16384]F . . Size:62.91 Gb . . Inserted at:+000000000 00:39:24.703000000 . Loading:PICTION_IMG_2B.DBF[16384]F . . Size:62.91 Gb . . Inserted at:+000000000 00:50:12.687000000 . Loading:PICTION_IND_1.DBF[419446784]F . . Size:409.6 Mb . . Inserted at:+000000000 00:00:13.328000000 . Loading:PICTION_LRG_1.DBF[524304384]F . . Size:512.0 Mb . . Inserted at:+000000000 00:00:14.360000000 . Loading:PICTION_MED_1.DBF[524304384]F . . Size:512.0 Mb . . Inserted at:+000000000 00:00:15.078000000 . Loading:PICTION_SML_1.DBF[419446784]F . . Size:409.6 Mb . . Inserted at:+000000000 00:00:11.094000000 . Loading:PICTION_TSP_1.DBF[104873984]F . . Size:102.4 Mb . . Inserted at:+000000000 00:00:02.765000000 Finish:+000000000 01:35:23.937000000
Yep. It loaded it ok.
(note: for datafiles >2Gb, there seems to be a java bug where it incorrectly reports the file size. It didn't impact the load, just the reporting of the size).
WEBSYS vnlz> select gl.img_size(bytes,'A') from user_segments where segment_name = 'L_CORE_FILE';
GL.IMG_SIZE(BYTES,'A')
--------------------------------------------------------------------------------------------------
35.65 Gb
and it compressed the 130+Gb down to 35.65Gb.
Very surprised by that result. My next assumption is that what is in these lobs is corrupted as I didn't enable database backup online before doing the load. So the next question is, if I extract it from the database will the database work (assume I did enable backup online)?
I'll leave that for another time. I have other work to do.....
If someone can see fault in what I did, please let me know. Am happy to retry the test under different conditions.

















RSS
Email