SQL Server到Oracle连接服务器

本文以SQL Server 2k为例说明SQL Server到Oracle连接服务器的具体实现过程。
　
1.要求pc机上安装oralce客户端软件和sqlserver2000软件。
　
2.客户端的配置tnsnames.ora文件，配置所要连接的数据库服务器（windows，unix等平台均可以）
eg：tnsnames.ora
......
TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.11.90)(PORT = 1521))
)
(CONNECT_DATA =
(sid = blue)
(SERVER = DEDICATED)
)
)
......
3.配置windows的ODBC数据源：
开始菜单—》设置—》管理工具—》数据源（ODBC）—》进入配置用户DSN或者系统DSN均可以：添加—》选择Microsoft ODBC for oracle—》自定义数据源名称（最好跟tns中连接串同名！）—》服务器名称（必填！填写tns文件中的连接串名称）—》完成。
　
4.配置sqlserver2000中的连接服务器：
企业管理器—》安全性—》连接服务器—》右键新建连接服务器—》定义连接名称； 选其他数据源； 指定程序名称为：Microsoft OLE DB Provider for Oracle; 产品名称可不填； 数据源指定刚才ODBC中定义好的数据源名称； 提供程序字符串按以下格式填写：User ID=username;Password=userpasswd(或者按如下格式：UID=username;PWD=userpasswd)，这里的用户名和密码对应所要连接的oracle数据库中的用户名和密码 —》 安全性标签页里：设置用此安全上下文进行，并录入oracle的数据库用户名和密码—》服务器选项标签页可默认—》确定。
　
5.准备工作全部完成啦！在sqlserver企业管理器—》安全性—》连接服务器打开刚建好的连接服务器—》点击表，即可在右边窗口看到该oracle数据库用户拥有的的所有表名，但在这里还并不能查看表的记录，这个需要在sqserver的查询分析器中用具体sql实现！访问表时，使用格式为： [连接服务器名]..[ORACLE用户].[表名]。更详细具体的使用这里不再赘述。

经常看见有人问，MSSQL占用了太多的内存，而且还不断的增长；或者说已经设置了使用内存，可是它没有用到那么多，这是怎么一回事儿呢？
首先，我们来看看MSSQL是怎样使用内存的。
最大的开销一般是用于数据缓存，如果内存足够，它会把用过的数据和觉得你会用到的数据统统扔到内存中，直到内存不足的时候，才把命中率低的数据给清掉。所以一般我们在看statistics io的时候，看到的physics read都是0。
其次就是查询的开销，一般地说，hash join是会带来比较大的内存开销的，而merge join和nested loop的开销比较小，还有排序和中间表、游标也是会有比较大的开销的。
所以用于关联和排序的列上一般需要有索引。
再其次就是对执行计划、系统数据的存储，这些都是比较小的。
　
我们先来看数据缓存对性能的影响，如果系统中没有其它应用程序来争夺内存，数据缓存一般是越多越好，甚至有些时候我们会强行把一些数据pin在高速缓存中。但是如果有其它应用程序，虽然在需要的时候MSSQL会释放内存，但是线程切换、IO等待这些工作也是需要时间的，所以就会造成性能的降低。这样我们就必须设置MSSQL的最大内存使用。可以在SQL Server 属性（内存选项卡）中找到配置最大使用内存的地方，或者也可以使用sp_configure来完成。如果没有其它应用程序，那么就不要限制MSSQL对内存的使用。
然后来看查询的开销，这个开销显然是越低越好，因为我们不能从中得到好处，相反，使用了越多的内存多半意味着查询速度的降低。所以我们一般要避免中间表和游标的使用，在经常作关联和排序的列上建立索引。
　

在MySQL4.1的安装过程中有缺省character的设置在下图中有显示

