Tag Info

This part is unusual: ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe/ This needs to be char-by-char identical every time. I see it ends with a slash here, which is non-standard, and I suspect that you've added it by mistake. Adding a slash will result in "ORACLE not available" in so-called bequeath sqlplus, I've just experimented on my system. Try again ...

At a guess I'd say Marian is right and this is caused by a unique index and constraint having the same name, eg: create table t( k1 integer, k2 integer, constraint u1 unique(k1,k2) using index(create unique index u1 on t(k1,k2)), constraint u2 unique(k2,k1) using index u1); select count(*) from user_indexes where ...

Seems very strange. You can run: SELECT * FROM user_objects WHERE object_name = 'A_DUP_CALLE_UK1' to check if what kind of object that is Oracle complains about. Then you can run the approriate DROP statement for that. The only other thing I can think of is to drop the table entirely using DROP TABLE A_DUP_CALLE CASCADE CONSTRAINTS to get rid of ...

You have a few options, some of which will make your database unsupportable by Oracle (if you care!) as you need to fiddle with SYS owned objects. The first option is to revoke select privs from everyone: revoke select on all_users from public; Then grant it back to certain users, plus all other internal Oracle users. The 2nd option is to look at the ...

Sounds like you just want a basic AFTER INSERT trigger. Then you can access the inserted data via :new. Something like: CREATE OR REPLACE TRIGGER insert_data AFTER INSERT ON OWNER.TABLE FOR EACH ROW BEGIN INSERT INTO OWNER.OTHER_TABLE (COL1, COL2, COL3) VALUES (:NEW.COL1, :NEW,COL2, :NEW,COL3) END;

The export utility will use the NLS_LANG environment variable specified for the client session. If all your data can be represented in the Windows-1252 character set, that shouldn't be an issue. If you want to do the export using the AL32UTF8 character set, you'd need to set the NLS_LANG. In Windows, that would be something like c:\> set nls_lang = ...

This is very simple and there are many tutorials out there. Here is a sample trigger to demonstrate. create table aaaa ( a number ); create table bbbb ( b number ); create trigger aaaa_aitrig after insert on aaaa for each row begin insert into bbbb values ( :new.a ); end; / In case you were wondering, ":new" is a reference to the newly inserted ...

You need to take a dump of the source database using DataPump export. Then on the target PC install Oracle XE, and use DataPump import to import the dump taken from your source PC. For details on the DataPump utility, please see the manual: http://docs.oracle.com/cd/E11882_01/server.112/e22490/part_dp.htm There are also various tutorials for this utility ...

I haven't tried this but in theory you should be able to: Install the exact same version of the software on the other PC using the same installation options (same directory structure, etc). Shutdown the instance on the original PC. Copy all the files from the original PC to the same location on the other PC. Start the instance on the other PC. This ...

NLS_LANG can't be changed from inside a session, however other settings can. You can't change the character set once a database connection has been established (ie: the 2nd part of NLS_LANG), but you can change the language with: alter session set NLS_LANGUAGE=SPANISH ... and the territory with: alter session set NLS_TERRITORY=SPAIN

I'll answer this at a high level for you. The two backup methods work at different levels. An RMAN backup is a physical backup and a Data Pump backup is a logical backup. A database dump using expdp is a 1-time export of one or more database schemas. It backs up DDL (table structures, views, synonyms, stored procedures, packages, etc), plus data. An RMAN ...

Currently Oracle does not support MacOSX. They did for Tiger but dropped support plans for Apple when they bought SUN Microsystems. If you are willing to install an older version of MacOSX you can install Oracle 10.1.0.5 (fully featured) or 10.2.0.4 (incomplete). For now: forget it. What you can do is run 11g on vmware. I have it running on macs using ...

You are encountering these problems because you are running a 32-bit version of Oracle XE on 64-bit Windows. This is not a supported configuration, and is known to have many documented problems. Due to there not being a 64-bit version of XE, you can instead install the Standard Edition (free for development) from here. If you're also using APEX, you can get ...

Don't think MCE are certified to run Oracle 11g XE. Try This thread mentions deleting install paths found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders key from the registry. You can try that. As always, ensure you have a working backup before you fiddle with the registry. Reinstalling SP3

The included backup.bat (windows) or backup.sh (all other platforms) script found under $ORACLE_HOME/config/scripts will do the following: Check that the user running the script is in the DBA or DBOPER system groups Check that the database is in archivelog mode and have the FAST_RECOVERY_AREA parameter configured. Back up the database to the fast recovery ...

You should be able to solve this with a full export and import of the database. Run a full export of the database on the linux VM Copy the dump file to your Windows machine Do a full import to the database on the Windows machine. I believe Oracle reccomends the use of Oracle Data Pump: expdp and impdp on Oracle 11g and up, rather than the traditional ...

There are two tables you can get this info from. APEX_WORKSPACES and APEX_APPLICATIONS. The schema that these tables reside in depends on the APEX version. By way of example, my vanilla Oracle 11.2 install has them in the APEX_030200 schema. To list: select USERNAME from DBA_USERS where USERNAME like 'APEX%'.

I've had the same problem just a few minutes ago... And I've found an explanation. By creating a Primary Key, Oracle creates two objects : A constraint, and an index, that controls the "UNIQUE" part. By dropping the constraint, the index remains there, using the same name of the index, so if you execute just alter table t drop constraint u1; You'll be ...