The simple version of this question is: Is it possible to export all the data from an Oracle 10g XE database that has reached it's 4GB maximum size limit?
Now, here's the background:
My (Windows) Oracle 10g XE database has reached its maximum allowed database size of 4GB. The solution I intended to implement to this problem was to upgrade to Oracle 11g XE which has a larger maximum size limit, and better reflects our production environment anyway. Of course, in typical Oracle fashion, they do not have an upgrade-in-place option (at least not that I could find for XE). So I decided to follow the instructions in the "Importing and Exporting Data between 10.2 XE and 11.2 XE" section of the Oracle 11g XE Installation Guide. After fighting with SQLPlus for a while, I eventually reached step 3d of the instructions which instructs the user to enter the following (it doesn't specify the command-line rather than SQLPlus, but it means the command-line):
expdp system/system_password full=Y EXCLUDE=SCHEMA:\"LIKE \'APEX_%\'\",SCHEMA:\"LIKE \'FLOWS_%\'\" directory=DUMP_DIR dumpfile=DB10G.dmp logfile=expdpDB10G.log
That command results in the following output:
Export: Release 10.2.0.1.0 - Production on Thursday, 29 September, 2011 10:19:11
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
ORA-31626: job does not exist
ORA-31633: unable to create master table "SYSTEM.SYS_EXPORT_FULL_06"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 863
ORA-12952: The request exceeds the maximum allowed database size of 4 GB
I have deleted quite a bit of data from the USERS tablespace, but am unable to resize it because of the physical locations of the data. And no matter what I do, I always get that same output. I have tried running "Compact Storage" from the admin web application with no effect.
So my question is, am I missing something? Or is Oracle really so incompetent as to leave people completely out of luck if their XE databases fill up?
You can get to the point you need to export data, sounds like you just need some help coalescing the data so you can reduce the USERS tablespace size and increase the SYSTEM tablespace size to get past your issue.
You mentioned that you removed data from the USERS tablespace but can't resize. Since you can't reduce the tablespace size smaller than the highest block, reorganiza your table data by executing the following command for each table:
ALTER TABLE <table_name> MOVE <tablespace_name>;
The tablespace name can be the same tablespace that the table currently lives in, it will still reorganize the data and coalesce the data.
This statement will give you the text for this command for all the tables that live in USERS tablespace:
select 'ALTER TABLE '||OWNER||'.'||TABLE_NAME||' MOVE '||TABLESPACE_NAME||';' From dba_tables where tablespace_name='USERS';
Indexes will also have to be rebuilt (ALTER INDEX REBUILD;) as the MOVE command invalidates them because it changes physical organization of the table data (blocks) instead of relocating row by row.
After the data is coalesced you can resize the USERS tablespace to reflect the data size.
Is it a pain? Yes. Is Oracle user friendly? They would love you to think so but its really not, especially when you hit some weird corner case that keeps you from doing the types of things you want to do.
As you can see, you need some free space in the SYSTEM tablespace in order to export, and Oracle XE refuses to allocate it because the sum of SYSTEM+USERS has reached 4 Gb.
I would try to install an Oracle 10gR2 Standard Edition instance on a similar architecture, then shutdown Oracle XE and make a copy your existing USERS data file. Using "ALTER TABLESPACE" commands on the standard edition, you should be able to link the USERS tablespace to your existing data file, then export the data.
Related
I want to move tables from my sybase database to my oracle database. However, some tables in my sybase database have long identifiers or table names (above 30chars) so the "copy to oracle" function on Oracle SQL Developer keeps failing.
How can I migrate TABLE DATA only to my oracle schema?
Also note, I tired doing the data migration flow but when i get to the step to move data, it doesn't let me move table data. It just isn't visible. It'll only let me move procedures and such.
Do i have something disabled?
You need to enable long identifiers in your 12cR2 (12.2.x.y) or newer version of Oracle Database.
As soon as you set COMPATIBLE to “12.2.0” or higher for your Database, you can use the Long identifiers for every object in Oracle with the following exceptions:
Database name ≤ 8 byte
Disk groups ≤ 30 byte
PDB names ≤ 30 byte
Rollback segments ≤ 30 byte
Tablespace names ≤ 30 byte
Tablespace sets ≤ 30 byte
So let's do a table then...I'm running 12.2 in this scenario, but it would be find in 18c or 19c as well.
Click OK and I get - Success!
Copied Objects:
Sybase.copy_to_oracle.dbo.TABLE.this_is_a_table_to_hold_employees_please_dont_put_customers_in_it
Drop Target: HR
Copy DDL: Yes
Do Not Replace Existing Objects
Copy Data: Yes
Append Existing Objects
Task Succeeded.
1 table(s) copied.
Created table this_is_a_table_to_hold_employees_please_dont_put_customers_in_it and inserted 0 row(s)
I'm experiencing rapid growth in my SYSAUX scheme. I have found that the majority of the space (27Gb) is being consumed by a LOBSEGMENT object in the AUDSYS schema. The research I did, suggested that the Unified Audit Log needed to be purged and I went ahead and cleaned it up as it was really massive, however, space has not been released from the LOBSEGEMENT and I'm wondering if there is a way to do this?
DB Version: Oracle Database 12c Release 12.1.0.1.0 - 64bit Production
I used the below to identify large objects in the system
select s.owner, s.segment_name, s.segment_type, s.tablespace_name, sum(s.BYTES) /1024/1024/1024 SIZE_GB
from DBA_SEGMENTS s
group by s.owner, s.segment_name, s.segment_type, s.tablespace_name;
From there I identified the table name associated with the largest segment with the below:
select * from dba_lobs where SEGMENT_NAME='SYS_LOB0000019764C00014$$';
The LOG_PIECE column of the AUDSYS.CLI_SWP$ea27aff$1$1 table was identified, but I cannot query the table directly. even connected with sysdba, when I try and query the table to find out what is in it, I get "ORA-00942: table or view does not exist". I also cannot find any reference to the table or column in any other views, procedures, synonyms, etc in the DB. So I have no idea how to view the contents of the table in order to figure out what it is.
When I look at the Unified Audit Trail, I can't find anything that would link to this column either.
After purging I did another backup of the system in the hopes that it might release unused space, space is still being used and the purge did not clean it up.
Any ideas on 1. How to figure out what is in the table/column and 2. how to clean it up would really be appreciated as I'm at a bit of a loss here.
I am using Oracle XE 10.2. I am trying to copy 2,653,347 rows from a remote database with the statement
INSERT INTO AUTOSCOPIA
(field1,field2...field47)
SELECT * FROM AUTOS#REMOTE;
I am trying to copy all 47 columns for all 2 million rows locally. After running for a few minutes, however, I get the error:
ORA- 12952 : The request exceeds the maximum allowed database size of 4 GB data.
How can I avoid this error?
Details: i have 3 indexes in my local table (where i want to insert the remote information).
You're using the express edition of Oracle 10.2 which includes a number of limitations. The one that you're running into is that you are limited to 4 GB of space for your tables and your indexes.
How big is the table in GB? If the table has 2.6 million rows, if each row is more than ~1575 bytes, then what you want to do isn't possible. You'd have to either limit the amount of data you're copying over (not getting every row, not getting every column, or not getting all the data in some columns would be options) or you would need to install a version and edition that allows you to store that much data. The express edition of 11.2 allows you to store 11 GB of data and is free just like the express edition of 10.2 so that would be the easiest option. You can see how much space the table consumes in the remote database by querying the all_segments column in the remote database-- that should approximate the amount of space you'd need in your database
Note that this ignores the space used by out-of-line LOB segments as well as indexes
SELECT sum(bytes)/1024/1024/1024 size_in_gb
FROM all_segments#remote
WHERE owner = <<owner of table in remote database>>
AND segment_name = 'AUTOS'
If the table is less than 4 GB but the size of the table + indexes is greater than 4 GB, then you could copy the data locally but you would need to drop one or more of the indexes you've created on the local table before copying the data over. That, of course, may lead to performance issues but you would at least be able to get the data into your local system.
If you (or anyone else) has created any tables in this database, those tables count against your 4 GB database limit as well. Dropping them would free up some space that you could use for this table.
Assuming that you will not be modifying the data in this table once you copy it locally, you may want to use a PCTFREE of 0 when defining the table. That will minimize the amount of space reserved in each block for subsequent updates.
I want to drop a partition that is empty but I am aware about oracle setting all indexes to unusable whenever you perform a partition DDL statement like DROP, therefore, I should add UPDATE GLOBAL INDEXES to the statement though it looks unnecessary.
Then I came up with this post where it says that it wont mark it as unusable so I decided to test it. The thing is that I tested it in two oracle versions and it worked different!
Having two instances:
DBa(Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production)
DBb(Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production)
In DBa it marked them as invalid and in DBb which contained the same data than the other db (cloned with exp/imp) it succeed to drop without marking them unusable.
Is it possible to explicitly tell Oracle that you want to keep the indexes usable because there is no data in the partition (without rebuilding the indexes) ?
So far I am not able to find out why it was marked as invalid in a placed but not in the other one but there is something to say in case someone have the same problem.
Run it always with UPDATE GLOBAL INDEXES since if the partition is empty it will take no time to perform the drop and it ensures that the indexes will not be marked as invalid. Therefore, there is no reason to hope that oracle won't mark them
May be you can try below, this maintains index validity during the drop.
ALTER TABLE t1 DROP PARTITION p5 UPDATE GLOBAL INDEXES;
yes .. use LOCAL indexes while creating indexes over partitioned table
In oracle what's the differences between a database and a table space?
A little terminology:
Oracle defines a database as the set of files that you find on your Oracle system. This means all data in your Oracle system is in these database files, commonly known as "data files". There are other files in the database such as parameter files and redo logs.
On the other hand, an instance consists of the processes and memory areas that Oracle database uses. Together, a database and an instance make up a database system. (For more information, see the Oracle Concept guide)
Logically, you will want to define different spaces within that database. This is done via tablespaces (see Oracle Concept guide). A tablespace usually consists of one or more data files. When you define a table with CREATE TABLE, you can specify in which tablespace the table should be created. This allows you to seperate different applications on the same database system, for example.
The Oracle Concepts guide is an excellent source of information for questions like these. See this picture on how data files and tablespaces are composed.
Let's consider an example of an Ocean consist of lots of water. Now you want that water. For this what you do is collect water in barrel for better usage and better storage purpose. Same here Ocean is database having lots of Data files here data file means water and for better usage and handling you put that into barrel you can relate barrel as Tablespace
An Oracle database consists of one or more logical storage units
called tablespaces, which collectively store all of the database's
data.
Databases, tablespaces, and datafiles are closely related, but they have important differences:
Each tablespace in an Oracle database consists of one or more files
called datafiles, which are physical structures that conform to the
operating system in which Oracle is running.
A database's data is collectively stored in the datafiles that
constitute each tablespace of the database. For example, the simplest
Oracle database would have one tablespace and one datafile. Another
database can have three tablespaces, each consisting of two datafiles
(for a total of six datafiles).
reference link
DATABASES's data are stored in logical storage units called TABLESPACES. A database may contain "one or more" tablespaces. A tablespace may contain one or more datafiles.
A database's data is collectively stored in the datafiles that constitute each tablespace of the database.
Example: the simplest database may have one tablespace and one datafile. On the other hande another database can have 5 tablespaces which may contain two datafiles each (On a total of 10 files)
This question is quite dated. IBM Db2 also has Table spaces. I think there is some commonality between Db2 table spaces and Oracle database table spaces. In that respect this link offers more insight into why table spaces, as storage structures, are needed and how are they distinct from databases. Two benefits are easy recoverability of the database and better storage management.