We have about 500 nodes and have a backup windows from 5pm until 7am. I have
our backup schedule setup so that about 30 nodes do incremental per hour with a
few exceptions. We have a 3T disk storage pool and 4 LTO4 drives in our tape
library. Our dbbackuptrigger is set at logfull 30% and
Hello all,
Why this query do not work in tsm 6.1.3.1 ?
select filespaces.node_name from filespaces
ANR0162W Supplemental database diagnostic information: -1:42S22:-206
([IBM][CLI Driver][DB2/NT64] SQL0206N FILESPACES.NODE_NAME is not valid in
the context where it is used. SQLSTATE=42703
Hana, This is correct request
select a.node_name from filespaces a, nodes b where
b.node_name=a.node_name
--
Dmitry Dukhov
Siberia Software SL
http://www.s-iberia.com
On 14.02.2010 17:33, Hana Darzi wrote:
Hello all,
Why this query do not work in tsm 6.1.3.1 ?
select
Hi...
We have a similar TSM system. We have our TSM DB (over 400GB) only about 1/3
full and proactively run incrementals. We have fourteen LTO3 tapes drives
directly connected using 4Gbps FC adapters. IBM 9155-55A with 8-WAY/64GB of
memory and an IBM SVC(four nodes)/FAStT system using
BTW, we have a TSM V5.5.2.0 with IBM 3584-L32 and 3-3584-D32s. A TSM system
needs I/Os, I/Os, I/Os and fast I/Os and a lot of disk space.
-Original Message-
From: Lamb, Charles P.
Sent: Sunday, February 14, 2010 9:35 AM
To: 'ADSM-L@VM.MARIST.EDU'
Subject: RE: Our TSM system is
On 14 feb 2010, at 15:33, Hana Darzi wrote:
Hello all,
Why this query do not work in tsm 6.1.3.1 ?
Hana,
have you tried using:
select node_name from filespaces
as a work-around? As you see from the error, there is an underlaying view in
DB2. It's not unlikely that you have found a bug
Hello John,
I am sorry, maybe I do not understand your request, but I have very simple
advice - just increase logs at least 3-4 times.You will have enough time for
everything.
I have 130 nodes and 16Gb database with 8GB logs and sometimes it is not
enough. I think 13GB logs for so big TSM
John,
A few things come to mind; Which nodes are pinning the recovery log? In my
experience it are always a few slow nodes (with a lot of small files
typically) that pin the log. Try to find out which one do, and try to
improve these nodes so that they backup faster. Hell of a job when you have
On Feb 14, 2010, at 11:32 AM, Grigori Solonovitch wrote:
Hello John,
I am sorry, maybe I do not understand your request, but I have very
simple advice - just increase logs at least 3-4 times.You will have
enough time for everything.
I have 130 nodes and 16Gb database with 8GB logs and sometimes
On 14 feb 2010, at 14:12, Dury, John C. wrote:
We have about 500 nodes and have a backup windows from 5pm until 7am. I have
our backup schedule setup so that about 30 nodes do incremental per hour with
a few exceptions. We have a 3T disk storage pool and 4 LTO4 drives in our
tape library.
Keith Arbogast wrote:
Someone 'Richard and famous' caught a syntax error in my include
statement. It is corrected to:
include.fs.nas /nfs/evs05/opt/oracle/rman rman
The include.fs.nas statement is for NDMP backups, not for backing up
an NFS filesystem mounted on the TSM client node.
Try
11 matches
Mail list logo
