my-vault/01_Projects/Work/Government-Projects/Zengcheng-District/Zengcheng-IT-Project-Mgmt/oracle.md at df3e3eb3abf60bc6e53ea35b88f032ca30e9e430

Files

T

windyboy 40f3fe3eb8 vault backup: 2026-01-05 14:26:17

2026-01-05 14:26:17 +08:00

12 KiB

Raw Blame History


SELECT 
    column_name,
    comments
FROM 
    all_col_comments
WHERE 
    owner = 'ZC' 
    AND table_name = 'BASE_USER';

To close all sessions associated with the user 'zc' in an Oracle database, you need to identify those sessions and then terminate them. This process requires administrative privileges. Below are the steps to accomplish this:

Connect to the Database as an Administrator

Open SQL*Plus or your preferred SQL client and connect as a user with administrative privileges (such as SYSDBA):
```
sqlplus / as sysdba
```
Identify the Sessions Belonging to User 'zc'

Execute the following query to retrieve the SID and SERIAL# of all sessions for user 'zc':
```
SELECT SID, SERIAL# FROM V$SESSION WHERE USERNAME = 'ZC';
```
Note: Oracle usernames are usually stored in uppercase unless created with double quotes.
Terminate the Sessions

You can terminate each session individually using the ALTER SYSTEM KILL SESSION command:
```
ALTER SYSTEM KILL SESSION 'SID,SERIAL#';
```
Replace SID and SERIAL# with the values obtained from the previous query.

Example:

If the query returns SID = 123 and SERIAL# = 4567, execute:
```
ALTER SYSTEM KILL SESSION '123,4567';
```

Automate the Termination of All Sessions

To kill all sessions for user 'zc' in one step, you can use a PL/SQL block:

