JAZZ DataBases

Mario Coluzzi (3●4●8) | asked May 23 '14, 9:18 a.m.
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?

5 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

sam detweiler (12.5k●6●191●201) | answered 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.

permanent link

Piotr Aniola (3.7k●1●16●38) | answered 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.

Comments

Kevin Ramer commented 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

Mario Coluzzi (3●4●8) | answered 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!

Comments

sam detweiler commented 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 commented May 23 '14, 10:05 a.m. | edited 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 commented 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

Mario Coluzzi (3●4●8) | answered May 23 '14, 8:34 p.m.
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

Comments

sam detweiler commented 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 commented May 27 '14, 9:21 a.m.

Did not know this. Nice! Attachments are intended as external files or also CIs?

sam detweiler commented 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●4●8) | answered 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 . . . . . . . . . . . . . .

Comments

sam detweiler commented May 27 '14, 10:20 a.m. | edited 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..)

It's all about the answers!

Related questions

JAZZ DataBases

5 answers

Your answer