Target: Oracle Report should generate > 13000 pages of PDF output. This is a long running report around 15 Minutes. Is a Oracle report with paper layout. Works perfect when pressing “run paper layout” in Oracle Reports Builder 10g (10.1.2.0.2) Can scroll down to pag 13000. Now I’d like to create a 13000 page pdf file. Reports Developer Menu - FILE - GENERATE TO FILE - PDF Report ist starting and counting up to something between 400 and 9000 pages - and then crashes.
The same behavior when doing it directly in Reports Developer as when depolyed on OAS Reports Services.
Error Log :
An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x65125621 Function=rwagrcm+0x51521 Library=C:\orant_10gR2\BIN\rw.dll
Current Java thread: at oracle.reports.engine.EngineImpl.CRunReport(Native Method) at oracle.reports.engine.EngineImpl.run(EngineImpl.java:437) at oracle.reports.server.JobManager.runJobInEngine(JobManager.java:916) - locked <0x11574a08> (a oracle.reports.engine.EngineImpl) at oracle.reports.server.ExecAsynchJobThread.run(ExecAsynchJobThread.java:54)
… … …
Heap at VM Abort: Heap def new generation total 1344K, used 1227K [0x10030000, 0x101a0000, 0x113e0000) eden space 1216K, 94% used [0x10030000, 0x1014fa78, 0x10160000) from space 128K, 59% used [0x10160000, 0x101732c8, 0x10180000) to space 128K, 0% used [0x10180000, 0x10180000, 0x101a0000) tenured generation total 17012K, used 15998K [0x113e0000, 0x1247d000, 0x20030000) the space 17012K, 94% used [0x113e0000, 0x1237fa28, 0x1237fc00, 0x1247d000) compacting perm gen total 17408K, used 17308K [0x20030000, 0x21130000, 0x24030000) the space 17408K, 99% used [0x20030000, 0x211173a8, 0x21117400, 0x21130000)
Solution 1:a) make the following change: b) open the rwbuilder configuration file located in:
DEVELOPER_SUITE_HOME\reports\conf\rwbuilder.conf
c) search for the following entry:
and replace the value=“50” with a value that should be larger that the report output will be generated. (the value is in Mb)
d) restart the Reports Builder in order that the change will take effect .
Solution 2:a). locate the rwbuilder configuration file in: DEVELOPER_SUITE_HOME\reports\conf\rwbuilder.conf and search for the id=“rwEng” ../>tag.b). Add the following attributes to the engine tag: jvmOptions=**"-Xms1024m -Xmx1024m"**for example Change from
maxEngine=“1” minEngine=“0” engLife=“50” maxIdle=“30” callbackTimeOut=“60000”>
into
maxEngine=“1” minEngine=“0” engLife=“50” maxIdle=“30” callbackTimeOut=“60000” jvmOptions="-Xms512m -Xmx512m"> This will set an Engine’s JVM options.
c). restart the report builder
( Alternate try to suppose this as a Oracle Reports command line extention as: C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions="-Xmx1024m -XX:+PrintGCDetail" )
Solution 3:I think the problem is somewhere in the PermSize section of Java / JVM I found an interesting link : http://forums.bea.com/bea/message.jspa?messageID=202465135&tstart=0 Afther that I started my report with: C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions="-Xmx1024m -XX:+PrintGCDetail" With this I tried getting more error information. But what happend? Beleve it or not. Now, my Report run successfully and created 13000 pdf pages.I will further investigate with jvmoptions: -XX:NewSize=128m -XX:MaxNewSize=128m -XX:PermSize=64m -XX:MaxPermSize=64m
Additional information belonging to this Oracle Reports Bug (Java Problem, JVM): I would bet you run out of permspace: compacting perm gen total 9472K, used 9414K [0x30010000, 0x30950000, 0x34010000) the space 9472K, 99% used [0x30010000, 0x30941a30, 0x30941c00, 0x30950000)I think low space is the problem, but I don’t know how to increase it… (I use the Eclipse platform)I solve the problem in desactivating the Hotspot mode with the option -Xint.The JVM options used are - maxpermsize 128M, xMs - 512M and xMx - 512M.The PERMANENT heap NEVER will reduce and in fact objects (Classes) placed in the PERMANENT heap are PERMANENTLY in that HEAP. Hence PERMANENT. No GC will ever unload any object from the permanent heap.When the perm gen is full, the classes would be unloaded from perm gen. And that is happening in my case also. The log file shows in some other cases when the perm gen size reaches some value of 46-47MB - the classes getting unloaded.
This is my currently VM options: -Xms256m -Xmx256m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintGCApplicationStoppedTime -XX:NewSize=64M -XX:MaxNewSize=64M -XX:SurvivorRatio=8 -Xloggc:/logs/weblogic/jdevext/gc.log
The key parameters that you can send to the JVM are summarized below: * -verbose:gc - Prints some GC info * -XX:+PrintGCDetails - PrintGC details * -XX:+PrintGCTimeStamps - Adds timestamp info to GC details * -XX:+PrintHeapAtGC - Prints detailed GC info including heap occupancy before and after GC * -XX:+PrintTenuringDistribution - Prints object aging or tenuring information * -XX:+PrintHeapUsageOverTime - Print heap usage and capacity with timestamps * -Xloggc:filename - Prints GC info to a log file
MaxPermSize ?? if Perm Size is in a separate area, are we saying that there should be a formula like: MaxNewSize+MaxPermSize=max heap size? -ms512m -mx512m -XX:MaxPermSize=64m
Please try setting PermSize to the same value as MaxPermSize when you run the test. -Xms512m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=64m
- The permanent space is memory allocated outside the regular heap (i.e. in addition to the -Xmx setting), so it is important to ensure there is enough physical RAM on the machine. The permanent space is used to primarily store classes and objects created for reflection support (methods etc.). If you have a large number of classes in a Java application, an OOM can occur if the PermSize is too small. - For the Max. Heap size, what would you recommend trying? Setting MaxPermSize to 1/4 of Xmx is suffient?? - I’d suggest getting some data first using the -XX:+PrintGCDetails flag. This flag breaks down GC information into nursery, old and perm spaces. That should indicate which space is running out of memory. Note that setting this flag has a performance impact. As a ballpark figure, I’d start with: -Xms512m -Xmx512m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:PermSize=64m -XX:MaxPermSize=64m Additional Links: http://www.informit.com/guides/printerfriendly.asp?g=java&seqNum=99&rl=1 http://forum.java.sun.com/thread.jspa?tstart=0&forumID=27&threadID=343789&trange=15 http://forum.java.sun.com/thread.jspa?threadID=550279&messageID=2689390 http://forums.bea.com/bea/message.jspa?messageID=202464913&tstart=0 http://forums.oracle.com/forums/thread.jspa?messageID=453207
Im Jahr 2024 sind Oracle Reports weiterhin ein wichtiger Bestandteil vieler Unternehmen, um PDF-Berichte zu erstellen. Es ist jedoch wichtig zu beachten, dass einige der Probleme, die in dem Text von 2011 beschrieben wurden, immer noch relevant sein können. Einige der genannten Lösungen könnten jedoch möglicherweise veraltet sein oder nicht mehr die effektivsten Methoden zur Behebung von Problemen mit Oracle Reports darstellen.
In dem Text von 2011 wurden verschiedene Probleme beim Generieren von PDF-Berichten mit Oracle Reports beschrieben, darunter Abstürze, Heap-Probleme und Zugriffsverletzungen. Diese Probleme könnten auch im Jahr 2024 noch auftreten, insbesondere wenn die Konfiguration von Oracle Reports nicht ordnungsgemäß aktualisiert wurde.
Es wird empfohlen, dass Unternehmen, die Oracle Reports verwenden, sicherstellen, dass ihre Konfigurationen auf dem neuesten Stand sind und dass sie die aktuellen Best Practices für die Konfiguration von Oracle Reports befolgen. Dies kann dazu beitragen, die Wahrscheinlichkeit von Problemen wie Abstürzen aufgrund von Speicherproblemen zu verringern.
Eine wichtige Aktualisierung für das Jahr 2024 ist die Tatsache, dass Oracle regelmäßig Updates und Patches für seine Produkte veröffentlicht, einschließlich Oracle Reports. Durch das Einspielen dieser Updates können Unternehmen sicherstellen, dass sie von den neuesten Verbesserungen und Fehlerbehebungen profitieren.
Ein weiterer wichtiger Punkt, der im Jahr 2024 beachtet werden sollte, ist die Sicherheit von Oracle Reports. Da PDF-Berichte möglicherweise sensible Unternehmensdaten enthalten, ist es entscheidend, sicherzustellen, dass die Zugriffsrechte und Sicherheitsmaßnahmen für Oracle Reports angemessen konfiguriert sind, um unbefugten Zugriff zu verhindern.
Zusammenfassend lässt sich sagen, dass Oracle Reports auch im Jahr 2024 eine wichtige Rolle bei der Erstellung von PDF-Berichten spielen. Unternehmen sollten sicherstellen, dass ihre Oracle-Reports-Konfigurationen auf dem neuesten Stand sind und die aktuellen Best Practices befolgen, um potenzielle Probleme zu minimieren und die Sicherheit ihrer Berichterstellung zu gewährleisten.