2011年1月26日 星期三

給想學SAP的朋友們!

回覆了一封信給想學SAP的朋友。
因為寫類似信的朋友也不少,乾脆把信內容轉貼上來,提供其他人參考。

[來信]

吳大你好:

在你的網誌看到 SAP IDES R/3 4.71筆記,感到受益良多.

冒昧請問我該到哪下載SAP IDES R/3 4.71 軟體,讓我能進而多瞭解學習.

XXX
……
……
……


[我的回覆]
X SIR你好!(人名以X代換處理。)
之前我曾在VERYCD上看到載點,是用驢子下載的。
但現在再去找載點,似乎被「處理」掉了。

SAP的學習資源,和ORACLE比起來,算是封閉多了。
但我建議有兩條路,可以繞道而行!
一是去找一本SAP ABAP學習的圖書(外文書),有附一套Mini SAP!
可以安裝在XP上運行,讓你學習ABAP4,
也有等於有了一個簡單的SAP系統管理練習環境。

二是把DATABASE學好,通常會是ORACLE。
因為SAP的運作,有很大一部份,其實和DB效能有關。
會管理DB,對維護SAP,有很大的助益!

還有,在台灣想自學SAP,其實不容易。
因為很難有專對SAP相關技術出版的圖書,可以說是幾乎沒有。
只有找找簡體書或外文書了~
不過,有一些資訊技術訓練機構,有對ERP技術在做推廣和教學。
裡頭會有包括到運作SAP的課程!可以多留意!
雖然成本頗高,但若能因此轉換更好的跑道,會很值得。

SAP由於十分龐大,分工也細!
光其中一種模組,可能就是一門很花時間的課程了。
我寫的安裝,只是其中一個技術環節。
而且,R/3 4.71也算是「相對」過時的軟體了。
新的 NetWeaver 平台安裝,又是不同的界面和程序。
但SAP安裝還是有一貫延續下來的邏輯步驟,可以接續成除錯維護的參考。

我認為找不到R/3 4.71 來練安裝,不必太再意。
有積極的學習心態,和好的現有資訊設備維護技術以及維護習慣。
也很重要哦!

以上~

……
……
……

補充:
原諒我不做任何有關軟體的複製和販售的動作,我只做單純的技術分享!

2011年1月25日 星期二

SAP怎麼去檢視DB?

如果你管理的SAP DB是ORACLE,看到TABLESPACE的使用率有達到99%。
我建議還是調整一下,把使用率降到85%以下吧~
雖然,SAP的DB通常有 autoextend 的機制,但一直讓DB去做autoextend,再處理資料I/O。
總是效能差了一些,不是嗎?

出處:https://forums.sme.sap.com/thread.jspa?messageID=8664551
You can consider the following Factors for measuring the FileSystem capacity planning and requirement to hold datafiles of tablespace.

1. Current Size of the Datafiles associated with Tablespace
Showing Disk Volumes with BR*Tools
Showing Tablespaces with BR*Tools
Showing Data Files with BR*Tools

2. Autoextend -If it is set to yes, the new data file is created autoextensible. In this case, maxsize and incrsize will paly an important role for the capacity planning

3.maxsize -For autoextensible data files, this parameter specifies the maximum size in MB up to which the data file can be increased.

4.incrsize - For autoextensible data files, this parameter specifies the size in MB, by which the data file is automatically increased when necessary.

補充:
https://forums.sme.sap.com/message.jspa?messageID=6120835

ORA-16032 錯誤!

也許我是被最近一連串的系統出錯的狀況搞暈頭了吧!
不小心下錯了指令排程,把 oracle 資料庫的 archive log 的置放路徑搬掉?!
導致運作中的 oracle , logfile 無法順利被 archive 出來。
也連帶造成其中一部 SAP 系統的運作再度異常……

下文總結中,裡頭講到意外的操作……真的讓我,心有戚戚焉啊!

出處:http://blog.csdn.net/nanyida0416sushe/archive/2010/08/06/5793831.aspx

