oracle数据库区分大小写吗？

嗨，这个问题我还真是有点经验。
我自己之前就踩过这个坑。

我记得是在2 02 3 年，我公司在做一个数据库迁移的项目，用到Oracle数据库。
那时候有个同事写了一个创建表的SQL语句，他是这样写的：CREATETABLETableName(idnumber); 表名和字段名都是小写的。

结果运行这个SQL语句时，数据库报错了，说找不到这个表。
我们一开始都纳闷，表名和字段名大小写都没变啊，怎么就不认了？
后来查了资料才发现，Oracle数据库在默认的NLS_COMP参数设置为BINARY时，是区分大小写的。
但是，表名和字段名在创建时如果不加引号，Oracle会自动转换为小写存储。
所以，尽管我们同事写的是大写，但在数据库里其实是小写的。

但是，当你在创建表的时候用了双引号，比如CREATETABLE"TableName"("id"number);，这时候Oracle就会按照你输入的原始大小写来存储，所以表名和字段名就是区分大小写的了。

所以，如果你的SQL语句中涉及到表名或字段名有双引号，那你一定要确保大小写正确，否则就可能出现我们当时遇到的问题。
反正你看着办，遇到类似的麻烦，记得先检查一下大小写和引号的使用。
我还在想这个问题，下次遇到类似的场景，希望能记得更牢。

oracle数据库一张表能存多少数据

哎哟，跟你说个事儿，前年我在上海碰到个客户，Oracle表空间快撑不住了，我就给他们整了个优化方案。
这理论最大容量啊，块表空间确实差不多8 TB，行表空间能到2 8 1 TB，听着挺吓人，但实际用起来可没这么简单。

块表空间那块儿，3 2 KB一块，理论8 TB。
我碰过一次，有个小厂，服务器就普通配置，结果表做大了，跑个查询卡半天，后来一查，块小了，I/O次数多。
换大块吧，1 6 KB一块，行表空间理论2 8 1 TB，但实际也未必到。
有个客户做金融，数据量一上来，1 6 KB块反而成了瓶颈，因为某些字段特别长，一行占8 KB都算小的。

行大小这块儿最坑人。
有个项目，客户表设计不合理，好多长文本，结果一行占了几KB，数据块1 6 KB，结果一个块里放不了几行，性能就下来了。
我给他们改了，把长文本弄成外键关联，表结构清爽多了，查询快了一大截。

空闲块空间也挺重要。
有个客户刚上系统，表空间全搞满了，结果一查，还有不少空闲块。
后来我教他们用DBA_FREE_SPACE看，根据数据增长速度调整，现在用得挺好。
不过有个小公司，一开始预留太多空闲块，结果空间利用率不到5 0%，老板还骂我，说浪费钱。

实际限制因素里，操作系统限制最常见。
有个客户用Linux， ext4 文件系统，结果表做到1 5 TB，系统就崩了，喊都喊不应。
还有存储资源，有个项目，服务器配置还行，但存储网络带宽太窄，数据一多，拷贝都卡，最后加钱买了高速存储才搞定。

优化建议里，分区表最管用。
有个电信客户，电话号码簿那表，做了分区，按月分区，查询快多了。
归档压缩也行，有个零售客户，搞了个OLTP压缩，结果存储省了一半，老板挺高兴。
不过压缩这块儿，得看业务场景，有个物流客户试了压缩，结果解压缩时CPU飙得不行，最后又解压了。

总的来说啊，理论容量就是个参考，实际用起来，得结合客户具体情况。
别光盯着理论值，还得看操作系统、硬件、业务需求，综合评估。
我这十年踩过的坑，就是光看理论，没结合实际，结果客户系统卡得不行，最后花了更多钱去改。

LINUX环境下如何设置Oracle数据库最大堆栈大小

上周试过这事儿。
在Linux装Oracle。

方法一临时改。
先看现在大小。
用root用户。
敲ulimit -s。
看多少KB。

然后设大点儿。
比如ulimit -s 1 02 4 00。
这个1 02 4 00是例子。
具体要查Oracle要求。

装完再检查下。
重启就没了。

方法二也是临时的。
装Oracle前。
新开个终端。
先敲ulimit -s 1 02 4 00。

然后必须在那个终端装Oracle。
装完也重启不管用。

方法三永久改。
用root。
开vi /etc/profile。

加一句 ulimit -s unlimited。
或者加具体数字。

改完保存。
敲source /etc/profile。
马上就生效了。

可以再开个终端看看。
敲ulimit -s。
看是不是设好了。

永久改要注意。
所有用户都会受影响。
系统其他地方可能出问题。
想清楚再说。