Reduce sysaux tablespace file
Hi.
Could anybody suggest the ways to reduce size of sysaux tablespace file.
Thanks in advance.
Andrii.
Pl post details of OS and database versions. See also these MOS Docs
Suggestions if your SYSAUX Tablespace grows rapidly or too large [Document 1292724.1]
General Guidelines for SYSAUX Space Issues [Document 552880.1]
SYSAUX Grows Because Optimizer Stats History is Not Purged [Document 1055547.1]
Space issue in Sysaux tablespace due to Unexpected AWR size [Document 1218413.1]
Space Management In Sysaux Tablespace with AWR in Use [Document 287679.1]
SYSAUX Tablespace Grows Heavily Due To AWR [Document 852028.1]
HTH
Srini
Similar Messages
-
How to reduce the size of a sysaux tablespace
Hi All,
I am using oracle 10g database. My SYSYAUX tablespace size is aroud 6GB.
Actually statspack was configured in this database because of this the tablespace grows more. Now i removed statspack (perfstat user). now the space used comes around 600MB. I want to reduce the size of the tablespace. Can any body help me.
KiranYour statspack report is generated in sysaux tablespace ?
SYSAUX tablespace was installed as an auxiliary tablespace to the system tablespace when we created our database.
Some database components that formerly created and used separate tablespaces now occupy the SYSAUX tablespace.
Viewing Components using SYSAUX tbs.
SQL> column occupant_name format a15
SQL> column occupant_desc format a30
SQL> column schema_name format a10
SQL> select schema_name,occupant_name,occupant_desc,space_usage_kbytes
from v$sysaux_occupants;
You can move components tbs other that SYSAUX first you know which component move is applicable or not.
SQL> column move_procedure format a25
SQL> column move_procedure_desc format a40
SQL> select move_procedure,move_procedure_desc from v$sysaux_occupants;
Two major components consume lot of space.
1.AWR ( automatic workload repository)
2.OEM ( oracle enterprise manager repository) -
How to release space of SYSAUX tablespace
Hi,
I am now using htmldb 2.0 and created tens of tables in one schema. Several tables are stored in tablespace SYSAUX. Since now I am trying to store a big file to the table(1GB), I found the tablespace grows pretty fast and I have to extend the size. The odd thing is when I delete that file from my table, SYSAUX tablespace seems not release any room and when I insert the big file again into the table, SYSAUX grows again. How can I release the space then? I can't image that why it can't release any room. I also check the occupants of SYSAUX and found one occupant called "other" takes over 90% of space. I tried to move it out of SYSAUX, it doesn't work. What do "other" do actually? I got completely lost. Any help will be greatly appreciated.
LinkeHi,
if you drop a table in Oracle 10g,
you will find teh extents of this table in
DBA_FREE_SPACE.
in DBA_FREE_SPACE???
I don't think so.
SQL >select ddf.tablespace_name,round(total/1024/1024,3) ttlSize,round((total-nvl(freespace,0))/1024/1024,3) used, round((total-nvl(freespace,0))/total*100,2) usedpct
from
(select tablespace_name,sum(bytes) total from dba_data_files group by tablespace_name) ddf,
(select tablespace_name,sum(bytes) freespace from dba_free_space group by tablespace_name) dfs
where ddf.tablespace_name=dfs.tablespace_name(+) and ddf.tablespace_name='USERS';
TABLESPACE_NAME TTLSIZE USED USEDPCT
USERS 16 2.813 17.58
SQL >create table test (col1 number) storage(initial 2m)
2 /
Table created.
SQL >select ddf.tablespace_name,round(total/1024/1024,3) ttlSize,round((total-nvl(freespace,0))/1024/1024,3) used, round((total-nvl(freespace,0))/total*100,2) usedpct
from
(select tablespace_name,sum(bytes) total from dba_data_files group by tablespace_name) ddf,
(select tablespace_name,sum(bytes) freespace from dba_free_space group by tablespace_name) dfs
where ddf.tablespace_name=dfs.tablespace_name(+) and ddf.tablespace_name='USERS';
TABLESPACE_NAME TTLSIZE USED USEDPCT
USERS 16 4.813 30.08<--used 2mb
SQL >select sum(bytes)/1024/1024 from dba_segments where tablespace_name='USERS'
2 /
SUM(BYTES)/1024/1024
6.75
SQL >drop table test
2 /
Table dropped.
SQL >select sum(bytes)/1024/1024 from dba_segments where tablespace_name='USERS'
2 /
SUM(BYTES)/1024/1024
6.75 <-- kept in the same tablespace -
Logical corruption found in the sysaux tablespace
Dear All:
We lately see the logical corruption error when running dbverify command which shows the block corruption. It is always on the the sysaux tablespace. The database is 11g and platform is Linux.
we get the error like:error backing up file 2 block xxxx: logical corruption and this comes to alert.log out of the automated maintenance job like sqltunning advisor running during maintenance window.
Now As far as I know,we can't drop or rename the sysaux tablespace. there is a startup migrate option to drop the SYSAUX but it does not work due to the presence of domain indexes. you may run the rman block media recovery but it ends with not fixing since rman backups are more of physical than maintain the logical integrity.
Any help, advise, suggestion will be highly appreciated.If you let this corruption there then you are likely to face a big issue that will compromise database availability sooner or later. The sysaux is a critical tablespace, so you must proceed with caution.
Make sure you have a valid backup and don't do any thing unless you are sure about what you are doing and you have a fall back procedure.
if you still have a valid backup then you can use rman to perform a db block level recovery, this will help you in fixing the block. Otherwise try to restore and recover the sysaux. In case you cannot fix the block by refreshing the sysaux tablespace then I suggest you to create a new database and use aTransportable Tablespace technique to migrate all tablespaces from your current database to the new one and get rid of this database.
~ Madrid
http://hrivera99.blogspot.com -
hi,
I ve upgraded an database for 9i to 10g. The upgrade was sucessfull and the Db was in normal usage. Due to some functionality testing the database was restored to a state from the backup taken after upgrade. But while restoring the database i forgot to include the path of the datafile of sysaux tablespace in the control file re-creation script.
I didnt notice this issue for long time until i realised the mistake made by me.
I found in the alert logs which showed errors such as
ORA-01157: cannot identify/lock data file 124 - see DBWR trace file
ORA-01110: data file 124: '/oracle/ora/dbs/MISSING00141'
ORA-27037: unable to obtain file status
since the path of the sysaux tablespace was not referred in the script i thought of referring it now and i issued the following command
alter tablespace sysaux add datafile '<path>/sysaux01.dbf' reuse;
i issed this as the datafile was already present and i thought of jus reuing it again.
But what had happened is this datafile had been added as an additional datafile for the sysaux tablespace,which means the sysaux is still referring '/oracle/ora/dbs/MISSING00141' as one of the datafile.
but one important thing is that there isnt any such datafile ie '/oracle/ora/dbs/MISSING00141' when i checked inside the dbs folder.
The path is getting referred as part of the sysaux tablespace but its physical location is not found.
So i did took this datafile offlinedrop issuing
alter database datafile '/oracle/ora/dbs/MISSING00141' ofline drop
but the problem i m facing now is the AWR is not opening up and it throw error stating first datafile of sysaux tablespace '/oracle/ora/dbs/MISSING00141' not found.
ORA-00376: file 124 cannot be read at this time
ORA-01110: data file 141: '/oracle/ora/dbs/MISSING00141'
ORA-06512: at line 21.
any solution for solving the problem would be appreciated
thanks,
ahmedi m able to start up the database normally....there isnt any errors while starting the DB.These errors are encountered in alert log file and user trace files.As as result AWR is not opening.
-
Sysaux tablespace issue-missing sysux datafile
hi,
I ve upgraded an database for 9i to 10g. The upgrade was sucessfull and the Db was in normal usage. Due to some functionality testing the database was restored to a state from the backup taken after upgrade. But while restoring the database i forgot to include the path of the datafile of sysaux tablespace in the control file re-creation script.
I didnt notice this issue for long time until i realised the mistake made by me.
I found in the alert logs which showed errors such as
ORA-01157: cannot identify/lock data file 124 - see DBWR trace file
ORA-01110: data file 124: '/oracle/ora/dbs/MISSING00141'
ORA-27037: unable to obtain file status
since the path of the sysaux tablespace was not referred in the script i thought of referring it now and i issued the following command
alter tablespace sysaux add datafile '<path>/sysaux01.dbf' reuse;
i issued this as the datafile was already present and i thought of jus reusing it again.
But what had happened is this datafile had been added as an additional datafile for the sysaux tablespace,which means the sysaux is still referring '/oracle/ora/dbs/MISSING00141' as one of the datafile.
but one important thing is that there isnt any such datafile ie '/oracle/ora/dbs/MISSING00141' when i checked inside the dbs folder.
The path is getting referred as part of the sysaux tablespace but its physical location is not found.
So i did took this datafile offlinedrop issuing
alter database datafile '/oracle/ora/dbs/MISSING00141' ofline drop
but the problem i m facing now is the AWR is not opening up and it throw error stating first datafile of sysaux tablespace '/oracle/ora/dbs/MISSING00141' not found.
ORA-00376: file 124 cannot be read at this time
ORA-01110: data file 141: '/oracle/ora/dbs/MISSING00141'
ORA-06512: at line 21.
any solution for solving the problem would be appreciated
thanks,
ahmedHi, I've got exactly the same problem up to the point where I try to offline drop the MISSING0009 datafile.
The command says it completed OK but the phantom datafile does not go and still reports that it's there in dba_data_files, althoguh the online_status is RECOVER, the status is ONLINE.
I'm not sure how to get rid of the entry if the offline drop command doesnt work. I've tried recreating the control file and deleting the entry for this datafile too but somehow it returned after that too!
I''m also not sure what to do when I do get rid of it - since I cant recover the old sysaux01.dbf datafile since it's not consistent with the database since there has been a week inbetween and we're not running archivelogging.
I would assume that all the stuff usually put in the SYSAUX tablespace is therefore lost, but I dont think we use anything that normally puts stuff in there, I've only noticed this since I was trying to install em.
Do I have to rebuild the database from scratch? Or any ideas on how I can recover the situation? Can I do something like startup upgrade and re-run the upgrade scripts which will put their stuff back into sysaux....?
Many thanks for ideas
Rob -
What is the use of SYSAUX Tablespace in Oracle 10G
Dear Experts,
Please Tell me What is the use of SYSAUX Tablespace in Oracle 10G Because
during Web Load Testing It is going to increase countinuosly.Although i am not using this with any tables.
How Can I find out the what is gong on in this.
Can I Remove this tablesspace and other non using Schemas like FLOWS_020100,MDSYS,OUTLN,DIP and TSMSYS etc.What is SYSAUX?
The SYSAUX tablespace provides storage of non-sys-related tables and indexes that traditionally were placed in the SYSTEM tablespace. For example, the tables and indexes that were previously owned by the system user can now be specified for a SYSAUX tablespace. Unfortunately, Oracle still places the SCOTT schema and the other demonstration schemas in the SYSTEM tablespace. Go figure.
The SYSAUX tablespace is specified with the CREATE DATABASE command. This is demonstrated in the example database creation script in Figure 1.1.
CREATE DATABASE test
MAXINSTANCES 1
MAXLOGHISTORY 1
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
DATAFILE '/usr/oracle/OraHome1/oradata/aultdb1/test/system01.dbf' SIZE 300M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/usr/oracle/OraHome1/oradata/aultdb1/test/sysaux01.dbf' SIZE 120M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/usr/oracle/OraHome1/oradata/aultdb1/test/temp01.dbf' SIZE 20M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL
UNDO TABLESPACE "UNDOTBS1" DATAFILE '/usr/oracle/OraHome1/oradata/aultdb1/test/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
CHARACTER SET WE8ISO8859P1
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 ('/usr/oracle/OraHome1/oradata/aultdb1/test/redo01.log') SIZE 10240K,
GROUP 2 ('/usr/oracle/OraHome1/oradata/aultdb1/test/redo02.log') SIZE 10240K,
GROUP 3 ('/usr/oracle/OraHome1/oradata/aultdb1/test/redo03.log') SIZE 10240K
USER SYS IDENTIFIED BY "password" USER SYSTEM IDENTIFIED BY "password";
Oracle10g sysaux
With the new SYSAUX tablespace, Oracle comes closer to providing all the needed tablespaces for a truly OFA-compliant database right out of the box. With just one CREATE DATABASE command we can specify the SYSTEM tablespace, the TEMPORARY tablespace, the AUXSYS tablespace, the default UNDO tablespace, and the redo logs.
Of course, with the Oracle Managed Files option you can create an entire database with a single command, but the database created is not suitable for production use and is not OFA-compliant.
The SYSAUX tablespace is required in all new 10g databases. Only the SYSAUX tablespace datafile location is specified. Oracle specifies the remainder of the tablespace properties including:
online
permanent
read write
extent managment local
segment space management auto
If a datafile is specified for the SYSTEM tablespace, then one must be specified for the SYSAUX tablespace as well. If one is not specified, then the CREATE DATABASE command will fail. The only exception is for an Oracle Managed File system.
During any update of a database to Oracle Database 10g, a SYSAUX tablespace must be created or the upgrade will fail. The SYSAUX tablespace has the same security profile as the SYSTEM tablespace. However, loss of the SYSAUX tablespace will not result in a database crash, only the functional loss of the schemas it contains.
Can I drop SysAux?
DROP DATAFILE
Read this... -
UNDOTBS1 and SYSAUX Tablespace Filename Mismatch in Oracle 11g XE
Hi,
We have installed Oracle 11g XE 32 bit on Windows and found that Tablespace name and filenames are mismatched for UNDOTBS1, SYSAUX.
If you run following query:
SELECT TABLESPACE_NAME, FILE_NAME FROM DBA_DATA_FILES; You will get below output:
TABLESPACE_NAME FILE_NAME
============================================================================
USERS C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\USERS.DBF
UNDOTBS1 C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\SYSAUX.DBF
SYSAUX C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\UNDOTBS1.DBF
SYSTEM C:\ORACLE\ORACLE11GXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBFNotice the difference between UNDOTBS1 and SYSAUX.
UNDOTBS1 tablespace has filename SYSAUX.DBF while
SYSAUX tablespace has filename UNDOTBS1.DBF
Is this a bug or just a wrong name mapping?
Will this affects the internal behavior of tablespace as well for undo tablespace and APEX Installation?
Regards,
Sohil Bhavsar.Error: ORA-03297 ... related to this mismatch of UNDOTBS1 with SYSAUXActually its related to trying to resize a file smaller than the existing extents in use, so yes, restores aren't the only place that could cause confusion from the "incorrect" datafile names.
Fixing it could be done in one pass if you don't mind adjusting filenames so they don't clash, i.e. shut down your database instance and move the files at the OS, startup mount and rename the files in the database.
Don't use the services applet, the instance has to be shutdown with sqlplus, leave the database service running. If you try to open the database with OS files renamed but not corrected in the instance, the database won't open if there are troubles with the undo datafile.
sqlplus /nolog
conn /as sysdba;
... connected ...
col name format a60
col tsname format a10
set lines 120
select t.name tsname, d.name, d.BYTES / 1024 / 1024 mb from v$tablespace t, v$datafile d where t.ts# = d.ts#;
system .../system.dbf <n>
shutdown immediate;
... database closed ...
exit
cd <datafile directory>
move sysaux.dbf undotbs01.dbf
move UNDOTBS1.DBF sysaux.dbf
# or use file explore GUI after shutdown
sqlplus /nolog
conn /as sysdba;
... connected to idle instance ...
startup mount;
... SGA, instance size info ...
alter database rename file 'C:\...<full path>\SYSAUX.DBF' to 'C:\...<full path>\UNDOTBS01.DBF';
alter database rename file 'C:\...<full path>\UNDOTBS1.DBF' to 'C:\...<full path>\SYSAUX.DBF';
select t.name tsname, d.name, d.BYTES / 1024 / 1024 mb from v$tablespace t, v$datafile d where t.ts# = d.ts#;
... make sure you get what was asked for ...
TSNAME NAME MB
SYSTEM C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF 360
SYSAUX C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSAUX.DBF 660
UNDOTBS1 C:\ORACLEXE\APP\ORACLE\ORADATA\XE\UNDOTBS01.DBF 25
USERS C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF 100
alter database open;
... database altered ... -
Block Corruption in the SYSAUX tablespace
Problem Description: Block Corruption in the SYSAUX tablespace :
==================================
We are facing block corruption issue in the SYSAUX tablespace during rman backup..
So currently we are using SET MAXCORRUPT FOR DATAFILE 3 TO 2; parameter to take the backup and it is running fine.. Now we have to fix the issue..
Please let us know the steps to fix the issue..
Please find the details below.
Dbv output:
sesoxpro33.p51x1> dbv file=/oradata/p51x/data/p51x_sysaux_01.dbf blocksize=32768 end=64000
DBVERIFY: Release 10.2.0.3.0 - Production on Fri Aug 26 20:47:29 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /oradata/p51x/data/p51x_sysaux_01.dbf
Page 64 is influx - most likely media corrupt
Corrupt block relative dba: 0x00c00040 (file 3, block 64)
Fractured block found during dbv:
Data in bad block:
type: 0 format: 0 rdba: 0x00000000
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000001
check value in block header: 0x0
block checksum disabled
DBVERIFY - Verification complete
Total Pages Examined : 64000
Total Pages Processed (Data) : 22547
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 23859
Total Pages Failing (Index): 0
Total Pages Processed (Other): 14586
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 3007
Total Pages Marked Corrupt : 1
Total Pages Influx : 1
Highest block SCN : 281617057 (2054.281617057)
SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents
WHERE file_id = 3 and 64 between block_id AND block_id + blocks - 1;
TABLESPACE_NAME SEGMENT_TYPE OWNER
SEGMENT_NAME
SYSAUX SYS_LOB0000000594C00007$$
OS & database Details :
==========
Oracle Solaris on x86-64 (64-bit)
Oracle Server - Enterprise Edition -- 10.2.0.3
If any more informatin is needed, Please let me know..
Thanks & Regards,
Suresh Bommalata.refer:
logical corruption found in the sysaux tablespace
Check the metalink note: Identify the corruption extension using RMAN/DBV/ANALYZE etc - 836658.1
Note 28814.1 - Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g
Note 472231.1 - How to identify all the Corrupted Objects in the Database reported by RMAN
http://download.oracle.com/docs/cd/B12037_01/server.101/b10734/rcmrecov.htm
http://oracleinstance.blogspot.com/2010/05/block-recovery-using-rman-backup.html -
ORA-01578: ORACLE data block corrupted on tables in sysaux tablespace
Dear Experts,
From the alert log file we noticed data block corruptions on one of our datafiles. After further investigation, we realized that the corruptions were on 3 of the AWR related tables in the SYSAUX tablespace:
1. WRH$_LIBRARYCACHE
2. WRH$_TEMPSTATXS
3. WRI$_ALERT_OUTSTANDING
The bad news is that we may not have a valid rman backup to do the recovery due to the retention policy - RECOVERY WINDOW OF 2 DAYS. Since this is a development database with limited monitoring, we did not discover the corruption until 6 days later. The issue happened about 6 days ago (about Christmas time).
So, what are our recovery options? Can someone advice? We are thinking about drop and recreate the 3 affected v$WR* tables, but not quite sure about the impact to the system if we drop and recreate the 3 objects. Did someone experience this type of recovery. If you did, what are your approaches?
We are running oracle 10.2.0.3 version.
I greatly appreciate your input and suggestion. Thanks!!!as long as you have a backup of ur database before christmas, you can use the " MAXDAYS " cmd to get ur backup working so long as you have not used delete obsolote....had a same sistuation....where i had a backup and trying to restore it ...kept saying no valid backup...after going thru some stuff...found the MAXDAYS cmd to use my backup...here is an example ...
$ rman target /
Recovery Manager: Release 10.2.0.2.0 - Production on Sun Apr 6 09:05:44 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> SET DBID=1528894801
executing command: SET DBID
RMAN> startup force nomount;
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/dbs/initsameera.ora'
starting Oracle instance without parameter file for retrival of spfile
Oracle instance started
Total System Global Area 159383552 bytes
Fixed Size 1259672 bytes
Variable Size 58722152 bytes
Database Buffers 92274688 bytes
Redo Buffers 7127040 bytes
RMAN> set controlfile autobackup format for device type disk to '/u99/backup/sameera/control_spfile_%F';
executing command: SET CONTROLFILE AUTOBACKUP FORMAT
using target database control file instead of recovery catalog
RMAN> run
2> {
3> allocate channel p1 type disk;
4> restore spfile to pfile '/u01/app/oracle/product/10.2.0/db_1/dbs/initsameera.ora' from autobackup;
5> shutdown abort;
6> }
allocated channel: p1
channel p1: sid=36 devtype=DISK
Starting restore at 06-APR-08
channel p1: looking for autobackup on day: 20080406
channel p1: looking for autobackup on day: 20080405
channel p1: looking for autobackup on day: 20080404
channel p1: looking for autobackup on day: 20080403
channel p1: looking for autobackup on day: 20080402
channel p1: looking for autobackup on day: 20080401
channel p1: looking for autobackup on day: 20080331
channel p1: no autobackup in 7 days found
released channel: p1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/06/2008 09:09:09
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
Solution:
RMAN> shutdown abort;
RMAN> EXIT;
$ ps -ef |grep pmon
oracle 2891 2856 0 09:05 pts/1 00:00:00 grep pmon
oracle 7448 1 0 Apr05 ? 00:00:00 ora_pmon_primary
$export ORACLE_SID=sameera
$ rman target /
Recovery Manager: Release 10.2.0.2.0 - Production on Sun Apr 6 09:05:44 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> SET DBID=1528894801
executing command: SET DBID
RMAN> startup force nomount;
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/db s/initsameera.ora'
starting Oracle instance without parameter file for retrival of spfile
Oracle instance started
Total System Global Area 159383552 bytes
Fixed Size 1259672 bytes
Variable Size 58722152 bytes
Database Buffers 92274688 bytes
Redo Buffers 7127040 bytes
RMAN> set controlfile autobackup format for device type disk to '/u99/backup/sameera/control_spfile_%F';
executing command: SET CONTROLFILE AUTOBACKUP FORMAT
using target database control file instead of recovery catalog
RMAN> run
2> {
3> allocate channel p1 type disk;
4> restore spfile to pfile '/u01/app/oracle/product/10.2.0/db_1/dbs/initsameera.ora' from autobackup maxdays 15;
5> shutdown abort;
6> }
released channel: ORA_DISK_1
allocated channel: p1
channel p1: sid=36 devtype=DISK
Starting restore at 06-APR-08
channel p1: looking for autobackup on day: 20080406
channel p1: looking for autobackup on day: 20080405
channel p1: looking for autobackup on day: 20080404
channel p1: looking for autobackup on day: 20080403
channel p1: looking for autobackup on day: 20080402
channel p1: looking for autobackup on day: 20080401
channel p1: looking for autobackup on day: 20080331
channel p1: looking for autobackup on day: 20080330
channel p1: looking for autobackup on day: 20080329
channel p1: looking for autobackup on day: 20080328
channel p1: looking for autobackup on day: 20080327
channel p1: looking for autobackup on day: 20080326
channel p1: looking for autobackup on day: 20080325
channel p1: looking for autobackup on day: 20080324
channel p1: looking for autobackup on day: 20080323
channel p1: autobackup found: /u99/backup/sameera/control_spfile_c-1528894801-20080323-00
channel p1: SPFILE restore from autobackup complete
Finished restore at 06-APR-08
Oracle instance shut down
Check to make sure if initsameera.ora exists in $ORACLE_HOME/dbs location.
$ cd $ORACLE_HOME/dbs
$ ls -ltr
total 7052
-rw-r----- 1 oracle oinstall 2560 Apr 5 13:21 spfileprimary.ora
-rw-r----- 1 oracle oinstall 7061504 Apr 5 13:23 snapcf_primary.f
-rw-rw---- 1 oracle oinstall 1544 Apr 5 18:42 hc_sameera.dat
-rw-r--r-- 1 oracle oinstall 1087 Apr 6 09:12 initsameera.ora
$ pwd
/u01/app/oracle/product/10.2.0/db_1/dbs
$ -
SYSAUX tablespace grow too quick????
We have EBS R12.1 on LINUX system. Recently I found our development EBS database SYSAUX tablespace grow very quick. The SYSAUX tablespace has two data files and each data files size is 6GB (total 12 GB). In one month all 12 GB space are gone.
My questions are:
1. what objects or reports or ??? take this much space?
2. how to delete un-need space?
3. what is reasonable SYSAUX size?
Thanks.I double check SYSAUX space usage and found it only use less than 100MB. Why SYSAUX show all 12 Gb space are gone?
SQL> l
1 SELECT occupant_name, schema_name, move_procedure,
2 space_usage_kbytes
3 FROM v$sysaux_occupants
4* ORDER BY 1
SQL> /
OCCUPANT_NAME SCHEMA_NAME MOVE_PROCEDURE SPACE_USAGE_KBYTES
AO SYS DBMS_AW.MOVE_AWMETA 45888
AUTO_TASK SYS 320
EM SYSMAN emd_maintenance.move_em_tblspc 0
EM_MONITORING_USER DBSNMP 0
EXPRESSION_FILTER EXFSYS 0
JOB_SCHEDULER SYS 1152
LOGMNR SYSTEM SYS.DBMS_LOGMNR_D.SET_TABLESPACE 13376
LOGSTDBY SYSTEM SYS.DBMS_LOGSTDBY.SET_TABLESPACE 1600
ORDIM ORDSYS 0
ORDIM/PLUGINS ORDPLUGINS 0
ORDIM/SQLMM SI_INFORMTN_SCHEMA 0
PL/SCOPE SYS 640
SDO MDSYS MDSYS.MOVE_SDO 0
SM/ADVISOR SYS 198528
SM/AWR SYS 1006144
SM/OPTSTAT SYS 10866560
SM/OTHER SYS 8192
SMON_SCN_TIME SYS 3328
SQL_MANAGEMENT_BASE SYS 1728
STATSPACK PERFSTAT 0
STREAMS SYS 1216
TEXT CTXSYS DRI_MOVE_CTXSYS 0
TSM TSMSYS 256
ULTRASEARCH WKSYS MOVE_WK 0
ULTRASEARCH_DEMO_USE WK_TEST MOVE_WK 0
R
WM WMSYS DBMS_WM.move_proc 0
XDB XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE 56192
XSAMD OLAPSYS DBMS_AMD.Move_OLAP_Catalog 0
XSOQHIST SYS DBMS_XSOQ.OlapiMoveProc 45888
29 rows selected. -
SYSAUX tablespace resize/shrink
Hi All,
I'm using 11g SE on Linux, and SYSAUX tablespace has grown too large (32Gb). I've reclaimed a space and the question is Is there any chance to resize this tablespace back to small size (let's say to 5Gb)?
I'll appreciate any help.
Thank you.Hi,
Here it is an output. I've removed some stuff to fit the message limit.
~~~~~~~~~~~~~~~
AWR INFO Report
~~~~~~~~~~~~~~~
Report generated at 10:36:09 on May 29, 2013 ( Wednesday ) in Timezone +01:00
Warning: Non Default AWR Setting!
Snapshot interval is 60 minutes and Retention is 8 days
DB_ID DB_NAME HOST_PLATFORM INST STARTUP_TIME LAST_ASH_SID PAR
* 182010396 PROD db01p2.db.mydomain.com - Linux x86 6 2 14:54:16 (03/26) 0 YES
4-bit
(I) AWR Snapshots Information
(1a) SYSAUX usage - Schema breakdown (dba_segments)
|
| Total SYSAUX size 1,790.6 MB ( 5% of 32,768.0 MB MAX with AUTOEXTEND ON )
|
| Schema SYS occupies 1,245.0 MB ( 69.5% )
| Schema XDB occupies 157.6 MB ( 8.8% )
| Schema PERFSTAT occupies 151.8 MB ( 8.5% )
| Schema APEX_030200 occupies 77.4 MB ( 4.3% )
| Schema MDSYS occupies 65.8 MB ( 3.7% )
| Schema SYSMAN occupies 45.3 MB ( 2.5% )
| Schema SYSTEM occupies 13.7 MB ( 0.8% )
| Schema ORDDATA occupies 13.6 MB ( 0.8% )
| Schema OLAPSYS occupies 5.1 MB ( 0.3% )
| Schema DBSNMP occupies 4.1 MB ( 0.2% )
| Schema EXFSYS occupies 3.6 MB ( 0.2% )
| Schema CTXSYS occupies 3.6 MB ( 0.2% )
| Schema WMSYS occupies 3.5 MB ( 0.2% )
| Schema ORDSYS occupies 0.4 MB ( 0.0% )
|
(1b) SYSAUX occupants space usage (v$sysaux_occupants)
|
| Occupant Name Schema Name Space Usage
| -------------------- -------------------- ----------------
| SM/AWR SYS 888.0 MB
| SM/OPTSTAT SYS 266.6 MB
| XDB XDB 157.6 MB
| STATSPACK PERFSTAT 151.8 MB
| SDO MDSYS 65.8 MB
| EM SYSMAN 45.3 MB
| AO SYS 36.3 MB
| XSOQHIST SYS 36.3 MB
| ORDIM/ORDDATA ORDDATA 13.6 MB
| LOGMNR SYSTEM 12.3 MB
| SM/ADVISOR SYS 11.3 MB
| JOB_SCHEDULER SYS 9.9 MB
| SM/OTHER SYS 7.1 MB
| XSAMD OLAPSYS 5.1 MB
| EM_MONITORING_USER DBSNMP 4.1 MB
| EXPRESSION_FILTER EXFSYS 3.6 MB
| TEXT CTXSYS 3.6 MB
| WM WMSYS 3.5 MB
| SMON_SCN_TIME SYS 3.3 MB
| SQL_MANAGEMENT_BASE SYS 1.7 MB
| PL/SCOPE SYS 1.6 MB
| LOGSTDBY SYSTEM 1.4 MB
| STREAMS SYS 1.0 MB
| ORDIM ORDSYS 0.4 MB
| AUTO_TASK SYS 0.3 MB
| AUDIT_TABLES SYS 0.0 MB
| ORDIM/ORDPLUGINS ORDPLUGINS 0.0 MB
| ORDIM/SI_INFORMTN_SC SI_INFORMTN_SCHEMA 0.0 MB
| TSM TSMSYS 0.0 MB
| ULTRASEARCH WKSYS 0.0 MB
| ULTRASEARCH_DEMO_USE WK_TEST 0.0 MB
|
| Others (Unaccounted space) 59.4 MB
|
(1c) SYSAUX usage - Unregistered Schemas
| This section displays schemas that are not registered
| in V$SYSAUX_OCCUPANTS
|
| Schema APEX_030200 occupies 77.4 MB
|
| Total space 77.4 MB
|
(1d) SYSAUX usage - Unaccounted space in registered schemas
|
| This section displays unaccounted space in the registered
| schemas of V$SYSAUX_OCCUPANTS.
|
| Unaccounted space in SYS/SYSTEM -18.1 MB
|
| Total space -18.1 MB
|
(2) Size estimates for AWR snapshots
|
| Estimates based on 60 mins snapshot INTERVAL:
| AWR size/day 53.0 MB (2,262 K/snap * 24 snaps/day)
| AWR size/wk 371.1 MB (size_per_day * 7) per instance
| AWR size/wk 1,484.4 MB (size_per_day * 7) per database
|
| Estimates based on 12 snaps in past 24 hours:
| AWR size/day 26.5 MB (2,262 K/snap and 12 snaps in past 24 hours)
| AWR size/wk 185.6 MB (size_per_day * 7) per instance
| AWR size/wk 742.2 MB (size_per_day * 7) per database
|
(3a) Space usage by AWR components (per database)
COMPONENT MB % AWR KB_PER_SNAP MB_PER_DAY MB_PER_WEEK TABLE% : INDEX%
FIXED 860.8 96.9 2,193 25.7 179.9 55% : 45%
SPACE 18.1 2.0 46 0.5 3.8 59% : 41%
EVENTS 3.5 0.4 9 0.1 0.7 50% : 50%
SQL 2.9 0.3 7 0.1 0.6 37% : 63%
ASH 1.5 0.2 4 0.0 0.3 50% : 50%
RAC 0.6 0.1 2 0.0 0.1 50% : 50%
SQLTEXT 0.1 0.0 0 0.0 0.0 50% : 50%
SQLPLAN 0.1 0.0 0 0.0 0.0 50% : 50%
SQLBIND 0.1 0.0 0 0.0 0.0 50% : 50%
(3b) Space usage within AWR Components (> 500K)
COMPONENT MB SEGMENT_NAME - % SPACE_USED SEGMENT_TYPE
FIXED 336.0 WRH$_SYSMETRIC_HISTORY - 12% TABLE
FIXED 296.0 WRH$_SYSMETRIC_HISTORY_INDEX - 18% INDEX
FIXED 88.0 WRH$_SYSMETRIC_SUMMARY - 10% TABLE
FIXED 42.0 WRH$_SYSMETRIC_SUMMARY_INDEX - 18% INDEX
FIXED 24.0 WRH$_WAITCLASSMETRIC_HISTORY - 21% TABLE
FIXED 21.0 WRH$_WAITCLASSMETRIC_HIST_IND - 17% INDEX
FIXED 16.0 WRM$_SNAPSHOT_DETAILS_INDEX - 80% INDEX
FIXED 10.0 WRM$_SNAPSHOT_DETAILS - 92% TABLE
SPACE 0.9 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12506 - 82% TABLE PARTITION
SPACE 0.9 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12530 - 84% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12458 - 89% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12650 - 88% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12626 - 87% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12602 - 86% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12578 - 87% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12482 - 89% TABLE PARTITION
SPACE 0.8 WRH$_SEG_STAT.WRH$_SEG_ST_182010396_12554 - 89% TABLE PARTITION
SPACE 0.7 WRH$_SEG_STAT_OBJ - 46% TABLE
SPACE 0.6 WRH$_SEG_STAT_OBJ_INDEX - 22% INDEX
SPACE 0.6 WRH$_SEG_STAT_OBJ_PK - 26% INDEX
SPACE 0.5 WRH$_SEG_STAT_PK.WRH$_SEG_ST_182010396_12554 - 63% INDEX PARTITION
SPACE 0.5 WRH$_SEG_STAT_PK.WRH$_SEG_ST_182010396_12626 - 51% INDEX PARTITION
(4) Space usage by non-AWR components (> 500K)
COMPONENT MB SEGMENT_NAME SEGMENT_TYPE
NON_AWR 104.0 SYS.I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST INDEX
NON_AWR 80.0 SYS.WRI$_OPTSTAT_HISTGRM_HISTORY TABLE
NON_AWR 53.2 XDB.SYS_LOB0000057465C00025$$ LOBSEGMENT
NON_AWR 50.0 SYS.I_WRI$_OPTSTAT_H_ST INDEX
NON_AWR 18.0 MDSYS.SYS_LOB0000064008C00006$$ LOBSEGMENT
NON_AWR 16.1 SYS.SYS_LOB0000065858C00004$$ LOBSEGMENT
NON_AWR 13.0 SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY TABLE
NON_AWR 9.0 SYS.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST INDEX
NON_AWR 8.0 XDB.XDB$RESOURCE TABLE
NON_AWR 7.2 SYS.SYS_LOB0000065843C00004$$ LOBSEGMENT
NON_AWR 7.0 MDSYS.SDO_CS_SRS TABLE
NON_AWR 5.0 SYS.SCHEDULER$_EVENT_LOG TABLE
NON_AWR 5.0 APEX_030200.WWV_FLOW_DICTIONARY$CAPED INDEX
NON_AWR 5.0 PERFSTAT.STATS$SQL_PLAN TABLE
NON_AWR 5.0 PERFSTAT.STATS$SQL_PLAN_USAGE TABLE
NON_AWR 5.0 PERFSTAT.STATS$SQLTEXT TABLE
NON_AWR 5.0 APEX_030200.WWV_FLOW_PAGE_PLUGS TABLE
NON_AWR 5.0 APEX_030200.WWV_FLOW_STEP_ITEMS TABLE
NON_AWR 4.2 SYS.SYS_LOB0000065848C00004$$ LOBSEGMENT
NON_AWR 4.0 APEX_030200.WWV_FLOW_DICTIONARY$ TABLE
NON_AWR 4.0 SYSTEM.SYS_LOB0000001147C00009$$ LOBSEGMENT
NON_AWR 4.0 SYS.SCHEDULER$_INSTANCE_PK INDEX
NON_AWR 4.0 SYS.I_WRI$_OPTSTAT_HH_ST INDEX
NON_AWR 3.2 SYS.SYS_LOB0000065838C00004$$ LOBSEGMENT
NON_AWR 3.0 XDB.XDB$H_INDEX TABLE
(5a) AWR snapshots - last 50
Total snapshots in DB 182010396 Instance 3 = 201
Total snapshots in DB 182010396 Instance 2 = 201
DBID SNAP_ID INST FLUSH_ELAPSED ENDTM STARTUP_TIME STATUS ERRCNT
182010396 12678 2 +00000 00:00:00.1 08:00:41 (05/29) 14:54:16 (03/26) 0 0
182010396 12678 3 +00000 00:00:00.5 08:00:41 (05/29) 14:56:33 (03/26) 0 0
182010396 12679 2 +00000 00:00:00.1 09:00:59 (05/29) 14:54:16 (03/26) 0 0
182010396 12679 3 +00000 00:00:00.1 09:00:59 (05/29) 14:56:33 (03/26) 0 0
182010396 12680 2 +00000 00:00:00.9 10:00:10 (05/29) 14:54:16 (03/26) 0 0
182010396 12680 3 +00000 00:00:00.1 10:00:10 (05/29) 14:56:33 (03/26) 0 0
(5b) AWR snapshots with errors or invalid
no rows selected
(5c) AWR snapshots -- OLDEST Non-Baselined snapshots
DBID INST SNAP_ID ENDTM STATUS ERROR_COUNT
182010396 2 12480 02:00:25 (05/21) 0 0
(6) AWR Control Settings - interval, retention
DBID LSNAPID LSPLITID LSNAPTIME LPURGETIME FLAG INTERVAL RETENTION VRSN
182010396 12680 12671 05/29 10:00:11 05/29 01:13:59 2 +00000 01:00:00.0 +00008 00:00:00.0 5
(7a) AWR Contents - row counts for each snapshots
SNAP_ID INST ASH SQL SQBND FILES SEGST SYSEVT
12656 2 0 0 0 0 104 0
12679 2 0 0 0 0 107 0
SNAP_ID INST ASH SQL SQBND FILES SEGST SYSEVT
12679 3 0 0 0 0 113 0
12680 2 0 0 0 0 110 0
12680 3 0 0 0 0 109 0
(7b) AWR Contents - average row counts per snapshot
SNAP_COUNT INST ASH SQLSTAT SQLBIND FILES SEGSTAT SYSEVENT
201 3 0 0 0 0 108.27 0
201 2 0 0 0 0 109.23 0
(7c) AWR total item counts - names, text, plans
SQLTEXT SQLPLAN SQLBMETA SEGOBJ DATAFILE TEMPFILE
0 0 0 2784 0 0
(II) Advisor Framework Info
(1) Advisor Tasks - Last 50
OWNER/ADVISOR TASK_ID/NAME CREATED EXE_DURATN EXE_CREATN HOW_C STATUS
SYS/SQL Tuning 1/SYS_AUTO_SQL_TUNING_TASK 09:52:13 (09/17) AUTO INITIAL
SYS/Segment Ad 10161/SYS_AUTO_SPCADV_5215001005 00:15:52 (05/10) 2,925 2,925 CMD COMPLETED
2013
SYS/Segment Ad 10162/SYS_AUTO_SPCADV_3804011005 01:04:38 (05/10) 50 50 CMD COMPLETED
(2) Advisor Task - Oldest 5
OWNER/ADVISOR TASK_ID/NAME CREATED EXE_DURATN EXE_CREATN HOW_C STATUS
SYS/Segment Ad 9980/SYS_AUTO_SPCADV_04002329042 23:00:04 (04/29) 426 427 CMD COMPLETED
013
SYS/Segment Ad 9990/SYS_AUTO_SPCADV_16002330042 23:00:16 (04/30) 5,519 5,519 CMD COMPLETED
013
SYS/Segment Ad 9991/SYS_AUTO_SPCADV_16320001052 00:32:17 (05/01) 2,831 2,831 CMD COMPLETED
013
SYS/Segment Ad 9992/SYS_AUTO_SPCADV_29190101052 01:19:29 (05/01) 80 80 CMD COMPLETED
013
SYS/Segment Ad 10000/SYS_AUTO_SPCADV_1300230105 23:00:13 (05/01) 445 445 CMD COMPLETED
2013
(3) Advisor Tasks With Errors - Last 50
OWNER/ADVISOR TASK_ID/NAME CREATED EXE_DURATN EXE_CREATN HOW_C STATUS
TASK_DESC
ERROR_MSG
SYS/SQL Tuning 1/SYS_AUTO_SQL_TUNING_TASK 09:52:13 (09/17) AUTO INITIAL
Description: Automatic SQL Tuning Task
Error Msg :
(III) ASH Usage Info
(1a) ASH histogram (past 3 days)
(1b) ASH histogram (past 1 day)
(2a) ASH details (past 3 days)
(2b) ASH details (past 1 day)
(2c) ASH sessions (Fg Vs Bg) (past 1 day across all instances in RAC)
Foreground %
Background %
MMNL %
End of Report -
Sysaux tablespace reached to 90%
Hi
I am getting alert message that sysaux tablespace reached to 90% I checked and found that total allocated space to sysaux is 500M.
1. Can I add datafile to increase size for sysaux tablespace?
2. What could be the reason for growth? Is there any way to free the space from sysaux table space?
Platform Solaris Database 10.2.0.4
Thank you in advanceSDD wrote:
Hi
I am getting alert message that sysaux tablespace reached to 90% I checked and found that total allocated space to sysaux is 500M.
1. Can I add datafile to increase size for sysaux tablespace?
2. What could be the reason for growth? Is there any way to free the space from sysaux table space?
Platform Solaris Database 10.2.0.4
Thank you in advanceselect occupant_name, space_usage_kbytes from v$sysaux_occupants;
use segment advisor to analyze the space occupied in sysaux tablesapace.
One thing you could do is to set AUTOEXTEND OFF in datafile(s) of SYSAUX tablespace, so you'll get an error, but you can understand where is the problem. Identify datafile(s) :
SQL> select file_name from dba_data_files
2 where tablespace_name = 'SYSAUX';
then for each file_name
SQL> alter database datafile
2 '<file_name>' autoextend off;
The sysaux tablespace is used to hold AWR data among other uses. Reduce the retention and interval setting for the AWR snapshots to reduce the space necessary to hold the data. See dbms_workload_repository package procedure modify_snapshot_settings.
Your statistics collection level will also feed into the above.
Take a look at other features/products you have assigned to sysaux if any and examine the data collection and retention rules you have specified for them.
Another major occupant of the SYSAUX tablespace is the embedded Enterprise Manager (EM) repository. This repository is used by Oracle Enterprise Manager Database Control to store its metadata. The size of this repository depends on database activity and on configuration-related information stored in the repository.
Other database components in the SYSAUX tablespace will grow in size only if their associated features (for example, Oracle UltraSearch, Oracle Text, Oracle Streams) are in use. If the features are not used, then these components do not have any significant effect on the size of the SYSAUX tablespace.
hope, this will helps you.
Edited by: rajeysh on Jun 17, 2010 4:20 PM -
SYSAUX tablespace increasing in size
Hi,
I have noticed that SYSAUX tablespace increasing in size. This tablespace is being used by the below components. However, none of those components are used by my applications. They are installed by default with Oracle 10g Realese1. what makes this tablespace increase?? and what should be done to stop increasing in this tablespace?
Oracle Ultra Search 10.1.0.3.0 VALID WKSYS
Oracle Enterprise Manager 10.1.0.3.0 VALID SYSMAN
Oracle XML Database 10.1.0.3.0 VALID XDB
OLAP Catalog 10.1.0.3.0 VALID OLAPSYS
Oracle Text 10.1.0.3.0 VALID CTXSYS
Spatial 10.1.0.3.0 VALID MDSYS
Oracle interMedia 10.1.0.3.0 VALID ORDSYS
Oracle Expression Filter 10.1.0.3.0 VALID EXFSYS
Oracle Workspace Manager 10.1.0.2.0 VALID WMSYS
Oracle Data Mining 10.1.0.3.0 VALID DMSYSThe following is from a metalink post of mine on the same subject>>
The sysaux tablespace is used to hold AWR data among other uses. Reduce the retention and interval setting for the AWR snapshots to reduce the space necessary to hold the data. See dbms_workload_repository package procedure modify_snapshot_settings.
Your statistics collection level will also feed into the above.
Take a look at other features/products you have assigned to sysaux if any and examine the data collection and retention rules you have specified for them.
<<
HTH -- Mark D Powell -- -
Sysaux Tablespace full 95 Percentage...
Hi,
I Have a tablespace call sysaux around 2GB.
The total tablespace is used around 1.9 GB and only 100 MB is free.
The 77 % of 1.9 GB is used to store AWR reports.
There are aound 4000 Awr report store in this table space...
I deleted around 3500 awr reports using drop_sanpshot.range option..
After droping this snapshot, still the status for Sysaux tablespaces used is around 1.9 GB.
system is not re-claiming the free disk space ...
What i can do to free up used sapce since, I have very less disk space on the disk itself ...
SSM>>
system is not re-claiming the free disk space ...
Fortunately, Oracle won't reduce the filesize, even if you drop objects inside tablespace.
If you want reclaim space, you need to find your own solution. In your case, exp, recreate database, and import is a way.
Nicolas.
Maybe you are looking for
-
Post Author: i3Mike CA Forum: Deployment Summary: I have a small web application that uses Visual Studio 2005 to render a few Crytsal Reports in the browser as PDFs. The report renders fine on my development machine (Windows XP Pro) but have issues
-
Help improving cd ripping i/o
I've completed a set of Java wrappers for AKRip32 on Windows, and integrated with the tritonus/cdparanoia CDDA classes, and I have CDDA working on Windows and Linux. The problem - on Windows the I/O performance of my code is a joke (10+ minutes to ri
-
Faulty DVD Drive/Burning Software?
Hi, I have a macbook pro and for some strange reason, the DVD drive or the software won't burn any DVD's I try to make. In iDVD, during the burning stages it get to the very near last stages of burning and then it ejects it before it has actually com
-
Is there a way to save individual slides created in Keynote as .jpg files? I'd like to use slides I've created as pictures in other projects. Thanks
-
I just got an ipad from a pawnshop. How do I change the user
I just got an ipad from a pawnshop. How do I change the user sign in ... to my email and not the previous owners