ORA-16032错误解决方法

数据库环境:

oracle 10.2.0+windows xp

故障描述:

在windows xp上把oracle服务和监听启动之后,在SQL*PLUS中用sysdba身份登录后,启动oracle,报如下错误:

ORA-16032: parameter LOG_ARCHIVE_DEST_1 destination string cannot be translated
ORA-09291: sksachk: invalid device specified for archive destination

如图:

错误解决:

根据错误提示该错误产生的原因是因为参数文件中的LOG_ARCHIVE_DEST_1参数无法读取而产生这个错误。我突然想起,我的数据库本来是启动了 自动归档并指定了归档日志存放地址的,即指定了LOG_ARCHIVE_DEST_1参数,但是昨天呢我一时手误把存放这个归档日志文件的文件夹给删掉 了。而启动oracle数据库的过程中首先是读取参数文件从中读取初始化参数并据此启动实例和后台进程,分配内存的,由于有些参数找不到,所以就报错了, 这就是此错误引起的原因。

知道了故障根源以及缘由之后,解决方法就很简单啦。既然是参数文件中某个参数出问题了,那么就可以在参数文件中下手。此时如果数据库使用的是静态参数文 件,那么可以直接在参数文件中修改LOG_ARCHIVE_DEST_1参数,保存后重新启动。如果数据库使用的是SPFILE,那么可以从SPFILE 中生成PFILE,然后在PFILE中修改LOG_ARCHIVE_DEST_1参数,保存后再从PFILE中生成SPFILE,保存,重新启动即可。

故障总结:

这参数文件的错误在数据库中时常有发生,即使意外的操作或者意外的DOWN机也可能导致参数出错,这就警告我们备份参数文件毋容置疑啊。




補充:
ORA-16038的解决(日志无法归档)
http://www.cnblogs.com/jimeper/archive/2008/04/14/1153234.html

2011年1月21日 星期五

IPv4玩完了?

今天看了一下IPv4計數器,居然是“0”?!
IPv4真的玩完了嗎?
http://inetcore.com/project/ipv4ec/index_zh_tw.html


IPv4 的一些相關文件
[1]
Indicates the status of address blocks as follows:
RESERVED: designated by the IETF for specific non-unicast purposes as noted.
LEGACY: allocated by the central Internet Registry (IR) prior to the Regional Internet Registries
(RIRs). This address space is now administered by individual RIRs as noted, including maintenance
of WHOIS Directory and reverse DNS records. Assignments from these blocks are distributed globally
on a regional basis.
ALLOCATED: delegated entirely to specific RIR as indicated.
UNALLOCATED: not yet allocated or reserved.
[2]
0.0.0.0/8 reserved for self-identification [RFC5735]
[3]
Reserved for Private-Use Networks [RFC1918]
[4]
This was reserved for Public Data Networks [RFC1356]
See: http://www.iana.org/assignments/public-data-network-numbers
It was recovered in February 2008 and was subsequently allocated to APNIC in April 2010
[5]
127.0.0.0/8 is reserved for Loopback [RFC5735]
[6]
169.254.0.0/16 reserved for Link Local [RFC5735]
[7]
172.16.0.0/12 reserved for Private-Use Networks [RFC1918]
[8]
192.0.2.0/24  reserved for TEST-NET-1 [RFC5737]
192.88.99.0/24 reserved for 6to4 Relay Anycast [RFC3068]
192.168.0.0/16 reserved for Private-Use Networks [RFC1918]
[9]
192.0.0.0/24 reserved for IANA IPv4 Special Purpose Address Registry [RFC5736]
[10]
198.18.0.0/15 reserved for Network Interconnect Device Benchmark Testing [RFC5735]
198.51.100.0/24 reserved for TEST-NET-2 [RFC5737]
[11]
203.0.113.0/24 reserved for TEST-NET-3 [RFC5737]
[12]
Multicast (formerly "Class D") [RFC5771] registed in http://www.iana.org/assignments/multicast-addresses
[13]
Unicast-Prefix-Based IPv4 Multicast Addresses [RFC6034]
[14]
Administratively Scoped IP Multicast [RFC2365]
[15]
Reserved for future use (formerly "Class E") [RFC1112]
[16]
255.255.255.255 is reserved for "limited broadcast" destination address [RFC0919] and [RFC0922] 

