你说的修改数据库表数据是指什么呢？
我们提供的服务有：成都网站设计、做网站、微信公众号开发、网站优化、网站认证、台前ssl等。为上千余家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的台前网站制作公司
不过我知道，可以使用sqlplus进行数据库的任何操作，增删改查都可以。
使用安装oracle的用户登录linux，
1. 敲入sqlplus /nolog
加入/nolog是不登陆的意思，也可以直接敲sqlplus，这样会直接提示输入用户名；
2. 敲入conn scott/tiger
提示已连接，那么就可以操作scott用户下的表了。例如inset ,update，delete等等。语法就是sql语法，与操作系统无关。
当然，你可以连接到你想连接的用户进行相关操作。
在Oracle 8i以前的版本里，当数据块被从磁盘送进数据缓冲区的时候，数据块会被自动地放置到最近使用过的数据列表的前部。但是，这种行为从Oracle 8i开始就变了：新数据缓冲区被放置在缓冲区链的中部。在调节数据库的时候，你的目标就是为数据缓冲区分配尽量多的内存，而不会导致数据库服务器在内存里分页。数据缓冲区每小时的命中率一旦低于90%，你就应该为数据块缓冲区增加缓冲区。
数据块的存活时间
在调入数据块之后，Oracle会不停地跟踪数据块的使用计数（touch count，也就是说，这个数据块被用户线程所访问的次数）。如果一个数据块被多次使用，它就被移动到最近使用过的数据列表的最前面，这样就能确保它会在内存里保存一段较长的时间。这种新的中点插入技术会确保最常使用的数据块被保留在最近使用过的数据列表的最前面，因为新的数据块只有在它们被重复使用的时候才会被移动到缓冲区链的最前面。
总而言之，Oracle 8i数据缓冲池的管理要比先前的版本更加有效。通过将新的数据块插入缓冲区的中部，并根据访问活动（频率）调整缓冲区链，每个数据缓冲区就被分割成两个部分：热区（hot section），代表数据缓冲区的最近使用的一半；冷区（cold section），代表数据缓冲区的最早使用的一半。只有那些被反复请求的数据块才会被移进每个缓冲池的热区，这就让每个数据缓冲区在缓冲常用数据块的时候效率更高。
热区的大小要用下面的隐藏参数来配置：
_db_percent_hot_default
_db_percent_hot_keep
_db_percent_hot_recycle
Oracle公司作为官方没有推荐更改这些隐藏参数。只有懂得内部机制和希望调节其数据缓冲区行为的有经验人员才应该使用这些参数。
找到热数据块
Oracle 8i保留着一个X$BH内部查看表，用来显示数据缓冲池的相对性能。X$BH查看表有下列数据列：
Tim：两次使用之间的时间差，和_db_aging_touch_time参数相关。
Tch：使用计数，它和被使用过_db_aging_hot_criteria次之后从冷区移入热区直接相关。
由于Tch数据列用来追踪特定数据块的使用次数，所以你就能够编写一个字典查询来显示缓冲区里的热数据块——使用计数大于10的数据块，就像下面这样：
SELECT
obj object,
dbarfil file#,
dbablk block#,
tch touches
FROM
x$bh
WHERE
tch 10
ORDER BY
tch desc;
这项高级查询技术在用于追踪DEFAULT缓冲池里的对象时尤其有用。一旦定位了热数据块，你就能够把它们从DEFAULT缓冲池移动到KEEP缓冲池。
完全缓冲数据库
从Oracle 8i开始，随着64位寻址的出现，你就能够创建一个完全在数据缓冲区里缓冲的数据库。现今，任何数据库通常只用不到20G的内存就能够被完全缓冲，而更大的数据库仍然需要部分数据缓冲区。
要利用完全数据缓冲的优势，就要记住从内存取回数据块和从磁盘取回数据块的时间差。对磁盘的访问时间是以毫秒或者说千分之一秒来计算的，而内存的速度是以纳秒或者说十亿分之一秒来计算的。因此内存的访问速度要快三个数量级，即通常要比磁盘的访问速度块将近14,000倍。
在完全缓冲Oracle数据库的时候，你需要仔细制定缓冲的规划，并在需要的时候增加db_block_ buffers参数的值。在缓冲整个数据库的时候，多数据缓冲池就不再需要了，所以你可以在DEFAULT数据池里缓冲所有的数据块。
如果要计算已分配数据块的数量，就要用下面的命令：
select
sum(blocks)
from
dba_data_files;
SUM(BLOCKS)
-----------
243260
select
sum(blocks)
from
dba_extents;
SUM(BLOCKS)
-----------
321723
已使用数据块的真实数量要通过查看DBMS_ROWID以获得真实的数据库地址来确定，就像下面这样：
select
sum(blocks)
from
dba_data_files;
随着数据库的扩展，你必须不忘增加参数的值。在数据库的启动阶段，你需要调用一个脚本加载缓冲区，这一步很简单，就像执行select count(*) from xxx;这样的命令，因为数据库里所有表格都会起作用。这就确保所有的数据块都被缓冲，从而大幅提高读取操作的性能。但是，写操作仍然会需要磁盘I/O。由于内存条的价格在持续下跌，现在只需要较小的或者不需要硬件投资就能够通过完全缓冲一个较小的数据库从而显著地提高性能。
以下是介绍如何修改一个Oracle存储过程的实际操作步骤，如果你要执行Oracle存储过程，首先你需要写出一个关于输出的字符串“Hello World!”的存储过程，以下的相关内容就是接这讲述Oracle存储的步骤。
让我们写一个输出字符串“Hello World!”的存储过程，用Notepad打开你的skeleton.sql 文件，. 用DBMS_OUTPUT.PUT_LINE 过程调用去替换NULL语句，如下所示:
CREATE OR REPLACE PROCEDURE skeleton
IS
BEGIN
DBMS_OUTPUT.PUT_LINE('Hello World!');
END;
保存到文件skeleton.sql.
从SQL*Plus命令行, 打开文件skeleton.sql .
SQL @skeleton
SQL
CREATE OR REPLACE PROCEDURE skeleton
IS
BEGIN
DBMS_OUTPUT.PUT_LINE('Hello World!');
* END;
SQL /
SQL*Plus 通知你存储过程成功创建并输出提示信息：Procedure created.
SQL
用EXECUTE 命令运行你的存储过程:
SQL EXECUTE skeleton;
SQL*Plus显示存储过程运行成功：
PL/SQL procedure successfully completed.
我们想要的输出字符串 "Hello World!"没有出来，在显示一个DBMS_OUTPUT.PUT_LINE 结果前需要运行一个SET命令，在SQL*Plus 命令行提示符,键入：
SQL SET SERVEROUTPUT ON
再次执行你的存储过程：
SQL EXECUTE skeleton;
现在结果输出了：
Hello World!
PL/SQL procedure successfully completed.
当调试一个存储过程时，遵循一样的步骤，修改SQL文件，创建存储过程，执行存储过程，根据编译器反馈的出错信息进行修改，这一步是非常繁琐的，需要依靠经验。
在实际的商用存储过程的开发调试过程中，由于涉及很多表、类型、光标、循环、条件等复杂的逻辑，和PL/SQL语句的灵活运用，编译时会产生很多错误提示信息，程序员在根据这些错误信息定位，进行修正，再编译最后得到正确的结构;
放弃一个Oracle存储过程
如果在数据库中你不在需要一个存储过程你可以删除它，SQL语句 DROP PROCEDURE 完成从数据库中删除一个存储过程，DROP PROCEDURE 在SQL中被归类为数据定义语言(DDL) 类操作，其他的例子有CREATE, ALTER, RENAME 和TRUNCATE。.
在SQL*Plus 命令提示符下，使用DROP PROCEDURE SQL 语句删除你的叫做skeleton的存储过程：
SQL DROP PROCEDURE skeleton;
SQL*Plus assures us the procedure has been removed:
Procedure dropped.
本文详细讨论了如何使用Oracle工具开发Oracle存储过程的步骤。最后在存储过程的使用中可能是程序直接调用，也可能被触发器调用。
希望我的回答能对您有所帮助！！！
工作流
系统关于工作流的设置工作包含两部分工作，一是基于企业的特殊需要，使用Workflow Builder软件包工具自定义工作流。详情需参考ORACLE的相关文档，这里不赘述。二是为系统设置工作流管理员。系统在安装后的初始化工作流管理员是系统超级用户SYSADMIN，企业应当首先使用SYSADMIN进入系统，将工作流管理员改为一个真实的用户，或者输入“*”，则所有用户都“可以”具有工作流管理员权限（用户实际是否有工作流管理权限还必须取决于其被赋予的“责任”或“菜单”功能），如下图48所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
实际具有工作流管理权限的用户在进入工作流管理“开发员工作室”TAB页后，可以查询出系统所有的“工作流类型”，可选择其一作具体设置，如下图49所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
上图中，工作流管理员选定具体需设置的工作流后，点击“运行”则可以打开该工作流的“属性”设置界面（具体有哪些属性可设置，不同工作流各不相同），如下图50所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
工作流管理员在工作流管理“状态监控程序”TAB页，可以监控选定工作流的具体运行情况的若干条目列表，针对每一个条目，可以查看其“活动历史记录、状态图、参与者回应、详细资料”等若干信息（必要时工作流管理员可实施干预，如更新属性、倒退、暂停、取消等等）。如下图51所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
系统在各应用模块基于业务处理功能，预置有若干不同工作流，有关详情容以后结合具体业务模块应用再来讨论。以下重点介绍一个比较特殊的工作流：在多个业务模块中均需使用且系统实施必须事先完善设置的“账户生成器流程”。
传统的手工业务模式下，所有可能涉及会计记账处理的业务处理例如物料接收、发出等等，作为业务处理人员在日常工作过程中是不需要考虑如何记账的，只是需要将有关业务处理记录例如入库单、出库单等作为原始凭证提交给会计人员去做处理。会计人员依据这些原始凭证制作“记账凭证”并手工为之指定“会计科目”或“账户代码”，以便正确地向总账GL实施“过账”。
手工业务模式或会计电算化模式下，由于作为原始凭证的业务单据不包含准确的记账信息（会计科目或账户代码），需要会计人员手工去做处理，这在业务量很大，记账科目数量设置较多的情况下，会计人员的工作负担将十分繁重。再考虑人工处理难免有疏漏，可能需要反复“对账”，每月月底必须及时结账关账、时间紧迫等等因素，故非人工的、高度准确的“会计分录（日记账）”自动生成功能（即所谓“自动会计”）是系统设计时必须考虑解决的重要问题。
在EBS系统中，账户代码被扩展为一个包含多个段组合的会计科目弹性域结构，系统在业务流程类表单例如采购订单、发票等做业务处理时，依赖所谓“账户生成器流程”根据业务处理的自身属性，自动生成准确的帐户代码组合并记录于业务表单的相关字段中，如下图52所示采购申请界面每个申请行（分配）所对应的“会计账户”（弹性域结构）：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
系统周期或人工启动向总账GL的“过账”流程，对符合条件的“事务处理”成批生成会计分录（日记账，是否还需复核审批视乎企业规定），一般来说无需再做繁琐的“对账”工作。这就大大减轻了会计人员的工作负担，记账科目数量的多少一般也不再成为障碍。（手工或电算化模式下，会计人员往往不愿意设置某些过渡性的“中间科目”，例如物料接收的“应计负债”等等，这对于会计工作的准确性有不小的影响）
ORACLE系统基于每个新定义的分类帐（帐套）自动生成所需的“账户生成器”，系统预置有14个账户生成器（工作流类型），对于每个“账户生成器”可以根据需要设置不同的“流程”（每个工作流类型有其LOV值，还可以使用Workflow Builder自定义添加），如下图53所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
“账户生成器流程”是基于“会计科目弹性域结构”来设置的，弹性域结构不同，流程设置可以不同。对于每个“账户生成器”，ORACLE都提供了默认的流程供使用。R11的账户生成器生成的账户代码被直接用之于向总账GL传送，而R12由于存在“多账簿”的不同“会计方法”因素，各子分类帐产品（业务模块）基于事务处理会计科目弹性域结构通过账户生成器而生成的帐户代码，在向总账GL传送时，还需结合“会计方法”中的“账户推导规则”等设置，才能在总账GL生成正确的会计分录（日记账）。
八、系统初始化设置
（一）关于安全性。
一个全新安装的EBSR12系统（Fresh Database），以SYSADMIN用户名登录，密码为sysadmin（注意EBS密码区分大小写），Home Page 可见系统所初始预置的10多个“责任”中包含“系统管理员”（System Administrator），如下图54所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
进入系统的GUI界面后，在“用户”定义界面，可查询到有30多个初始化的User，比较特殊与重要的User 是两个“SYSADMIN、GUEST”，GUEST无密码设置，可以作为测试时的特殊用户使用。如下图55所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
其中有些User是系统残留，并不可用，还有些是只有用户名，但并未为之分配责任。注意，上图初始的GUI界面默认配色方案，为演示方便已通过配置文件“Java color scheme”做调整。
系统初始预置的“责任”有1500多个，范围涉及所有模块的几乎所有“岗位角色”，企业可基于自身的管理习惯制定相应的责任“命名规则”，以定义新的“责任”。如下图56所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
系统初始预置的“菜单”有12000多个，基本上覆盖了几乎所有可能应用的需要，如企业需要“个性化”的菜单显示效果（prompt），则可以自定义用户菜单，形成特定的菜单结构。如下图57所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
本文为测试需要，在系统中建立用户名MFG，并将常用模块的超级用户责任均与之关联。为测试方便，建一包含所有常用超级用户菜单的总菜单，并以此建一超级总责任，也与用户MFG关联。
（二）关于配置文件
系统配置文件总数有6600多个，绝大多数有初始化的默认值，可以有需要时再来修改，有关系统配置文件的设置情况（初始化时尤其可能希望了解），可以使用工具栏“File—Export”将它们全部导出，以方便的格式如EXCEL集中查看，如下图58所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
有些必须设置且没有默认值的配置文件，例如“GL Ledger Name ”、“MO：Operating Unit”等，由于其LOV取决于系统的其它具体设置如分类账（帐套）、业务实体OU等，故这些特殊的配置文件初始进入时会报错，如下图59所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
这些少数的特殊配置文件是系统初始化参数配置是的重点与难点，在完成相关会计科目弹性域结构、分类账、组织架构等等设置后，应及时为这些特殊“配置文件”赋值。
（三）值集与弹性域
EBS系统初始预置有16000多个值集名（Value Set Name，包括近2000个“验证”类型为“无”、无需LOV的特殊值集名），基本上都属于系统各表单所使用LOV的值集，有着特定的用途，这些值集也可以根据需要修改添加新的条目行。如下图60所示。而对于系统键弹性域与说明性弹性域所使用到的值集，则需要根据企业具体情况，进行完善的定义设置（尤其是38个键弹性域所需使用的值集）。
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
关于键弹性域的设置，除了使用范围广泛的Item类别弹性域（Item Categories），系统已经预置有20个不同结构表示其在不同场合的多个应用之外（还可根据需要添加结构，系统预置的结构也可以进行更改，如下图61所示：）
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
其它键弹性域如“会计科目弹性域”基本只有一个结构名称范例，并无具体的结构设置，需要企业根据自己的情况来完成设置。所有的说明性弹性域均无预置结构，均需根据需要从值集开始设置。
弹性域结构的段也可以不选择值集而留空，则此时，此段就好象使用了这样一个值集：验证类型为“无”，格式类型为“字符”，宽度与基础键弹性域段列相同（即与弹性域系统设计所允许的段最大字符长度相同），允许混合大小写字母字符，无右对齐或填零。对于基础列不是“字符”列的任何段，则必须使用值集，否则将不能够编译弹性域。但需注意，“会计科目弹性域”必需使用值集。
已经定义并编译好的弹性域结构（键或说明性），在使用时均会打开弹出式窗口，以便逐段输入数据。但这样输入对于一些常用到的“代码组合”，既不方便记忆，也不方便输入，为此，ORACLE为定义的每一弹性域结构的代码组合提供了“别名”（Aliases）定义的功能。例如，实际工作使用得比较多的“账户代码”的“账户别名”就是一个典型。其它弹性域结构是否需要使用“别名”，取决于实际业务需要。
（四）分类账（帐套）与组织架构
这是系统初始化设置最复杂的工作。R12较之R11，由于引入了“会计方法”的新维度，在设置方法与顺序方面有较大的变化，其过程也更为复杂。R12的法人实体LE的设置与R11相比也有很大变化，只能在“会计科目管理器”中设置，原在GUI组织设置界面的LE设置的值不再有效（即使设定也无法分配给分类账）。有关多组织、多账簿的接入功能还需与“安全性配置文件（Security Profile）、数据访问权限集（Data Access Set）”的定义，配置文件“BG：安全配置文件、MO：安全配置文件、GL：数据访问权限集”等等参数的设置进行协调配合，包括运行“转换为多组织体系结构（仅R11，在AD Utility 工具中执行；R12安装已经是多组织结构）”以及为新添OU“复制系统初始数据”（在“系统管理员”责任下，运行“Replicate Seed Data”请求）公用程序等等。有关详情，限于篇幅，这里不再赘述。
（五）单据编号
新安装的EBS系统初始并未定义单据编号发生器，需要全新定义，如下图62所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
需要指出的是，这里的“单据编号”仅是“系统内部”使用的标识，都是不包含任何业务管理信息的数字代码。某些特殊单据如采购申请、采购订单以及供应商等虽具有自己专门的编号管理机制，其所生成的也是不包含业务信息的数字代码。这些数字代码和实际业务管理中所需使用到的“业务标识”可能有一定区别，例如对于采购订单、供应商，基于管理的某些特殊需要，除了系统自动生成（或手工输入）的单据代码标识外，可能还需使用单据头的“说明性弹性域”生成包含“采购员代码、业务类别代码、行业代码、地域代码”等等管理信息的“业务标识”（可能需要打印在纸面单据上），以方便相关业务信息的统计分析工作。
系统初始预置有若干数量的“单据类别（Document Categories）”（属于GL/AP/AR），每个单据类别对应数据库中的某个表（Table）。可以根据需要为相关业务模块如INV/PO/OM等等的某些表（Table，是否允许取决于Table本身的设计）添加“单据类别”，以便对表中的相关字段应用编号机制。未来在完成系统设置过程中，还会基于某些表单的业务类别设置（例如销售订单类别等）自动生成新的单据类别。如下图63所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
单据类别与单据编号发生器的关联分配是基于分类账（帐套）的，故在每次新定义分类账或帐套后，均需完成有关的单据编号“分配”工作。
（六）层次性设置结构
不涉及具体应用模块或具全局性、属于EBS系统层面的初始化设置，还包括工作流、预警、文件夹、配置文件定义、查找代码定义、消息定义、地区维护、打印机等等一系列内容，限于篇幅，这里不再赘述。下图64所示表达了EBS（R11）全系统公共层面的基础设置内容与层次结构： Common Applications Process Hierarchy
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
EBS核心系统习惯上可以划分为四大分支系统：财务、制造、分销、人力资源。每一大分支系统也有相关的公用层面设置，如下图65所示是EBS（R11）公共“分销系统”的基础设置内容与层次结构（公共财务、制造、人力资源的相关层次结构比较简单，故略）：
Common Distribution Process Hierarchy
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
而涉及具体应用模块的系统初始设置，情况就更为复杂，通常需要按照应用模块的设置流程图，结合全系统与分支系统的设置情况来决定具体如何执行。如下图66所示是EBS（R11）采购系统的设置步骤：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
对应上述设置步骤的是下述列表清单。流程图和设置步骤清单概括了各设置步骤，其中一些步骤是必需的，而另外一些步骤则是可选的。“具有默认值的必需步骤”是指在数据库中预植了默认值的设置功能。但是，通常需要复查一下这些默认值，以决定是否要对其进行更改。其中有些步骤在“系统”或“分支系统”层如果已经设置，则在应用模块层就无需再执行这些设置步骤。
步骤
必需
步骤
AIW 参考
1
必需
设置系统管理员
Common Applications
2
必需
定义会计键弹性域
Common Applications
3
必需
设置日历、币种和帐套
Common Applications
4
必需
定义人力资源键弹性域
Common Applications
5
必需
定义地点
Common Applications
6
必需
定义组织和组织关系
Common Applications
7
可选
转换为多组织体系结构
Common Applications
8
必需
定义库存键弹性域
Common Applications
9
必需
定义单位
Common Applications
10
可选
定义承运人
Common Applications
11
具有默认值的必需步骤
定义物料属性、代码和模板
Common Applications
12
必需
定义类别
Common Applications
13
可选
定义目录组
Common Applications
14
必需
设置人事
Common Applications
15
必需
设置 Oracle Workflow
Common Applications
16
必需
决定如何使用帐户生成器
Oracle Purchasing
17
必需
打开库存和采购会计期
Common Distribution
18
可选
定义子库存地点
Common Distribution
19
可选
定义交叉引用类型
Oracle Purchasing
20
可选
定义税码
Common Financial
21
可选
定义付款条件
Common Financial
22
必需
设置审批信息
Oracle Purchasing
23
具有默认值的必需步骤
定义查找和分类
Oracle Purchasing
24
可选
定义标准附件
Oracle Purchasing
25
必需
定义采购选项
Oracle Purchasing
26
必需
定义采购员
Oracle Purchasing
27
可选
定义物料
Oracle Purchasing
28
具有默认值的必需步骤
定义行类型
Oracle Purchasing
29
必需
启动采购数据库管理程序
Oracle Purchasing
30
必需
定义财务选项
Common Financial
31
可选
定义事务处理原因
Oracle Purchasing
32
必需
定义接收选项
Oracle Purchasing
33
必需
设置事务处理管理器和重新提交时间间隔
Oracle Purchasing
34
必需
定义供应商
Common Financial
35
具有默认值的必需步骤
设置工作流选项
Oracle Purchasing
36
必需
提交工作流相关流程
Oracle Purchasing
37
可选
定义说明性弹性域
Common Applications
38
可选
设置自动来源补充
Oracle Purchasing
39
必需
执行附加的系统管理员设置
Common Applications
40
必需
定义制造系统和用户配置文件
Oracle Purchasing
如果要实施多个 Oracle Applications 模块产品，ORACLE建议使用 Oracle Applications 实施向导 (AIW，Oracle Applications Implementation Wizard User's Guide) 来协调设置活动。该“向导”将指导用户完成对已安装应用产品的设置步骤，给出满足交叉产品相关性要求的逻辑实施顺序并免去多余的设置步骤。用户可以使用“向导”来查看以图形表示的设置步骤概览、查阅设置活动的联机帮助和打开相应的设置窗口。通过使用“向导”来为每个步骤记录备注信息，还可以记录实施情况以供日后参考和复查。
这个和数据库安装的时候选择的时区有关，一般国内安装都是选择北京时区。
查看timestamp
select current_timestamp,systimestamp from dual;
current_timestamp systimestamp
12-12月-18 04.24.02.427990 下午 +08:00 12-12月-18 04.24.02.427980 下午 +08:00
查看时区
select dbtimezone,sessiontimezone from dual;
dbtimezone sessiontimezone
+00:00 +08:00
对于显示是12小时制这个问题，和客户端的操作系统有关，与实际存储的数据无关。
如果想显示成24小时制，修改客户端操作系统的环境变量可以达到目的：
NLS_TIMESTAMP_FORMAT
YYYY-MM-DD HH24:MI:SS:FF6
按照上图设置后，重启plsql，查询后我们能看到时间显示成“2018-12-12 16:16:35:877000”这样的格式了。
但是，如果建库时，时间设置错误或者是将来要改变时区时，表中的值会不会变化呢？因此引用官方的回答：
对于time zone数据类型的数据，即使你更新了数据库时区，原数据也不会进行对应调整，只能你导出数据，然后调整数据库时区，再把原始数据导入即可。所以，一般情况下，一定不要调整数据库时区。官方建议数据库时间采用UTC，因为这种时区性能好。如果没有显式指定数据库时区，数据库会使用操作系统的时区，但是如果操作系统时区不是一个合理的数据库时区，数据库则会使用默认的时区UTC，且UTC的取值范围为-12:00 to +14:00。等等，为什么会有+14？百度一下基里巴斯。这是一个神奇的网站国度。
