--=_mixed 006C4B6086256CBD_=
Content-Type: multipart/alternative; boundary="=_alternative 006C4B6286256CBD_="
--=_alternative 006C4B6286256CBD_=
Content-Type: text/plain; charset="us-ascii"
It sounds like this agent works similar to the Oracle agent and the RMAN
scripts. I would also be interested on how everyone is handling this in a
large environment with Oracle or any of these similar database agents.
How do you handle multiple instances on the same box? ... when the
schedules and/or retentions are different? ...do you use NetBackup's
scheduler or an outside scheduler?
Do you create one Policy per instance? If not, how do you handle this?
... when each instance has different requirements?
- Scott
briandiven AT northwesternmutual DOT com
Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu
01/29/2003 01:24 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
cc:
Subject: [Veritas-bu] NBU 4.5 MP2 Database Backup Scheduling
We are struggling trying to find a best practice for scheduling database
backups. This email is partially in response to Deb's question about
getting creative and bending wires. We are primarily a Sybase shop
using SQL BackTrack with expanding Oracle and DB2 usage. It was the
intent to keep things similar to the way we used to do backups as we
convert to NBU (maybe that is our downfall?). The old way, we had a
common pre/post command script that we passed parameters to (DB
instance, tape or disk, retention period, etc.).
NBU doesn't allow you to pass parameters, but the schedule name gets
passed to the script. Aha, how about if we camouflage our parms in the
name (e.g.SYB26+Marketing+30Day+Tape+Full)? So, we created a policy for
a HP-UX 11.11 server, and each database became a schedule. Then come to
find out that NBU will not run multiple schedules in the same evening.
OK, let's make every instance it's own policy (this would become approx
1,000 policies). The first test night, several backups failed because
we exceeded the number of simultaneous remote connections allowed to the
database (default value is 20). This became a catch-22, because I could
control this on the policy level, but that won't run multiple schedules
at a time.
I'm now looking at keeping the 1,000 policies and using Autosys/CRON to
group 10-15 backups/run box. This is really getting ugly. Did we start
off on the wrong path? Is this a pain because of the number of
databases? How are you getting around these issues and how are you
bending this wire?
TIA !!!
--=_alternative 006C4B6286256CBD_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="Arial">It sounds like this agent works similar to the
Oracle agent and the RMAN scripts. I would also be interested on how
everyone is handling this in a large environment with Oracle or any of these
similar database agents.</font>
<br>
<br><font size=2 face="Arial">How do you handle multiple instances on the same
box? ... when the schedules and/or retentions are different? ...do you
use NetBackup's scheduler or an outside scheduler?</font>
<br>
<br><font size=2 face="Arial">Do you create one Policy per instance? If
not, how do you handle this? ... when each instance has different
requirements?</font>
<br>
<br>
<br><font size=2 face="Arial">- Scott</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>briandiven AT northwesternmutual DOT
com</b></font>
<br><font size=1 face="sans-serif">Sent by: veritas-bu-admin AT
mailman.eng.auburn DOT edu</font>
<p><font size=1 face="sans-serif">01/29/2003 01:24 PM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
veritas-bu AT mailman.eng.auburn DOT edu</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
[Veritas-bu] NBU 4.5 MP2 Database Backup
Scheduling</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
We are struggling trying to find a best practice for scheduling database<br>
backups. This email is partially in response to Deb's question about<br>
getting creative and bending wires. We are primarily a Sybase shop<br>
using SQL BackTrack with expanding Oracle and DB2 usage. It was the<br>
intent to keep things similar to the way we used to do backups as we<br>
convert to NBU (maybe that is our downfall?). The old way, we had a<br>
common pre/post command script that we passed parameters to (DB<br>
instance, tape or disk, retention period, etc.).<br>
<br>
NBU doesn't allow you to pass parameters, but the schedule name gets<br>
passed to the script. Aha, how about if we camouflage our parms in the<br>
name (e.g.SYB26+Marketing+30Day+Tape+Full)? So, we created a policy
for<br>
a HP-UX 11.11 server, and each database became a schedule. Then come
to<br>
find out that NBU will not run multiple schedules in the same evening.<br>
<br>
OK, let's make every instance it's own policy (this would become approx<br>
1,000 policies). The first test night, several backups failed because<br>
we exceeded the number of simultaneous remote connections allowed to the<br>
database (default value is 20). This became a catch-22, because I
could<br>
control this on the policy level, but that won't run multiple schedules<br>
at a time.<br>
<br>
I'm now looking at keeping the 1,000 policies and using Autosys/CRON to<br>
group 10-15 backups/run box. This is really getting ugly. Did we
start<br>
off on the wrong path? Is this a pain because of the number of<br>
databases? How are you getting around these issues and how are you<br>
bending this wire?<br>
<br>
TIA !!!<br>
</font>
<br>
<br>
--=_alternative 006C4B6286256CBD_=--
--=_mixed 006C4B6086256CBD_=
Content-Type: application/rtf; name="BDY.RTF"
Content-Disposition: attachment; filename="BDY.RTF"
Content-Transfer-Encoding: base64
e1xydGYxXGFuc2lcZGVmZjB7XGZvbnR0Ymx7XGYwXGZzd2lzc1xmY2hhcnNldDAgQXJpYWw7fXtc
ZjFcZnJvbWFuXGZwcnEyXGZjaGFyc2V0MCBUaW1lcyBOZXcgUm9tYW47fX0NCntcY29sb3J0Ymwg
O1xyZWQwXGdyZWVuMFxibHVlMjU1O30NClx2aWV3a2luZDRcdWMxXHBhcmRcY2YxXGxhbmcxMDMz
XGYwXGZzMjBccGFyDQpcY2YwXGYxIFdlIGFyZSBzdHJ1Z2dsaW5nIHRyeWluZyB0byBmaW5kIGEg
YmVzdCBwcmFjdGljZSBmb3Igc2NoZWR1bGluZyBkYXRhYmFzZSBiYWNrdXBzLiAgVGhpcyBlbWFp
bCBpcyBwYXJ0aWFsbHkgaW4gcmVzcG9uc2UgdG8gRGViXHJxdW90ZSBzIHF1ZXN0aW9uIGFib3V0
IGdldHRpbmcgY3JlYXRpdmUgYW5kIGJlbmRpbmcgd2lyZXMuICBXZSBhcmUgcHJpbWFyaWx5IGEg
U3liYXNlIHNob3AgdXNpbmcgU1FMIEJhY2tUcmFjayB3aXRoIGV4cGFuZGluZyBPcmFjbGUgYW5k
IERCMiB1c2FnZS4gIEl0IHdhcyB0aGUgaW50ZW50IHRvIGtlZXAgdGhpbmdzIHNpbWlsYXIgdG8g
dGhlIHdheSB3ZSB1c2VkIHRvIGRvIGJhY2t1cHMgYXMgd2UgY29udmVydCB0byBOQlUgKG1heWJl
IHRoYXQgaXMgb3VyIGRvd25mYWxsPykuICBUaGUgb2xkIHdheSwgd2UgaGFkIGEgY29tbW9uIHBy
ZS9wb3N0IGNvbW1hbmQgc2NyaXB0IHRoYXQgd2UgcGFzc2VkIHBhcmFtZXRlcnMgdG8gKERCIGlu
c3RhbmNlLCB0YXBlIG9yIGRpc2ssIHJldGVudGlvbiBwZXJpb2QsIGV0Yy4pLlxwYXINClxwYXIN
Ck5CVSBkb2VzblxycXVvdGUgdCBhbGxvdyB5b3UgdG8gcGFzcyBwYXJhbWV0ZXJzLCBidXQgdGhl
IHNjaGVkdWxlIG5hbWUgZ2V0cyBwYXNzZWQgdG8gdGhlIHNjcmlwdC4gIEFoYSwgaG93IGFib3V0
IGlmIHdlIGNhbW91ZmxhZ2Ugb3VyIHBhcm1zIGluIHRoZSBuYW1lIChlLmcuU1lCMjYrTWFya2V0
aW5nKzMwRGF5K1RhcGUrRnVsbCk/ICBTbywgd2UgY3JlYXRlZCBhIHBvbGljeSBmb3IgYSBIUC1V
WCAxMS4xMSBzZXJ2ZXIsIGFuZCBlYWNoIGRhdGFiYXNlIGJlY2FtZSBhIHNjaGVkdWxlLiAgVGhl
biBjb21lIHRvIGZpbmQgb3V0IHRoYXQgTkJVIHdpbGwgbm90IHJ1biBtdWx0aXBsZSBzY2hlZHVs
ZXMgaW4gdGhlIHNhbWUgZXZlbmluZy5ccGFyDQpccGFyDQpPSywgbGV0XHJxdW90ZSBzIG1ha2Ug
ZXZlcnkgaW5zdGFuY2UgaXRccnF1b3RlIHMgb3duIHBvbGljeSAodGhpcyB3b3VsZCBiZWNvbWUg
YXBwcm94IDEsMDAwIHBvbGljaWVzKS4gIFRoZSBmaXJzdCB0ZXN0IG5pZ2h0LCBzZXZlcmFsIGJh
Y2t1cHMgZmFpbGVkIGJlY2F1c2Ugd2UgZXhjZWVkZWQgdGhlIG51bWJlciBvZiBzaW11bHRhbmVv
dXMgcmVtb3RlIGNvbm5lY3Rpb25zIGFsbG93ZWQgdG8gdGhlIGRhdGFiYXNlIChkZWZhdWx0IHZh
bHVlIGlzIDIwKS4gIFRoaXMgYmVjYW1lIGEgY2F0Y2gtMjIsIGJlY2F1c2UgSSBjb3VsZCBjb250
cm9sIHRoaXMgb24gdGhlIHBvbGljeSBsZXZlbCwgYnV0IHRoYXQgd29uXHJxdW90ZSB0IHJ1biBt
dWx0aXBsZSBzY2hlZHVsZXMgYXQgYSB0aW1lLlxwYXINClxwYXINCklccnF1b3RlIG0gbm93IGxv
b2tpbmcgYXQga2VlcGluZyB0aGUgMSwwMDAgcG9saWNpZXMgYW5kIHVzaW5nIEF1dG9zeXMvQ1JP
TiB0byBncm91cCAxMC0xNSBiYWNrdXBzL3J1biBib3guICBUaGlzIGlzIHJlYWxseSBnZXR0aW5n
IHVnbHkuICBEaWQgd2Ugc3RhcnQgb2ZmIG9uIHRoZSB3cm9uZyBwYXRoPyAgSXMgdGhpcyBhIHBh
aW4gYmVjYXVzZSBvZiB0aGUgbnVtYmVyIG9mIGRhdGFiYXNlcz8gIEhvdyBhcmUgeW91IGdldHRp
bmcgYXJvdW5kIHRoZXNlIGlzc3VlcyBhbmQgaG93IGFyZSB5b3UgYmVuZGluZyB0aGlzIHdpcmU/
XHBhcg0KXHBhcg0KVElBICEhIVxwcm90ZWN0XGYwXHBhcg0KfQ0KAA==
--=_mixed 006C4B6086256CBD_=--
|