ORA-03113 經典錯誤![轉貼]

[Oracle] ORA-03113错误分析与解决

作者:Fenng
日期:13-Oct-2004 
出处:http://www.dbanotes.net
版本:0.04 ($$ 2003-05-22 v0.1 $$ 2003-12-17 v0.3$$)


前言

每一个DBA在进行数据库管理的过程中不可避免的要遇到形形色色的错误(ORA-1547 ,ORA-904,ORA-1578 ......)。有些错误由于频繁出现、原因复杂而被 Oracle DBA 们戏称之为"经典的错误"。其中ORA-3113 "end of file on communication channel" 就是这样的一个。

我们可以简单的把这个错误理解为Oracle客户端进程和数据库后台进程连接中断。不过,导致这个错误的原因实际上有很多种:对数据库设置不当、任何能导致数据库后台进程崩溃的行为都可能产生这个错误。这个错误的出现还经常伴随着其它错误,比如说:
ORA-1034 ORACLE not available
此外,该错误出现的场景复杂,可能出现在:
  • 启动的Oracle的时侯
  • 试图创建数据库的时侯
  • 试图对数据库进行连接的时侯
  • 在客户端正在运行SQL/PL/SQL的时侯
  • 备份/恢复数据库的时侯
  • 其它一些情况下......
在论坛上也时常可以看到初级DBA对这个问题的求救。在这里简单的对该问题进行一下整理。

错误原因种种


根据网络上大家反映的情况来看,错误原因大约有这些:
  • Unix核心参数设置不当
  • Oracle执行文件权限不正确/环境变量问题
  • 客户端通信不能正确处理
  • 数据库服务器崩溃/操作系统崩溃/进程被kill
  • Oracle 内部错误
  • 特定SQL、PL/SQL引起的错误
  • 空间不够
  • 防火墙的问题
  • 其它原因
在开始解决问题之前,作如下几件事情:
  • 回忆一下在出现错误之前你都做了什么操作,越详细越好;
  • 查看 background_dump_dest 目录中的 alertSID.log 文件也是你必须要的事情;
  • 用Google.COM 搜索一下,在互联网上有很多信息等着你去发现,不要什么都问别人。
当然, 如果你找到了一些对你更有帮助的东西--这篇文档就不用看了 :-)

错误原因情景分析


  • Unix核心参数设置不当 / init参数设置不当
如果数据库在安装过程中没有设定正确的操作系统核心变量,可能在安装数据库文件的时侯没甚么问题,在创建数据库的时侯常常会出现03113错误。和此有关 的另一个原因是init.ora 参数文件中的processes参数指定了不合理的值,启动数据库导致错误出现(当然这个归根到底也是核心参数的问题)。

这个错误信息一般如下:
ORA-03113: end-of-file on communication channel
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
解决办法有两个:

1、修改核心参数,加大相应核心参数的值(推荐);
2、减小init.ora参数的Processes的值。

需要注意的是:
SEMMSL必须设定为至少要10 + '进程数的最大值';
SEMMNS 也依赖于每个数据库上的进程参数值。
注:

这个错误类型只在Unix平台上出现。在Windows上如果processes的值过大,则会出现类似如下的错误:
ORA-00068: invalid value 24200001 for parameter max_rollback_segments,
must be between 2 and 65535

/* 此时指定的参数值超过了65535 */

或者
ORA-27102: out of memory 
/* 小于65535的一个大参数值 */ 软件环境:
Windows 2000 Version 5.0 Service Pack 3, CPU type 586
ORACLE RDBMS Version: 8.1.7.0.0

