The Geeky DBA

So I’ve been trying to clone our production database to this new NAS device. It’s not as fast as a SAN of course but it’s decent. My steps were to copy the last hot backup, recover to current, then open it up. I had two iterations of this and the second one is what worked. Here’s what I ended up doing…

I found that Oracle (no matter what I tried security-wise) couldn’t work with a permanent drive mapped to my NAS share. So I used UNC paths. That’s all good.

I tried copying my hot backup across the network first. This took several days (from one older NAS to the new one). After I recovered it for a week I can only guess it got corrupted somehow and I was unable to open it up after recovery was well past the end of the hot backup.

In my final attempt, I took a fresh hot backup directly to the new NAS. This worked like a charm and finished in roughly 30 hours. I immediately started recovery which started out well but then I began having the recovery issues. The database would recover four or five archive logs then fail with an OS error saying the network name was no longer available and that the asynchronous I/O could not be queued. This was very frustrating as it was taking hours to recover two to three archive logs. Finally I created a batch file to keep the database looping into recovery. This worked out. By Wednesday of this week I was recovered and was able to open up the database.

The NAS is performing adequately and all seems to be ok. I’ve got load on it today and will post back with updates.

Here’s my set up. Per my last post, I’ve created a hot backup of my production database. After copying it to our newly acquired NAS device (which blew a drive already), I started the recovery process. This was started several days ago. The recovery puked about 20 times over the weekend because of network hiccups or possibly the blown RAID (from the bad drive). The drive was replaced yesterday and the process has only puked once. That’s the good news.

The bad news is that it’s taking approximately 25-30 minutes per archive log file. Each file is 250 MB in size. Therefore the recovery is taking longer than real-time. I feel like I’m traveling backwards in time!

Anyway, let’s hope the performance of this test system is adequate for our needs otherwise I’m not sure what our next options are.

My latest project is to move our test instance off of our primary SAN and move it to a cheaper NAS device. This instance is used for testing and quality assurance. We purchased a RaidWeb NAS device last week. It has 2TB when formatted RAID5.

I mounted it up in two shares to drives P: and O: on my test box. I copied all the data file to the two drives. When I tried to create the control database I found that oracle could not authenticate, therefore read the datafiles on the mapped drives. So I next tried UNC paths (i.e. \\hostname\share). This too did not work. I changed my service to run under a privileged user. Still no love.

As a last ditch effort, I changed the hostname in the path to the IP address of the NAS device. Guess what, it worked! Woot! Control file created, on to recovery.

Our system generates quite a bit of redo, about 100GB a day. I don’t want to copy all this locally to recover this test instance. I set the archive log destination to a public share on our hot standby and started recovery. Sure enough, Oracle picked up the files and started blasting through the recovery. I’ll post tomorrow on the results.

I’m curious to see how well the database performs, even though it’s a test instance, over an ethernet connected NAS versus a fiber connected SAN.