Chuyển đổi file Excel xls sang file csv vẫn giữ font tiếng Việt unicode

 Mấy hôm nay gặp vấn đề về font tiếng Việt với  file csv. Vấn đề chi tiết như sau.
 Mình có file dữ liệu là excel *.xls . Vì nhu cầu công việc mình cần phải chuyển nó sang file có định dạng *.csv để import vào một ứng dụng của công ty. Mặc dù trong Excel có chức năng Save As, chọn type là *.csv; nhưng Excel lại không hỗ trợ Unicode. Do đó file *.csv sau khi tạo bằng chức năng Save As của Excel bị mất font tiếng Việt.
 Lên net tìm một một buổi chẳng có chỉ thấy ai làm được. Chỉ có cách của Anhgolden's Blog! . Nhưng cách này thì rườm rà, không hay.
Thế là mình quyết định viết một macro ngay trên Excel để chuyển font Unicode sang UTF8. Rồi sau đó dùng chức năng Save As của Excel để lưu ra file *.csv. Vì đặc tính của UTF8 là dùng nhiều ký tự 1byte để biểu diễn cho một ký tự Unicode nhiều bytes. Nên file *.csv tạo ra vẫn có tiếng Việt. Và có thể import vào ứng dụng của công ty. Hiện nay, hầu hết các ứng dụng đều hỗ trợ UTF8(nhưng Excel không hiễn thị được tiếng Việt UTF8 nhé).
Giờ thì chỉ mỗi việc mở file excel có macro (Link download) run macro để chuyển font Unicode sang UTF8, và Save As là có file *.csv với font Tiếng Việt. Bài viết giúp được bạn comment cảm ơn 1 tiếng nhé.

  Dưới đây là demo:

MySQL my.cnf configuration for a large Drupal site

For a large web site with hundreds of thousands of page views per day, it is important to increase certain parameters, such as the query cache, join buffers, key buffer, ..etc.
The following my.cnf file is from an Ubuntu server (Debian derived) with dual CPUs, and 2 GB of RAM. It assumes that you are using MyISAM tables only and not InnoDB.
Depending on what modules you have, you may need to adjust some of those parameters, but this is definitely a good start.

 

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
old_passwords = 1
bind-address = 127.0.0.1
key_buffer = 16M
key_buffer_size = 32M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 64
query_cache_limit = 8M
query_cache_size = 64M
query_cache_type = 1
join_buffer_size = 512K
max_connections = 150
log_slow_queries = /var/log/mysql/mysql-slow.log
skip-bdb
skip-innodb

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 16M

Duplication Fails with Multiple RMAN-06023 Errors: Scenario

Duplication Fails with Multiple RMAN-06023 Errors: Scenario

In this scenario, you back up the database, then run the DUPLICATE command. You receive the following error stack:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/04/2001 13:55:11
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 8 found to restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

Duplication Fails with Multiple RMAN-06023 Errors: Diagnosis

The DUPLICATE command recovers to archived redo logs, but cannot recover into online redo logs. Thus, if the restored backup cannot be made consistent without applying the online redo logs, then duplication fails with RMAN-06023 errors because RMAN is looking for backups created before the most recent archived log.

Duplication Fails with Multiple RMAN-06023 Errors: Solution

After backing up the source database, archive and back up the current redo log:

RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
RMAN> BACKUP ARCHIVELOG ALL;

ref: Oracle® Database Backup and Recovery Advanced User's Guide

Oracle 10g Data Dictionary

Shell script schedule backup MySQL Database

There are many software that can help you schedule backup MySQL Database using user interface. But with MySQL Database are installed on Linux host, you write Shell script to schedule backup MySQL Database without any additional software. Below I will show the script:

#!/bin/bash

MyUSER="root"
MyPASS="rootpassword"
MyHOST="localhost"

# Linux bin paths, change this if it can't be autodetected via which command
MYSQL="$(which mysql)"
MYSQLDUMP="$(which mysqldump)"
CHOWN="$(which chown)"
CHMOD="$(which chmod)"
GZIP="$(which gzip)"

# Backup Dest directory, change this if you have someother location
DEST="/backup/database"

# Main directory where backup will be stored
MBD="$DEST/mysql"

# Get hostname
HOST="$(hostname)"

# Get data in dd-mm-yyyy format
NOW="$(date +"%d-%m-%Y")"

# DO NOT BACKUP these databases
IGGY="test"

[ ! -d $DEST ] && mkdir -p $DEST || :
[ ! -d $MBD ] && mkdir -p $MBD || :

# Only root can access it!
$CHOWN 0.0 -R $DEST
$CHMOD 0600 $DEST

# Get all database list first
DBS="$($MYSQL -u $MyUSER -h $MyHOST -p$MyPASS -Bse 'show databases')"
echo "==>List of Database:" $DBS