在特定平台上更改核心参数可能会有差别,请参考Oracle Technet(http://otn.oracle.com) 上的安装文档。对特定Unix平台的安装文档也有对核心参数意义的解释。 Init.ora中的参数如果设置不当,会产生该错误。有经验表明:shared_pool_size设置 过小会出现错误,此外timed_statistics=true的设置也会带来问题。
  • Oracle执行文件权限不正确/环境变量问题
这个问题只出现在Unix平台上。常见情况是有的时侯管理员为了方便而使用Unix的tar命令 处理过的压缩包进行的安装,或者是系统管理员指定了额外的OS用户也可以管理数据库却没 有指定正确的环境变量。
Oracle执行文件在$ORACLE_HOME/bin目录下,如果出现问题,应该用如下Unix类似命令来纠正 :
#chmod 7755 $ORACLE_HOME/bin/oracle
有的时侯要对Oracle进行relink操作。
在Unix上通过cp拷贝安装的时候,常常会出现环境变量的问题,和个别执行程序连接问题。 LD_LIBRARY_PATH如果设置的不正确会导致问题,在这种情况下,需要对Oracle进行relink。 如果可执行文件oralcle被破坏,也要对其relink。 如果安装了并行服务器选项而Distributed Lock Manager没有安装或正确运行也会导致错误。
  • 客户端通信不能正确处理
1.SQL*Net驱动器的问题:
如果使用的版本比较低的驱动器,请更换到新版本的驱动。 SQL*Net 的驱动没有连接到Oracle可执行文件会导致错误。
2.检查TCP/IP网络是否通畅;
3.Windows平台的常见网络问题:
在Windows平台创建数据库的时侯,如果出现该问题可以考虑用如下的方法:

首先检查本地网络设置.查看网络上是否有同名的结点或有冲突的IP.如果问题依旧,可以保 守的用下面的方法:

1). 禁用网卡:将本地连接状态改为禁用;
2). 将sqlnet.ora文件打开(以记事本形式)将nts验证注释掉:
#SQLNET.AUTHENTICATION_SERVICES= (NTS)
3). 创建数据库;
4). 创建成功后,恢复本地连接;
  • 数据库服务器崩溃/操作系统崩溃/进程被异常的Kill
在连接过程中,如果Oracle数据库的服务器崩溃或者数据库所在的操作系统崩溃,就会出现这 个错误,Oracle Server崩溃的原因可能因为主要后台进程死掉,被错误的进行了Kill操作。如果是这个原因还是比较容易解决的。此外,和OS有关的应用程序存在内存 泄漏(或者有病毒)的时侯也会导致Oracle后台程序问题。 推荐排错步骤:
  • 1、 查看应用软件相关进程是否正常运行;
  • 2、 查看有无内存泄漏;
  • 3、 查杀病毒;
  • 4、 确定系统管理员没有进行误操作;
  • 5、 确定无黑客入侵行为;
  • 6、 其它不确定因素......
  • Oracle 内部错误 / Bug
如果查看background_dump_dest目录中的alert.log发现有ora-600/ora-07445等错误,可以到Metalink站点上查看具体信息及其解决方案。一般情况下要打软件补丁。
  • 特定SQL、PL/SQL引起的错误
尝试把SQL进行分开执行,也可以用SQL_TRACE来进行跟踪,找到导致问题的SQL语句。在SQLPlus下:
ALTER SESSION SET sql_trace=TRUE;
SQL语句中的非法字符和不合理的处理结果,甚至一些不可解释的原因偶尔会带来问题.
SQL问题举例:
SELECT *
FROM (SELECT ROWNUM AS num, k.*
FROM (SELECT a.cp_code, c.cp_cha_name, a.service_code,
a.service_name, a.content_name,
SUBSTR (a.access_time, 1, 8) thedate,
COUNT (*) AS hit_count
FROM sm_wap_log_daily_tab a, t_cp_info c
WHERE (SUBSTR (a.access_time, 1, 8) BETWEEN '20040301'
AND '20040304'
)
AND c.cp_code LIKE '%%'
AND a.cp_code = c.cp_code
AND a.service_code LIKE '%%'
GROUP BY a.cp_code,
c.cp_cha_name,
a.service_code,
a.service_name,
a.content_name,
SUBSTR (a.access_time, 1, 8)
ORDER BY a.cp_code,
a.service_code,
a.content_name,
SUBSTR (a.access_time, 1, 8) DESC) k) n;
上面这条语句在9204/Linux 系统上始终出现03113 的错误。对语句进行细化,分成小一点的子语句逐步执行,最后判定问题出现在
                 ORDER BY a.cp_code,
