Veritas-bu

[Veritas-bu] Backing up Thousands of Databases

2003-11-16 12:44:00
Subject: [Veritas-bu] Backing up Thousands of Databases
From: markjessup AT northwesternmutual DOT com (markjessup AT northwesternmutual DOT com)
Date: Sun, 16 Nov 2003 11:44:00 -0600
--openmail-part-60c5abfd-00000002
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
        ;Creation-Date="Sun, 16 Nov 2003 11:44:00 -0600"
Content-Transfer-Encoding: quoted-printable

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.=20


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=20





--openmail-part-60c5abfd-00000002
Content-Type: application/rtf
Content-Disposition: attachment; filename="BDY.RTF"
        ;Creation-Date="Sun, 16 Nov 2003 11:44:00 -0600"
Content-Transfer-Encoding: base64

e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYw
XGZyb21hblxmY2hhcnNldDAgVGltZXMgTmV3IFJvbWFuO317XGYxXGZzd2lzc1xmY2hhcnNl
dDAgQXJpYWw7fX0NClx2aWV3a2luZDRcdWMxXHBhcmRcc2IxMDBcc2ExMDBcZjBcZnMyNCBI
aSBBbGwsXHBhcg0KSSBhbSB3b25kZXJpbmcgd2hhdCBtZXRob2Qgb3Igc3RyYXRlZ3kgcGVv
cGxlIHVzZSBmb3IgYmFja2luZyB1cCBhcHBsaWNhdGlvbiBkYXRhYmFzZXMgc3VjaCBhcyBz
eWJhc2UsIG9yYWNsZSwgb3IgZGIyLiBXZSBoYXZlIG92ZXIgMTUwMCBkYXRhYmFzZXMgaW5c
bGluZSBvdXIgc2hvcCBhbmQgYXJlIGluIHRoZSBtaWRkbGUgb2YgbWlncmF0aW5nIHRvIE5l
dGJhY2t1cCBEYXRhY2VudGVyIGZyb20gYW4gb2xkZXIgbWFpbmZyYW1lIGJhc2VkIHN5c3Rl
bS4gV2UgY3VycmVudGx5IHVzZSB0aGUgTmV0YmFja3VwIGRhdGFiYXNlXGxpbmUgZXh0ZW5z
aW9uIGZvciBlYWNoIGZsYXZvciBvZiBkYXRhYmFzZSBvdXQgdGhlcmUsIFN5YmFzZSwgT3Jh
Y2xlLCBhbmQgVURCIHNvIHdlIGFyZSBkb2luZyBob3Qgb25saW5lIGJhY2t1cHMuICBXZSBi
YWNrdXAgZWFjaCBpbmRpdmlkdWFsIGRhdGFiYXNlIGFuZCB0aGUgd2F5IHdlIGhhdmUgaXQg
c2V0IHVwIHRvZGF5IGlzIHdpdGggYSBzZXBhcmF0ZSBOZXRiYWNrdXAgcG9saWN5IGZvciBl
YWNoIGRhdGFiYXNlIGR1bXAgYW5kIGFsc28gZm9yIHRoZSBkYXRhYmFzZSBsb2cgZHVtcC4g
VGhpcyBtZXRob2QgaGFzIGludHJvZHVjZWQgb3ZlciAxMjAwIHBvbGljaWVzIHRvIE5ldGJh
Y2t1cCBzbyBmYXIgYW5kIGl0IGhhcyBjYXVzZWQgcGVyZm9ybWFuY2UgaXNzdWVzIHdoZW4g
ZXhwYW5kaW5nIHRoZSBwb2xpY3kgdHJlZSBpbiB0aGUgV2luZG93cyBBZG1pbiBjb25zb2xl
LiBJdCB0YWtlcyB1cyBvdmVyIDMgbWludXRlcyB0byBicmluZyB1cCB0aGUgaW5pdGlhbCBw
b2xpY3kgbGlzdC4gVGhlIGJpZ2dlciBpc3N1ZXMgaXMgdGhhdCB3aXRoIGVhY2ggZGF0YWJh
c2UgYmVpbmcgYSBzZXBhcmF0ZSBwb2xpY3ksIHdlIGxvc2UgYWxtb3N0IGFsbCBjb250cm9s
IG92ZXIgYmFja3VwIG1hbmFnZW1lbnQgYmVjYXVzZSBhbGwgb2YgdGhlIGRhdGFiYXNlIGJh
Y2t1cHMgYXJlIG5vdCBwYXJ0IG9mIGEgc2luZ2xlIHBvbGljeSBidXQgYXJlIGluZGl2aWR1
YWwgcG9saWNpZXMuIFdpdGggdGhpcyBtZXRob2QsIHdlIGFsc28gZXhwZXJpZW5jZSBzdGF0
dXMgNTgsIDIwMiwgYW5kIDIwNSBlcnJvcnMgYWxvdCBuaWdodGx5IGJlY2F1c2UgZWFjaCBk
YXRhYmFzZSBiYWNrdXAgd2hpY2ggaXMgYSBzZXBhcmF0ZSBwb2xpY3kgY2FuIGdvIGJhY2sg
dG8gdGhlIHNhbWUgcGh5c2ljYWwgVW5peCBjbGllbnQgc28gd2UgY291bGQgaGF2ZSBtYW55
LCBtYW55IGRhdGFiYXNlIGJhY2t1cCBqb2JzIHRyeWluZyB0byBydW4gYW5kIGNvbm5lY3Qg
dG8gdGhlIHNhbWUgVW5peCBkYXRhYmFzZSBzZXJ2ZXIgYXQgdGhlIHNhbWUgdGltZSBhbmQg
dGhlbiB0cnlpbmcgdG8gY29tbXVuaWNhdGUgYmFjayB0byBvdXIgbWVkaWEgc2VydmVyLiBU
aGlzIGlzIGFsbCBiZWluZyBkb25lIHdpdGhpbiBOZXRiYWNrdXAncyBpbnRlcm5hbFxsaW5l
IHNjaGVkdWxlciB3aXRoIGhvdCBiYWNrdXBzIHRvIGRpc2sgb3IgdGFwZSBiYXNlZCBvbiB0
aGUgc2l6ZSBvZiB0aGUgZGF0YWJhc2UuICBXZSBoYXZlIGluY3JlYXNlZCBrZXJuYWwgcGFy
YW1ldGVycywgaW50cm9kdWNlZCBsb2NhbCBETlMgY2FjaGluLCBldGMgd2l0aFxsaW5lIGxp
dHRsZSBpbXByb3ZlbWVudCBvbiB0aGUgc3RhdHVzIDU4LCAyMDIsIDIwNSB3aGVuIE5ldGJh
Y2t1cCBkb2VzIHRoZSBzY2hlZHVsaW5nLiAgV2UgaGF2ZSB0aGUgZGVmYXVsdCBvZiAxMCBt
aW50dWVzIHNldCBmb3IgdGhlIHNjaGVkdWxlciBpbnRlcnZhbC4gSSB3YXNcbGluZSB3b25k
ZXJpbmcgaG93IG90aGVyIGJpZyBkYXRhYmFzZSBzaG9wcyBiYWNrdXAgYXBwbGljYXRpb24g
ZGF0YWJhc2VzLCB3aGF0IHByb2Nlc3Mgb3IgbWV0aG9kIGFuZCBob3cgeW91IHNjaGVkdWxl
IHRoZW0gYW5kIG1vbml0b3IgdGhlIGRhdGFiYXNlIGJhY2t1cCBqb2JzLlxsaW5lIEFsc28s
IGlzIHRoaXMgcHJvY2VzcyBzdXBwb3J0ZWQgYnkgdGhlIGNlbnRyYWwgYmFja3VwIHRlYW0g
b3IgYnkgdGhlIGRhdGFiYXNlIGFkbWluIHRlYW0gZm9yIHRoZXNlIGFwcGxpY2F0aW9uIGRh
dGFiYXNlIGJhY2t1cCBqb2JzLiBccGFyDQpBbnkgZmVlZGJhY2ssIGlkZWFzLCBvciB0aG91
Z2h0cyBvbiB0aGlzIHRvcGljIG9yIHdoYXQgSSBkZXNjcmliZWQgYWJvdmUgcmVnYXJkaW5n
IG91ciBjdXJyZW50IHByb2Nlc3Mgd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRlZC4gVGhh
bmtzIVxsaW5lXHBhcg0KXGxpbmVcbGluZSBNYXJrIEplc3N1cFxsaW5lIE5vcnRod2VzdGVy
biBNdXR1YWwgXGxpbmVccGFyDQpccGFyZFxmMVxmczIwXHBhcg0KfQ0KAA==

--openmail-part-60c5abfd-00000002--


<Prev in Thread] Current Thread [Next in Thread>