Hi Robert!
Thanks for the tip! You're right, all missing filespaces were not in the
occupancy table. And to make things even more difficult, some filespaces were
listed twice, because data for the same filespace resides in the diskpool and
the primary pool... The latter issue I can solve by addi
EJ:
Wish I could be as helpful this time. Sadly, I’ve not found a way to
generate this output with a single SQL statement - the TSM SQL engine doesn’t
seem to support the concept of OUTER JOIN. I’ve had to resort to doing 2
queries - one of the occupancy table and one of the filespaces tabl
The SQL engine actually does support OUTER JOIN, it's just that the view
schema exposed to us depends on joining on multiple keys; occupancy and
filespace are joined with (node_name,filespace_name). You can kind of fake
it by generating those keys in subqueries:
SELECT -
f.fs_key -
FROM -
(S
Skylar:
Never thought of this - thanks for sharing! Gonna be experimenting with some
of my existing queries
Robert Talda
EZ-Backup Systems Engineer
Cornell University
+1 607-255-8280
r...@cornell.edu
> On Apr 12, 2016, at 9:58 AM, Skylar Thompson wrote:
>
> The SQL engine actually does sup
One of my servers has issued backing up the DB and my research points to my
making ACTIVELOGSIZE bigger than the filesystemsize - 20%.
As I understand it, all I need to do is make the number smaller and restart
the server, twice.
This document:
http://www.ibm.com/support/knowledgecenter/SSGSG7_6