a.service_code,
a.content_name,
SUBSTR (a.access_time, 1, 8) DESC) k) n;
中的 SUBSTR (a.access_time, 1, 8) 这里。 去掉SUBSTR (a.access_time, 1, 8)则问题不再出现。尝试调整SUBSTR (a.access_time, 1, 8) 的位置,语句得到通过。之后,顺便优化一下该语句。:) 
SELECT *
FROM (SELECT ROWNUM AS num, k.*
FROM (SELECT a.cp_code, c.cp_cha_name, a.service_code,
a.service_name, a.content_name,
SUBSTR (a.access_time, 1, 8) thedate,
COUNT (*) AS hit_count
FROM sm_wap_log_daily_tab a, t_cp_info c
WHERE (SUBSTR (a.access_time, 1, 8) BETWEEN '20040301'
AND '20040304'
)
AND c.cp_code LIKE '%%'
AND c.cp_code = a.cp_code
AND a.service_code LIKE '%%'
GROUP BY a.cp_code,
c.cp_cha_name,
a.service_code,
a.service_name,
a.content_name,
SUBSTR (a.access_time, 1, 8)
ORDER BY (SUBSTR (a.access_time, 1, 8)),
a.cp_code,
a.service_code,
a.content_name DESC) k) n;
  • 系统空间不够
任何时侯都要确保数据库系统有足够的空间.如果 USER_DUMP_DEST和BACKGROUND_DUMP_DEST没有剩余空间的话,会导致此问题.此外,如果打开了审计,AUDIT目录要由足够的空间.如果激活了Trace的话,Trace目录要由足够的空间. Dave Wotton的文档 (Local Copy) 表明,在对表进行插入数据的时侯,如果文件超过了2G (而文件系统有2G限制),会导致该问题.
  • 防火墙的问题
如果数据要通过防火墙,请联系系统管理员,询问是否对数据库数据进行了过滤或者是突然禁止了通信端口。如本地安装有个人防火墙,请检查本地设置。
  • 其它方面说明
