Memory Target on 11g

If MEMORY_TARGET is set to a non-zero value:

1. If SGA_TARGET and PGA_AGGREGATE_TARGET are set, they will be considered the minimum values for the sizes of SGA and the PGA respectively. MEMORY_TARGET can take values from SGA_TARGET + PGA_AGGREGATE_TARGET to MEMORY_MAX_SIZE.
2. If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not set, still both parameters will be auto-tuned. PGA_AGGREGATE_TARGET will be initialized to a value of (MEMORY_TARGET-SGA_TARGET).
3. If PGA_AGGREGATE_TARGET is set and SGA_TARGET is not set, still both parameters will be auto-tuned. SGA_TARGET will be initialized to a value of min(MEMORY_TARGET-PGA_AGGREGATE_TARGET, SGA_MAX_SIZE (if set by the user)) and will auto-tune subcomps.
4. If neither is set, they will be auto-tuned without any minimum or default values. The policy is to give 60% for sga and 40% for PGA at startup.
   

If MEMORY_TARGET is not set or set to set to 0 explicitly (default value is 0 for 11g):

1. If SGA_TARGET is set it will only auto-tune the sizes of the sub-components of the SGA. PGA will be autotuned independent of whether it is explicitly set or not. Though the whole SGA(SGA_TARGET) and the PGA(PGA_AGGREGATE_TARGET) will not be auto-tuned, i.e., will not grow or shrink automatically.
2. If neither SGA_TARGET nor PGA_AGGREGATE_TARGET is set, it will follow the same policy as it have today; PGA will be auto-tuned and the SGA will not be auto-tuned and parameters for some of the sub-components will have to be set explicitly (for SGA_TARGET).
3. If only MEMORY_MAX_TARGET is set, MEMORY_TARGET will default to 0 and it will not auto tune sga and pga. It will default to 10gR2 behavior within sga and pga.
4. If sga_max_size is not user set, it will internally set it to MEMORY_MAX_TARGET.
5. In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET and include a value for MEMORY_TARGET, the database automatically sets MEMORY_MAX_TARGET to the value of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup, you can then dynamically change MEMORY_TARGET to a non-zero value, provided that it does not exceed the value of MEMORY_MAX_TARGET.
   

following views can be useful

* V$MEMORY_DYNAMIC_COMPONENTS has the current status of all memory components
* V$MEMORY_RESIZE_OPS has a circular history buffer of the last 800 SGA resize requests

metalink note 452512.1

Java Code Sinppet: JAX-WS & MTOM

To enable MTOM (Message Transmission Optimization Mechanism) there are several things need to be done and in a nutshell

1. add the MTOM annotation on the services class

@javax.xml.ws.soap.MTOM
    @WebService(serviceName =

2. Following table list the relationship between MIME type and java type

MIME type          Java type
image/gif          java.awt.Image
image/jpeg          java.awt.Image
text/plain          java.lang.String
text/xml          javax.xml.transform.Source
application/xml  javax.xml.transform.Source
*/*                  javax.activation.DataHandler

3. Edit the WSDL to and list the correct mime type which will change the schema from

<xs:sequence>
    <xs:element name="return" type="xs:base64Binary" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>

to

<xs:sequence>
    <xs:element name="return" type="xs:base64Binary" minOccurs="0" maxOccurs="unbounded" 
xmime:expectedContentTypes="image/jpeg" xmlns:xmime="http://www.w3.org/2005/05/xmlmime"/>
</xs:sequence>

4. Make the container use the edited WSDL than generated one

@WebService(serviceName = ...., wsdlLocation="WEB-INF/wsdl/edited.wsdl")

5. Deploy the new service

for more info netbeans tutorial pages 1, page 2, page 3



To do the above without any modification to wsdl (using annotation on the java class)

1. Set the @MTOM as above on the service

@MTOM
@WebService
public class NewWebService {

2. Annotate the data type on the web method as follows

@WebMethod
public void setImage(@XmlMimeType("image/gif")Image img){

3. Can also annotate a return type

@WebMethod
public @XmlMimeType("image/gif")Image getImage( String name){

4. All kind of data types could be used

@WebMethod
public @XmlMimeType("*/*")Image getFiles

Rolling Forward Image Copy Backups

On the first day create a incremental level 0 copy of the database

backup as copy incremental level 0 tag 'roll_update' database;

On the second day create a incremental level 1 of the database

backup incremental level 1 for recover of copy with tag 'roll_update' database;

On the thrid day use the second day incremental level 1 backup to roll forward the first day level 0 backup and then take a new incremental level 1 backup and repeat this step.

run{
   recover copy of database with tag 'roll_update';
   backup incremental level 1 for recover of copy with tag 'roll_update' database;
}

The whole thing could be simplified with

run{
   recover copy of database with tag 'roll_update';
   backup incremental level 1 for recover of copy with tag 'roll_update' database;
}

Points to note.

1. The BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG... command does not actually always create a level 1 incremental backup. If there is no level 0 image copy backup of an particular datafile, then executing this command creates an image copy backup of the datafile on disk with the specified tag instead of creating the level 1 backup. Thus, the first time the script runs, it creates the image copy of the datafile needed to begin the cycle of incremental updates. In the second run and all subsequent runs, it produces level 1 incremental backups of the datafile.

2. The RECOVER COPY OF DATABASE WITH TAG... command causes RMAN to apply any available incremental level 1 backups to a set of datafile copies with the specified tag. If there is no incremental backup or no datafile copy, the command generates a message but does not generate an error. The first time the script runs, this command has no effect, because there is neither a datafile copy nor a level 1 incremental backup. The second time the script runs, there is a datafile copy (created by the first BACKUP command), but no incremental level 1 backup, so again, the command has no effect. On the third run and all subsequent runs, there is a datafile copy and a level 1 incremental from the previous run, so the level 1 incremental is applied to the datafile copy, bringing the datafile copy up to the checkpoint SCN of the level 1 incremental.

3. Each time a datafile is added to the database, an image copy of the new datafile is created the next time the script runs. The time after that, the first level 1 incremental for that datafile is created, and on all subsequent runs the new datafile is processed like any other datafile.

4. Tags must be used to identify the incremental level 0 datafile copies created for use in this strategy, so that they do not interfere with other backup strategies you implement. If you have multiple incremental backup strategies in effect, RMAN cannot unambiguously create incremental level 1 backups unless you tag level 0 backups. The incremental level 1 backups to apply to those image copies are selected based upon the checkpoint SCNs of the image copy datafiles and the available incremental level 1 backups. (The tag used on the image copy being recovered is not a factor in the selection of the incremental level backups.)

more on incremental backups