--=_mixed 004B06EB85256DE1_=
Content-Type: multipart/alternative; boundary="=_alternative 004B06EB85256DE1_="
--=_alternative 004B06EB85256DE1_=
Content-Type: text/plain; charset="us-ascii"
Mark,
You could reduce the number of polcies for your Oracle or other database
hot backups that
use Netbackup extensions by having only one policy per server. For
example, we have
one server that we backup 7 different instances of Oracle. We have one
policy that calls all
the startup scripts serially. That seems to work pretty well. You could
decide on a constant
such as 6 backups per policy, or play around and come up with a good
balance. If they are all
small instances you could do more per policy, etc.
Regards
=============================
Carl Stehman
PHI Services Company
202-331-6619
Pager 301-765-2703
ckstehman AT pepco DOT com
markjessup AT northwesternmutual DOT com
Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu
11/16/2003 12:44 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
cc: briandiven AT northwesternmutual DOT com, markjessup AT
northwesternmutual DOT com
Subject: [Veritas-bu] Backing up Thousands of Databases
Hi All,
I am wondering what method or strategy people use for backing up
application databases such as sybase, oracle, or db2. We have over 1500
databases in
our shop and are in the middle of migrating to Netbackup Datacenter from
an older mainframe based system. We currently use the Netbackup database
extension for each flavor of database out there, Sybase, Oracle, and UDB
so we are doing hot online backups. We backup each individual database
and the way we have it set up today is with a separate Netbackup policy
for each database dump and also for the database log dump. This method
has introduced over 1200 policies to Netbackup so far and it has caused
performance issues when expanding the policy tree in the Windows Admin
console. It takes us over 3 minutes to bring up the initial policy list.
The bigger issues is that with each database being a separate policy, we
lose almost all control over backup management because all of the
database backups are not part of a single policy but are individual
policies. With this method, we also experience status 58, 202, and 205
errors alot nightly because each database backup which is a separate
policy can go back to the same physical Unix client so we could have
many, many database backup jobs trying to run and connect to the same
Unix database server at the same time and then trying to communicate
back to our media server. This is all being done within Netbackup's
internal
scheduler with hot backups to disk or tape based on the size of the
database. We have increased kernal parameters, introduced local DNS
cachin, etc with
little improvement on the status 58, 202, 205 when Netbackup does the
scheduling. We have the default of 10 mintues set for the scheduler
interval. I was
wondering how other big database shops backup application databases,
what process or method and how you schedule them and monitor the
database backup jobs.
Also, is this process supported by the central backup team or by the
database admin team for these application database backup jobs.
Any feedback, ideas, or thoughts on this topic or what I described above
regarding our current process would be greatly appreciated. Thanks!
Mark Jessup
Northwestern Mutual
--=_alternative 004B06EB85256DE1_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">Mark,</font>
<br>
<br><font size=2 face="sans-serif">You could reduce the number of polcies for
your Oracle or other database hot backups that</font>
<br><font size=2 face="sans-serif">use Netbackup extensions by having only one
policy per server. For example, we have</font>
<br><font size=2 face="sans-serif">one server that we backup 7 different
instances of Oracle. We have one policy that calls all</font>
<br><font size=2 face="sans-serif"> the startup scripts serially.
That seems to work pretty well. You could decide on a
constant</font>
<br><font size=2 face="sans-serif">such as 6 backups per policy, or play around
and come up with a good balance. If they are all</font>
<br><font size=2 face="sans-serif">small instances you could do more per
policy, etc. </font>
<br>
<br><font size=2 face="sans-serif">Regards<br>
=============================<br>
Carl Stehman<br>
PHI Services Company<br>
202-331-6619<br>
Pager 301-765-2703<br>
ckstehman AT pepco DOT com</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>markjessup 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">11/16/2003 12:44 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:
briandiven AT northwesternmutual DOT com, markjessup AT
northwesternmutual DOT com</font>
<br><font size=1 face="sans-serif"> Subject:
[Veritas-bu] Backing up Thousands of
Databases</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Hi All,<br>
<br>
<br>
I am wondering what method or strategy people use for backing up<br>
application databases such as sybase, oracle, or db2. We have over 1500<br>
databases in<br>
our shop and are in the middle of migrating to Netbackup Datacenter from<br>
an older mainframe based system. We currently use the Netbackup database<br>
extension for each flavor of database out there, Sybase, Oracle, and UDB<br>
so we are doing hot online backups. We backup each individual database<br>
and the way we have it set up today is with a separate Netbackup policy<br>
for each database dump and also for the database log dump. This method<br>
has introduced over 1200 policies to Netbackup so far and it has caused<br>
performance issues when expanding the policy tree in the Windows Admin<br>
console. It takes us over 3 minutes to bring up the initial policy list.<br>
The bigger issues is that with each database being a separate policy, we<br>
lose almost all control over backup management because all of the<br>
database backups are not part of a single policy but are individual<br>
policies. With this method, we also experience status 58, 202, and 205<br>
errors alot nightly because each database backup which is a separate<br>
policy can go back to the same physical Unix client so we could have<br>
many, many database backup jobs trying to run and connect to the same<br>
Unix database server at the same time and then trying to communicate<br>
back to our media server. This is all being done within Netbackup's<br>
internal<br>
scheduler with hot backups to disk or tape based on the size of the<br>
database. We have increased kernal parameters, introduced local DNS<br>
cachin, etc with<br>
little improvement on the status 58, 202, 205 when Netbackup does the<br>
scheduling. We have the default of 10 mintues set for the scheduler<br>
interval. I was<br>
wondering how other big database shops backup application databases,<br>
what process or method and how you schedule them and monitor the<br>
database backup jobs.<br>
Also, is this process supported by the central backup team or by the<br>
database admin team for these application database backup jobs. <br>
<br>
<br>
Any feedback, ideas, or thoughts on this topic or what I described above<br>
regarding our current process would be greatly appreciated. Thanks!<br>
<br>
<br>
<br>
<br>
<br>
Mark Jessup<br>
Northwestern Mutual <br>
<br>
<br>
<br>
<br>
</font>
<br>
<br>
<br>
--=_alternative 004B06EB85256DE1_=--
--=_mixed 004B06EB85256DE1_=
Content-Type: application/rtf; name="BDY.RTF"
Content-Disposition: attachment; filename="BDY.RTF"
Content-Transfer-Encoding: base64
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYwXGZy
b21hblxmY2hhcnNldDAgVGltZXMgTmV3IFJvbWFuO317XGYxXGZzd2lzc1xmY2hhcnNldDAgQXJp
YWw7fX0NClx2aWV3a2luZDRcdWMxXHBhcmRcc2IxMDBcc2ExMDBcZjBcZnMyNCBIaSBBbGwsXHBh
cg0KSSBhbSB3b25kZXJpbmcgd2hhdCBtZXRob2Qgb3Igc3RyYXRlZ3kgcGVvcGxlIHVzZSBmb3Ig
YmFja2luZyB1cCBhcHBsaWNhdGlvbiBkYXRhYmFzZXMgc3VjaCBhcyBzeWJhc2UsIG9yYWNsZSwg
b3IgZGIyLiBXZSBoYXZlIG92ZXIgMTUwMCBkYXRhYmFzZXMgaW5cbGluZSBvdXIgc2hvcCBhbmQg
YXJlIGluIHRoZSBtaWRkbGUgb2YgbWlncmF0aW5nIHRvIE5ldGJhY2t1cCBEYXRhY2VudGVyIGZy
b20gYW4gb2xkZXIgbWFpbmZyYW1lIGJhc2VkIHN5c3RlbS4gV2UgY3VycmVudGx5IHVzZSB0aGUg
TmV0YmFja3VwIGRhdGFiYXNlXGxpbmUgZXh0ZW5zaW9uIGZvciBlYWNoIGZsYXZvciBvZiBkYXRh
YmFzZSBvdXQgdGhlcmUsIFN5YmFzZSwgT3JhY2xlLCBhbmQgVURCIHNvIHdlIGFyZSBkb2luZyBo
b3Qgb25saW5lIGJhY2t1cHMuICBXZSBiYWNrdXAgZWFjaCBpbmRpdmlkdWFsIGRhdGFiYXNlIGFu
ZCB0aGUgd2F5IHdlIGhhdmUgaXQgc2V0IHVwIHRvZGF5IGlzIHdpdGggYSBzZXBhcmF0ZSBOZXRi
YWNrdXAgcG9saWN5IGZvciBlYWNoIGRhdGFiYXNlIGR1bXAgYW5kIGFsc28gZm9yIHRoZSBkYXRh
YmFzZSBsb2cgZHVtcC4gVGhpcyBtZXRob2QgaGFzIGludHJvZHVjZWQgb3ZlciAxMjAwIHBvbGlj
aWVzIHRvIE5ldGJhY2t1cCBzbyBmYXIgYW5kIGl0IGhhcyBjYXVzZWQgcGVyZm9ybWFuY2UgaXNz
dWVzIHdoZW4gZXhwYW5kaW5nIHRoZSBwb2xpY3kgdHJlZSBpbiB0aGUgV2luZG93cyBBZG1pbiBj
b25zb2xlLiBJdCB0YWtlcyB1cyBvdmVyIDMgbWludXRlcyB0byBicmluZyB1cCB0aGUgaW5pdGlh
bCBwb2xpY3kgbGlzdC4gVGhlIGJpZ2dlciBpc3N1ZXMgaXMgdGhhdCB3aXRoIGVhY2ggZGF0YWJh
c2UgYmVpbmcgYSBzZXBhcmF0ZSBwb2xpY3ksIHdlIGxvc2UgYWxtb3N0IGFsbCBjb250cm9sIG92
ZXIgYmFja3VwIG1hbmFnZW1lbnQgYmVjYXVzZSBhbGwgb2YgdGhlIGRhdGFiYXNlIGJhY2t1cHMg
YXJlIG5vdCBwYXJ0IG9mIGEgc2luZ2xlIHBvbGljeSBidXQgYXJlIGluZGl2aWR1YWwgcG9saWNp
ZXMuIFdpdGggdGhpcyBtZXRob2QsIHdlIGFsc28gZXhwZXJpZW5jZSBzdGF0dXMgNTgsIDIwMiwg
YW5kIDIwNSBlcnJvcnMgYWxvdCBuaWdodGx5IGJlY2F1c2UgZWFjaCBkYXRhYmFzZSBiYWNrdXAg
d2hpY2ggaXMgYSBzZXBhcmF0ZSBwb2xpY3kgY2FuIGdvIGJhY2sgdG8gdGhlIHNhbWUgcGh5c2lj
YWwgVW5peCBjbGllbnQgc28gd2UgY291bGQgaGF2ZSBtYW55LCBtYW55IGRhdGFiYXNlIGJhY2t1
cCBqb2JzIHRyeWluZyB0byBydW4gYW5kIGNvbm5lY3QgdG8gdGhlIHNhbWUgVW5peCBkYXRhYmFz
ZSBzZXJ2ZXIgYXQgdGhlIHNhbWUgdGltZSBhbmQgdGhlbiB0cnlpbmcgdG8gY29tbXVuaWNhdGUg
YmFjayB0byBvdXIgbWVkaWEgc2VydmVyLiBUaGlzIGlzIGFsbCBiZWluZyBkb25lIHdpdGhpbiBO
ZXRiYWNrdXAncyBpbnRlcm5hbFxsaW5lIHNjaGVkdWxlciB3aXRoIGhvdCBiYWNrdXBzIHRvIGRp
c2sgb3IgdGFwZSBiYXNlZCBvbiB0aGUgc2l6ZSBvZiB0aGUgZGF0YWJhc2UuICBXZSBoYXZlIGlu
Y3JlYXNlZCBrZXJuYWwgcGFyYW1ldGVycywgaW50cm9kdWNlZCBsb2NhbCBETlMgY2FjaGluLCBl
dGMgd2l0aFxsaW5lIGxpdHRsZSBpbXByb3ZlbWVudCBvbiB0aGUgc3RhdHVzIDU4LCAyMDIsIDIw
NSB3aGVuIE5ldGJhY2t1cCBkb2VzIHRoZSBzY2hlZHVsaW5nLiAgV2UgaGF2ZSB0aGUgZGVmYXVs
dCBvZiAxMCBtaW50dWVzIHNldCBmb3IgdGhlIHNjaGVkdWxlciBpbnRlcnZhbC4gSSB3YXNcbGlu
ZSB3b25kZXJpbmcgaG93IG90aGVyIGJpZyBkYXRhYmFzZSBzaG9wcyBiYWNrdXAgYXBwbGljYXRp
b24gZGF0YWJhc2VzLCB3aGF0IHByb2Nlc3Mgb3IgbWV0aG9kIGFuZCBob3cgeW91IHNjaGVkdWxl
IHRoZW0gYW5kIG1vbml0b3IgdGhlIGRhdGFiYXNlIGJhY2t1cCBqb2JzLlxsaW5lIEFsc28sIGlz
IHRoaXMgcHJvY2VzcyBzdXBwb3J0ZWQgYnkgdGhlIGNlbnRyYWwgYmFja3VwIHRlYW0gb3IgYnkg
dGhlIGRhdGFiYXNlIGFkbWluIHRlYW0gZm9yIHRoZXNlIGFwcGxpY2F0aW9uIGRhdGFiYXNlIGJh
Y2t1cCBqb2JzLiBccGFyDQpBbnkgZmVlZGJhY2ssIGlkZWFzLCBvciB0aG91Z2h0cyBvbiB0aGlz
IHRvcGljIG9yIHdoYXQgSSBkZXNjcmliZWQgYWJvdmUgcmVnYXJkaW5nIG91ciBjdXJyZW50IHBy
b2Nlc3Mgd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRlZC4gVGhhbmtzIVxsaW5lXHBhcg0KXGxp
bmVcbGluZSBNYXJrIEplc3N1cFxsaW5lIE5vcnRod2VzdGVybiBNdXR1YWwgXGxpbmVccGFyDQpc
cGFyZFxmMVxmczIwXHBhcg0KfQ0KAA==
--=_mixed 004B06EB85256DE1_=--
|