导致这个错误的原因有很多种,上面列到的只是一些典型情况。经常去一些数据库技术论坛可能会有帮助。比如说ITPUB( http://www.itpub.net)、CNOUG(http://www.cnoug.org)等。

参考信息


Metalink - http://metalink.oracle.com Oracle的技术支持站点,要有CSI号码才可以登录。
参考Note编号:
Note:17613.1 ORA-3113 on Unix - What Information to Collect
NOTE:131207.1 How to Set UNIX Environment Variables
Note:131321.1 How to Relink Oracle Database Software on UNIX
Note:22080.1 An Introduction to Error Message Articles
http://www.jlcomp.demon.co.uk/faq/ORA-3113.html
技术专家Jonathan Lewis的站点上的一则FAQ

2011年1月13日 星期四

2011網管人員一定要重視的事件-IPv6

[轉載自IP邦新聞稿]
ISOC組織主導一場即將在今年6月8月舉行的World IPv6 Day,並號召全球網路相關業者共同參與,包括Google、Yahoo及Facebook都已決定要參與這場盛會。

專門制定網路標準、政策及教育的The Internet Society(ISOC)組織主導一場即將在今年6月8月舉行的World IPv6 Day,並號召全球網路相關業者共同參與,在當天於主要的網站上採用IPv6,在可控制的情況下測試新一代的網路協定標準,而包括Google、Yahoo及Facebook都已決定要參與這場盛會。

ISOC指出,The Internet Society是首次讓網路產業的各個成員在最小的影響下一起進行IPv6的大規模測試,不論是ISP業者、網站業者、作業系統業者或硬體業者都將共同解決相關問題,例如家中網路的IPv6故障或是IPv6互連問題等,任何全球規模的問題都可在當天被發現,然後共同解決。

目前全球採用的網路協定版本為IPv4,使用32位元長度的位址,但由於目前連網裝置太多,IPv4位址的發放預計今年就會耗盡,而新的IPv6則使用128位元長度的位址,可創造的位址數量是IPv4的40億倍。該協定屬於基礎架構,因此其部署牽涉到網路服務供應商、作業系統業者、網路公司與硬體製造商等,雖然已有不少大型網路開始使用IPv6技術,但迄今仍缺乏全球規模的測試。

ISOC說明,全球網路若要轉移至IPv6必須有來自不同業者的配合,例如ISP業者要提供IPv6連網服務,網站業者要透過IPv6提供內容服務,作業系統業者必須更新系統以支援IPv6,骨幹業者必須建立IPv6架構的連接,硬體或閘道器製造商必須更新韌體。

Google、Yahoo及Facebook都已決定加入這場全球性測試,當天相關網站都將啟用IPv6技術,並維持24小時。Google網路傳播長Vint Cerf表示,在短暫的網路歷史上,轉移至IPv6是保護網路最重要的措施之一,Google從2008年就提供僅支援IPv6的版本,在6月8日當天,不論是Google或是YouTube都將啟用IPv6技術。

雖然這是場全球性測試,但ISOC表示絕大多數的使用者都能照常存取各種服務,目前估計只有0.05%使用者在造訪參與該測試的網站時可能會遇到問題,這些問題可能與作業系統或是家中路由器設定有關,真遇到問題時使用者可關閉IPv6功能或尋求ISP業者的協助。ISOC已建置一IPv6測試網頁,供使用者進行連結測試。(編譯/陳曉莉)

2011年1月6日 星期四

一個修復DB案例的警惕-留意版本的差異?

狀況:http://space.itpub.net/7204674/viewspace-468429

修改了oracle database 10gR2的spfile內容!
重開資料庫後,無法重新啓動 DB.

SQL> startup
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORA-19905: log_archive_format must contain %s, %t and %r

仔细看了看两个问题的说明,ORA-32004是因为指定了已经废弃的参数,ORA-19905是说log_archive_format 必须包含%s, %t and %r。看到这里,我突然明白了,我练习用的课本是9i,实际操作的数据库是10.2,看来是log_archive_format 参数命名发生了变化。

...
...
...

案例的除錯心得中,強調版本不同的資料庫,必須留意制訂參數的使用.

除錯的過程,需要了解pfile和spfile的差別以及使用時機.

如何管理ORACLE ARCHIVELOG MODE ?

ORACLE DATABASE 切換到 Archive LOG 或 NO ARCHIVE LOG 模式必須關閉、重新啟動資料庫。

切換到ARCHIVE LOG 模式並不表示系統會自動執行 ARCHIVE LOG,必須下指令執行,如果希望一開機就自動執行必須在 spfile 中作設定。

切換到ARCHIVE LOG 模式後應立即作備份的動作,如果使用之前的備份回復資料,資料只能回復至 NOARCHIVE LOG Mode 時的狀況。

檢查是否為 Archive Log 模式
SQL>select archiver select * from v$log;
SQL>archive log list;

更改 ARCHIVE/NOARCHIVE LOG 模式步驟:
1.SQL>shutdown immediate
2.SQL>startup mount
3.SQL>alter database archivelog/noarchivelog;
4.SQL>alter database open;
5.backup full database and control file;

啟動 Archive LOG Mode
SQL>alter system archive log start/stop;

變更啟動 Parameter,讓資料庫一啟動就自動執行 ARCHIVE LOG
SQL>alter system set log_archive_start=true scope=spfile;
或是在 pfile 中加入 log_archive_start=true

查詢 ARCHIVE LOG 狀況
SQL>Archive Log List

其它一些相關的設定參數和查詢
SQL>show parameter log_archive_format
SQL>alter SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3 scope=spfile sid='*';;
SQL>alter SYSTEM SET log_archive_dest_1 = "location=C:Oracleoradataoradbarchive" scope=spfile sid='*';
SQL>alter SYSTEM SET log_archive_format = %%ORACLE_SID%%T%TS%S.ARC scope=spfile sid='*';


出處:http://yu-minspace.blogspot.com/2007/07/oracle-database-archive-log-no-archive.html

如何建立ORACLE 資料庫 DATABASE LINK?

  本地数据库SID=T2

  远程数据库SID=LIFE02

  假设你的网络设定无误

  

  1) vi local database tnsname.ora


  life02 =

  (description =

  (address = (protocol = tcp)(host = 192.168.1.1)(port = 1521))

  (connect_data = (sid = life02))

  )

  

  2)建立属于公开的(public)或者是专属的db link object


  SQL> CREATE PUBLIC DATABASE LINK MYTEST

  2 CONNECT TO APPLE IDENTIFIED BY APPLE

  3 USING 'life02'

  Database link created.

  

  3)复制远程数据库的table到本地数据库来


  SQL> COPY FROM APPLE/APPLE@LIFE02 -

  > CREATE ABC -

  > USING SELECT * FROM TEST;

  Array fetch/bind size is 15. (arraysize is 15)

  Will commit when done. (copycommit is 0)

  Maximum long size is 80. (long is 80)

  Table ABC created.

  3 rows selected from APPLE@LIFE02.

  3 rows inserted into ABC.

  3 rows committed into ABC at DEFAULT HOST connection.

  SQL> SELECT * FROM ABC;

  ID

  ----------

  100

  200

  333

  SQL>

  

  4)从本地端表格复制数据到远程数据库表格上


  SQL> COPY FROM JACK/JACK@T2 TO APPLE/APPLE@LIFE02 -

  > INSERT TEST -

  > USING SELECT * FROM T1;

  Array fetch/bind size is 15. (arraysize is 15)

  Will commit when done. (copycommit is 0)

  Maximum long size is 80. (long is 80)

  2 rows selected from JACK@T2.

  2 rows inserted into TEST.

  2 rows committed into TEST at APPLE@LIFE02.

  详细资料请参考SQL*Plus User's Guide and Reference

