We have two large TSM servers, the larger with a database on the order of 1.4TB.
In the latest hardware refresh, I debated whether to buy SSDs for the
database. I ended up sticking with the tried-and-true 15K SAS disks since I
wasn't sure of the consequences of the high write load from DB2 on the
Hi to all
To increase performance on my TSM servers 7.1.1.0 , I think to install my
databases on SSD disks.
I have some questions:
Þ Will be more efficient to put the active log too on the SSD disks
Þ Can I move in the same step the database and the active log as:
o On
Hello Robert,
We use SSD arrays for both our database and our active log. That said,
unless you are using TSM deduplication or node replication, SSD disks
should not be required for good server performance. Standard 15K SAS
drives are more than sufficient for regular server operations when
This probably isn't completely right, but it might be a start:
select node_name,hl_name,min(backup_date) from backups group by
node_name,hl_name
--
Cameron Hanover
chano...@umich.edu
Let's get dangerous.
--Darkwing Duck
On Mar 9, 2015, at 3:42 PM, Kamp, Bruce (Ext) bruce.k...@alcon.com wrote:
I think the README is just incompletely labeled. If you follow the link, the
target page is titled Linux x86/x86_64 Client Requirements, and the section
for version 6.2 includes both X86 and AMD64/EM64T as supported hardware.
The dsmtca fixes in 6.2.5.4 would be at that code level, too, not just
Just to chip in my experiences after almost a year with TSM on enterprise SSDs:
OS drive (Windows): 100 GB RAID 1 - wear at 99.78 %
TSM log disk: 100 GB RAID 1 - wear at 99.49 % (log disk may be 128 GB - I know,
but this was what I had)
TSM DB disks: 8 containers on 500 GB each, all on a 4 TB
I think that is the case, but you can workaround the bug by deleting or
removing access to the dsmtca binary.
On Tue, Mar 10, 2015 at 03:56:24PM +, Thomas Denier wrote:
We have a considerable number of Linux TSM clients running on 32 bit x86
processors and currently using either 6.2.2.0 or
Thanks for the help!
This what I ended up with.
SELECT CAST((NODE_NAME) AS CHAR(20)) AS Node Name,CAST(MIN(BACKUP_DATE) AS
DATE) AS BACKUP DATE FROM BACKUPS WHERE NODE_NAME LIKE '%_TDP' AND
STATE='ACTIVE_VERSION' AND CLASS_NAME LIKE
'%DB%' AND BACKUP_DATE '2015-02-01' AND FILESPACE_NAME NOT
We had a customer who installed his application on d: (with windows on c:).
No files missed or excluded from the backup. His d: drive crashed and he
restored it. Again no files missed or excluded. Everyone expected success.
Sadly his application could not start.
Why?
Part of his .exe files