BEGIN
  FOR rec IN (SELECT SID, SERIAL# FROM V$SESSION WHERE USERNAME = 'ZC') LOOP
    EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION ''' || rec.SID || ',' || rec.SERIAL# || ''' IMMEDIATE';
  END LOOP;
END;
/

This script loops through each session and issues the kill command.

Verify the Sessions Are Closed

Run the initial query again to ensure all sessions have been terminated:
```
SELECT SID, SERIAL# FROM V$SESSION WHERE USERNAME = 'ZC';
```
If no rows are returned, all sessions have been successfully closed.

Important Considerations:

Transactions: Killing a session that is in the middle of a transaction can cause that transaction to be rolled back. Ensure that terminating these sessions won't negatively impact your database integrity.
Privileges: You must have the necessary privileges (ALTER SYSTEM privilege) to kill sessions.
Immediate Termination: Adding the IMMEDIATE clause forces the session to terminate without waiting for ongoing transactions to complete.
Oracle Versions: In Oracle 12c and newer, you can use ALTER SYSTEM DISCONNECT SESSION for immediate termination:
```
ALTER SYSTEM DISCONNECT SESSION 'SID,SERIAL#' IMMEDIATE;
```

By following these steps, you can close all sessions associated with the user 'zc' in your Oracle database.

When the source and target databases have different character sets (NLS settings), exporting and importing data in Oracle requires careful handling to ensure data integrity. Incorrect handling can lead to character corruption, loss of data, or import errors. Below, I'll guide you through the steps to perform exp (export) and imp (import) when the source and target NLS_LANG settings are not the same.

Understanding NLS_LANG and Character Sets

NLS_LANG Environment Variable: Determines the language, territory, and character set settings for Oracle client applications.
Character Set Conversion: Oracle performs character set conversion between the client (as specified by NLS_LANG) and the database character set.

Key Principle: To prevent unwanted character set conversion and potential data corruption, set NLS_LANG to match the database character set when using exp and imp utilities.

Steps for Exporting and Importing Between Different NLS_LANG Settings

1. Determine the Character Sets

Source Database:

SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

Target Database:

SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

2. Set NLS_LANG for Export

Objective: Prevent character set conversion during export.
Action: Set NLS_LANG to match the source database character set.

Example:

If the source database character set is WE8MSWIN1252:

Windows:

SET NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252

Unix/Linux:

export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252

3. Perform the Export (`exp`)

Run the exp command after setting NLS_LANG:

exp userid=username/password@source_db file=export.dmp log=export.log [other options]

No Character Set Conversion: Since NLS_LANG matches the database character set, Oracle doesn't perform character set conversion during export.

4. Transfer the Dump File

Copy export.dmp to the target machine if necessary.

5. Set NLS_LANG for Import

Objective: Ensure correct character set conversion during import.
Action: Set NLS_LANG to match the target database character set.

Example:

If the target database character set is AL32UTF8:

Windows:
```
SET NLS_LANG=AMERICAN_AMERICA.AL32UTF8
```

Unix/Linux:

export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

6. Perform the Import (`imp`)

Run the imp command:

imp userid=username/password@target_db file=export.dmp log=import.log [other options]

Character Set Conversion: Oracle converts character data from the dump file's character set (source database character set) to the target database character set.

7. Verify the Imported Data

After import, check the data integrity, especially for special characters or multilingual data.

Detailed Explanation

Why Set NLS_LANG to the Database Character Set?

During Export:
- Setting NLS_LANG to match the source database character set ensures that no character set conversion occurs between the database and the export utility.
- Data is exported exactly as it is stored in the database.
During Import:
- Setting NLS_LANG to match the target database character set allows Oracle to correctly interpret the character data from the dump file and convert it to the target database's character set if necessary.
- This prevents character corruption due to incorrect character set conversion.

Understanding Character Set Conversion

Export Process:
- Database → Client (exp utility): If NLS_LANG matches the database character set, no conversion occurs.
Import Process:
- Dump File → Client (imp utility): The imp utility reads data in the dump file's character set.
- Client (imp utility) → Target Database: Oracle converts character data from the client character set (specified by NLS_LANG) to the target database character set.

Example Scenario

Source Database:

Character Set: WE8ISO8859P1
NLS_LANG: AMERICAN_AMERICA.WE8ISO8859P1

Target Database:

Character Set: AL32UTF8
NLS_LANG: AMERICAN_AMERICA.AL32UTF8

Export Steps

Set NLS_LANG:

SET NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1

Run Export:

exp userid=source_user/password@source_db file=export.dmp log=export.log

Import Steps

Set NLS_LANG:
```
SET NLS_LANG=AMERICAN_AMERICA.AL32UTF8
```

Run Import:

imp userid=target_user/password@target_db file=export.dmp log=import.log

Additional Considerations

Character Set Compatibility

Ensure the target character set can represent all characters from the source character set.
Superset Character Sets: If the target character set is a superset of the source, conversion should be lossless (e.g., importing from WE8ISO8859P1 to AL32UTF8).

Testing

Test Import: Before full-scale import, test with a small dataset to verify character data integrity.

Data Pump Utilities

expdp and impdp: For Oracle 10g and later, consider using Data Pump utilities which handle character set conversions more efficiently.
Note: Data Pump utilities run on the server side and generally require less attention to NLS_LANG, but it's still good practice to set it appropriately if your parameters include non-ASCII characters.

Locale-Specific Data

Date Formats, Numeric Formats: Other NLS parameters (like NLS_DATE_FORMAT, NLS_NUMERIC_CHARACTERS) may need to be set if your data depends on locale-specific formats.

Common Mistakes to Avoid

Setting NLS_LANG to the Wrong Character Set

Do Not: Set NLS_LANG to the operating system character set unless it matches the database character set.
Result: Misalignment can cause Oracle to perform unwanted character set conversions, leading to data corruption.

Ignoring NCHAR and NVARCHAR Data

Note: NLS_NCHAR_CHARACTERSET may also need to be considered if your databases use NCHAR, NVARCHAR2, or NCLOB data types.

Frequently Asked Questions

Q1: Can I set NLS_LANG to the same value during both export and import?

A: While possible, it's not recommended unless the source and target databases have the same character set. Setting NLS_LANG to match the respective database character sets at each stage ensures proper handling.

Q2: What if I can't match NLS_LANG to the database character set?

A: If you cannot set NLS_LANG to match the database character set, you risk character data corruption. It's crucial to find out the correct character set and set NLS_LANG accordingly.

Q3: How do I handle data that includes special or non-English characters?

A: Use Unicode character sets (e.g., AL32UTF8) for the target database if possible, and ensure NLS_LANG is correctly set to handle these characters.

Summary of Steps

Determine Character Sets:
- Source and target database character sets.
Set NLS_LANG for Export:
- Match to source database character set.
Export Data:
- Use exp utility.
Set NLS_LANG for Import:
- Match to target database character set.
Import Data:
- Use imp utility.
Verify Data Integrity:
- Check for character corruption or data loss.

Example Commands

Export Command

Windows:

SET NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
exp userid=source_user/password@source_db file=export.dmp log=export.log

Unix/Linux:

export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
exp userid=source_user/password@source_db file=export.dmp log=export.log

Import Command

Windows:

SET NLS_LANG=AMERICAN_AMERICA.AL32UTF8
imp userid=target_user/password@target_db file=export.dmp log=import.log

Unix/Linux:

export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
imp userid=target_user/password@target_db file=export.dmp log=import.log

Final Tips

Backup: Always backup your databases before performing import/export operations.
Documentation: Keep records of your NLS_LANG settings and character sets for future reference.
Consult Oracle Documentation: For complex scenarios, refer to Oracle's Globalization Support Guide.

By carefully setting the NLS_LANG environment variable to match the database character sets during export and import, you can safely transfer data between databases with different NLS_LANG settings. This approach ensures proper character set conversion and maintains data integrity across different environments.

If you have further questions or encounter specific issues during the process, feel free to ask for more assistance!

12 KiB Raw Blame History

Understanding NLS_LANG and Character Sets

Steps for Exporting and Importing Between Different NLS_LANG Settings

1. Determine the Character Sets

2. Set NLS_LANG for Export

3. Perform the Export (exp)

4. Transfer the Dump File

5. Set NLS_LANG for Import

6. Perform the Import (imp)

7. Verify the Imported Data

Detailed Explanation

Why Set NLS_LANG to the Database Character Set?

Understanding Character Set Conversion

Example Scenario

Export Steps

Import Steps

Additional Considerations

Character Set Compatibility

Testing

Data Pump Utilities

Locale-Specific Data

Common Mistakes to Avoid

Setting NLS_LANG to the Wrong Character Set

Ignoring NCHAR and NVARCHAR Data

Frequently Asked Questions

Summary of Steps

Example Commands

Export Command

Import Command

Final Tips

12 KiB

Raw Blame History

3. Perform the Export (`exp`)

6. Perform the Import (`imp`)