Почему именно Tenured? JDK/bin/jvisualvm - запускаем, подсоединяемся к существующему Java процессу. Делаем дамп кучи, анализируем.

GregTkПри выполнении кода связанного с запалнением БД данными падает:
java.lang.OutOfMemoryError: GC overhead limit exceeded
Куча не переполнилась, просто GC работал слишком долго и не смог освободить достаточно места.

GregTkПри падении получаю Heap Dump, как в нём понять что именно лежит в Old Gen не ясно. Old gen я хочу про анализировать потому что, локализовав участок кода я вижу что при его исполнении начинает быстро заполнятся OldGen(определяю по графика Visual GC).

Забудьте про Old Gen. Эта фильтрация вам ничего не даст. Скажу даже более. Если у вас это временные данные, то может имеет смысл просто увеличить Young?

GregTkЯ так понимаю что анализ heap dump делается через OQL , может покажете как отфильтровать по Old gen.
Ненужно ничего фильтровать. Запускаете, открываете дамп и анализируете содержимое памяти
http://visualvm.java.net/heapdump.html

GregTkпонятно, но мне не ясно как из например 2 млн. String понять какие именно относятся к моему приложению, грубо говоря если начинать просмотр их содержимого, то вижу вещи вообще не связанные. А можно Instances с группировать по их refernces? Я такого просто в VisualVM не нашел...
VisualVM достаточно простой профайлер, возможно нужные вам фичи есть в YourKit или JProfiler.
Но мне хватает VisualVM с головой. Сортируете строки по размеру. Находите несколько тех типичных, из-за которых произходит утечка. Находите их GC Root. Анализируете этот пусть и смотрите какой общий объект держит ссылки.

Можно ещё попробовать Memory Profiler. Он покажет прирост каких объектов произошел на некоторое время. И там вместо String увидите свои сущности, и проанализируете.

Можно отфильтровать по package и смотреть только свои классы, например.

Если хотите, можете выложить дамп, я посмотрю может что подозрительное увижу.