Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

JAZZ DataBases

Questions
Tags
Users
Badges
Mario Coluzzi
(3●5●8) edited
May 23 '14, 9:19 a.m.
I have been wondering the reasons of why Jazz allows one database to store everything! OK you can have single CCM-QM-RM-JTS databases. . . . still one DB for CCM; one DB for RM; one DB for QM DB and one DB for JTS.

It does not make any sense in terms of:

- Fast access
- Easy backup
- Easy Refactoring
- Moving/Restoring/Backup of DB
- Balancing/Moving/Administration

I am puzzled why there is neither an option not a setting to create "individual CCM-QM-RM Project's Databases?" In one environment I administer I have seen an exponential growth, yes exponentially because I had to ask twice to have the datafile increased.

Have I missed something important in JAZZ?

0 votes

5 answers
10,072 views
0 votes

5 answers

Permanent link
Mario Coluzzi
(3●5●8) May 27 '14, 10:07 a.m.
Another argumentation and reason of why JAZZ needs to address the necessity of individual DataBase is when a restoring of an individual Project is required (also backup for that matter)

To my knowledge you cannot selectevely restore a Project but you restore the whole DataBase . .  . a bit absourd I'd say. Let's for example have this scenario:

Project A: work normally and progresses
Project B: work normally and progresses 
Backup day 1: full and/or incremental backup
---
Project A: work normally and progresses
Project B: work normally and progresses
Backup day 2: full and/or incremental backup
---
Project A: work normally and progresses
Project B: work normally and progresses
Backup day 3: full and/or incremental backup
--
Project A: work normally and progresses
Project B: they realize it is currupted and unknown when

What is the correct restore for Project B? Day 1 backup brings both projects back three days, day 2 back two days, day 3 back one day . . . . hence I advocate and I believe that a single DB for a project is prefereable, am I wrong? Am I missing something else in here?

P.S.: imagine the above for 10 or  20 projects . . . . .  . . . . . . . . . 

0 votes

Comments
sam detweiler
May 27 '14, 10:21 a.m.
same design for the other rational products. We had a similar issue with RQM. someone deleted a whole project worth of testcases somehow.    didn't discover til three days later.. 15 other projects had moved forward.. no way to restore just one project to get the testcases back. (I just joined here, so I can't tell if they could have restored to a sandbox to get the testcases, and copy back into the project..)

Permanent link
Mario Coluzzi
(3●5●8) edited
May 23 '14, 8:35 p.m.
I have forgotten to add that once you "archive" a Project the data cannot be removed from the DataBase = waste of resources. 

At least once a Project is "archived" there should be the option "dump" the data and "removed" it from the DataBase 

0 votes

Comments
sam detweiler
May 23 '14, 8:37 p.m.
You can delete workitems. So unarchive , delete workitems, archive again. Attachments will be dropped when not referenced.  So, most can be cleaned up.

Mario Coluzzi
May 27 '14, 9:21 a.m.
Did not know this. Nice! Attachments are intended as external files or also CIs? 

sam detweiler
May 27 '14, 9:25 a.m.
attachments are loaded from files into the database as objects. they have a unique identifier, but I don't think they rise to CI.. there is no search capability to find attachment x and how it is referenced.

Permanent link
Mario Coluzzi
(3●5●8) May 23 '14, 9:39 a.m.
I agree for JTS-RM-QM but really so for CCM  . . . . . . . 

Only CCM in my environment accounts for more than 120GB Oracle DW_DATA table space. In ClearCase you have individual VOBs that you can move in case of refactoring, with JAZZ-CCM you are stuck!

0 votes

Comments
sam detweiler
May 23 '14, 9:44 a.m.
Yes, it would be nice if you could separate Source file content from workitem content. for a number of reasons. sounds like someone is using SCM to store binary files too. (we had that problem)

Mario Coluzzi
May 23 '14, 10:07 a.m.
You cannot force the developers to store only text files and leave any other types out. I agree and I would neither advise anyone nor advocate to store builds bundles in any SCM. Still you need a common version of Java/Ant/Maven. So where do you store any specific version in a safe way? In your PC? No way! The Build Managers, for example, need to rely on a common version of Ant, Maven or other binaries and not use the ones you have into your machine. Therefore those have to come from a common place. Someone suggested once a NTFS drive . . . it has never been a reliable source (not only in this current environment, but also in past places I worked with) I am missing ClearCase UCM features, honestly. Lots out there hated it on lack of knowledge. Once you did show them what UCM could do, well they become best pal in the end 

sam detweiler
May 23 '14, 10:26 a.m.
Yeh, Nexus or somesuch for binaries.. we had one team stuff TWO 1.5 GIG binaries into the SCM, dragged out for each build, executed (runtime install packs), really messed up the whole infrastructure stability and performance. we had enhancement https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=232245 opened to try to find some way to isolate the build/source system workload from the UI workload.

Permanent link
Piotr Aniola
(3.7k●1●17●38) May 23 '14, 9:36 a.m.
There are several factors mentioned in the original post.
First of all, I doubt if creating one database per project instead of one per application would affect the overall disk space required (in a positive way, anyway, I can imagine that some data would need to be duplicated between databases). If you see exponential growth of your database I encourage you to create a PMR so support can have a look at it.

In terms of fast access, I'm no expert but I don't think there is any significant difference between one larger DB and several smaller, as long as they reside on the same machine. DB speed is limited by disk IO, not by logical arrangement of data.

I can agree that maintenance of large databases is more troublesome that that of even a larger number of smaller ones. If this is an issue for you, please consider creating more CCM/RM applications, and distributing the projects among them, rather than having one application for all the projects.

0 votes

Comments
Kevin Ramer
May 23 '14, 9:44 a.m.
One point here:  The time to distribute would be before large amounts of work go into the project areas as currently there is no complete migration from one repository to another.  Nor is there a means of removal of a project area from a repository (other than marking it achived)

Permanent link
sam detweiler
(12.5k●6●195●201) May 23 '14, 9:29 a.m.
they are different applications with different schema with nothing shared, and different usage models.. best to keep them separated.

what is the overhead for creating a new 'database' vs adding some more tables to the same database? nothing really.

1 vote

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 6,180

Question asked: May 23 '14, 9:18 a.m.

Question was seen: 10,072 times

Last updated: May 27 '14, 10:21 a.m.

Confirmation Cancel Confirm