本文来自:Linux宝库 -- http://www.linuxpk.com/49151.html

補充:
1.編輯好 tnsnames.ora 後,可以利用 tnsping 指令來測看看.
雖然與 /etc/hosts 設定無關,但為了網管配合,最好也訂上對應的設定值.

2.db link 搭配 synonym ,可以把遠端資料庫當成LOCAL端來使用,但不建議!
有點把LOCAL資料庫當成ROUTER來用的味道.

如何查詢ORACLE資料庫的字元集?

使用以下兩種語法,都能查出你所管理的資料庫是,使用那個語系和字元集.
語法 一:
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' ;

繁體中文不脫乎 BIG5 和 WIN950 兩大類!
若是使用 UNICODE ,應該會是用 AL32UTF8.


語法二:
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET' ;

我最早只知道語法二!

搜尋此網誌

本站大事記

這個部落格(網站)內容以分享LINUX和延伸出的技術文章為主!
特別是為了工作和進修需要,搜集了不少網站連結。
希望對來這裡觀文的朋友們,有提供一些有用的資訊或文章。
但這裡的文章中,也包含個人的心情扎記和隨興言談……
若是當中沒有對上你的口味,請多包涵!

原「琳娜絲與希斯寇的邂逅」,改名為「愛上琳娜絲」!

原「琳娜絲與希斯寇的邂逅」,改名為「愛上琳娜絲」!
--原序文--
就是當LINUX遇上CISCO啦!他們的結合還能作什麼事…不就是讓這個世界的網路,串…串起來啊…不然你們那能上這網站看部落格!