Hi Jeff,We have scripts that put the databases in hot backup mode and then take a snapshot. We plan to look into using SnapManager for Oracle to replace that functionality, though.For long-term, archival, backups we take RMAN exports of the dbs.Cheers,RyanOn Sat, May 17, 2014, at 08:51 PM, Jeff Cleverley wrote:Ryan,Thanks for the information. It sounds like we may have a window of opportunity to have them check out dnfs.How are you doing the backups of your database?Thanks,JeffOn Thu, May 15, 2014 at 11:21 AM, Ryan Pugatch <rpug@lp0.org> wrote:Your DBAs may have a lot of interest in Oracle DNFS because it is an "Oracle product" and should be well supported by the Oracle support team that they would be used to dealing with. Maybe that will help you push them in the right direction. Though, you may start missing being able to use 'nfsstat.'
Recently, Oracle has been trying to sell me their Oracle ZFS storage products. Allegedly, their use of Oracle Intelligent Storage Protocol (OISP) is the secret sauce that makes them better than everyone else. I'm skeptical. That said, even in that instance, they would prefer you use DNFS (and in fact, OISP is only available when you are using DNFS - and version 12c or newer.)
We have started moving our databases to using DNFS (had been using NFS.) We can certainly see the databases are sending and receiving more traffic to and from our NetApp (6220) and some of our jobs run quicker (noticeably, refresh jobs in our data warehouse.) We had seen that using the kernel's NFS, we'd be getting some backup in the rpc backlog, so not surprised that we are being more efficient now.
Interestingly, though, we have a series of batch jobs that run overnight related to our homegrown ERP system, and we found that while most of the jobs are running the same duration or even quicker, a few key jobs that do bulk selections took a significant amount of time longer when using DNFS (2.5-3 hours longer, when on average the day end jobs run in about 5-6 hours.) My thought at this point is that we have moved our bottleneck to CPU on the database server and it is presenting itself in this manner. Still digging into that, though.
Ryan---Ryan Pugatch • Boston, MA • www.ryanp.comOn Tue, May 13, 2014, at 06:25 PM, Jeff Cleverley wrote:Alexander, Nice reply :-) They are not quite that bad since they don't get that far down into the storage aspect.Peta, Thanks for the reply. I know they are looking at other options other than SMO, but I'm not sure what yet.Neto, I'll look through the blogs and see what applies. The DBAs don't even want to talk to use about NFS, I'm pretty sure they won't go out of their comfort zone on this yet.Thanks,JeffOn Tue, May 13, 2014 at 6:37 PM, Neto, Antonio Jose Rodrigues <Antonio.Jose.Rodrigues.Neto@netapp.com> wrote:
Hi Jeff,
This is neto from BrazilHow are you?Please let me know how I can help. I have a lot of good stuff at my blog: blogs.netapp.com/databases or netofrombrazil.com. Also at twitter at @netofrombrazil
If you want my help to talk to the DBAs to help to define a good architecture, please just let me know.All the best,netoNetApp – I love this company!Greetings,My Oracle experience with and without NetApp has largely been non-existent. Please bear with me on this. All of our current DBs are on dedicated servers with locally attached storage.One of our groups has a 6280 cluster running 8.1.2P4 7-mode. They want to look into using iscsi to a new 11.2 Oracle server. The cluster can get pretty busy at times so I'm not sure Oracle NFS will work in this case.
The questions are largely about backups and DR. I'm curious about how most people choose to back this up and how to recover for that solution. I know there are lun copy options, snapmanager/flex clone options, etc. We're very open to manual scripting and custom solutions. Backups would most likely go to a NearStore, and the DR would be a second server connected via iscsi also.Thanks,Jeff--Jeff CleverleyUnix Systems Administrator4380 Ziegler RoadFort Collins, Colorado 80525_______________________________________________Toasters mailing list--Jeff CleverleyUnix Systems Administrator4380 Ziegler RoadFort Collins, Colorado 80525970-288-4611--Jeff CleverleyUnix Systems Administrator4380 Ziegler RoadFort Collins, Colorado 80525970-288-4611_______________________________________________Toasters mailing list--Jeff CleverleyUnix Systems Administrator4380 Ziegler RoadFort Collins, Colorado 80525970-288-4611