for db in $DBS
do
  skipdb=-1
  if [ "$IGGY" != "" ]; then
    for i in $IGGY
    do
      [ "$db" == "$i" ] && skipdb=1 || :
    done
  fi

  if [ "$skipdb" == "-1" ] ; then
    FILE="$MBD/$db-$HOST-$NOW.gz"
    echo "==>dump database" $db "to file" $FILE
    # do all inone job in pipe,
    # connect to mysql using mysqldump for select mysql database
    # and pipe it out to gz file in backup dir
    $MYSQLDUMP -u $MyUSER -h $MyHOST -p$MyPASS $db | $GZIP -9 > $FILE
  fi
done

How Change ORACLE_SID & DB_NAME

Overview

This month, I will describes how to find and change the "db_name" for a database, or the ORACLE_SID for an instance, without recreating the database.

Query the data dictionary to find the current DB_NAME and ORACLE_SID

Query the views v$database and v$thread.

• V$DATABASE gives DB_NAME
• V$THREAD gives ORACLE_SID

ORACLE_SID = DB_SID and db_name = DBNAME: To find the current value of ORACLE_SID:

SVRMGR> select instance from v$thread;

     INSTANCE
     ----------------
     DB_SID

To find the current value of DB_NAME:

SVRMGR> select name from v$database;

     NAME
     ---------
     DBNAME

How to modify the database to run under a new ORACLE_SID

1.  Shutdown the instance  
 
2.  Backup all control, redo, and data files.  
 
3.  Go through the .profile, .cshrc, .login, oratab, tnsnames.ora,  
    (for SQL*Net version 2), and redefine the ORACLE_SID environment 
    variable to a new value.  
 
    For example, search through disks and do a grep ORACLE_SID *  
 
4.  Change locations to the "dbs" directory 
 
       % cd $ORACLE_HOME/dbs   
 
    and rename the following files:  
 
    o   init.ora  (or use pfile to point to the init file.)  
    o   control file(s). This is optional if you do not rename any 
        of the controlfiles, and the control_files parameter is used.  
        The "control_files" parameter is set in the "init.ora" file 
        or in a file it references with the ifile parameter.  Make  
        sure that the control_files parameter does not point to old 
        file names, if you have renamed them.  
    o   "crdb.sql" & "crdb2.sql",  This is optional.  These are  
        only used at database creation.  
 
5.  Change locations to the "rdbms/admin" directory 
 
       % cd $ORACLE_HOME/rdbms/admin    
    
    and rename the file:  
 
    o   startup.sql.  This is optional.  On some platforms,  
        this file may be in the "$ORACLE_HOME/rdbms/install" directory. 
        Make sure that the contents of this file do not reference old  
        init.ora files that have been renamed.  This file  
        simplifies the "startup exclusive" process to start your database.  
 
6.  To rename the database files and redo log files, you would follow the  
    instructions in [NOTE:9560.1]. 
 
7.  Change the ORACLE_SID environment variable to the new value. 
 
8.  Check in the "$ORACLE_HOME/dbs" directory to see if the password  
    file has been enabled.  If enabled, the file "orapw" will 
    exist and a new password file for the new SID must be created  
    (renaming the old file will not work).  If "orapw" does not 
    exist, skip to step 9.  To create a new password file, issue 
    the following command as oracle owner: 
  
       orapwd file=orapw password=?? entries= 
 
9.  Start up the database and verify that it works.  Once you have done  
    this, shutdown the database and take a final backup of all control,  
    redo, and data files.  
 
10. When the instance is started, the control file is updated with the  
    current ORACLE_SID.

How to the "db_name" for a Database

1.  Login to Server Manager 
 
        % svrmgrl 
        SVRMGR> connect internal  

2.  Type

        SVRMGR> alter system switch logfile;

    to force a checkpoint.
  
3.  Type 
 
        SVRMGR> alter database backup controlfile to trace resetlogs;  
      
    This will create a trace file containing the "CREATE CONTROLFILE" 
    command to recreate the controlfile in its current form.  
 
4.  Shutdown the database and exit SVRMGR 
 
        SVRMGR> shutdown

        SVRMGR> exit 

    The database must be shutdown with SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE.
    It must not be shutdown abnormally using SHUTDOWN ABORT.
 
5.  Change locations to the directory where your trace files are located.  
    They are usually in the "$ORACLE_HOME/rdbms/log" directory.  If  
    "user_dump_dest" is set in the "init.ora" file, then go to the  
    directory listed in the "user_dump_dest" variable.  The trace file will 
    have the form "ora_NNNN.trc with NNNN being a number.   

6.  Copy the contents of the trace file starting from the line with
    STARTUP NOMOUNT down to the end of the trace file and put it in
    a new file called something like "ccf.sql".

