Reporting_MB = "REPORTING_MB is the amount of space that would be occupied if
the data wasn't placed in a deduplication-enabled storage pool."
So on the first node below, you saved 5MB out of 1.8GB.
Your physical_mb shouldnt be 0 though which is weird (unless I'm mixing up the
columns, they l
Hi Charles,
Thanks for the quick reply! I ran the select against my storage
pool and it worked. Now I just have to analyze the data to verify that it
can be billed properly. Thanks much!
Jim
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU
Gents, got a message back from IBM regarding the 6.2.3 client.
Here's the doc they pointed me to:
"It looks like the issue might be related to not keeping the TSM metadata
(control files) on disk while allowing the actual virtual machine backup data
to reside on tape, as documented under the "
It appears by doing a select on the occupancy table; the full amount of
data is reported in the Logical Column, and reporting is deduped
tsm: TSMLAB1>select NODE_NAME, STGPOOL_NAME, NUM_FILES, PHYSICAL_MB,
LOGICAL_MB, REPORTING_MB from occupancy where STGPOOL_NAME='DISK-DEDUPE'
NODE_NAME
Hi All,
We are in the process of testing TSM's Deduplication feature
and I have a question about how the cost of the deduplicated data gets
allocated. For example:
Two systems that have 80% of their data in common and that belong to two
different departments get backed up
Sorry Paul, Just seeing your reply in the thread..
We had no issues with recovery log pinning at 5.5.4.0 and now are
experiencing them at 5.5.5.0,but will put in to upgrade the TSM Server to
go to .5.5.5.2 for the IC58852 next week. I want to let this code run
this week and I need to finish our
Hi all,
We have 2 proxy vm servers
Proxy 1 - Windows 2003 standard R2 SP2 using Tivoli client level 6.2.3
(which was upgraded from 6.2.2.0 in which we were having the same issue)
During the nightly incremental VM backups are causing the server to reboot
(this started happening recently)
T
Oh my god!
I really thought I was the only one fighting the logpinning issue! My
database is filled up to 80% or more at least 20 times a day and all the
triggered incrementals have made me running out of scratches multiple
times. This very weekend our standby was called again because the
r
Thanks to everyone who replied with the not so wonderful news on the
performance/recovery log issues. I have an open case with IBM TSM
Support now and working on it with support now on it. I will let you
know if I hear anything different once they review my output I sent them
over the weekend.
On Apr 17, 2011, Nick Laflamme wrote:
>[...]
> And 5.5.5.2 was just released; this has, among other things, a fix for a
> bug that hangs TSM when you use automatic relabeling of scratch volumes
> (ie, VTL users, usually) and MOVE DRM. I've had 5.5.5.2 on about eight
> servers that had been running
Been there - read the book - saw the movieetc.
We went through the same problem plus other issues with the log
stair-stepping (more transactions that it could handle - things slowing
down until it could catch up - flooded with transactions again -
rinse-lather-repeat) generating false log-fu
Hello,
I don't know the behavior on 5.5.5 (we went straight to 5.5.5.2 because of the
SQL SELECT bug), but on 5.5.4 we had a lot of issues with logs being pinned due
to IC65781.
Problems have disappeared since the upgrade.
Paul
-Original Message-
From: ADSM: Dist Stor Manager [mailt
12 matches
Mail list logo
