Hmmm. I think you're right. I meant occupancy. The contents table is
impossibly slow to process via SELECT.
The occupancy table is much faster, though still not fast. There is an
anomoly I noticed with occupancy data. SELECT * FROM OCCUPANCY is MUCH
faster than QUERY OCC. So much faster that I mad
I think Avy's question should be rephrased to "Which nodes are currently
scheduled to be backed up?" (Avy, correct me if I'm wrong)
In which case the select statement should be against the associations
table.
Shawn Drew
Data Protection Engineer
Cor
On Mar 15, 2008, at 2:36 PM, Roger Deschner wrote:
That occupancy table can be REALLY slow to process if your system
is at
all large. I prefer to search the summary table which is fast, even
with
my 275gb database.
Roger - Are you thinking of the Contents table?
I have a large system, and it
.
That occupancy table can be REALLY slow to process if your system is at
all large. I prefer to search the summary table which is fast, even with
my 275gb database.
select distinct entity from summary where activity='BACKUP'
...will be MUCH faster. This gives you the past 30 days. If you want
fe
Thank you Richard, Bill. I understand q occ will do the job, but because I
need to pin down the ones that are currently being backed up, that is why I
need to be specific. Thanks again.
Avy Wong
Business Continuity Administrator
Mohegan Sun
1 Mohegan Sun Blvd
Uncasville, CT 06382
(860)862-8164
(ce
Your select statement works great, but, just 'query occupancy' or 'q
occ' will also show number of files, size and where the copies are
stored for each node.
_Bill
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: Friday, March 14,
