However, there are some optimisation that may be required to perform after the conversion is done. So, you should consider revising the conversion after it is done.
SQL Developer Migration technology supports the following core features when migrating from Microsoft SQL Server:
Automatically converts column data types to appropriate Oracle data types.
Automatically resolves object name conflicts, such as conflicts with Oracle reserved words.
Parses and transforms T-SQL stored procedures, functions, triggers, and views to Oracle PL/SQL.
Provides advanced customization capabilities such as the ability to change data type mappings, delete and rename objects.
Generates reports about the status of the migration.
Generates the DDL scripts for the creation of the destination Oracle database.
Generates scripts for data movement
Displays informational, error, and warning messages about the migration in a progress window.
So, I would suggest that you look out everything in details that is not above-mentionned;
Take a good look to the information details provided by the tool;
Test your stored procedures after they are converted.
If you take a look as what SQL Server doesn't offer in comparison to Oracle, these are points where I would look first. In order to know these differences, follow the 3. Convert SQL Server T-SQL to Oracle PL/SQL (syntax and equivalences) link above.
I would suggest doing it by hand. First, to me, personally, a 100 doesn't sound too bad at all. I'd bet that your development follows patterns - using getutcdate() instead of current_timestamp, etc. This means, there probably are a few very repetitive problems that you and your team will be able to learn from. To me, this will hold the added benefit of teaching you PL/SQL nuances/extensions, which you'll probably need to learn in order to maintain / expand the new system.
In the past I tried to do the opposite, but I'm afraid there's no 100% reliable way. Some features are unique to each RDBMS and can't be replicated by a tool (for example IDENTITY fields in SQL Server vs Sequences in Oracle). Considering that, at the end, I had to review each Stored Procedure to ensure it does what it's supposed to do, I realized it was better to plan a manual port and learn some PL/SQL while doing it.
发布评论
评论（3）
但是，转换完成后可能需要执行一些优化。因此，您应该考虑在完成转换后对其进行修改。
编辑 #1
另一个有趣的工具是：
Spectral Core 的 Full Convert Enterprise
不幸的是没有。我刚刚使用 SSIS 执行了到 SQL Server 的转换。
编辑 #2
似乎有一个直接来自 Oracle 的更合适的工具，我最好相信它。
直接来自 Oracle：从 Microsoft SQL Server 迁移到 Oracle
并且核心特点：
在进度窗口中显示有关迁移的信息、错误和警告消息。
如果你看看 SQL Server 与 Oracle 相比没有提供什么，我会首先考虑这些。要了解这些差异，请遵循
3。将 SQL Server T-SQL 转换为 Oracle PL/SQL（语法和等效项）链接。However, there are some optimisation that may be required to perform after the conversion is done. So, you should consider revising the conversion after it is done.
EDIT #1
Another interesting tool would be:
Spectral Core's Full Convert Enterprise
Unfortunately not. I have just performed conversions to SQL Server using SSIS.
EDIT #2
There seems to be a more appropriate tool directly from Oracle that I would better trust.
Directly from Oracle: Migrating from Microsoft SQL Server to Oracle
And the core features:
Displays informational, error, and warning messages about the migration in a progress window.
If you take a look as what SQL Server doesn't offer in comparison to Oracle, these are points where I would look first. In order to know these differences, follow the
3. Convert SQL Server T-SQL to Oracle PL/SQL (syntax and equivalences)link above.我建议用手做。首先，就我个人而言，100 分听起来并不算太糟糕。我敢打赌，您的开发遵循模式 - 使用 getutcdate() 而不是 current_timestamp 等。这意味着，您和您的团队将能够从中学习一些非常重复的问题。对我来说，这将带来教您 PL/SQL 细微差别/扩展的额外好处，您可能需要学习这些才能维护/扩展新系统。
祝你好运！
I would suggest doing it by hand. First, to me, personally, a 100 doesn't sound too bad at all. I'd bet that your development follows patterns - using getutcdate() instead of current_timestamp, etc. This means, there probably are a few very repetitive problems that you and your team will be able to learn from. To me, this will hold the added benefit of teaching you PL/SQL nuances/extensions, which you'll probably need to learn in order to maintain / expand the new system.
Good luck!
过去我尝试过相反的做法，但恐怕没有100%可靠的方法。某些功能对于每个 RDBMS 都是唯一的，无法通过工具复制（例如 SQL Server 中的 IDENTITY 字段与 Oracle 中的序列）。考虑到最后我必须检查每个存储过程以确保它执行其应做的操作，我意识到最好计划一个手动端口并在执行过程中学习一些 PL/SQL。
In the past I tried to do the opposite, but I'm afraid there's no 100% reliable way. Some features are unique to each RDBMS and can't be replicated by a tool (for example IDENTITY fields in SQL Server vs Sequences in Oracle). Considering that, at the end, I had to review each Stored Procedure to ensure it does what it's supposed to do, I realized it was better to plan a manual port and learn some PL/SQL while doing it.