Re: TDP for Oracle on AIX...configuration
On Fri, Oct 20, 2006 at 02:11:34PM -0400, Lawrence Clark wrote: tdpoconf password -TDPO_OPTFILE=/home/oracle/ts You should point to the optionsfile itself, not the directory containing it. This means: tdpoconf password -tdpo_optfile=/home/oracle/ts/tdpo.opt. Regards, -- Jurjen Oskam
Re: TDP Oracle
On Fri, Oct 20, 2006 at 12:10:17PM -0700, Gill, Geoffrey L. wrote:
3.If this ignores the retention values set in the management class
settings, and I believe it still does, do I need a specific management
class for them?
A TDP for Oracle node *only* has active files on the TSM server, as Oracle
by default guarantees that only unique filenames are sent. This means that
the retention parameters concerning extra versions are irrelevant.
In addition to that, when Oracle RMAN deletes a backup, it doesn't only
delete the file on the TSM server, but also the information it has in the
RMAN repository required to restore that file. So, while you can set up
a TDP node such that inactive files will be retained on the TSM server, it
doesn't make sense because the file is useless without the RMAN repository
information, which is already gone.
The retention values in the management class are certainly not ignored. If
you don't set them correctly (as described above), you're almost certainly
storing too much data on the TSM server.
1.Can we use a domain we have in place already and if so are there
any settings we need to look at?
4.I am assuming we should use a specific node name for these
backups and not let them use the node name that is now backing up to the
server. Still correct right?
You can use an existing domain, but it's much simpler to use a dedicated
TDP for Oracle domain. You only need to set one managementclass containing
one copygroup in that domain. That way, it's guaranteed that the RMAN
backups are bound to the correct management class and you don't have to
fiddle with include statements in the API configuration on the client.
And you should indeed use a specific node for the TDP backups. The TDP node
goes in the TDP domain.
2.I believe expiring of objects is done from the RMAN side. If
this is correct how do I know they are keeping, or maybe better
described as deleting, what they should?
You need access to the RMAN repository ('recovery catalog') for that.
The RMAN repository can be located in the database itself, or be a
database on its own. Normally RMAN deletes all obsolete objects (as
specified by the DBA) on its own, but there are situations where RMAN
doesn't know that a certain file is stored on the TSM server. That's where
the tdposync tool comes in. It checks the RMAN repository, and then checks
what's available on the TSM server. If there are files in TSM which RMAN
doesn't know about, it can delete those files on the TSM server.
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
Re: Backing up very large Filesystems...
Hi Skylar, Thanks for you answer, very useful but I have got a silly question: Using the proxy relationship do we know if TSM is going to spread the work accross all the nodes of the cluster of just only above the nodes that have enable the scheduler ¿? Thanks for your help, Regards, Ibán Bernaldo de Quirós Márquez Technical Specialist cell: + 34 659 01 91 12 Sun Microsystems Iberia -Mensaje original- De: ADSM: Dist Stor Manager en nombre de Skylar Thompson Enviado el: vie 20/10/2006 17:18 Para: ADSM-L@VM.MARIST.EDU Asunto: Re: [ADSM-L] Backing up very large Filesystems... Bernaldo de Quiros, Iban 1 wrote: Hi, I am planning to backup very large Filesystems (GPFS filesystems), about 37 TB and more , does exists a White Paper or best practices to do that ¿? I've found that setting RESOURCEUTILIZATION as high as practical helps a lot, especially if you have lots of files. You can also break up the work across however many nodes that you have by using proxy node relationships: http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmhpn.doc/update/anrhgd53372.htm -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- K324, (206)-685-7354 -- University of Washington Medical Center
Re: Backing up very large Filesystems...
Hi Allen, Thanks for your reply !! Using virtual mount points do we know if TSM takes care of the Journalling of the files that he is going to do backup ¿? If it takes care, the backup window will be more small because it knows which files have changed...¿? less processing time... What do you think about that ¿? Thanks in advance, Regards, Ibán Bernaldo de Quirós Márquez Technical Specialist cell: + 34 659 01 91 12 Sun Microsystems Iberia -Mensaje original- De: ADSM: Dist Stor Manager en nombre de Allen S. Rout Enviado el: vie 20/10/2006 19:08 Para: ADSM-L@VM.MARIST.EDU Asunto: Re: [ADSM-L] Backing up very large Filesystems... On Fri, 20 Oct 2006 10:50:09 +0100, Bernaldo de Quiros, Iban 1 [EMAIL PROTECTED] said: I am planning to backup very large Filesystems (GPFS filesystems), about 37 TB and more , does exists a White Paper or best practices to do that Consider virtualmountpoints; these let you separate all kinds of processing. Independant storage volumes, independant incremental processing, etc. With separate filespaces, you can also make the reclamation independant; this can be very useful if your file sizes on that huge tract of land are normal. You'll be talking many many millions; it could take days of expiration to cover it. If it's one big filespace, expiration has to finish the whole filespace before it goes on. That could be sticky in your case. If your filespace is full of big (multi-GB) files, this might not be a big deal. - Allen S. Rout
Re: Backing up very large Filesystems...
Bernaldo de Quiros, Iban 1 wrote: Hi Skylar, Thanks for you answer, very useful but I have got a silly question: Using the proxy relationship do we know if TSM is going to spread the work accross all the nodes of the cluster of just only above the nodes that have enable the scheduler ¿? Thanks for your help, The manual really isn't clear on this, and I haven't explored it too much since our GPFS cluster doesn't change all that much day-to-day. The manual seems to imply that it does, but I haven't tested it out. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- K324, (206)-685-7354 -- University of Washington Medical Center
Re: Restoring Database to new Location
My mistake, I meant dsmserv.dsk. In the end I did it by editing the file and restoring the database. Worked fine and I was (or could have been) done in about 3.5 hours. Creating and deleting dbvs would have taken just around a week (with a trailing wind), which was time I didn't have. Thanks everyone for the input. Jason On Oct 20, 2006, at 1:24 PM, Prather, Wanda wrote: Not to mention that if you use the recommended approach, you can do everything while your TSM server is up and running! Wanda Prather I/O, I/O, It's all about I/O -(me) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: Friday, October 20, 2006 4:19 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Restoring Database to new Location -Jason Lee wrote: - could anyone confirm that if one takes a backup of the database, then changes the location of the database files in devconfig and then does a restore of the db, it'll do the right thing and restore to the new locations... assuming you have dbvs dsmfmt'd in place? I have a 1/2 TB database to move, and going the delete dbv route will take days to complete - hence the question. The database file locations are not stored in the devconfig file. They and the recovery file locations are in dsmserv.dsk. This file is updated using the dsmserv command with the 'format' option. A database restore will restore the database contents to whatever files are listed in dsmserv.dsk even if the file locations are different than the ones in use when the database was backed up. In fact, the numbers and sizes of the files can be different as well, as long as the total amount of space in the files is sufficient. We have made these kinds of changes during disaster recovery tests. That being said, I don't recommend this approach. The mirrored volume manipulations mentioned in other responses strike me as a safer approach. If you want the option of changing volume sizes during the migrations, I would recommend defining new volumes and deleting old ones despite the elapsed time this appraoch wouldtake.
A little database performance foo
Well, I've beed trying my damnedest to get some actual performace out of my database here and have come to the conclusion that IBM was not lying to me and that the database is, in fact, not all it might be. It also appears, though I stand to be corrected, that the buffer pool cache hit rate is a somewhat dubious number. It would be nice if someone from IBM could weigh in on this All database accesses (to disk) are serial and synchronous. That is, each IO has to complete before the next is dispatched. Therefore, the maximum number of IOs that the database can sustain (to disk) is 1/ average latency, or about 300 per second for a nice array and 250 for a not nice array. Each of those IOs is a single 4K database page, working out to a maximum bandwidth of ~1.2-1.4 MB/s I've tested this every which way, under different loads, fewer and more volumes, one big LUN, multiple small LUNs. It doesn't seem to matter what you do, that's all you get. Needless to say, an enormous Shark or EMC does not seem to be necessary in the TSM world (storage pools and reliability not withstanding). In fact, 3 15K spindles will probably do it just fine - I'll try that later. As for the buffer pool numbers, I don't know exactly how the internals work (nobody will tell me) but this is what I have been told. There are two threads that actually access the database on disk, one reader and one writer. All their operations are serial and synchronous and they read and write to the buffer pool. The reader thread does it's best to pre-fill the buffer pool with what it assumes you will want. The writer thread looks for changes that have occurred in the buffer pool and writes them out to disk. I.E. all database activity takes place in the buffer pool. A buffer pool miss occurs when you request something that has not been pre-fetched into the buffer. Here's a situation. I have N clients all starting at the same time. They all are going to request ~100MB of data (or at least that is the number being reported by q session as bytes sent when they have been running for a while). The clients are running on very lightly loaded boxes and can consume anything the server can throw at them (or anything it's likely to throw, anyway) from the database. Seems to me, at this starting point, there is *nothing* of relevance (excluding the odd index or two) in the buffer pool. Everything is going to be a buffer miss. Now, the pre-fetcher is doing it's best to load that stuff in, but I have gigs of data I'm looking for, and it's feeding me at 1.3MB/s. I'm sure the data direct from the DB is not the data sent to the client, but I would suggest that the sizes are not wildly disparate. Under this load, how can it be that there is *ever* anything useful in the buffer pool, unless the clients are being throttled in some way to allow the pre-fetcher to stay ahead? If that throttle is the CPU (more time being given to the pre-fetcher thread), then getting more horsepower will decrease my cache hit percentage as the DB clients get more time to make request, but the pre-fetcher is already maxed out (because of the 300 I/O limit). This all suggests to me that on a heavily loaded box the buffer hit rate is perhaps artificially high, and the true numbers can only be achieved when the box has spare cycles and the requesting threads have time to twiddle their thumbs. Does this make sense, or have I been up too long? Any thought, comments, words of wisdom or discussion would be gratefully acknowledged. Thanks Jason -- Jason Lee DreamWorks Animation (818) 695-3782
Re: TDP Oracle
On Fri, 20 Oct 2006 16:13:54 -0400, Lawrence Clark [EMAIL PROTECTED] said: the problem you have with them not deleteing automaticly may be in the client (node) def. You have to make sure Backup Delete Allowed?: Yes is set. do a q node x f=d and verify. If it is not set, even if they product issues a delete it will not occur. Thanks, but yes, we touched that base. - Allen S. Rout
Re: A little database performance foo
On Sat, 21 Oct 2006 14:00:06 -0700, Jason Lee [EMAIL PROTECTED] said: I've beed trying my damnedest to get some actual performace out of my database here and have come to the conclusion that IBM was not lying to me and that the database is, in fact, not all it might be. Oh, they're telling you the truth. :) DB architecture is one of the fundamental gripes about TSM by initiates. We're considering moving to a DB2 architecture has been dangled before us since at least '98. I'm looking forward to the notion, but I can't say I'm sorry they're moving carefully. [...] I have N clients all starting at the same time. They all are going to request ~100MB of data (or at least that is the number being reported by q session as bytes sent when they have been running for a while). The clients are running on very lightly loaded boxes and can consume anything the server can throw at them (or anything it's likely to throw, anyway) from the database. Well, the party-line answer to that problem is that you don't want to start them at anything like 'the same time'. This is kind of skew to your actual question, but may help your operational problem. If you set the DURation of your schedules to be somewhat higher, then (since actual start times are scattered over the first half of that duration) your contention will go down. Also or alternately, you may want to run some (most?) of your clients INCRBYDATE many days of the week. This would reduce the impact of the initial download at the cost of some DB inflation and an opportunity to miss, for a while, files which are new but have old dates. (unpacked archives are the easiest example of such). If this is the same server that has a 500G DB, then that may explain why you're seeing this performance problem. That's broadly considered Freakin' HUGE, and most folks find some other portion of their DB performance to become unacceptable long before they get that big. How long does it take you to do a DB backup, anyway? For ~350GB of DB, I've got 11 servers, 9 customer-facing, on one box. Now, I'm using relatively sucky old hardware (18G 10K SSA drives), but that means I've got 9 threads wandering around a smaller DB displacement. Does this make sense, or have I been up too long? Heh, I'll note these need not be exclusive. :) - Allen S. Rout
Re: A little database performance foo
On Oct 21, 2006, at 6:05 PM, Allen S. Rout wrote: On Sat, 21 Oct 2006 14:00:06 -0700, Jason Lee [EMAIL PROTECTED] said: I have N clients all starting at the same time. They all are going to request ~100MB of data (or at least that is the number being reported by q session as bytes sent when they have been running for a while). The clients are running on very lightly loaded boxes and can consume anything the server can throw at them (or anything it's likely to throw, anyway) from the database. Well, the party-line answer to that problem is that you don't want to start them at anything like 'the same time'. This is kind of skew to your actual question, but may help your operational problem. If you set the DURation of your schedules to be somewhat higher, then (since actual start times are scattered over the first half of that duration) your contention will go down. :-) that was more to illustrate the point. After a little while the start times become pretty random, since each backup job runs after the previous (but I have ~40 queues of jobs) Also or alternately, you may want to run some (most?) of your clients INCRBYDATE many days of the week. This would reduce the impact of the initial download at the cost of some DB inflation and an opportunity to miss, for a while, files which are new but have old dates. (unpacked archives are the easiest example of such). I've been thinking about that as a stopgap until I get things more under control. If this is the same server that has a 500G DB, then that may explain why you're seeing this performance problem. That's broadly considered Freakin' HUGE, and most folks find some other portion of their DB performance to become unacceptable long before they get that big. How long does it take you to do a DB backup, anyway? Several hours for a full... it's watching the DB restores that is killer :-) For ~350GB of DB, I've got 11 servers, 9 customer-facing, on one box. Now, I'm using relatively sucky old hardware (18G 10K SSA drives), but that means I've got 9 threads wandering around a smaller DB displacement. That's where I'm at... gotta break this bad boy up. I knew the day was coming, but it was just recently that I suddenly started to get way behind - it's a vicious cycle, the more behind you get, the more behind you get! I was hoping that I had my box setup incorrectly, but it appears that in reality I have a well performing database - scary. I see another late night or two coming up :-) Jason -- Jason Lee DreamWorks Animation (818) 695-3782