7.  Edit the "ccf.sql" file   
 
    FROM: CREATE CONTROLFILE REUSE DATABASE "olddbname" RESETLOGS ...  
      TO: CREATE CONTROLFILE set DATABASE "newdbname"  RESETLOGS ...  

    Change the word 'REUSE' to 'set' and the 'olddbname' to 'newdbname'.

    It is possible to recreate the controlfile using the syntax:
          CREATE CONTROLFILE REUSE set DATABASE "newdbname" RESETLOGS ...

    But this syntax will allow the existing controlfiles to be overwritten
    without giving an error.

    FROM:
    # Recovery is required if any of the datafiles are restored backups,
    # or if the last shutdown was not normal or immediate.
    RECOVER DATABASE USING BACKUP CONTROLFILE
    TO:
    # Recovery is required if any of the datafiles are restored backups,
    # or if the last shutdown was not normal or immediate.
    # RECOVER DATABASE USING BACKUP CONTROLFILE

    The last command in ccf.sql should be:
    alter database open resetlogs

8.  Save and exit the "ccf.sql" file 
  
9.  Rename the old control files for backup purposes and so that they do
    not exist when creating the new ones.  
 
10. Edit the "init.ora" file so that db_name="newdb_name" .  
 
11. Login to Server Manager 
 
        % svrmgrl
        SVRMGR> connect internal
 
12. Run the "ccf.sql" script 
 
        SVRMGR> @ccf  

    This will issue a startup nomount, and then recreate the controlfile.

    If, at this point, you receive the error that a file needs media recovery, 
    the database was not shutdown normally as specified in step 4. You can
    try recovering the database using the redo in the current logfile, by
    issuing:

    SVRMGRL>  recover database using backup controlfile until cancel;

    This will prompt for an archived redologfile. It may be possible to 
    open the database after applying the current logfile. BUT this is not 
    guaranteed. 

    To apply the necessary redo, you need to check the online logfiles 
    and apply the one with the same sequence number as reported in the
    message. This usually is the logfile with status=CURRENT. If not apply,
    the logfiles in turn until the logfile with status=CURRENT has been 
    applied.  If, after applying the current logfile, the database will 
    not open then it is highly likely that the operation must be restarted 
    having shutdown the database normally.
 
    To find a list of the online logfiles:

    SVRMGR> select group#, seq#, status from v$log;
    GROUP#     SEQUENCE#   STATUS
    ---------- ---------   ----------------
             1 123         CURRENT     <== this redo needs to be applied
             2 124         INACTIVE
             3 125         INACTIVE
             4 126         INACTIVE
             5 127         INACTIVE
             6 128         INACTIVE
             7 129         INACTIVE

    7 rows selected.
 
    SVRMGR> select member
              from v$logfile
             where GROUP# = 1;

    Member
    ------------------------------------
    /u02/oradata/V815/redoV81501.log
   
    After applying the current online log file the following prompt should
    be displayed:

    Log Applied
    Media Recovery Complete

    At this point the database can be opened with:
 
    SVRMGR> alter database open resetlogs;  
 
13. You may also need to change the global database name:

    alter database rename global_name to .

14. Make sure the database is working.   

15. Shutdown and backup the database.

by Jeff Hunter, Sr. Database Administrator
Source: http://www.idevelopment.info/data/Oracle/DBA_tips/Database_Administration/DBA_7.shtml

NID-00111: Oracle error reported from target database

I was restoring an Oracle 10g database using RMAN from our production environment to a development environment. I had completed most of the necessary steps, and the database was restored and recovered up to the point in time that I wanted.

The next step was to run the NID command in order to change the name of the database. I made sure that I was using the Oracle 10g NID utility and not the 9i version and ran it. I got the following error:

NID-00111: Oracle error reported from target database while executing
begin dbms_backup_restore.nidprocessdf(:fno, :istemp, :skipped, :idchged, :nmchged); end;
ORA-01116: error in opening database file R:\ORACLE\DATA\TEMP01.DBF
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
ORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE", line 6185
ORA-06512: at line 1

In order to get the NID utility to run successfully, I had to log into the database and manually drop the TEMP files, then add TEMP files again using the following commands:

SQL> ALTER DATABASE TEMPFILE 'R:\ORACLE\DATA\TEMP01.DBF' DROP;
SQL> !rm 'R:\ORACLE\DATE\TEMP01.DBF'
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE 'R:\ORACLE\DATA\TEMP01.DBF' SIZE 100M;

You can also read my article on how to drop TEMP files for more details on dropping TEMP files.

It seemed very odd that I had to do this because I’ve never had to do it with a 9i database, and I didn’t think that the TEMP files were needed. RMAN certainly doesn’t back them up. So, if you have a NID command scripted into anywhere and you come across this, make sure that you put the extra step in of dropping the TEMP files first.

Source: http://www.ora00600.com/scripts/databaseconfig/NID-00111.html