Attachments storage location
Planning an initial import to RTC with attachments - are there any guidelines / papers to follow when deciding on best location for attachments?
Initial import of attachments will be near 20GB, with an estimated growth rate of attachments by 20GB every 5 years. Should attachments be placed within the repository or on external file server? Will long term db performance be an issue if attachments are within the repository? |
One answer
Dr. Hans-Joachim Pross (1.1k●44●58)
| answered Jan 14 '14, 5:37 a.m.
JAZZ DEVELOPER edited Jan 14 '14, 5:39 a.m. Comments
Ian Pillion
commented Jan 14 '14, 12:12 p.m.
Is my understanding incorrect that attachments don't have to be stored in the database? As @sdetweil mentions here attachments can be linked to a file server, which I assume would maximize the performance of the database..
If you use Links, they are not considered 'attachments'
so, yes you can link them to workitems, but the UI for users creating them stinks.
they must KNOW the file URL, and cut/paste it into the link creation UI.
they cannot navigate the filesystem like using 'attachments'
I created an enhancement and prototype to effectively use symbolic style links to files so that the user would navigate the filesystem like normal
Ian Pillion
commented Jan 22 '14, 9:33 a.m.
Thanks. I don't think using Links and a file server is going to fulfill our requirements. Back to adding attachments into the database so.
@sam detweiler : any chance you could share the code underlying your external attachment storage solution beyond the comments in the jazz.net work item? I really would like to fiddle around with it, try to get it to run on 4.0.5 and share back to you. If you have a cycle, please ping me @ arne(dot)bister(at)de(dot)ibm(cot)com.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
starting with 4.0.3 you can actually delete workitem attachments.
you should add this policy to your operations and on some cycle delete what u don't need. the default size setting is limited to 50 meg/attachment. (set in the ccm server advanced properties