如果您所在的服务器有没有选择缺省为GB则会使用UFT8就会出现乱码
或者
只要在你连到数据库后，先执行这句
mysql_query("Set Names 'uft8'");
其中 uft8 可改成你需要的编码，e.g. gb2312 等
这个命令也可以用于 mysql 得命令行，从而可以显示正确的文字
连接数据库出现
-------------------------------------------------------------------------------------------
Client does not support authentication protocol requested
by server; consider upgrading MySQL client
-------------------------------------------------------------------------------------------
由于MySQL 4.1版本开始密码的hash算法改变，所以连接数据库
时可能会出现Client does not support authentication protocol问题。
可以通过一下两种方法解决
其一:
mysql> SET PASSWORD FOR
-> 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
其二:
mysql> UPDATE mysql.user SET Password = OLD_PASSWORD('newpwd')
-> WHERE Host = 'some_host' AND User = 'some_user';
mysql> FLUSH PRIVILEGES;
OLE DB Method for SQL
<%
set cnn = server.createobject("ADODB.Connection")
cnn.open "PROVIDER=SQLOLEDB;DATA SOURCE=sqlservername;UID=username;PWD=password;DATABASE=databasename "
%>
DSN Less connection for Access
<%
set cnn = server.createobject("ADODB.Connection")
cnn.open "DRIVER={Microsoft Access Driver (*.mdb)};DBQ=c:anydatabase.mdb"
%>
OLE DB Method for Access
<%
set cnn = server.createobject("ADODB.Connection")
cnn.open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA SOURCE=c:anydatabase.mdb"
%>
File DSN Connection Method for Access
<% set cnn = server.createobject("ADODB.Connection")
cnn.open "FILEDSN=AccessDSN"
%>

MySQL非常适合于支持网站内的客户资源管理（customer resource management，CRM）系统。它已经是很多Web网站不可分割的一部分了，而且其价格水平也是无人能敌的。此外在动态网站里，很可能已经存在相当数量的CRM数据有待发掘。
在做一家电话公司SAP实施组管理员的过程中，我逐渐精通了其卓越的CRM工具包。我了解到CRM中大约有90%的工作是系统配置实施和维护，以满足用户不断变化的要求。一名CRM的开发人员必须精通过程和结构的设计。现在就让我们来讨论一下，你在使用MySQL创建一个可升级的高性能CRM系统时所要经历的过程。
为MySQL设计CRM解决方案
CRM数据库很复杂：你的用户表格会链接到你的联系方法表格上，后者又链接到你的地址和机构的表格上，这两个表格又链接到你的事物表格上，而这个事物表格又链接到你的目录表格上，等等。对于某些关系，你需要创建复杂的复合索引。对于其他的关系，你可能只需要简单的索引，或者根本就不需要。你实现里的更新和删除可能会也可能不会被层叠。
这就意味着，你需要极其熟悉MySQL里可用的调整方法。但是在你能够进行调整之前，你就需要设计一个CRM过程，依靠它来利用这些调整方法。
逻辑和数据流
正如你能够在图A里看到的那样，你可以将MyISAM表格作为报告类型数据的源来使用。这非常有用，因为在你只是简单地查询数据库时，ISAM表格将是个闪电般快速的数据源。ISAM的缺点是，表格文件自身可能会崩溃，而对其数据的更新很容易就会导致这样的问题。

图A

要解决ISAM的不稳定性，你可以使用InnoDB表格来添加、更新和删除数据表格里的记录。InnoDB引擎是事务性（transactional），所以如果更新失败，那么数据就会退回到更改之前的状态。InnoDB在参照上更加完整，这样数据的更新就不会违反表格之间的任何关系法则。
上面的图表中所没有反映出来的东西是，你应该随时备份你的数据。在这样的情况下，ISAM表格里所保存的都是贵重的数据。这些表格都是你应该备份的东西。你可以在InnoDB表格里获得同样的数据，但是ISAM的表格更适合于备份过程的查询。
对InnoDB表格的恢复操作也是出于同样的原因——它们更适合于更新（例如参照的完整性、速度、稳定性等等），而且它们将被自动地与任何有待添加／更新的操作进行同步。如果InnoDB表格不幸崩溃了，那么就能够利用ISAM的数据来重建表格，这就是为什么要将这个过程像这样分割的最好原因了。毕竟，冗余就等于安全。