tailieunhanh - OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P100

OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P100:There is an ever increasing demand for staff with IT industry certification. The benefits to employers are significant—they can be certain that staff have a certain level of competence—and the benefits to the individuals, in terms of demand for their services, are equally great. Many employers are now requiring technical staff to have certifications, and many IT purchasers will not buy from firms that do not have certified staff. | OCA OCP Oracle Database 11g All-in-One Exam Guide 946 in one byte then UTF8 becomes much less efficient because the multibyte characters must be assembled at runtime from a number of single bytes with a consequent performance hit. Also UTF8 will often need three or even four bytes to store a character that AL16UTF16 can encode in two. The second possibility for a fully multilingual database is to use Unicode as the actual database character set. The supported options are UTF8 and AL32UTF8 which are both variable-width multibyte character sets. The only limitation on the database character set is that it must have either US7ASCII or EBCDIC as a subset. This is because the database character set is used to store SQL and PL SQL source code which is written in these characters. Both the database character set and the National Character Set are specified in the CREATE DATABASE command. The defaults are US7ASCII and AL16UTF16. If you create a database using the Database Creation Assistant DBCA DBCA will provide a default for the database character set which it will pick up from the character set of the host operating system where you are running DBCA. This may be more appropriate than the seven-bit Oracle default but remember that your clients may be using terminals with a different operating system from the database server. Changing Character Sets There are many occasions when DBAs have wished that they could change the database character set. Typically this is because the database was created using the default of US7ASCII and later on a need arises for storing information using characters not included in that character set such as a French name. Prior to release 9i there was no supported technique for changing the character set. From 9i onward there is a supported technique but there is no guarantee that it will work. It is your responsibility as DBA to carry out thorough checks that the change will not damage the data. The problem is simply that a change of character

TỪ KHÓA LIÊN QUAN
TÀI LIỆU MỚI ĐĂNG
crossorigin="anonymous">
Đã phát hiện trình chặn quảng cáo AdBlock
Trang web này phụ thuộc vào doanh thu từ số lần hiển thị quảng cáo để tồn tại. Vui lòng tắt trình chặn quảng cáo của bạn hoặc tạm dừng tính năng chặn quảng cáo cho trang web này.